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

Joe Touch <touch@ISI.EDU> Mon, 14 July 2008 15:20 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 26C593A6903; Mon, 14 Jul 2008 08:20:29 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 193953A6B4E for <>; Mon, 14 Jul 2008 08:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.464
X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fguBkoRWlZXf for <>; Mon, 14 Jul 2008 08:20:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A22003A6BF8 for <>; Mon, 14 Jul 2008 08:20:13 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m6EFKHAi013932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jul 2008 08:20:19 -0700 (PDT)
Message-ID: <>
Date: Mon, 14 Jul 2008 08:20:17 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
Cc:,, Sérgio Freire <>
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="===============0877439267=="

PS - if there's interest in this, we could pull together an I-D in time 
for Dublin, but it won't (didn't) make the individual deadline...


Joe Touch wrote:
> Adam Langley wrote:
>> On Mon, Jul 14, 2008 at 5:14 AM, Michael Scharf
>> <> wrote:
>>> Even though RFC 793 explicitly allows payload in SYN segments, there
>>> are TCP stacks that just seem to ignore it. Couldn't this offer an
>>> opportunity to transport long TCP options in the payload of SYN
>>> segments, instead of expanding the header option space?
> See Usenix 2008, "A TCP-layer Name Service for TCP Ports"
> The authors, Sergio and Andre (cc'd), therein combine options in the SYN 
> payload with other mechanisms in a port-names solution. I have spoken 
> with them about cleanly separating the idea of data as payload option 
> space (i.e., removing other features that are distinct, e.g., use of 
> port 0, changing ports after the SYN, etc.), and basically we came up with:
>     set a conventional option that says where the
>     payload option ends, within the SYN segment
>     (typically the end of that segment)
>     wait for an ACK indicating that option is set
>     (could be set in advance), indicating the
>     options will be processed correctly
>         NB - the option is set in advance when
>         a sender speaks the option but has no
>         long options to send, or has long options
>         to send and is doing so. EITHER WAY
>         the option MUST occur, or the handshake
>         will fail.
>     if the ACK does not confirm the ability to
>     process options in the data, then RST the
>     connection and retry without data options
> Note that this works only for the SYN segment, and it isn't clear how it 
> might interoperate with SYN cookies. It also ALWAYS consumes option 
> space, and MUST occur in the existing options.
> ...
>> And that suggests that it's not just those OSes which ignore SYNs with
>> payloads - it's also those which reject the packet completely.
> AFAICT, ACKing the SYN and not the data is compliant, but rejecting the 
> SYN entirely doesn't appear to be - it should be called a bug, IMO.
> Joe

tcpm mailing list