Date: Tue, 22 Jun 2010 15:20:27 +0200 From: Andre Oppermann <andre@freebsd.org> To: Fernando Gont <fernando@gont.com.ar> Cc: freebsd-net@freebsd.org Subject: Re: Extended SYN cookies Message-ID: <4C20B89B.4050101@freebsd.org> In-Reply-To: <4C207FD4.2060300@gont.com.ar> References: <4C207FD4.2060300@gont.com.ar>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22.06.2010 11:18, Fernando Gont wrote: > Hi, folks, > > I have a few questions wrt the FreeBSD TCP extended syncookies. I'm > quoting the explanation in the code: > > >> * Timestamp we send: >> * 31|................................|0 >> * DDDDDDDDDDDDDDDDDDDDDDSSSSRRRRA5 >> * D = MD5 Digest (third dword) (only as filler) > > What about the second MD5 dword? -- It doesn't seem to be used anywhere... From looking at the code it indeed isn't used anywhere. I don't remember any specific reason and there probably isn't any. Each dword containing the MD5 output is as good as any other provided it isn't used twice. >> * S = Requested send window scale >> * R = Requested receive window scale > > What's this snd_window rcv_window thing? I mean, why do you need to > include in the cookie the TCP wscale option *you* adverised? Isn't it > expected to be the same in all cases? Most of the time yes. If the application changed the socket buffer size on the accept socket the window may be scaled differently. You are right though, the send window scale stays the same for a given socket. Unless the application changes the socket buffer size while there are outstanding SYN-ACK's around. It's a race condition. Better be on the safe side and include it. It also makes the implementation a tiny bit simpler as we get the information directly from the cookie instead of fetching it from somewhere else. >> * A = SACK allowed >> * 5 = TCP-MD5 enabled (not implemented yet) >> * XORed with MD5 Digest (forth dword) > > Any reason for XOR'ing the timestamp with the MD5 Digest? To prevent direct manipulation of the values we put into the cookie and more importantly to seed/randomize the lower bits of the timestamp. Otherwise they would be very predictable. >> * The timestamp isn't cryptographically secure and doesn't need to be. > > What's the motivator of this comment? MD5 itself (used here) being > cryptographically weak, or what? A (too) short sentence about a couple of things: a) MD5 is rather weak these days and can be broken with reasonable effort. It is fast though. Preventing someone from breaking it for a few minutes is sufficient for SYN cookies to work properly. The secret will be changed every minute or so. b) The values that are XOR'ed in the timestamp are not cryptographically secure. With a little guesswork you may be able to reverse a few bits and gain some information. However this is all TCP session information and you'll know it anyway. It's about making it hard to change the parameters we will use for the new session when the ACK returns. >> * Some problems with SYN cookies remain however: >> * Consider the problem of a recreated (and retransmitted) cookie. If the >> * original SYN was accepted, the connection is established. The second >> * SYN is inflight, and if it arrives with an ISN that falls within the >> * receive window, the connection is killed. > > What do you mean by "recreated", specifically? Duplicated in the network, by accident or malicious. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C20B89B.4050101>