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

"Sergio Freire" <> Mon, 14 July 2008 22:45 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 36CE728C314; Mon, 14 Jul 2008 15:45:36 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B68CF28C127 for <>; Mon, 14 Jul 2008 15:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O-Bc1l0tUzcw for <>; Mon, 14 Jul 2008 15:45:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 044353A6B0B for <>; Mon, 14 Jul 2008 15:45:31 -0700 (PDT)
Received: from [] (account HELO portsfreire) by (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 151993370; Mon, 14 Jul 2008 23:45:53 +0100
From: Sergio Freire <>
To: 'Joe Touch' <touch@ISI.EDU>
References: <> <> <> <>
Date: Mon, 14 Jul 2008 23:45:50 +0100
Message-ID: <003c01c8e603$5db60740$192215c0$@pt>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcjlxXUzdE6E+wMmQZCQzvcUsc3D1wAPWbbAAAAamsA=
Content-Language: pt
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Joe et all,
Yes, I think it would be a great idea to write an I-D concerning the use of
TCP options in the payload.. what is the deadline?

-----Original Message-----
From: Joe Touch [mailto:touch@ISI.EDU] 
Sent: segunda-feira, 14 de Julho de 2008 16:20
To: Joe Touch
Cc:;; Sérgio Freire
Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs?

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"
> tml/index.html
> 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