Subject: Re: kernel ip_randomid() and libc randomid(3) still "broken"
To: Jun-ichiro itojun Hagino <itojun@itojun.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-net
Date: 11/26/2003 12:56:02
In message <20031126175928.817288B@coconut.itojun.org>Jun-ichiro itojun Hagino 
writes
>>   | 	so we can either:
>>   | 	- stop skipping random number of ids (n=0)
>>   | 	- reduce numbers on the manpage to 1/3
>>   | 	and then we are happpy.
>> 
>> The problem with all of this is that in order to make it a bit more
>> difficult to suffer from a (fairly unlikely) DoS type attack, you're
>> proposing breaking IP.
>
>	i don't. [...]

But you *are* breaking IP. For purposes of IP reassembly counts, TTL
*IS* still a time-to-live, not a hopcount.

Consider a gigabit pipe filled with NFS-over-UDP traffic, which isnt
at all hard to achieve (merely moderately expensive). With 32kbyte RPC
payloads, that's 32 RPCs per megabyte, or 3,200 RPCs per second.  Even
with per-(src,dst) ip_Id allocation, IDs will wrap about 20 seconds.
This already causes signficant pucker-factor amongst people who think
about the numbers. 

Your scheme means the ip_id can wrap in about 5 seconds over gigabit
Ethernet.  Thats just *not acceptable*.

Then consider that 10Gbit Ethernet is already on the market, and set
to fall in price once 10GbE-CX4 becomes available.