From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 15:24:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FBB516A4CF for ; Thu, 21 Oct 2004 15:24:11 +0000 (GMT) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id C367443D5D for ; Thu, 21 Oct 2004 15:24:10 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 67547 invoked from network); 21 Oct 2004 15:24:09 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay01.pair.com with SMTP; 21 Oct 2004 15:24:09 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 21 Oct 2004 10:24:08 -0500 (CDT) From: Mike Silbersack To: Andre Oppermann In-Reply-To: <4177C8AD.6060706@freebsd.org> Message-ID: <20041021101010.V7681@odysseus.silby.com> References: <4177C8AD.6060706@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 15:24:11 -0000 On Thu, 21 Oct 2004, Andre Oppermann wrote: > I want to bring this up for discussion prior to start working on it. > > I intend to remove T/TCP (transactional TCP) support from our TCP > implementation for the following reasons: That sounds good. > 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... 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. > FUD Notice: > > If you haven't read and/or unstood the link above or TCP/IP Illustrated > Volume 3 then please refrain from participating in this discussion! Hey, I just looked in section 24.7 in Vol. 1, and it says nothing but good things about T/TCP - you must be the one misunderstanding things here! :) Mike "Silby" Silbersack