Christoph Paasch <[email protected]> writes: > Hello, > > I have read through the TCP-ENO draft and have a few comments: > > > First, am wondering whether there might be an issue when the third ACK > gets lost. > > Specifically, the draft says that a host MUST disable ENO if the > following condition is met: > > 4. The first ACK segment received by a host does not contain an ENO > option. > > So, if this ACK gets lost, and the client goes on with sending > (encrypted) data, the server won't be able to know whether ENO has > been successfully negotiated or not and how to interpret the data. > > To overcome this, one possible way would be to include the ENO-option > in every data-segment that a host is sending after the 3-way handshake > until successful use of ENO has been confirmed by the receiver.
Indeed, this is a good point. The idea is really that you MUST include the ENO option whenever you ACK a SYN segment. The problem is that the ACK might be cumulative. So we would like flows to look like this: A -> B: SYN ENO B -> A: SYN-ACK ENO A -> B: ACK ENO (lost) A -> B: ACK ENO* data The draft is not at all clear about the need for the ENO marked by *. Your suggestion is one way to fix this. > But even then, there might be a middlebox that removes the ENO-option > from non-SYN segments (assuming that we want to support such kind of > middleboxes). The sender will thus send encrypted data with the > ENO-option. The receiver receives this encrypted data without the > ENO-option (due to the middlebox stripping the option) and thus will > assume that the data is unencrypted. (for the background, this kind of > behavior is the reason why MPTCP makes sure to only send in-order data > in the first few segments, until middlebox-support has been confirmed > as it allows to fallback to regular TCP) This is one reason we would love to collaborate with someone who has very concrete middlebox experience (hint hint), at the very least on a TCP-ENO Middlebox Probing document, if not on ENO itself. We have not observed stripping from SYN but not non-SYN segments, and agree it would be annoying. Currently we would deal with this in the same as DPI--probe the middlebox at DHCP lease time and disable ENO if the middlebox is not compatible. However, if such middleboxes are common enough, then we might need to support them. Such middleboxes are kind of pernicious, since a lot of options are first negotiated in SYN segments then used later. Hence, if they exist but are not too common, I would be okay with disabling encryption, so long as connections don't fail entirely or get garbled. > This kind of means that we would need to do a 4-way handshake where > data can only be sent after it has been confirmed on non-SYN segments > that ENO is enabled. Maybe there is a better solution to it? There are other solutions, though it's not clear if they are better. The 4-way handshake could be compressed by sending a SYN-ACK and plain ACK back-to-back (so at least it doesn't incur an extra 1/2 round trip in the common case). Or we could do it probabilistically, including 4-8 bytes of randomness in the ENO options that then get hashed along with some magic number and included in the TCP payload data. That's kind of yucky. > Second, there are loadbalancers out there (used by baidu.com > <http://baidu.com/> in particular) that echo unknown TCP options. As > far as I can tell, TCP-ENO won't be able to handle this situation > gracefully, as an active opener will interpret the ECHO'd option as > valid. The P-bit seems to allow to resolve this situation as the > client would receive a TCP-ENO option with the P-bit set on a SYN/ACK > segment. But, the P-bit is currently not part of the option thus I > think it would be good to include it. That's another very useful point we didn't know about. The p-bit is currently implicit, but we could get rid of it and rely entirely on the explicit b bit. That would have the added advantage of simplifying role negotiation at the cost of sometimes consuming an extra byte of option space in the SYN-ACK segments. Thanks for the useful feedback. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
