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

"David Mazieres" <dm-list-tcpcrypt@scs.stanford.edu> Mon, 01 August 2016 07:36 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 2CD1112D52D for <tcpinc@ietfa.amsl.com>; Mon, 1 Aug 2016 00:36:56 -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 sfdHrV6Zru3l for <tcpinc@ietfa.amsl.com>; Mon, 1 Aug 2016 00:36:55 -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 4376212B051 for <tcpinc@ietf.org>; Mon, 1 Aug 2016 00:36:55 -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 u717atdp008656 for <tcpinc@ietf.org>; Mon, 1 Aug 2016 00:36:55 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id u717as8T007649; Mon, 1 Aug 2016 00:36:54 -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: tcpinc <tcpinc@ietf.org>
In-Reply-To: <87k2g16mvb.fsf@ta.scs.stanford.edu>
References: <CAJU8_nU1WzQNFFUn_2o1cACutB01iyQ_hC29PHoutr8TRDKGnA@mail.gmail.com> <579A4669.7030600@isi.edu> <87lh0lselg.fsf@ta.scs.stanford.edu> <CAJU8_nUPrm9JJMrrMbL5+FpP-9CKC6EkidCry9UuZA5ZfyJtoA@mail.gmail.com> <579A8223.8050308@isi.edu> <CAJU8_nXSxr7ykC1TwptBmyP8pNccz52ozq=hF7-EYiaMdDeLBQ@mail.gmail.com> <579BA470.3000405@isi.edu> <CAJU8_nXjhHH1eEXPA3hvhJ3YXsP_v2djGX=X2p9+wyn767Hm5A@mail.gmail.com> <adcaa33a-3bf5-e63a-bd19-fd165b16aa7d@wizmail.org> <87oa5fniu0.fsf@ta.scs.stanford.edu> <9ff12fb6-44f9-b1d0-2e9d-a67683679037@wizmail.org> <CAJU8_nVBem40i5Rqke37UBtOquF_mVBJHkjrtAmNN2qPdHqY=A@mail.gmail.com> <87d1lunvhn.fsf@ta.scs.stanford.edu> <579E9248.7050006@isi.edu> <87popt6nci.fsf@ta.scs.stanford.edu> <87k2g16mvb.fsf@ta.scs.stanford.edu>
Date: Mon, 01 Aug 2016 00:36:54 -0700
Message-ID: <87y44hc549.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/LDehMuC3L0H_WqCx8xL3IN9ch1c>
Subject: Re: [tcpinc] TCP's treatment of data in SYN packets
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: Mon, 01 Aug 2016 07:36:56 -0000

Oops, I failed to notice that you had in-line comments as well.  Please
read this instead of the previous version.

Sorry,
David

4.7.  Data in SYN segments

   TEPs MAY specify the use of data in SYN segments so as to reduce the
   number of round trips required for connection setup.  The meaning of
   data in a SYN segment with an ENO option (a SYN+ENO segment) is
   determined by the last TEP identifier in the ENO option, which we
   term the segment's _SYN TEP_.

   A SYN+ENO segment MUST NOT include data unless the SYN TEP's
   specification defines the use of such data.  Furthermore, a SYN+ENO
   option MUST NOT include a non-empty TCP Fast Open (TFO) option
   [RFC7413].

   A host implementing ENO, even if ENO has been disabled by
   configuration, MUST discard the data in a received SYN+ENO segment if
   any of the following applies:

   o  Encryption is disabled for the connection,

   o  The received segment's SYN TEP is not the negotiated TEP,

   o  The negotiated TEP does not define the use of SYN data, or

   o  The SYN segment contains a non-empty TFO option or any other TCP
      option implying a conflicting definition of SYN data.

   A host MUST NOT acknowledge the sequence number of any discarded SYN
   data, but rather MUST acknowledge the other host's initial sequence
   number as if the received SYN segment contained no data.
   Furthermore, a host MUST NOT assume discarded SYN data will be
   identically retransmitted.  If later non-SYN segments contain
   different data for the same sequence numbers as SYN data, the host
   MUST process only data from non-SYN segments.

   If a host receives acknowledgment for data in a SYN+ENO segment but
   the SYN TEP governing that data is not the negotiated TEP (either
   because a different TEP was negotiated, or because encryption is
   disabled), then the host that sent the SYN+ENO segment MUST reset the
   TCP connection.  Proceeding in any other fashion risks misinterpreted
   SYN data.

   If a host sends data in a SYN-only SYN+ENO segment and subsequently
   receives a SYN-ACK segment without an ENO option, the host SHOULD
   reset the connection even if the SYN-ACK segment does not acknowledge
   the SYN data.  The reason is that a host sending a SYN-ACK segment
   without an ENO option does not necessarily follow the requirements of
   this section, and in particular could buffer SYN data and later
   process it instead of the contents of non-SYN segments with the same
   sequence numbers.  Barring empirical evidence against the existence
   of such buffering, it is not safe to assume unacknowledged SYN data
   has been discarded.

   To avoid unexpected connection resets, TEPs SHOULD support a normal
   mode of operation that does not make use of data in SYN-only
   segments.  Moreover, implementations SHOULD enable data in SYN-only
   segments only if explicitly requested by the application or in cases
   where such use is unlikely to cause connection failure.
   Implementations MAY provide a per-connection mandatory encryption
   mode that automatically resets a connection if ENO fails.  For TEPs
   that support it, an implementation MAY default to using SYN data when
   in mandatory encryption mode.