From owner-freebsd-net@FreeBSD.ORG Wed May 28 10:03:47 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6DFA37B404 for ; Wed, 28 May 2003 10:03:47 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4B16D43F85 for ; Wed, 28 May 2003 10:03:44 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 24404 invoked from network); 28 May 2003 17:03:43 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 28 May 2003 17:03:43 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 28 May 2003 12:02:34 -0500 (CDT) From: Mike Silbersack To: Barney Wolff In-Reply-To: <20030528155914.GA4573@pit.databus.com> Message-ID: <20030528115405.M39182@odysseus.silby.com> References: <20030528155914.GA4573@pit.databus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: [dab@BSDI.COM: Re: [e2e] TCP-SYN and delayed TCB allocation] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2003 17:03:48 -0000 On Wed, 28 May 2003, Barney Wolff wrote: > I found this message interesting. > Can someone point me to the rationale for putting all conns through > the syncache? > Thanks, > Barney The main rationale is simple: Code duplication. If we kept both the incomplete listen queue and the syn cache, any incoming syn-ack would have to search both of them. I agree that FreeBSD's syn cache could be better, jlemon and I talked about incorprorating some of Yahoo's patches to it, but we haven't had time yet. The main problem now is that we calculate syncookies for everything, and that we kick entries out of the syncache in FIFO order. What we should do is change things around so that we never kick out syncache entries due to incoming packets (although we could reduce their lifetime during attack), and only use syncookies for connections not resident in the syncache. That would increase our efficiency while under attack, although we're still in decent shape right now. I think the main difference in opinion is that we use the syncache to replace the incomplete listen queue, with syncookies as the backup plan. BSDI apparently still uses the incomplete listen queue as the main mechanism, with a syncache as backup. Hence, we're both going to be defensive about our implementations. If you want to arrange a syn-floodoff, I'd be interested in seeing the results. :) Mike "Silby" Silbersack