Subject: Re: synchronous ip_id
To: Jun-ichiro itojun Hagino <firstname.lastname@example.org>
From: Steven M. Bellovin <email@example.com>
Date: 02/24/2003 10:31:58
In message <20030224000222.E8EFC791@starfruit.itojun.org>, Jun-ichiro itojun Ha
> should we shuffle ip_id like openbsd does? (see PR 11288)
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)