Re: [tcpm] Faster application handshakes with SYN/ACK payloads

"Adam Langley" <> Mon, 04 August 2008 17:52 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 7731C3A691F; Mon, 4 Aug 2008 10:52:07 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 449733A67A1 for <>; Mon, 4 Aug 2008 10:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.306
X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wB8HkDdjGobF for <>; Mon, 4 Aug 2008 10:52:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3D0E63A6783 for <>; Mon, 4 Aug 2008 10:52:05 -0700 (PDT)
Received: by with SMTP id b25so1828800rvf.49 for <>; Mon, 04 Aug 2008 10:52:34 -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=mhd55LYdPEfOqV1jmPKHoeZGYWfgKNbCCtBM4M/1uE8=; b=AQkxPoqSENOVaPIw0+672DZ+wnXnUsdcDdYWZEnrXySksbreR/azoCyBcsHGF1PEF0 IAmN9VUGcIo9eoi3na2iggcYuOn4IsG8pS3Gw/OM0hOJv/aQxZoJI5teVEExFWTU3K23 MEYOyeD9YlFZLyjT437WjA5GG1o9k6xPMpc+Y=
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=f7vFXvNZOGusSis6y9iaW1Bk5Ri7EG0JiOsIWjAdOZHoPqmkcUWN3w6xOgdd9esabe smOYsCAZqVG+zV2fZeX0sUvcUqGtaQExYOECy4UpLK8Uk9ldrN/2EebxapzaS4jEWzv6 /I6LFk6tzoXDpys5zfEQ8eEoNx/OvphT5KzGA=
Received: by with SMTP id s6mr7670880rvm.239.1217872354023; Mon, 04 Aug 2008 10:52:34 -0700 (PDT)
Received: by with HTTP; Mon, 4 Aug 2008 10:52:33 -0700 (PDT)
Message-ID: <>
Date: Mon, 04 Aug 2008 10:52:33 -0700
From: Adam Langley <>
To: "Anantha Ramaiah (ananth)" <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <>
X-Google-Sender-Auth: dac1ca8d42a7af8b
Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads
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 Sun, Aug 3, 2008 at 9:56 PM, Anantha Ramaiah (ananth)
<> wrote:
> - fix the sentence : "we should how this has...."

Thanks! will do.

> - you mention "cryptographic applications" would benefit with this
> proposal, and give example of SSH in your draft. It would be really
> interesting to know how many very commonly used TCP applications would
> really benefit with this ? Atleast the draft can mention those..

Will do with the next draft.

> - with the SSH example which you give, it appears that one of the
> advantages of this proposal is that you can tear down the connection
> before the connection moves to ESTAB if the authentication fails?  (For
> eg:- some implementations don't create a full blown TCB before TWHS
> completes)

Indeed. Although I believe that a (short lived) TCB would actually be
created in this case for current, common stacks, that's an
implementation limit. It would be possible, with the authentication
that I sketched, for neither end to create a TCB if the server's
public value didn't match.

> - Can you elaborate on the flags option? It simply mentions that the
> meaning of this would be assigned by IANA? Again this is not infinite
> (2+n, n is finite) since it should be bounded by the TCP header length
> inclusive of options?

The flags option was designed to allow future flag options to be
assigned bits, rather than option numbers. Consider that, if SACK
permitted has been designed this way, then this proposed option
wouldn't need any extra options space, it could just take a bit in an
option that it already ubiquitous. However, it might well be the case
that I should just stick to a standard, 2 byte, option for this.

> - the doc says (section 3 ) "host MUST not include data payload in
> SYN+ACK resulting from a SYN frame without SYNACK payload permitted"
> But RFC 793 does permit data in SYN which includes SYN+ACK, so this
> statement raises a new level of ambiguity.

Thanks. Joe pointed out this ambiguity also. It will be fixed in the
next draft by echoing the option in the SYNACK.

> Section 4:
> You mention 64 bytes of payload is enough to include sufficient crypto
> material. Just wondering the interoperability of this statement with TCP
> auth (TCP MD5 and TCP AO for example)

The method for upgrading a normal connection to TCP AO is currently
not specified, although there has been discussion of it. In my
current, very rough, patches there's an option that I'm calling LATCH
that allows a connection to upgrade to TCP AO. Also, I have userspace
software that uses SYNACK payloads and LATCH to establish a connection
and upgrade to TCP AO using the agreed key (and no additional round
trips). Fundamentally, however, these drafts are independent.

> What about Kamikaze like packets ? where SYN, FIN are set the
> applications can send data and also set the FIN bit in the oriinal SYN
> (Not sure if 793 talks about it but Stevens book does mention it and so
> as BSD implementatiosns which support this type of packets) Would those
> still work within your proposal?

I would have to investigate how the BSD stacks handle this. Linux
would ack only the SYN flag, to the other host would have to
retransmit any data and the FIN anyway. BSD stacks, I hope, would not
deliver data to userspace with an unauthenticated source IP address,
so may do the same. But it isn't incompatible with my scheme. The
SYNACK payload, if configured, would be sent as part of the data

> Also, the applications need to change to make use of this proposal (the
> HTTP example which you mention below) In other words, it would be nice
> if you can explain the "opportunistic encryption" scheme and how
> applications (which all) can benefit from your proposal in more detail
> in the draft.

Since several people have suggested this, I certain shall in the next
draft (which should be in the next couple of days)

Thanks for your comments.


Adam Langley
tcpm mailing list