From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 14:33:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 454CC16A4CF for ; Thu, 21 Oct 2004 14:33:22 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63FB743D48 for ; Thu, 21 Oct 2004 14:33:21 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 77418 invoked from network); 21 Oct 2004 14:31:58 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 14:31:58 -0000 Message-ID: <4177C8AD.6060706@freebsd.org> Date: Thu, 21 Oct 2004 16:33:17 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 14:33:22 -0000 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