A question about SYN cookies...

[George Neville-Neil]

On Feb 4, 2013, at 04:09 , Andre Oppermann <andre at freebsd.org> wrote:

> 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 .
> 

Yes, I heard about that off list and then got time to review the mailbox.

> 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.

I'll wait for Colin and Nates' evaluation of your scheme to weigh in, though
given the limited key space already in place I do wonder how you got that much
information into a 32 bit int.

Thanks,
George