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

[Kyle Rose <[e-mail]>]

On Wed, Jul 27, 2016 at 1:35 PM, David Mazieres <
[e-mail]> wrote:

> What I had in mind was something along the lines of saying that the last
> TEP suboption in host A's SYN segment is the SYN TEP, and that host B
> MUST ignore and MUST NOT ACK any data in SYN segments unless the
> negotiated TEP is the SYN TEP and that TEP explicitly defines the use of
> data in SYN segments.  Furthermore, SYN data MUST be discarded in the
> event that TCP-ENO is disabled, even when such data has already been
> ACKed.  TEPs MAY define the use of data in SYN segments for when they
> are the SYN TEP, but SHOULD limit such usage to cases in which it is
> known that the passive opener and network path both support ENO.
>

It's interoperability with older stacks that drove my question: if there
are multiple machines behind an IP, some of which support ENO and some of
which don't, do we break the charter by sending *any* data in the SYN
(outside of TFO, which as we've established is unusable for tcpinc)?

The charter says: q( The protocol must gracefully fall-back to TCP if the
remote peer does not support the proposed extensions. )

If TCP's behavior in the absence of a TFO cookie is to discard data in the
SYN, normatively and (especially) observationally, then your second
sentence ("Furthermore, SYN data MUST be dscarded...") is true when a host
doesn't support ENO, and so we can safely put whatever we like in the SYN.

If not, then unexpected data in the SYN *might* be forwarded to the
application as garbage by some TCP stacks, resulting in mostly-undefined
behavior but almost certainly connection breakage; in that case, do we need
some explicit signaling from the server on a prior connection for when SYN
data on resumption attempts is okay, or is "...but SHOULD limit such
usage..." good enough?

Kyle