On Thu, Nov 27, 2003 at 02:59:28AM +0900, Jun-ichiro itojun Hagino wrote:
> >   | 	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.  you are asserting the old (and probably obsolete) meaning
> 	TTL all the time.  nowadays TTL field really means "hoplimit" (if
> 	there's any device that interprets TTL field as "seconds", please show
> 	me).  so i think your assertion and logic based on TTL = seconds no
> 	longer holds, and the # of packets that can be sent between ID
> 	recycling is no longer a concern.

Actually that is backwards, the fact that the TTL is treated as a hop-count
rather than a time in seconds makes it all the more imperative that you
don't reuse the same ID until you absolutely have to.
The only timer that will discard anything is the fragment reassembly 
timer on the recieving system.  I can't remember the default value, but 10
seconds springs to mind.

Now if the recieving system knew you were using sequential IDs (even
if assigned to multiple src/dest/protocol sets) it could use that fact
to discard IP datagrams with missing fragments before the ID would be
reused by the sending system.  So actually the protocol would work better
if random IDs were disallowed.
(I think NAT breaks the above though :-(

	David

-- 
David Laight: david@l8s.co.uk