netdev - Re: TCP 2MSL on loopback

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]

Date:	Tue, 06 Mar 2007 12:41:00 -0800
From:	Rick Jones <rick.jones2@...com>
To:	Howard Chu <hyc@...as.com>
Cc:	Eric Dumazet <dada1@...mosbay.com>, netdev@...r.kernel.org
Subject: Re: TCP 2MSL on loopback

>> With transparant bridging, nobody knows how long the datagram may be 
>> out there.  Admittedly, the chances of a datagram living for a full 
>> two minutes these days is probably nil, but just being in the same IP 
>> subnet doesn't really mean anything when it comes to physical locality.
> 
> 
> Bridging isn't necessarily a problem though. The 2MSL timeout is 
> designed to prevent problems from delayed packets that got sent through 
> multiple paths. In a bridging setup you don't allow multiple paths, 
> that's what STP is designed to prevent. If you want to configure a 
> network that allows multiple paths, you need to use a router, not a bridge.

Well, there is trunking at the data link layer, and in theory there 
could be an active-standby where the standby took a somewhat different path.

The timeout is also to cover datagrams which just got "stuck" somewhere 
too (IIRC) and may not necessarily require a multiple path situation.

> 
>> SPECweb benchmarking has had to deal with the issue of attempted 
>> TIME_WAIT reuse going back to 1997.  It deals with it by not relying 
>> on the client's configured local/anonymous/ephemeral port number range 
>> and instead making explicit bind() calls in the (more or less) entire 
>> unpriv port range (actually it may just be from 5000 to 65535 but still)
> 
> 
> That still doesn't solve the problem, it only ~doubles the available 
> port range. That means it takes 0.6 seconds to trigger the problem 
> instead of only 0.3 seconds...

True.  Thankfully, the web learned to use persistent connections so 
later versions of SPECweb benchmarking make use of persistent connections.

> In an environment where connections are opened and closed very quickly 
> with only a small amount of data carried per connection, it might make 
> sense to remember the last sequence number used on a port and use that 
> as the floor of the next randomly generated ISN. Monotonically 
> increasing sequence numbers aren't a security risk if there's still a 
> randomly determined gap from one connection to the next. But I don't 
> think it's necessary to consider this at the moment.

I thought that all the "security types" started squawking if the ISN 
wasn't completely random?

I've not tried this, but if a client does want to cycle through 
thousands of connections per second, and if it is the one to initiate 
connection close, would it be sufficient to only use something like:

socket()
bind()
loop:
connect()
request()
response()
shudtown(SHUT_RDWR)
goto loop

ie not call close on the FD so there is still a direct link to the 
connection in TIME_WAIT so one could in theory initiate a new connection 
from TIME_WAIT?  Then in theory the randomness could be _almost_ the 
entire sequence space, less the previous connection's window (IIRC).

rick jones

rick jones
-
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