On Fri, 12 Sep 2003, Jun-ichiro itojun Hagino wrote:

> > [nessus]
> > Itujun, that's really reaching. I'm looking for a responsive,
> > well-reasoned, technical argument to support making randomized IDs the
> > default. If this is the best you can offer, you're not helping your case.
>
> 	http://www.insecure.org/nmap/idlescan.html
>
> 	i don't understand why you don't know about this very commonly-known
> 	issue, and i don't understand why do i have to prove it is a problem
> 	to make it into netbsd tree.  i can't leave netbsd in an insecure
> 	state (predictable ip_id).  my mission as a developer is to make it
> 	better protected against potential attacks.  is it enough?

If you want a truly secure computer, cut all the network connections. As
long as you're on a network, you are open to network-based attachs.

To do anything less, say adding a network card and getting an IP address,
opens you up to attacks. As everyone on this list has done so, we must
have decided that the benefits out weigh the costs; we get something out
of being net-conencted that is worth more than the cost of worrying about
attacks. There are things more important than pure security.

We have made a cost-benefit assessment, and chosen.

The bigest concern I have with all of these recent randomness threads,
Itojun, is that you don't seem to be assessing the cost side of things
before making the change. You also don't seem to be sensitive to the fact
the costs may be different for others.

For a lightly-loaded multi-GHz P-something i386, these changes look rather
cheep. However if you either lower the CPU ability (say run it in the Mac
IIci I have) or up the workload (try to keep GigE saturated out of an
XScale or be something like cnn.com), these things become VERY expensive.
Like we said in a past thread, the expense of three pointer de-references
becomes a big deal in these cases. EVERYTHING is expensive.

Especially as the "advisory" for this issue (ip_id) assesses the risk as,
"Low," I don't think this should be the default.

Take care,

Bill