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

[David Mazieres <[e-mail]>]

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.