Date: Thu, 21 Oct 2004 16:33:17 +0200 From: Andre Oppermann <andre@freebsd.org> To: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Removing T/TCP and replacing it with something simpler Message-ID: <4177C8AD.6060706@freebsd.org>
next in thread | raw e-mail | index | archive | help
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:
o T/TCP is very intrusive to the TCP code and has special cases and
dependencies in many places. This makes it a lot harder to maintain
the TCP code and is prone to break when other changes are made. In
fact I don't know whether still works on 6-current.
o T/TCP only available on FreeBSD. No other Operating System or TCP/IP
stack implements it to my knowledge. Certainly no OS that is common.
o T/TCP is more or less broken by design. It's security model is very
weak and it strongly recommended to disable it if your host is exposed
to the Internet.
o T/TCP is disabled by default on FreeBSD.
o T/TCP requires different API calls than TCP to use it (UDP like).
o T/TCP is not supported by any common network application.
o T/TCP is unmaintained and other major OS have refused to consider
including it based on it's weak security model (DDoS heaven).
However something like T/TCP is certainly useful and I know of one special
purpose application using it (Web Proxy Server/Client for high-delay Satellite
connections).
Thus after the removal of T/TCP for the reasons above I want to provide
a work-alike replacement for T/TCP's functionality:
o Using a cookie mechanism instead of the clumsy TAO connection counting
like SYN cookies in syncache.
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
on the server side, the TCP connection will be direcly propagated into
ESTABLISHED state and process plus present the payload to accept socket.
The SYN/ACK will be returned together with the answer payload from the
socket (or it will SYN/ACK directly as we do now, doesn't matter that
much). With this we get the same short-cutting of the 3WSH but with way
less intrusive code and much more secure than T/TCP.
o Using the same standard TCP API but with an deferred connect() until
the first write() is made.
o To be enabled with a simple socket option on the client and server side.
o All infrastructure is in place to easily implement this (syncache and
tcphostcache).
This different implementation will be disabled by default and clearly marked
EXPERIMENTAL in a protocol sense. It will allow the only known user of T/TCP
to keep the same functionality with a very small change to his application.
It allows interesting new uses primarily in Intranet environment where many
short connections are openend in rapid succession (LDAP servers, SQL servers,
etc.). The modifications to those programs to use the new option is minimal
and requires only the setting of the socket option, one setsockopt() call.
A nice description of T/TCP is here:
http://linuxgazette.net/issue47/stacey.html
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!
--
Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4177C8AD.6060706>