Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[[e-mail]]

Eric Rescorla <[e-mail]> 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