> >        have you experienced the scenario in reality, ever?
> You mean as opposed to *actual* threats to linear IP ids, which
> AFAIK nobody has yet cited in this discussion?

	ok, try this page.  google is so useful.
	http://www.linuxfocus.org/English/March2003/article282.meta.shtml

> (Sorry. that was a low blow, but you really asked for it).

	yes i asked for it.  actually i regretted that i did not write about
	the attack using predictable fragment ID while i was waiting in line
	at the hospital this morning.

> Yes of *course* I have seen it. (are you really that ill-informed
> about IPv4?) Its well-known in certain circles that in Linux circa RH
> 7.3, some NICs will repeatedly lose fragments from outbound NFS write
> RPC before the fragments ever hit the wire. The remaining fragments then
> sit in reassembly buffers for at least their remaining TTL.
> Which is typically around 63 seconds, these days.

	i would say that's broken card which is the culprit, and the thing that
	needs fix is the card, and/or reassembly timer setting, not the
	fragment ID usage.  and wrt reass timer, the value in your example
	(63 seconds) is too big and need fixing.
	(i will bollow your word here, heh) given the widespread usage of GigE
	and 10GE cards, attacker could fill up the kernel memory space by
	sending bogus fragments at wire rate.

> I really don't understand why you are quoting RFC-791's paragraph
> about "time to live" to yourself, nor why you do so without
> attribution. The section relevant to this discussion is
> "Fragmentation" and "An Example Reassembly Procedure", its description
> of how the effetive reassembly timer should be set to no less than the
> TTL in arriving fragments.

	ok, i see RFC791 refers to TTL field in reassembly logic.  thanks for
	pointing it out.  our implementation does not do it however.  see below.

> Followed by a perusal of
> sys/netinet/ip_input.c, particularly how the reassembly code hangs
> onto fragments until their TTL hits zero.

	in NetBSD code (i suspect *BSD code), i see no use of ip_ttl field in
	reassembly code.  in fact, ip_ttl field is accessed only in
	ip_forward().  could you point the line where ip_input.c is
	using ip_ttl for reassembly timer?

> The more we go into this, the more it seems to me that you could
> (genuinely, and with no ill-will) use a lesson or two on IP
> fragmentation and reassembly.  If that is the case, do you *really*
> think you should be making technical decisions which so deeply impact
> IP reassembly?

	i don't think i need a lesson from you.  and i do think i should make
	this discussion, because i think the balance between fragment ID reuse
	and fragment ID prediction attack differently from you.

itojun