Subject: Re: Question on initial sequence numbers

From: Vernon Schryver <[email-masked]>
Date: Mon, 4 Jan 1999 14:43:22 -0700 (MST)

> From: [email-masked]
> To: [email-masked]
> Cc: [email-masked], [email-masked]

> ...
> I have been reading RFCs 793, 1072, 1185, and 1323 expecially ...

] From: [email-masked] (Alan Cox)

]It seems somewhat dangerous and unneccessary. ...

] What most vendors Im aware of do is to compute the sequence space as
]
] 	counter+hash_function(src,dst{, port, port})
] ...

Yes, RFC 1948 should be added to that list of RFC's.  Besides describing
the New Offishal IETF method of generating initial sequence numbers,
RFC 1948 talks about reasons to space them.

There is some distinctly lame Security Checking Software out there that
the suckers--oops--network administrators and purchasers are using that
purports to detect insecure initial sequence numbers.  Its documentation
evidently mentions RFC 1948 and so has made RFC 1948 a check-list item
around the world.  Never mind that according to its vendor, this wonderful
software does not detect some dubious initial sequence numbers, nor that
it's test apparently consists of sending a burst of back-to-back SYN's on
the local LAN, and then looking for constant, non-zero deltas.  If the
bad guy is on your LAN, then worrying that he might guess initial sequences
numbers is as perceptive as worrying about getting fleas by petting a
rabid wolf.

As far as I can see, there would be no problem (other than cost) with what
Microsoft is alledged to be doing if they guarantee that all initial
sequence numbers are "sufficently far apart."   "Smaller" is as good as
"larger", provided the delta is large enough so the probability of
collision is small enough.  Incrementing with a clock is one way to get
"far apart," but there are plenty of other permutations of the natural
order of the most significant ~16 bits that would work just as well. 
Of course, no one with a clue about the problem would bother with a simple
permuation such as an LCRN.  You must assume the bad guy has access to
your source and can get enough samples from any running system to solve
any non-crypto random number generator.  However, if you were willing to
keep enough state and spend enough cycles, you might use a dynamic mapping
of the most significant bits.  You could be to keep cycling your secure
random number generator until it delivers a number sufficiently different
from recent choices.  It's not what I'd do, but maybe Microsoft is
expecting faster computers than those I've written initial sequence number
code for.

Vernon Schryver    [email-masked]

---

From: [email-masked] (Alan Cox)
Date: Mon, 4 Jan 1999 23:51:29 +0000 (GMT)

> permuation such as an LCRN.  You must assume the bad guy has access to

Its not as simple as it first looks because BSD also allowed the shortcut
from timewait for sequence spaces subject to certain range rules. That means
you either have to ignore the shortcuts or for a given src,dst,ports pair
keep incrementing sanely