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: <20140110.173857.1280113609417951585.davem@davemloft.net>
Date:	Fri, 10 Jan 2014 17:38:57 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	christoph.paasch@...ouvain.be
Cc:	netdev@...r.kernel.org, eric.dumazet@...il.com, ycheng@...gle.com,
	ja@....bg
Subject: Re: [PATCH net-next v2 0/5] Make tcp-metrics source-address aware

From: Christoph Paasch <christoph.paasch@...ouvain.be>
Date: Wed,  8 Jan 2014 16:05:54 +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):
> 
> For example, a host contacting a server over WiFi will store the tcp-metrics
> per destination IP. If then the host contacts the same server over 3G, the
> same tcp-metrics will be used, although the path-characteristics are completly
> different (e.g., the ssthresh is probably not the same).
> 
> In case of TFO this is not a problem, as the server will provide us a new cookie
> once he saw our SYN+DATA with an incorrect cookie.
> It may be (in case of carrier-grade NAT), that we keep the same public IP but
> have a different private IP. Thus, we better reuse the old cookie even if our
> source-IP has changed. However, this scenario is probably very uncommon, as 
> carriers try to provide the same src-IP to the clients behind their CGN.
> 
> Patches 1 + 2 add the source-IP to the tcp metrics.
> 
> Patches 3 to 5 modify the netlink-api to support the source-IP. From now on,
> when using the command "ip tcp_metrics delete address ADDRESS" all entries
> which match this destination IP will be deleted.
> 
> Today's iproute2 will complain when doing "ip tcp_metrics flush PREFIX" if
> several entries are present for the same destination-IP but with different
> source-IPs:
> 
> root@...ent:~/test# ip tcp_metrics
> 10.2.1.2 age 3.640sec rtt 16250us rttvar 15000us cwnd 10
> 10.2.1.2 age 4.030sec rtt 18750us rttvar 15000us cwnd 10
> root@...ent:~/test# ip tcp_metrics flush 10.2.1.2/16
> Failed to send flush request
> : No such process
> 
> 
> Follow-up patches will modify iproute2 to handle this correctly and allow
> specifying the source-IP in the get/del commands.
> 
> 
> v2: Added the patch that allows to selectively get/del of tcp-metrics based
>     on src-IP and moved the patch that adds the new netlink attribute before
>     the other patches.

Looks good, series applied, thanks Christoph.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ