In message <20030224000222.E8EFC791@starfruit.itojun.org>, Jun-ichiro itojun Ha
gino writes:
>	should we shuffle ip_id like openbsd does? (see PR 11288)
>
>itojun
>


I've never been impressed by that as a security issue.  The stealth 
scan issue is the only real one, as far as I'm concerned.  Wall clock 
time is a good starting point, because it helps prevent reuse across 
very fast reboots (which might happen in an embedded system).  I'm also 
concerned by the need to avoid reuse in any period shorter than 2^16.  
In fact, for high-end systems, we should really do what Solaris does:  
use a separate counter for each destination, or (better yet, though 
more expensive) for each source-destination pair.  The former scheme 
would also avoid the stealth attack mentioned, since Innocent I -- the 
party whose IPid space is being probed -- would use different sequences 
to talk to the scanner than to the scannee.  I specify "high-end" 
because a busy server can wrap its counter pretty quickly, and that can 
have unfortunate consequences, especially given the DSL-induced smaller 
MTUs we're starting to see.

As I recall, the OpenBSD system rekeys its generator periodically.  
That's a good idea -- it's not hard to build a table of 2^16 entries -- 
but it makes it harder to avoid reuse.  Here's a scheme that handles 
that problem, too (I hope -- this is off the top of my head).  Use a 
PRNG with a cycle of 2^15.  When it wraps, rekey, but invert the 
high-order bit of the 16-bit space.  That bit gets flipped back when 
this key wraps.  In other words, we partition the IPid space, but since 
we're using a 15-bit generator, the high-order bit is acting as the 
IPid space selector in some sense.  We therefore can't have collisions 
any more frequently than 2^15 packets -- not as good as 2^16, but I 
suspect as good as you can do if you want the ability to rekey.

Using src/dst pairs to select a counter (or generator) protects against 
people who try to determine if two IP addresses refer to the same 
machine (see Spring, Mahajan, and Weatherall's "Rocketfuel" paper).

The IPid attack I'm most concerned about is the one I described in my 
paper about counting NATted hosts.  But the latest versions of ipfilter 
have the appropriate defenses.


		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)