From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 15:35:21 2004 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 17DC516A4E0 for ; Thu, 21 Oct 2004 15:35:21 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E15E43D1D for ; Thu, 21 Oct 2004 15:35:20 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 78076 invoked from network); 21 Oct 2004 15:33:57 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 15:33:57 -0000 Message-ID: <4177D73E.C0531896@freebsd.org> Date: Thu, 21 Oct 2004 17:35:26 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack References: <4177C8AD.6060706@freebsd.org> <20041021101010.V7681@odysseus.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler 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: Thu, 21 Oct 2004 15:35:21 -0000 Mike Silbersack wrote: > > On Thu, 21 Oct 2004, Andre Oppermann wrote: > > o The client has to enable the option in the TCP SYN request to the server. > > If the server accepts it, then it returns a unique cookie generated from > > the IP address of the client and some random seed. On subsequent > > connections > > the client will include the cookie in the TCP SYN request and it will > > send the first chunk of payload in the SYN packet. If the cookie matches > > I think that it would have to be slightly more complex than that for it to > be secure. Instead of using syncookie/RFC1948-like generation, just > randomly generate the cookie and store it in the tcp host cache. Then > steal the concept of NQNFS leases, giving the cookie a limited lifetime, > after which it must be reissued. I think you'll need to track two cookies > on the server side, to gracefully handle the cookie transition period... It wasn't meant to use the exact syncookies code, but the general mechanism like your description of it. We can't use syncookies and that code as is anyway because it puts far more information into the cookie. > Well, I'm sure there are many ways to do it, but I agree that it's > certainly doable; we have plenty of time to talk about the exact > implementation. My reason for avoiding the use of syncookies/RFC1948 in > the implementation is that relying on those pieces of code makes a FreeBSD > implementation easy, but would make an implementation in other OSes > potentially difficult. -- Andre