On Fri, Sep 12, 2003 at 07:24:50AM +0900, Jun-ichiro itojun Hagino wrote:
>
> > 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?

I think what you're missing is that many other developers feel that it's
a poor technical decision to get into an "arms race" patching up the
system to frustrate script kiddies using first one toolkit, then the next,
then the next, then the next -- when we _know_ full well that many of the
changes in question don't actually eliminate the underlying protocol
vulnerabilities; they just require the attacker to write a little bit more
code to exploit them.  The potential benefit of sidestepping _this_
generation of attack _examples_ -- not attacks, just the set-piece
examples thereof that 8th-grade schoolkids may amuse themselves by
downloading from the net -- doesn't seem, to many of us, worth the high
cost in CPU time and system complexity.  The point is not to be able
to brag about being 53|<Ur -- the point is to actually have a system
that _is_ demonstrably secure when it claims to be, but reasonably clean
and performant in situations in which the kind of security in question is
not wanted or needed (e.g. on private high-speed networks such as compute
cluster interconnects, where random ip_id does nothing but eat CPU cycles).

Another issue is the quality of the implementations being imported from
elsewhere.  Almost every piece of this code, right back to the original
arc4random() implementation, has had performance issues, and some of it
has had security issues as well.  This can't help but lead people to
look at the next in this series of security-related changes more skepically
than the last, no?