Joe Touch <[email protected]> writes:
> 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).
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.
Reactions/opinions?
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
