From owner-freebsd-net@FreeBSD.ORG Thu Feb 7 20:07:32 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 10684AC1; Thu, 7 Feb 2013 20:07:32 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id DC25BAB9; Thu, 7 Feb 2013 20:07:31 +0000 (UTC) Received: from [38.105.238.108] (port=54612 helo=[10.7.1.235]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U3Xkp-0008Jv-8v; Thu, 07 Feb 2013 15:07:31 -0500 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: A question about SYN cookies... From: George Neville-Neil In-Reply-To: <510F7AB5.1040508@freebsd.org> Date: Thu, 7 Feb 2013 15:07:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2615E46D-2C39-42DB-B38F-E15A39A730BB@neville-neil.com> References: <131E67C7-F336-414E-89C7-535D549443F5@neville-neil.com> <510F7AB5.1040508@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com 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: Thu, 07 Feb 2013 20:07:32 -0000 On Feb 4, 2013, at 04:09 , Andre Oppermann 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