From owner-freebsd-hackers  Thu Oct 17 01:44:57 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id BAA16900
          for hackers-outgoing; Thu, 17 Oct 1996 01:44:57 -0700 (PDT)
Received: from dog.farm.org (dog.farm.org [207.111.140.47])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA16893
          for <freebsd-hackers@freebsd.org>; Thu, 17 Oct 1996 01:44:51 -0700 (PDT)
Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id BAA01012 for freebsd-hackers@freebsd.org; Thu, 17 Oct 1996 01:48:08 -0700 (PDT)
Date: Thu, 17 Oct 1996 01:48:08 -0700 (PDT)
From: Dmitry Kohmanyuk <dk@dog.farm.org>
Message-Id: <199610170848.BAA01012@dog.farm.org>
Subject: Re: Excellent host SYN-attack fix for BSD hosts (fwd)
Cc: freebsd-hackers@freebsd.org
References: <199610141726.NAA20351@neon.ingenia.com>
Organization: FARM Computing Association
Reply-To: dk+@ua.net
X-Newsreader: TIN [version 1.2 PL2]
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Mike Shaver (shaver@neon.ingenia.ca) wrote:
> Thus spake Michael Dillon:
> > window size
> > and any initial data is discarded;

> This, of course, breaks the TCP specification, in case anyone still
> cares about that.  (Few do, I fear.)

Hmm...  you can ACK only to position 0, assuming some weird
router fragmented the packet along the way and then eaten all but the
first fragment.  Then the client would retransmit.
(Well, the client could rely on minimal MTU...)

> (I seem to recall someone saying that it made it impossible to talk to
> any machine that did T/TCP, as well.)

You can easily distinguish T/TCP by looking for CC option set.
Also, since you normally bybass TCP 3-way handshake with T/TCP, there
is no reason to prevent SYN floods.  (Here comes the issue of T/TCP 
cache state floods.)