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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 63D6A3A6AD5; Mon, 14 Jul 2008 08:02:49 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 363013A6856 for <>; Mon, 14 Jul 2008 08:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, MISSING_HEADERS=1.292]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id flbPBdNmfiTp for <>; Mon, 14 Jul 2008 08:02:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4CF033A6ADF for <>; Mon, 14 Jul 2008 08:02:10 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m6EF2HP3008098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jul 2008 08:02:20 -0700 (PDT)
Message-ID: <>
Date: Mon, 14 Jul 2008 08:02:17 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
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="===============0104537561=="

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.


tcpm mailing list