Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

This seems fine to me.

On Mon, Nov 13, 2017 at 6:35 AM, David Mazieres <
[e-mail]> wrote:

> David Mazieres expires 2018-02-10 PST
> <[e-mail]> writes:
>
> >> The problem is that "govern" is not very clear. It's clearer to link the
> >> requirement
> >> here to the specific feature of the packet.
> >
> > Okay, let me futz with the language a bit and try to get rid of or
> > clearly define the term govern.
>
> Okay, how about the following?
>
> Thanks,
> 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 may of course
>    include multiple TEP suboptionss, but only the SYN TEP (i.e., the
>    last one) specifies how to interpret the SYN segment's data payload.
>
>    A host sending a SYN+ENO segment MUST NOT include data in the segment
>    unless the SYN TEP's specification defines the use of such data.
>    Furthermore, to avoid conflicting interpretations of SYN data, a
>    SYN+ENO segment MUST NOT include a non-empty TCP Fast Open (TFO)
>    option [RFC7413].
>
>    Because a host can send SYN data before knowing which if any TEP the
>    connection will negotiate, hosts implementing ENO are REQUIRED to
>    discard data from SYN+ENO segments when the SYN TEP does not become
>    the negotiated TEP.  Hosts are furthermore REQUIRED to discard SYN
>    data in cases where another Internet standard specifies a conflicting
>    interpretation of SYN data (as would occur when receiving a non-empty
>    TFO option).  This requirement applies to hosts that implement ENO
>    even when ENO has been disabled by configuration.  However, note that
>    discarding SYN data is already common practice [RFC4987] and the new
>    requirement applies only to segments containing ENO options.
>
>    More specifically, a host that implements ENO MUST discard the data
>    in a received SYN+ENO segment if any of the following applies:
>
>    o  ENO fails and TEP-indicated 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 discarding SYN data in compliance with the above requirement
>    MUST NOT acknowledge the sequence number of the discarded data, but
>    rather MUST acknowledge the other host's initial sequence number as
>    if the received SYN segment contained no data.  Furthermore, after
>    discarding SYN data, such a host MUST NOT assume the SYN data will be
>    identically retransmitted, and MUST process data only from non-SYN
>    segments.
>
>    If a host sends a SYN+ENO segment with data and receives
>    acknowledgment for the data, but the SYN TEP in its transmitted SYN
>    segment is not the negotiated TEP (either because a different TEP was
>    negotiated or because ENO failed to negotiate encryption), then the
>    host MUST abort the TCP connection.  Proceeding in any other fashion
>    risks misinterpreted SYN data.
>
>    If a host sends a SYN-only SYN+ENO segment bearing data and
>    subsequently receives a SYN-ACK segment without an ENO option, that
>    host MUST abort the connection even if the SYN-ACK segment does not
>    acknowledge the SYN data.  The issue is that unacknowledged data may
>    nonetheless have been cached by the receiver; later retransmissions
>    intended to supersede this unacknowledged data could fail to do so if
>    the receiver gives precedence to the cached original data.
>    Implementations MAY provide an API call for a non-default mode in
>    which unacknowledged SYN data does not cause a connection abort, but
>    applications MUST use this mode only when a higher-layer integrity
>    check would anyway terminate a garbled connection.
>
>    To avoid unexpected connection aborts, ENO implementations MUST
>    disable the use of data in SYN-only segments by default.  Such data
>    MAY be enabled by an API command.  In particular, implementations MAY
>    provide a per-connection mandatory encryption mode that automatically
>    aborts a connection if ENO fails, and MAY enable SYN data in this
>    mode.
>
>    To satisfy the requirement of the previous paragraph, all TEPs SHOULD
>    support a normal mode of operation that avoids data in SYN-only
>    segments.  An exception is TEPs intended to be disabled by default.
>