Kyle Rose <[email protected]> writes:
> I think maybe what Mirja is implying is that it's okay to break TCP
> (i.e., not fall back to unencrypted) if the two peers explicitly set
> their roles locally to the same thing. TCP-ENO-aware applications that
> set the role are assumed to get it right and not set both to A or both
> to B.
>
> Question re: the WG goals: is it in fact okay not to always fall back
> to unencrypted TCP if the applications themselves are aware of TCPINC
> and relying on TCPINC-specific API calls?
So to be pedantic here, we are now assuming a design with three local
states for each side, let's call them NULL, A, and B. If both sides of
a simultaneous open are NULL (the default) you get unencrypted TCP. If
one side is A and the other is B, you get TCP-ENO. In the other 6
permutations, you get complete connection failure.
I don't particularly love that or foresee getting a WG consensus behind
it, but I guess I could live with it. Moreover, it doesn't really
address any of the "hot" TCP-SO questions at this point, which are:
1. Does TCP-SO really exist in the wild, and if so under what
circumstances (NAT, no NAT, etc.)?
2. If applications of TCP-SO exist, must TCPINC support them
unmodified, or is it okay to disable encryption in the absence of a
setsockopt on at least one end of the connection?
3. If we require a setsockopt to encrypt a TCP-SO connection, is it
okay to ask applications to break the tie as well?
For my part, I'm beginning to have doubts about 1, but answer YES to 2
and 3.
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
