On Sat, Sep 13, 2003 at 07:28:34AM +0900, itojun@iijlab.net wrote:
> >>        note also freebsd and Solaris do randomize ip_id.
> >>http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c.diff?r1=1.188&r2=1.189
> >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
   proposed approach.

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
the default.

Thor