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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
