A question about SYN cookies...

[Andre Oppermann]

On 04.02.2013 01:09, George Neville-Neil wrote:
> Howdy,
>
> I've been reviewing the SYN cache and SYN cookie code and I'm wondering why we do all the work
> of generating a SYN cache entry before sending a SYN cookie.  If the point of SYN cookies is to
> defend against a SYN flood then, to my mind, the SYN/ACK for the cookie case should be sent off before
> doing all the work to try to create and insert a cache entry.  Has anyone, as yet, looked at a way
> to move the sending code earlier into syncache_add() and checked to see if there is a performance
> improvement when a system is flooded with SYN packets?

So far all syncookie implementations have an information loss because
they can't store all state in the cookie unless timestamps are enabled.
Apparently Windows 8 still doesn't enable timestamps but does quite a
bit of window scaling leading to problems.  See recent bug report here
on net at .

For generating syncookies we have three possible strategies:

  1/ Use syncache and cookies in parallel and bump the oldest syncache
     entry replacing it with the new SYN attempt.  Syncookies are done
     on all SYN-ACK's going out.

  2/ Fill the syncache but do not bump the oldest entry, other than normal
     expiry.  All further SYN-ACK's are syncookies-only (w/o window scaling
     etc).  Those in the syncache do not need to carry syncookies and are
     real full SYN-ACK's.

  3/ Only send syncookies and do not cache anything.  No window scaling
     and SACK-PERM can be carried though.

So far we've been doing option 1.  We can switch to option 2 which, depending
on the situation, may be better or worse. Options 3 isn't viable currently
due to loss of window scaling and SACK.

Based on the recent Windows 8 issue I've devised a different HMAC based
syncookie scheme where all necessary information can be stored in the ISS
forgoing the need for the timestamp bits.  I have sent a description of
the scheme to Colin and Nate to have it reviewed.  It must be cryptographically
strong enough to withstand cracking attempts for about 30 seconds.  Forward
security isn't necessary as the syncookie secrets are completely random and
renewed every 30 seconds.

--
Andre