Re: [PATCH]

["Theodore Ts'o" <tytso@mit.edu>]

On Mon, Aug 09, 2004 at 02:49:51PM -0400, Jean-Luc Cooke wrote:
> The only parts we're proposing to replace are:
>  - TCP sequence number generation (AES in CTR mode truncated to 32 bits, has
>    period of 2^32 and cannot be easily determined from pervious sequences)
>    I will read your reference and learn from the implementation in random.c

Nope, that's not sufficient.  There's a reason why we're doing what
we're doing in random.c.  To quote from RFC 1948:

   The choice of initial sequence numbers for a connection is not
   random.  Rather, it must be chosen so as to minimize the probability
   of old stale packets being accepted by new incarnations of the same
   connection [6, Appendix A].  Furthermore, implementations of TCP
   derived from 4.2BSD contain special code to deal with such
   reincarnations when the server end of the original connection is
   still in TIMEWAIT state [7, pp. 945].  Accordingly, SIMPLE
   RANDOMIZATION, AS SUGGESTED IN [8], WILL NOT WORK WELL.

The F() as defined in RFC 1948, needs to be a crypto hash.  But it
doesn't need to be a particularly strong hash.  If it takes longer for
the attacker to break the hash than our rekey interval, that's
sufficient, since what we're protecting any kind of secrecy of the
data; we just need to prevent the attacker from guessing the initial
sequence number just long enough so that he can't hijack a TCP
connection.  Hence the use of a cut-down MD4.  It's kludgy, yeah, and
it smells of roll-your-own-crypto, granted, but I emphasize again that
(a) this was never considered very high protection; if you really care
about protecting against these sorts of attacks, you will be using
application-level crypto (i.e., ssh'ing to a Cisco box instead of
using an unencrypted telnet connection), and (b) using real crypto is
too slow, and was affecting Linux in various network benchmarks.
That's why it was changed from the original MD5 as suggested by
Bellovin in RFC 1948, to a cut-down MD4.  

And we ***never*** were insane enough to use SHA, or suggest that the
use of SHA was a good idea in this particular application.  I don't
know why some people had the assumption that SHA was ever used in TCP
sequence number generation, but they were wrong; that was never the
case.

						- Ted