IETF Logo Mail Archive

Re: [tcpinc] TCP's treatment of data in SYN packets

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Wed, 27 July 2016 21:45 UTC

Return-Path: <dm-list-tcpcrypt@scs.stanford.edu>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA37A12D966 for <tcpinc@ietfa.amsl.com>; Wed, 27 Jul 2016 14:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.188
X-Spam-Level:
X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xEbtwz6_4fe for <tcpinc@ietfa.amsl.com>; Wed, 27 Jul 2016 14:45:14 -0700 (PDT)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E19312D95D for <tcpinc@ietf.org>; Wed, 27 Jul 2016 14:45:14 -0700 (PDT)
Received: from market.scs.stanford.edu (localhost.scs.stanford.edu [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id u6RLjCV8013259; Wed, 27 Jul 2016 14:45:12 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id u6RLjBDg004281; Wed, 27 Jul 2016 14:45:11 -0700 (PDT)
X-Authentication-Warning: market.scs.stanford.edu: dm set sender to dm-list-tcpcrypt@scs.stanford.edu using -f
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: Kyle Rose <krose@krose.org>
In-Reply-To: <CAJU8_nWni5wu2BJLT_j559RjRT=GgrkyurQi2uwE7v8Mo61NHA@mail.gmail.com>
References: <CAJU8_nU1WzQNFFUn_2o1cACutB01iyQ_hC29PHoutr8TRDKGnA@mail.gmail.com> <CAK6E8=d3psZBS1yX56fRQ-SP7qCN_vem5tNB8O42zPyo0TKj7Q@mail.gmail.com> <CAJU8_nWMBbqLLsYQ3GhqRk8YkptqjCF40h_R7HNSOrqHwLbgxQ@mail.gmail.com> <87wpk7x9v6.fsf@ta.scs.stanford.edu> <CAJU8_nWni5wu2BJLT_j559RjRT=GgrkyurQi2uwE7v8Mo61NHA@mail.gmail.com>
Date: Wed, 27 Jul 2016 14:45:11 -0700
Message-ID: <877fc6ycuw.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/BM__vvCMfocGn7bApzQCPiPKB3k>
Cc: tcpinc <tcpinc@ietf.org>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, Praveen Balasubramanian <pravb@microsoft.com>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, Yuchung Cheng <ycheng@google.com>, Christoph Paasch <cpaasch@apple.com>
Subject: Re: [tcpinc] TCP's treatment of data in SYN packets
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: David Mazieres expires 2016-10-25 PDT <mazieres-5mehvxfqtr38mvjvf6tfwgcy62@temporary-address.scs.stanford.edu>
List-Id: "Discussion list for adding encryption to TCP." <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2016 21:45:16 -0000

Kyle Rose <krose@krose.org> writes:

> do we need some explicit signaling from the server on a prior
> connection for when SYN data on resumption attempts is okay, or is
> "...but SHOULD limit such usage..." good enough?

This is precisely the question on which some input from more experienced
members of the working group could be helpful.

Basically I'd like to ensure that ENO conflicts as little as possible
with future use of data in SYN segments.  So rather than just flat-out
prohibiting it (and having people not even test the corner case), I
think it would be good to specify that receivers explicitly ignore the
data in places where it couldn't possibly be useful.  And then once you
are there, why not say that TEPs MAY define data but probably shouldn't
send it for the time being in the remaining cases.

David

v2.35.0 | Report a Bug | By Email | System Status