Subject: Re: CVS commit: src/sys/netinet
To: Darren Reed <firstname.lastname@example.org>
From: Steven M. Bellovin <email@example.com>
Date: 09/08/2003 13:50:18
In message <firstname.lastname@example.org>, "Darren Reed" writes:
>From Steven Bellovin:
>> The IPid field shouldn't repeat
>> for somewhat longer than the fragment lifetime on the receiving system.
>Given the speed in which the IP ID field can be recycled, these days, we
>should look at ways that allow the ID number to be reused "safely". On
>systems that are sending out large amounts of traffic, the randomised
>ID field does not add a lot of value at all (consider if you will the
>original premis for this was scanning otherwise "quiet" hosts.)
>As an example of different methods, can we reasonably expect to use one
>sequence set per protocol or even one sequence set per IP address pair ?
>Should we possibly think about a sysctl knob that choses the IPid slection
>algorithm so that it can be tuned for "best fit" ? Picking "random" as the
>default might not be a bad idea to begin with either.
>(0 = sequential, 1 = random, 2 = per proto, 3 = per IP pair...)
>And of course, do the costs outweigh the benefits of other alternatives in
>supporting multiple alternatives for this ?
The spec permits one IPid sequence per <src,dst,protocol> triple,
since those parameters are used in matching fragments. The downside
is implementation complexity; it won't break anything anywhere on
the net. You also don't need to consume IPid space -- or at least,
you don't need to worry about preventing duplicates -- on packets
that have set.
--Steve Bellovin, http://www.research.att.com/~smb