Date: Thu, 7 Feb 2013 15:07:39 -0500 From: George Neville-Neil <gnn@neville-neil.com> To: Andre Oppermann <andre@freebsd.org> Cc: net@freebsd.org Subject: Re: A question about SYN cookies... Message-ID: <2615E46D-2C39-42DB-B38F-E15A39A730BB@neville-neil.com> In-Reply-To: <510F7AB5.1040508@freebsd.org> References: <131E67C7-F336-414E-89C7-535D549443F5@neville-neil.com> <510F7AB5.1040508@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 4, 2013, at 04:09 , Andre Oppermann <andre@freebsd.org> wrote: > On 04.02.2013 01:09, George Neville-Neil wrote: >> Howdy, >>=20 >> 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? >=20 > 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@. >=20 Yes, I heard about that off list and then got time to review the = mailbox. > For generating syncookies we have three possible strategies: >=20 > 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. >=20 > 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. >=20 > 3/ Only send syncookies and do not cache anything. No window scaling > and SACK-PERM can be carried though. >=20 > 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. >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2615E46D-2C39-42DB-B38F-E15A39A730BB>