> Also take care that the attacker can't do a bunch of ISN probes, deduce
> the random number generator state, and thus predict the values you'll
> add, or again it's as pointless as what we have now.  Perhaps have
> system events such as packet reception or transmission, disk I/O,
> context switches, etc, corrupt the random number generator state
> slightly, so as to ensure it's not predictable even with several dozen
> old values to work from...?

About six months ago, Ted Ts'o wrote a "physical randomness collector"
device driver for linux -- it kept a pool of random bits, mixing in
the low order bits of the high-resolution hardware clock on every
interrupt.  This was primarily intended for user-mode cryptographic
applications (e.g, PGP & kerberos) but could also be used for ISN rate
adjustment.

It should be very simple to port this to NetBSD -- but it's probably
overkill for the current problem.  However, when NetBSD eventually
supports IP-layer security, it would be somewhat more useful.

I should go read that RFC, to see whether using sequencing through a
keyed permutation of [0..2**32-1] would provide "compliance in spirit"
with the spec.  I'm not sure whether the issue is *overlap* of the
sequence numbers, or *exact match*; if the latter, going through the
sequence numbers in a permuted order would work just fine.

					- Bill