On Feb 4, 2013, at 04:09 , Andre Oppermann <an...@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@. > 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 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
