In message <200311170406.01354.abuse@spamalicious.com>",
Charles M. Hannum" writes:

The bottom line is: doing a really robust, scalable, safe randomized
IP-id implementation is more than I have time for right now.  The
patches I posted remediate the immediate problem. They also make it
simpler to either remove the existing random-id code, or replace it
with something "better" in future.  So unless someone offers a good
reason not to, I propose to commit the patch I posted within the next
day or so; plus any further feedback.


>No more complex than the routing table or the state that T/TCP keeps on a 
>couple of systems.

It really *is* more complex.

Compared to the routing table, you care about both local and remote
addresses, and about *per-IP-address* state not per subnet (or per
route state). You can try and do otherwise, but if you get a routing
change which merges two routing-table leaves which used to be
separate, Bad Things happen to the ip-id space for the merged node.

Multiply the complexity by the number of local IP addresses, which
for some NetBSD systems could be in the hundreds to thousands
(do I have that right?)

And T/TCP relies on a 32-bit TCP sequence number and the "fact" that
TCPs are supposed not to reuse sequence numbers within the 2*MSL `grey
area' (From memory; for a more detailed exposition, see any TCP or network
textbook that talks about crash recovery and the `forbidden zone').

Using a cache of `recently seen IP addresses' and per-IP-address
``next id'' has the flaw that a DoS, or suitably disperse IP-address
reference patterns (webcrawler) will blow away the cache. If one of
those blown-away addresses comes back, you have to pick a new IP id.
But you no longer know the last-used id sent to that IP address, so
any guess *might* be Really Bad.

Unless we're talking toy-systems that can, for example, refuse to
emit IP packets for 2*MSL after a route change, in which case yes,
it is pretty simple :-/.