Hi, David, On 7/28/2016 1:16 PM, David Mazieres wrote: >> 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.
As with investment, past behavior is not a guarantee of future performance. "Believe", but verify. > * 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. IMO, the 3WHS supports offering capabilities and letting the other end decide to confirm them. It does not allow for offers to be rescinded. That would require another 3WHS, which can be done only inside a specialized option (but it's a mess and should be avoided at all cost). > > At this point host B would have to discard the data, since it includes > ciphertext. Strictly, whatever B ACKs MUST be delivered. So the solution is simple - if you think this behavior needs to be supported as part of the exchange, then (in the third step above) host B MUST ACK only the SYN and discard the data. > 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. Within your option, you can require that TCP's that support ENO MUST discard SYN data. But you need to allow for legacy receivers that behave otherwise, as long as they also don't support ENO. > 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. See above; I see only one way out here. Joe
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
