netdev - Re: [PATCH 0/4] Make tcp-metrics source-address aware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20131215.204527.2114963340287148861.davem@davemloft.net>
Date:	Sun, 15 Dec 2013 20:45:27 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	christoph.paasch@...ouvain.be
Cc:	netdev@...r.kernel.org, eric.dumazet@...il.com, ja@....bg
Subject: Re: [PATCH 0/4] Make tcp-metrics source-address aware

From: Christoph Paasch <christoph.paasch@...ouvain.be>
Date: Sun, 15 Dec 2013 13:10:40 +0100

> Currently tcp-metrics only stores per-destination addresses. This brings
> problems, when a host has multiple interfaces (e.g., a smartphone having
> WiFi/3G):

So, at what point will we stop adding keys to tcp-metrics?

Several things can influence the network path, 'saddr' is just an
arbitrary and obvious one.

Even the TCP port numbers, via IPSEC rules, can make the packets go
over a completely different route with wildly different
characteristics, resulting in the same exact problem you say we need
to add 'saddr' for.

I'm not against adding 'saddr' to the metrics key, I just want to
know decide now (rather than later) far we need to go and implement
that fully rather than inching along one step at a time to the
same final result.

If the answer is "yes we must consider all potential keys" then we
will essentially have something approximating a single tcp-metrics
entry for every unique TCP connection ever openned because the source
and destination ports will be taken into account.

We won't be sharing metrics information at all at that point, so we
might as well remove it.

Arguably, when the metrics were in the routes, these details we hidden
away from us and we used fine grained metrics information when it
actually mattered.  If there were no IPSEC rules being used, we
wouldn't use keys detailed down to the port numbers.

However the routing cache always, at the very least, got us metrics
which were fine grained down to saddr/daddr/TOS/MARK etc.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html