Date: Fri, 4 Sep 1998 15:10:35 -0400 (EDT) From: "Charles M. Hannum" <mycroft@mit.edu> To: Jos Backus <Jos.Backus@nl.origin-it.com> Cc: tcp-impl@cthulu.engr.sgi.com Subject: Re: Should FreeBSD-3.0 ship with RFC 1644 (T/TCP) turned off by default? Message-ID: <199809041910.PAA01261@lunacity.ne.mediaone.net>
next in thread | raw e-mail | index | archive | help
[I'm CCing this back to tcp-impl, because I'm sure that at least one other person has come up with this idea.] > How about using syncookies? > > (See ftp://koobera.math.uic.edu/pub/docs/syncookies-archive for a discussion.) I thought that would have been obvious, especially in light of my comments regarding RFC-1948 in the draft. If you simply stuff a bunch of things through a hash function, the outputs will be randomly spaced around the range, and will therefore break the usage of the TCP sequence number to prevent receiving stale data from an old instance of the connection. This is not acceptable. The `syncookies' thread includes a hack around this, which is to add the IRS, with the assumption that the other side is doing proper spacing. However, this assumes convenient little properties such as the other side always being the same host. Bellovin's RFC instead uses a hash based on everything *except* the time-based ISS to rotate the ISS space into a different position for each possible pair of addresses and ports. This preserves the correct TCP behaviour, while frustrating sequence number attacks by preventing rapid testing of possible ISNs -- because an ISS learned from probing one pair of addresses and ports is not useful in predicting the ISS for another pair, and you can't test a particular pair again until the previous SYN has timed out. BTW, I assume you just mean using a hash such as was suggested in the `syncookies' thread. The rest of the idea is severely broken and will result in massive interoperability problems, as well as killing useful features like window scaling and time stamps, when even a slow `flood' is occuring. Even when not flooding, the algorithm described in Dan's last summary in the thread has the additional flaw that the top 3 bits are not used for wraparound protection, which makes it significantly less robust even on existing networks. (This could probably be solved just by putting the MSS bits at the bottom rather than the top, but I haven't worked out all the implications.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809041910.PAA01261>