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? Kyle On Thu, Aug 27, 2015 at 12:13 PM, David Mazieres <[email protected]> wrote: > Mirja Kühlewind <[email protected]> writes: > >> Don't you need anyway an internal interface to say that tcp-eno has to >> set the "b" bit? >> >> That's simply saying to tcp-eno that this side will be the host A. Isn't this >> sufficient? Or do I miss something? > > You need both a local interface to set the role, and a bit on the wire > to verify that the remote application set is role compatibly. Isn't > that the minimum necessary to break the symmetry of simultaneous open? > Anything less risks complete connection failure (not just fallback to > plaintext) when the tie is incorrectly broken. > > David > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
