On 7/24/2016 4:45 PM, Kyle Rose 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).
Data in the SYN can be:
- ACKd, but then it MUST be cached and delivered to the application
at the completion of the 3WHS (and not before)
- not ACKd (i.e., ACK only the SYN but not the data) but then it
MUST be discarded until it is retransmitted
Either behavior is valid in the absence of TFO. Dropping the SYN data
protects against DOS attacks that could overload servers, but a server
can easily protect itself by ACKing SYN data only until space becomes
limited. Keeping the data can be more efficient and reduce latency in
some cases.
TCP options should assume this behavior unless *they* redefine it (e.g.,
TFO).
Middleboxes MUST not interfere with this behavior (or any TCP behavior,
FWIW).
Joe
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
