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

[Yuchung Cheng <[e-mail]>]

On Sun, Jul 24, 2016 at 4:45 PM, Kyle Rose <[e-mail]> wrote:
>
> In the absence of a TFO cookie, what is the behavior of TCP in the presence of data in the SYN packet? The ability of ENO to send early data on session resumption to servers that potentially don't understand ENO depends on the servers throwing this data away so it can be replaced in the following ACK.
>
> RFC 4987 section 3.5 (https://tools.ietf.org/html/rfc4987#section-3.5) states that:
>
> q( If data accompanies the SYN segment, then this data is not
>    acknowledged or stored by the receiver, and will require
>    retransmission. )
>
> But I have read elsewhere that the server might queue it up and wait for the 3WHS to complete (though if it is conformant, it will ACK only a single byte for the SYN and have the blob retransmitted by the client anyway).

We did some tests with this when during TFO development. AFAIK Linux,
*BSD/iOS, Windows all return a SYN that acks only the ISN but not the
data. None of them queues the data hence the active side needs to
retransmit the data. But my knowledge is 5 years old.

FWIW I and other TFO developers in other stacks (cc'd) have all found
that some middle-boxes will crash or hang on receiving SYN-data
(regardless of TFO cookie option or not). For instance, I found a bug
in Linux netfliter that the conntrack module assumes SYN never carries
data, so the internal sequence was only incremented by one on SYN-data
packe, and led to rejecting every packet afterward. Others have found
FW blocking the IP completely (see last meetings material by Praveen).
We were talking about putting a TFO-bis on these issues.

>
> I guess I'm interested in both normative and observed behavior. I'm happy to inquire elsewhere if someone has a suggestion. (tcpm?)
>
> Kyle
>
>
> _______________________________________________
> Tcpinc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpinc