Subject: Re: IP source address security issue
To: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
From: Bill Sommerfeld <firstname.lastname@example.org>
Date: 01/27/1995 09:47:21
> 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
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.