On Thu, Aug 27, 2015 at 10:32 AM, David Mazieres < [email protected]> wrote:
> 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.)? > TCP-SO definitely exists in the wild. We do it in Firefox's ICE stack. -Ekr > 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
