[tcpm] FYI: Extended TCP syncookies in FreeBSD-current

[Andre Oppermann <[e-mail]>]

I have committed an extended version of TCP syncookies to FreeBSD-current
today.  FreeBSD-current the development version which will become the new
stable FreeBSD 7.0 platform by mid of next year.  This gives plenty of
time to shake out bugs and problems.

The main addition is the use of the RFC1323 timestamp field to store
additional state (send/receive windows, SACK allowed) allowing the full
setup of an syncookie accepted connection.

Read for yourself the comments replicated from the source code.  Any
comments and problem reports of the theory or implementation welcome.

/*
  * The purpose of SYN cookies is to avoid keeping track of all SYN's we
  * receive and to be able to handle SYN floods from bogus source addresses
  * (where we will never receive any reply).  SYN floods try to exhaust all
  * our memory and available slots in the SYN cache table to cause a denial
  * of service to legitimate users of the local host.
  *
  * The idea of SYN cookies is to encode and include all necessary information
  * about the connection setup state within the SYN-ACK we send back and thus
  * to get along without keeping any local state until the ACK to the SYN-ACK
  * arrives (if ever).  Everything we need to know should be available from
  * the information we encoded in the SYN-ACK.
  *
  * More information about the theory behind SYN cookies and its first
  * discussion and specification can be found at:
  *  http://cr.yp.to/syncookies.html    (overview)
  *  http://cr.yp.to/syncookies/archive (gory details)
  *
  * This implementation extends the orginal idea and first implementation
  * of FreeBSD by using not only the initial sequence number field to store
  * information but also the timestamp field if present.  This way we can
  * keep track of the entire state we need to know to recreate the session in
  * its original form.  Almost all TCP speakers implement RFC1323 timestamps
  * these days.  For those that do not we still have to live with the known
  * shortcomings of the ISN only SYN cookies.
  *
  * Cookie layers:
  *
  * Initial sequence number we send:
  * 31|................................|0
  *    DDDDDDDDDDDDDDDDDDDDDDDDDMMMRRRP
  *    D = MD5 Digest (first dword)
  *    M = MSS index
  *    R = Rotation of secret
  *    P = Odd or Even secret
  *
  * The MD5 Digest is computed with over following parameters:
  *  a) randomly rotated secret
  *  b) struct in_conninfo containing the remote/local ip/port (IPv4&IPv6)
  *  c) the received initial sequence number from remote host
  *  d) the rotation offset and odd/even bit
  *
  * Timestamp we send:
  * 31|................................|0
  *    DDDDDDDDDDDDDDDDDDDDDDSSSSRRRRA5
  *    D = MD5 Digest (third dword) (only as filler)
  *    S = Requested send window scale
  *    R = Requested receive window scale
  *    A = SACK allowed
  *    5 = TCP-MD5 enabled (not implemented yet)
  *    XORed with MD5 Digest (forth dword)
  *
  * The timestamp isn't cryptographically secure and doesn't need to be.
  * The double use of the MD5 digest dwords ties it to a specific remote/
  * local host/port, remote initial sequence number and our local time
  * limited secret.  A received timestamp is reverted (XORed) and then
  * the contained MD5 dword is compared to the computed one to ensure the
  * timestamp belongs to the SYN-ACK we sent.  The other parameters may
  * have been tampered with but this isn't different from supplying bogus
  * values in the SYN in the first place.
  *
  * 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.
  *
  * Notes:
  * A heuristic to determine when to accept syn cookies is not necessary.
  * An ACK flood would cause the syncookie verification to be attempted,
  * but a SYN flood causes syncookies to be generated.  Both are of equal
  * cost, so there's no point in trying to optimize the ACK flood case.
  * Also, if you don't process certain ACKs for some reason, then all someone
  * would have to do is launch a SYN and ACK flood at the same time, which
  * would stop cookie verification and defeat the entire purpose of syncookies.
  */

The actual implementation source code provides additional hints:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_syncache.c?rev=1.99&content-type=text/x-cvsweb-markup

-- 
Andre

[e-mail]
FreeBSD Developer


_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm