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

[David Mazieres <[e-mail]>]

Okay, guys.  Thanks for the feedback.  Here's yet another attempt at
revamping the section.  I made sure each SHOULD is followed by an
exception.  Note I made one other change, which is to allow SYN-form ENO
options with no suboptions.  Before that didn't make sense, but now it
does as a way of saying "I don't want to encrypt, but I threw away your
SYN data."

Once we converge on this I will release yet another draft...

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 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 option 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 will
   govern a connection, hosts implementing ENO are REQUIRED to discard
   data from SYN+ENO segments when the SYN TEP does not govern the
   connection or when there is any ambiguity over the meaning of the SYN
   data.  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 with 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 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 governing the data is
   not the negotiated TEP (either because a different TEP was negotiated
   or because ENO failed to negotiate encryption), then the host MUST
   reset 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 SHOULD reset 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.
   Connection resets are potentially avoidable if SYN data caching is
   empirically found not to occur, or in response to an API command (for
   cases where a higher-layer integrity check would anyway terminate a
   garbled connection).

   To avoid unexpected connection resets, 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
   resets 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.