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

[David Mazieres <[e-mail]>]

Okay, guys.  This is getting long and feels a bit pedantic, but how
about the following?

David


4.7.  Data in SYN segments

   A SYN segment containing an ENO option MUST NOT include a TCP Fast
   Open (TFO) option [RFC7413].  However, TEPs MAY specify the use of
   data in SYN segments to achieve similar benefits to TFO.

   The last TEP identifier suboption in host A's SYN segment is the _SYN
   TEP_.  The use of data in host A's SYN segment is goverend by the SYN
   TEP.  If the SYN TEP's specification does not define the use of SYN
   data, then host A's SYN segment MUST NOT contain data and host B MUST
   discard any SYN data.  Host B MUST also discard SYN data if either
   the SYN TEP differs from the negotiated TEP or host B disables
   encryption.

   The use of data in B's SYN-ACK segment is governed by the negotiated
   TEP.  If the negotiated TEP's specification does not define the use
   of SYN data, then host B's SYN-ACK segment MUST NOT contain data and
   host A MUST discard any SYN data.  Host A MUST also discard SYN data
   if host A disables encryption.  In the event that host B is an active
   opener (because of simultaneous open), host B's SYN-only segment MUST
   NOT include data.

   A host MUST NOT act on discarded data under any circumstances.  In
   particular, after a host discards SYN data, if a later non-SYN
   segment contains different data for the same sequence numbers, the
   host MUST process the contents of the non-SYN segment only.
   Furthermore, when a host discards SYN data, it MUST NOT acknowledge
   the sequence number of the discarded data.  Rather, it MUST
   acknowledge the other host's initial sequence number as if the
   received SYN segment contained no data.

   If host A's SYN segment contains data, host B's SYN-ACK segment
   acknowledges that data, and either encryption is disabled or the
   negotiated TEP is not the SYN TEP, then host A MUST reset the TCP
   connection.  Under such circumstances, the acknowledged data is
   defined by the SYN TEP, which does not govern the connection.  Hence,
   there is significant risk of host B misinterpreting SYN data.

   If host A sends SYN data, host B does not acknowledge the SYN data,
   and host B's SYN-ACK segment does not include an ENO option, then
   host A SHOULD reset the connection.  The reason is that a legacy host
   B, if it does not implement ENO, could buffer and later act on SYN
   data even without first acknowledging that data.  Barring empirical
   evidence against the existence of unacknowledged data buffering, it
   is not safe for host A to assume its SYN data has been discarded.

   To avoid unexpected resets, TEPs SHOULD support a normal mode of
   operation that does not make use of data in SYN segments, and SHOULD
   enable data in host A's SYN segment 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.  If supported by the TEP, host A MAY enable SYN data when
   the application requests mandatory-encryption mode.