Eric Rescorla <[email protected]> writes: > I think we're finally getting to the place where we have been > misunderstanding each other. We have some mechanism in the signaling > which attempts to break the symmetry and assign one side as A and one > as B. If that mechanism works, then no signaling in TCP is > necessary. However, if that mechanism does not work, then you have > three main choices: > > 1. Allow things to just fail. > 2. Have a mechanism to detect failure and then fall back to ordinary TCP. > This is what the "b" bit primarily does. You could also do this by having > the negotiated security protocol detect that both sides thought they > were (A) or (B) and then discard the handshake and fall back to ordinary > TCP. > 3. Have a mechanism to resolve the conflict. This is what a larger > tiebreaker > like the one in TCP-use-TLS or the one in ICE does. > > Does that seem like a fair summary of the situation?
Indeed, if Mirja was thinking #1, I was thinking #2, and you were thinking #3, then this all makes sense. Frankly, I could live with any of the three, so long as some application action is required. The only thing I strongly oppose is having to support encrypted simultaneous open without some non-default setting by the connecting application. In the absence of a TCP-SO application that can use TCPINC, I'm in favor of doing the minimum work possible for TCP-SO, which I thought was #2, but maybe is #1. If you strongly prefer #3, we can easily make TCP-ENO support it either before or after adoption. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
