Extended SYN cookies

[Andre Oppermann]

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