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.
- Re: [tcpinc] TCP's treatment of data in SYN packe… Black, David
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… David Mazieres
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… David Mazieres
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… Kyle Rose
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… David Mazieres
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… Black, David
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… David Mazieres
- Re: [tcpinc] TCP's treatment of data in SYN packe… Black, David
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… Black, David
- Re: [tcpinc] TCP's treatment of data in SYN packe… David Mazieres
- Re: [tcpinc] TCP's treatment of data in SYN packe… Derek Fawcus
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… Kyle Rose
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… Jeremy Harris
- Re: [tcpinc] TCP's treatment of data in SYN packe… David Mazieres
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] [tcpm] TCP's treatment of data in SY… Derek Fawcus
- [tcpinc] TCP's treatment of data in SYN packets Kyle Rose
- Re: [tcpinc] [tcpm] TCP's treatment of data in SY… Joe Touch
- Re: [tcpinc] [tcpm] TCP's treatment of data in SY… Gavin McCullagh
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… Jeremy Harris
- Re: [tcpinc] TCP's treatment of data in SYN packe… David Mazieres
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… Derek Fawcus
- Re: [tcpinc] TCP's treatment of data in SYN packe… Kyle Rose
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… Jeremy Harris
- Re: [tcpinc] TCP's treatment of data in SYN packe… David Mazieres
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… David Mazieres
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… Kyle Rose
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… David Mazieres
- Re: [tcpinc] TCP's treatment of data in SYN packe… Wesley Eddy
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… David Mazieres
- Re: [tcpinc] TCP's treatment of data in SYN packe… Kyle Rose
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… David Mazieres
- Re: [tcpinc] TCP's treatment of data in SYN packe… Joe Touch
- Re: [tcpinc] TCP's treatment of data in SYN packe… Derek Fawcus
- Re: [tcpinc] TCP's treatment of data in SYN packe… David Mazieres
- Re: [tcpinc] TCP's treatment of data in SYN packe… Kyle Rose
- Re: [tcpinc] TCP's treatment of data in SYN packe… Kyle Rose
- Re: [tcpinc] TCP's treatment of data in SYN packe… Yuchung Cheng