On Wed, Aug 26, 2015 at 10:28 PM, David Mazieres < [email protected]> wrote:
> Eric Rescorla <[email protected]> writes: > > > Note: you can't really build a reliable NAT traversal system where you > > use STUN to learn your public address and then register it because > > too many NATs have unstable bindings or require you to open pinholes. > > We tried that and it didn't work which is why ICE is the way it is. > > Can you demonstrate simultaneous open without stable NAT bindings? I > don't see how that could work. The issue is how stable they are over time. My point is that you need real-time signaling because you can't publish something and have it be valid 10 minutes later, not that it's not stable over 5-15 second intervals. >> If you remove the b bit from TCP-ENO, there will be pairs of hosts that > >> can communicate via simultaneously opened TCP connections that cannot > >> use TCP-level encryption. > > > > OK, I don't understand that. Can you please provide an example of a case > > where the "b" bit helps that the sides couldn't have already broken the > > tie via out-of-band signaling. > > I'm not sure I understand your comment. The "b" bit assumes the > applications have broken the tie via out-of-band signaling. It is the > mechanism that permits you to have encryption when applications break > the tie. So no "b" bit means no encryption on simultaneous open, ever. I don't think that's true. See Mirja's point below. > > I haven't seen anyone argue that the b bit fails to achieve its goal. > > > > That's precisely what I am arguing with the example above. > > So to be clear, the goal is that if applications can break the tie, the > "b" bit allows encryption with simultaneous open. If you believe > there's a case where simultaneous open will still fail to encrypt, even > with the "b" bits correctly set, can you break it down on a > packet-by-packet basis (for the first 4 packets of the connection)? > Such a four-segment example with two SYNs and two ACKs would really > advance the debate. In order to assess the issue, you actually need to see how it interacts with the NAT traversal algorithm. Here's the example I sent before, with the following NAT topology. A: 10.0.0.1 (host), 198.51.100.1 (srflx) B: 192.0.2.1 (srflx and host). A Signaling B STUN STUN Check -------------------------> Host Cand ----> Host Cand --> <-- Candidate <--- Candidate SYN --------------------------------> X <---------------------- STUN Response What appears in the "b" bit in the packet marked with "X"? > >> Since TCPINC has been around for over a year and neither of the two main > >> candidate drafts has yet attempted goal #4, perhaps we should say that > >> fully-transparent encryption with simultaneous open is not a high enough > >> priority to delay TCPINC progress. If some subdelegation wants to > >> investigate the problem in parallel and report back with some data, > >> there's no reason the WG couldn't later move to accommodate the results. > > > > This seems like a good proposal. FWIW, the major applications that I > know of > > that use TCP-SO for NAT traversal have their own COMSEC anyway and > > in fact often treat TCP as if it were UDP. > > Ah... great. Sounds like progress. Also, do you mind sharing what > those major TCP-SO applications are? It would add some badly needed > context to this discussion. > The one I am mostly familiar with VoIP, whether of the SIP (3261, etc.) variety or WebRTC. In either case, you use ICE (RFC 5245, 6544) and try to set up a channel in parallel via both UDP and TCP (preferring UDP). -Ekr
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
