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.