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

"Adam Langley" <> Wed, 13 August 2008 23:05 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id C464A3A69AE; Wed, 13 Aug 2008 16:05:20 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 662253A6A4A for <>; Wed, 13 Aug 2008 16:05:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.277
X-Spam-Status: No, score=0.277 tagged_above=-999 required=5 tests=[AWL=-1.734, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rpab8jWkWnCq for <>; Wed, 13 Aug 2008 16:05:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 875383A69AE for <>; Wed, 13 Aug 2008 16:05:18 -0700 (PDT)
Received: by with SMTP id b25so183006rvf.49 for <>; Wed, 13 Aug 2008 16:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=tEFDG2aQHVX855sHjjMmkJPYLt4OEtlKXcP1F3EfOYk=; b=sxqyJSLd2LpgrAyoh/49MXhmDU7TM1nmWCrFV0/bLupHJf+iFBq2uW4zeVSY+UPoTU tBdVJjZws4SAF/Ie361zfufrp2d04YKsbS46EwES06pv3Rgm+1f+zXnYMEmRhcxOg2SS k3znh5EpmoMB2lY/jPWummfBMUoL6MRJsSAd4=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=l4o5w95LfSO2avf6EZQFC+jBgOr/O7VQEI1kRSbIWawk9AMmmPK8lF32AqaGNc/2Kd 3UOLsCE+u7drylwYBQZDLlNUAT2wboEIF3iUGn7oBYZ0ZWnHSzVpQZDVD55Sv7nfs3zm nFCzV06kleqv7UXj9X2DDnRZOXBWKx78ULWoU=
Received: by with SMTP id w20mr281670rvh.21.1218668722519; Wed, 13 Aug 2008 16:05:22 -0700 (PDT)
Received: by with HTTP; Wed, 13 Aug 2008 16:05:22 -0700 (PDT)
Message-ID: <>
Date: Wed, 13 Aug 2008 16:05:22 -0700
From: Adam Langley <>
To: Joe Touch <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <> <> <> <> <> <> <> <> <>
X-Google-Sender-Auth: 43555101ed815f71
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Wed, Aug 13, 2008 at 3:32 PM, Joe Touch <> wrote:
> Sites that understand this option would be listening on the desired
> ports. It's trivial to issue two SYNs and wait to see which ones are
> returned.

If the two connections are made in parallel, and port 80 returns
first, how long do you wait for the other one? In this case, that
additional latency effects all *existing* sites. Hopefully the
difference would be small, but 5ms, 10ms? Also, in the case that both
return, the application probably can't close the socket in time for
the kernel not to ACK it, in which case clients would constantly be
opening very short lived connections to port 80.

I understand that application level changes based on options is a bit
discomforting but, personally, I find racing SYNs to be much worse.

> Further, I'm not even sure how to write the application at the server -
> one that responds with different data depending on signals in a SYN.
> What does that even mean, and how does the TCP API (as specified in
> RFC793, e.g.) need to be extended to support that?

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
} else {
   // No special case,

> Firewalls and NATs also sometimes munge TCP options, especially ones
> they don't understand, FWIW.

Certainly, and middleware which drops packets packets with the extra
option would be a concern. (The draft makes provisions for retrying
without the extra option in case implementations wish to do this).
However, hosts with restricted outbound port numbers are downright
common, sadly.



Adam Langley
tcpm mailing list