Re: [tcpm] TCP Long Options - Why not as payload in SYNs?

Joe Touch <touch@ISI.EDU> Tue, 15 July 2008 00:35 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 18FDF3A694D; Mon, 14 Jul 2008 17:35:00 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 170953A68EC for <>; Mon, 14 Jul 2008 17:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.481
X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id imGnhBm6wgIt for <>; Mon, 14 Jul 2008 17:34:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A1C503A6845 for <>; Mon, 14 Jul 2008 17:34:56 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m6F0ZBjR028421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jul 2008 17:35:13 -0700 (PDT)
Message-ID: <>
Date: Mon, 14 Jul 2008 17:35:10 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: Adam Langley <>
References: <> <78C9135A3D2ECE4B8162EBDCE82CAD7703E66F37@nekter> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
Cc:, Caitlin Bestler <>
Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0974671938=="

Adam Langley wrote:
> Extensions which involve SYN options thus need to cope with the case
> where they are ignored by a host under attack. (I've a draft, that
> I'll probably post tomorrow, that does exactly that.)

I don't think that's tenable. SYNs are where the presence of all 
capabilities are negotiated. TCP has no semantics for turning 
capabilities on after a connection is negotiated.

If you ignore options in the SYN, you're saying "I can't do that 
capability for the entirety of this connection". For options that are 
optional (i.e., that are disabled if not ACKd), that works fine, but 
then disables the feature for the rest of the connection.

For options that initiators want to require (e.g., TCP-AO, for one), if 
you ignore the option in the SYN-ACK, or forget that it was negotiated, 
the option will not work and the connection will be dropped.

That says you've hit a case where SYN cookies don't support TCP, not 
where your options aren't supported by SYN cookies, IMO.


tcpm mailing list