IETF Logo Mail Archive

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

"Adam Langley" <agl@imperialviolet.org> Thu, 14 August 2008 01:27 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 8FD223A6A70; Wed, 13 Aug 2008 18:27:04 -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 D990C3A69F8 for <tcpm@core3.amsl.com>; Wed, 13 Aug 2008 18:27:03 -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=[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 syhqI4KY7Zuz for <tcpm@core3.amsl.com>; Wed, 13 Aug 2008 18:27:03 -0700 (PDT)
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by core3.amsl.com (Postfix) with ESMTP id 1C2A23A6941 for <tcpm@ietf.org>; Wed, 13 Aug 2008 18:27:02 -0700 (PDT)
Received: by py-out-1112.google.com with SMTP id x19so170070pyg.24 for <tcpm@ietf.org>; Wed, 13 Aug 2008 18:27:05 -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=AaJM5Px/4cEo+GrzqzXcm5dqkehAXgL5dxkGdTN5zXg=; b=A3qITchZY9jVkkDXTpMC3/5bVoiBCXj7aknKfjUGcvILl1+frXXkUyW+UTMYZi2yhy sQmRgXUXF6v+EjV9lgk9ofRS5+/YKWf9NgCBdoMKQxCND6OBU+xJiMSLlGDxwZlUDAxG uR0UoDVg2ORNuv8HnnZDopZt3OmfpNBnhcQpM=
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=ZB3aTf+GGxwGZ8UUsLxNd0DgYWCB978rbGXluuSivWUZ9XQ7f7mZlDmkHZYLDC+2z8 cNaCRtICgaKtgUCDq4fHUhdglk7YHq4BT+Akdz2W03pRoWAkMocOkSjku1ycejiAld/i zDHGWH0clX5Y0+QhnfntmvAC4ZMSB26k8VlZE=
Received: by 10.141.206.13 with SMTP id i13mr323185rvq.100.1218677225005; Wed, 13 Aug 2008 18:27:05 -0700 (PDT)
Received: by 10.141.37.3 with HTTP; Wed, 13 Aug 2008 18:27:04 -0700 (PDT)
Message-ID: <396556a20808131827x1ab32b13yaa9358ac1a70c6ed@mail.gmail.com>
Date: Wed, 13 Aug 2008 18:27:04 -0700
From: Adam Langley <agl@imperialviolet.org>
To: Joe Touch <touch@isi.edu>
In-Reply-To: <48A383F0.9030601@isi.edu>
MIME-Version: 1.0
Content-Disposition: inline
References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com> <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com> <48A35CFA.4060709@isi.edu> <396556a20808131525i20dabf06w7a7a11e3468e541a@mail.gmail.com> <48A36104.6000000@isi.edu> <396556a20808131605w2ccac3ceo21160401e4545c15@mail.gmail.com> <48A383F0.9030601@isi.edu>
X-Google-Sender-Auth: 0b1cf2ecd9bc5182
Cc: tcpm@ietf.org
Subject: Re: [tcpm] SYN/ACK Payloads, draft 01
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 Wed, Aug 13, 2008 at 6:01 PM, Joe Touch <touch@isi.edu> 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. Additionally, it suggests that it should be able to
insert some random bytes in there for cryptographic protocols that
need it.

Thus, the kernel is able to send the SYN/ACK (with payload) without
any application involvement. 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.


AGL

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

v2.23.0 | Report a Bug | By Email