Subject: Re: random ip_id must be configurable
To: None <firstname.lastname@example.org>
From: Thor Lancelot Simon <email@example.com>
Date: 09/12/2003 18:43:53
On Sat, Sep 13, 2003 at 07:28:34AM +0900, firstname.lastname@example.org wrote:
> >> note also freebsd and Solaris do randomize ip_id.
> >For those who have poor reading skills, please note that the FreeBSD 4
> >randomized ip_ids are an config-time option, and the option defaults
> >to "off". I think that's a *good* example for us to follow.
> >(Anyone who read the netipsec/ code should have notice that; netipsec/
> >still has support for the FreeBSD 4 option header and ifdef.)
> based on nmap OS fingerprint database, freebsd randomizes ip_id.
> also you see even quite a few embedded products (like small broadband
> router) randomizes ip_id. why we can't do it for netbsd.
I can think of some reasons why perhaps we _should not_:
1) The proposed randomid() function is slow -- slower than it needs
to be, as David pointed out, simply because some of the math is not
done in the most efficient manner.
2) The scope and severity of the "attack" this change works around is
quite significantly limited.
3) The Solaris approach (different ip_id per src, dst tuple) offers
many of the same advantages, while avoiding the expense of the
4) The examples you provide are not tremendously persuasive. A
"home broadband router" that uses a 486 CPU to forward a piddling
5 or 6 Mbit/sec of traffic using a custom-written firmware written
in assembly language is not exactly a device where maximum performance
is a concern -- hell, it could probably impose a 1/10 second latency on
every TCP connection open and most users wouldn't notice. A Foundry
switch/router has a separate control processor that has basically zero
to do with its principal function of switching/routing packets; the
presence of the FreeBSD system in question in the nmap database doesn't
necessarily mean that it does something different, by default, than
what the source code shows it does, and so forth.
5) This change doesn't really make any attack -- except perhaps Steve's
"count hosts behind NAT" method -- impossible; it just makes a few of
them a little bit harder. As I suggested before, I don't think that
getting in an arms race with the skr1p+ writers is really a good thing
to do; what is the point of making the system slower, for everyone, by
default, just to require some attacker to write a few extra lines of
code and iterate his attack program somewhat longer?
I suppose I can see the utility of this code as an option (If ipnat could
randomize outbound ip_id I would probably turn that on on my firewall)
but I think it's much too expensive, for much too little benefit, to make