From owner-freebsd-net@FreeBSD.ORG Mon Feb 4 09:09:19 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B8AD19E8 for ; Mon, 4 Feb 2013 09:09:19 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 179DC638 for ; Mon, 4 Feb 2013 09:09:18 +0000 (UTC) Received: (qmail 20332 invoked from network); 4 Feb 2013 10:28:20 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Feb 2013 10:28:20 -0000 Message-ID: <510F7AB5.1040508@freebsd.org> Date: Mon, 04 Feb 2013 10:09:09 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: George Neville-Neil Subject: Re: A question about SYN cookies... References: <131E67C7-F336-414E-89C7-535D549443F5@neville-neil.com> In-Reply-To: <131E67C7-F336-414E-89C7-535D549443F5@neville-neil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 09:09:19 -0000 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@. 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