Removing T/TCP and replacing it with something simpler

[Andre Oppermann]

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