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

[Kyle Rose <[e-mail]>]

On Thu, Jul 28, 2016 at 4:16 PM, David Mazieres <
[e-mail]> wrote:

> Thanks for this explanation.  This matches my understanding, and raises
> a subtle point because of the elimination of the application-aware
> mandatory bit on the wire.  Suppose you are in the following situation:
>
>   * Host A and host B have previously established a bunch of TCP-ENO
>     sessions successfully, so believe the network path is clear and so
>     forth.
>
>   * The application on host A suddenly sets the mandatory
>     application-aware mode, and host B is not application aware.
>
>   * Host A uses a TEP that allows for SYN data, and in fact tries to use
>     SYN data on the next connection.
>
>   * Host B acks the SYN data, because the SYN TEP is also the negotiated
>     TEP.
>
>   * Host A disables TCP-ENO because host B was not application aware, so
>     the third leg of the handshake does not include an ENO option.
>
> At this point host B would have to discard the data, since it includes
> ciphertext.  If the data were a Diffie-Hellman parameter this might be
> okay, though a redefinition of TCP's behavior since the data was ACKed.
> I'm hesitant to redefine TCP's behavior in a way that does not closely
> hue to other studied modifications such as TFO.
>
> In particular, TFO suggests required buffering is not the best behavior.
> In fact, I would imagine in the short term SYN data is most useful for
> cases like session resumption, where you really want the data directly
> delivered to the application (since it's cryptographically authenticated
> anyway) and not buffered.  This is a modification of TCP I feel
> comfortable with because TFO has essentially already vetted this model.
>
> One possible solution is to say that you cannot send data in the SYN
> segment if you set the application-aware mandatory bit.  Another
> possible solution is to convey the application-aware mandatory bit by
> going back to two a bits, the way we had a few drafts ago.
>

If box B sends back an ENO option, we know it's ENO aware, so we can choose
the behavior here; we just need to make sure it's consistent and knowable
by both endpoints. Why can't the semantics here be that B throws away the
SYN data if it disagrees with A on app awareness? Are there situations
where the two endpoints could disagree on this determination?

If this works, then in the steady state (both endpoints are either
app-aware or not) clients will be able to send SYN data to known ENO-aware
servers, while in the rollout case (A and B don't agree on app awareness)
SYN data will be thrown away by B and known by A to have been thrown away.

I still don't have a good feel for what folks like Joe are recommending re:
dealing with a B that doesn't understand ENO. If B is suddenly not
ENO-aware, by the spec it could deliver garbage data to the application
upon completion of the 3WHS; is this okay under an assumption that B should
*not* suddenly be unable to understand ENO, or do we need explicit
signaling from a prior connection to the same IP saying "SYN data is okay
upon resumption", or is even that not good enough?

A lot of this would be resolved if we updated TCP to say that a server MUST
not ACK, buffer, or deliver SYN data unless this behavior is overridden by
some negotiated extension (like TFO or ENO), in which case the treatment of
such data is extension-specific. The ship has probably sailed on that one,
but it's interesting that this is essentially what 4987 states, as I posted
at the top of the thread:

q( If data accompanies the SYN segment, then this data is not
   acknowledged or stored by the receiver, and will require
   retransmission. )

Kyle