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

"Adam Langley" <agl@imperialviolet.org> Tue, 15 July 2008 21:14 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0DD93A6AD9; Tue, 15 Jul 2008 14:14:59 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9833A6AA3 for <tcpm@core3.amsl.com>; Tue, 15 Jul 2008 14:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqBXrWyuagxo for <tcpm@core3.amsl.com>; Tue, 15 Jul 2008 14:14:57 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 506FE3A67BD for <tcpm@ietf.org>; Tue, 15 Jul 2008 14:14:57 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so4747660rvf.49 for <tcpm@ietf.org>; Tue, 15 Jul 2008 14:15:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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=OlpuRNT+9kTRmStumez1gwyLkV0yUOX0DvYVh7FEzlA=; b=qKOdgti3xxsAjxSohwPkicunTzw8MpOJI6gr5wq0q04Ic5I3hpaGa9afKQF8z+CUDh gqCfPGAvTEoIZ9MEN6dW+cLXhyT+fnn1itwbXttF0Jc8uMuSyG5hp88ypoxdwkox7FtJ b1JZ0Tf3gstu4KFTWluM6Wljv8g81hGwweQK8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; 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=hBNLfDnb3N+TWgpNS9SRZRdHRFD0ECtwDGYwnAyro9xHs/1FY6ypr4wypi4qFDRRna DNPVR9sET5yoJk2B+TpDcd6a1DkrNdEvSRl96mKFSofRXPi9bzmwUl138rMaDSp7qQwO AqjZSuXXJi/dwexFBPofer08Y6uSHMfD5NrUQ=
Received: by 10.140.185.1 with SMTP id i1mr7761594rvf.102.1216156513731; Tue, 15 Jul 2008 14:15:13 -0700 (PDT)
Received: by 10.141.186.3 with HTTP; Tue, 15 Jul 2008 14:15:13 -0700 (PDT)
Message-ID: <396556a20807151415i7e6b0d4bu6984617a095b07db@mail.gmail.com>
Date: Tue, 15 Jul 2008 14:15:13 -0700
From: "Adam Langley" <agl@imperialviolet.org>
To: "Joe Touch" <touch@isi.edu>
In-Reply-To: <487D0E0D.3030408@isi.edu>
MIME-Version: 1.0
Content-Disposition: inline
References: <396556a20807151111u778faed3wb5a533e90c00b8c1@mail.gmail.com> <7E78ADB4-804B-4C57-824E-04E11B484E94@surrey.ac.uk> <396556a20807151129m50cc0ad6u44cd9599b7e51ac1@mail.gmail.com> <487D0E0D.3030408@isi.edu>
X-Google-Sender-Auth: ea19e2ee436e7f05
Cc: tcpm@ietf.org, Lloyd Wood <L.Wood@surrey.ac.uk>
Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Tue, Jul 15, 2008 at 1:52 PM, Joe Touch <touch@isi.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Data could *always* come in the SYN/ACK (i.e., in a SYN), but often it's
> just ignored. So this option is just a hint to the server that the
> client won't ignore that data. It doesn't change any rules about data
> delivery; once the SYN/ACK arrives, the client can send that data up to
> the user as per conventional rules, AFAICT.

Although I've not tested it, I suspect that you're correct here. I
should reword that section of the draft.

> I'm really not sure what buying a single RTT will do for TCP, though.
> Very few exchanges that need reliable transfer of a single packet need
> TCP, IMO.

Although it could be used for single packet exchanges from the server,
I would be surprised if any one did. My expectation is that protocols
would use it to shave a RTT from the TCP connection setup latency. My
personal motivation for this draft is hinted at in section 2:

"This also allows existing protocols to be extended with encryption
with no additional round trips and with transparent fallback."

Consider a web browser which sets the SYNACK permitted bit and a web
server which includes an elliptic-curve Diffie Hellman key in it's
static SYNACK payload. When connecting to a normal webserver, the
browser will see that no SYNACK payload was received and carry on as
normal. But for augmented webservers, the browser calculate a shared
key and include its own ECDH key just before the HTTP "GET" request,
carried in the final ACK of the 3-way. Thus we have opportunistic
encryption and no additional latency in either case.

(Also, that's not just idle speculation: the firefox build that I'm
writing this email in is such a web browser and the lighttpd I have
running at home is such a web server.)

Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm