Messages in this thread | | | Date | Mon, 9 Aug 2004 20:22:55 -0400 | From | Theodore Ts'o <> | Subject | Re: [PATCH] |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |