Date: Thu, 21 Oct 2004 17:35:26 +0200 From: Andre Oppermann <andre@freebsd.org> To: Mike Silbersack <silby@silby.com> Cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler Message-ID: <4177D73E.C0531896@freebsd.org> References: <4177C8AD.6060706@freebsd.org> <20041021101010.V7681@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4177D73E.C0531896>