Re: [tcpm] SYN/ACK Payloads, draft 01

Joe Touch <touch@ISI.EDU> Thu, 14 August 2008 05:21 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 3ED073A682A; Wed, 13 Aug 2008 22:21:54 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6ADC3A67F3 for <>; Wed, 13 Aug 2008 22:21:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.06
X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[AWL=-1.329, BAYES_00=-2.599, FRT_STOCK2=3.988]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fsgUrtvtzass for <>; Wed, 13 Aug 2008 22:21:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0D2AF3A682A for <>; Wed, 13 Aug 2008 22:21:52 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m7E5LZ8i029638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Aug 2008 22:21:38 -0700 (PDT)
Message-ID: <>
Date: Wed, 13 Aug 2008 22:20:51 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: Adam Langley <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
Subject: Re: [tcpm] SYN/ACK Payloads, draft 01
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Hash: SHA1

Adam Langley wrote:
| On Wed, Aug 13, 2008 at 6:01 PM, Joe Touch <> wrote:
|> I'm wondering why an implementation in user space would expect to find
|> out anything about a TCP connection that hadn't finished handshaking,
|> i.e., the accept call above (AFAIR) ought to return only after the end
|> of the three-way handshake (I'll have to dig out my Stephens book to
|> confirm, though):
| Absolutely accept() only returns after the 3-way has completed.
| Note that the draft only requires that the stack be able to configure
| a static payload.

I'm confused now; your code - and your note. Let's go back to the key issue:

	- is the data received by the client dependent on the option?

Here's your code:

- ----

The existing patches make the change fairly easy. From the comments:

"A listening socket is configured with a setsockopt with non-zero
payload len
and, optionally, TCP_SADATA_INC_NONCE and tcpsa_nonce_offset if the kernel
should include random data.

On a resulting, accepted socket, a getsockopt reveals:
~  TCP_SADATA_REQ - a SYN/ACK payload was requested
~  TCP_SADATA_NONCE - the 8 random bytes generated are in tcpsa_payload"

So the code looks like:

int newsocket = accept(...)
getsockopt(newsocket, SOL_TCP, &tcpsa, ...)
if (TCP_SADATA_REQ & tcpsa.tcpsa_flags) {
~   // The first data from the socket is the client's draft-agl handshake
~   decode_tagged_data(newsocket);
~   ...
} else {
~   // No special case,
~   continue_as_normal();

- ---

The SERVER is the one in listen; this means that the server thinks there
is different data on the socket depending on whether the client has the
option set? That would mean that the SYN had the data, not the SYN-ACK.

Or am I misreading the code?

Further, how does the server put different code in the connection
depending on a socket option it can't see until after the listen? It
can't write to the socket until the listen completes, at which point the
SYN-ACK is gone.

It seems like you're going to end up needing a new call to write to the
socket before the listen completes, i.e., a setsockopt that effectively
'writes'. Again, this is --far-- afield from TCP semantics.

| Thus, the kernel is able to send the SYN/ACK (with payload) without
| any application involvement.

This is truly confusing to me. The payload **is** application
communication. You're creating an option to generate that data inside
the TCP protocol?

| Thus, all the application needs to find
| out, after an accept() is weather the kernel echoed the SYNACK Payload
| Permitted option. If it did, then the server knows that it's SYNACK
| payload was sent and the data from the client will be a tagged
| structure that I don't actually define in the draft (since it's not
| anything to do with TCP). Otherwise, the option wasn't echoed in which
| case the protocol continues as normal.

As a final question, if this is experimental, why not just use the
experimental TCP option KIND?

(and how much of this has been implemented, traced, and checked for
things like simultaneous open - I don't recall if you noted that before)

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

tcpm mailing list