Re: Removing T/TCP and replacing it with something simpler
From: Mike Silbersack (silby_at_silby.com)
Date: 10/21/04
- Previous message: Richard Wendland: "Re: Removing T/TCP and replacing it with something simpler"
- In reply to: Andre Oppermann: "Removing T/TCP and replacing it with something simpler"
- Next in thread: Andre Oppermann: "Re: Removing T/TCP and replacing it with something simpler"
- Reply: Andre Oppermann: "Re: Removing T/TCP and replacing it with something simpler"
- Reply: Garrett Wollman: "Re: Removing T/TCP and replacing it with something simpler"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 21 Oct 2004 10:24:08 -0500 (CDT) To: Andre Oppermann <andre@freebsd.org>
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
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Richard Wendland: "Re: Removing T/TCP and replacing it with something simpler"
- In reply to: Andre Oppermann: "Removing T/TCP and replacing it with something simpler"
- Next in thread: Andre Oppermann: "Re: Removing T/TCP and replacing it with something simpler"
- Reply: Andre Oppermann: "Re: Removing T/TCP and replacing it with something simpler"
- Reply: Garrett Wollman: "Re: Removing T/TCP and replacing it with something simpler"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|