Subject: Re: kernel ip_randomid() and libc randomid(3) still "broken"
To: Jun-ichiro itojun Hagino <itojun@itojun.org>
From: Charles M. Hannum <abuse@spamalicious.com>
List: tech-net
Date: 11/26/2003 21:48:55
On Wednesday 26 November 2003 08:21 pm, Jun-ichiro itojun Hagino wrote:
> > Since the network is allowed to reorder packets, if you send two packets
> > with the same ip_id and network re-orders the fragments so that arrive
> > interspersed, you will end up with dropped packets (due to checksum
> > failure) or worse (checksum didn't fail but corrupted data).  That is
> > unacceptable.
> >
> > The only way to reduce or eliminate this risk to ensure the maximum
> > delay before reusing ip_id's.
>
> 	i can't really parse what you are trying to mean.  even with
> 	ip_randomid() there's guaranteed recycle period, which is about 12000.
> 	yes, the likelihood of the problem like you stated will increase
> 	by factor of (64K/12K), but with that cost we can buy hard-to-guess
> 	fragment ID.

When are you going to wake up to the rather obvious fact that the "guarantee" 
has been thoroughly disproven?  It was clearly shown that *consecutive* calls 
to ip_randomid() can return the same number.

The current implementation is proven to be broken and as such should not exist 
in our source tree at all.  Your sheer arrogance in trying to keep it alive 
despite this is astounding.