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

[Joe Touch <[e-mail]>]

Hi, David,

There are two problems with the text:
1) it's never clear whether you're talking about:
    - all hosts, including legacy ones
    - hosts that support ENO, whether the segment includes the ENO
option or not
    - hosts that support ENO and are processing a segment including the
ENO option
Wherever you say "host" below, you should be clear about the case you're
indicating.

2) the text is still incorrect about interaction with legacy hosts

Joe

On 7/30/2016 11:59 PM, David Mazieres wrote:
> 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. 
MUST. There is no case where you can do otherwise and retain the
semantics of TCP to the legacy host.

>  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.
That's incorrect - what it CAN do is buffer the SYN data and ACK it
later, and act on it once ACKd.  The issue is that TCP does not have a
strict rule for what happens if data is received but not ACKd and later
overwritten - there's no rule of "latest data is kept".

>   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.

The above is fine, FWIW, and what I was expecting - i.e., it's OK to
send data in the SYN when you think your bet is likely to win, and that
also means you're willing to take the RESET hit on legacy endpoints if
you're wrong. So the gamble is yours to win or pay the cost of.

Joe