On Fri, Aug 28, 2015 at 12:21 PM, David Mazieres expires 2015-11-26 PST < mazieres-dyxeg4qpw8c44aeprmspr6f...@temporary-address.scs.stanford.edu> wrote:
> Eric Rescorla <[email protected]> writes: > > > On Wed, Aug 26, 2015 at 10:28 PM, David Mazieres < > >> 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. > > Ah, I see. So you are saying one key issue is effectively the existence > of "brief cone" NATs? That makes sense. > > >> 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. > > Yes, I still don't understand her point, unless we are willing to accept > total connection failure for misconfigured tie breaking. I am indeed willing to live with that. >> 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"? > > It looks like the packet marked X is an ordinary SYN segment sent as > part of a three-way handshake to a STUN server (which presumably has a > public IP address, though you don't list it). In that case, the b bit > is irrelevant. I suspect I just don't understand how to read your > diagram, but it doesn't appear to contain a TCP-SO flow. > This was supposed to go to B. Sorry about that. > But again, to make sure we are talking about the same thing, I'm not > necessarily saying ICE gives you enough information to set the b bit > correctly. I'm just saying that if you do set the b bit correctly > (though whatever means, including a modified ICE or signaling > mechanism), you will get TCPINC + TCP-SO. Well, it seems like the question is whether or not the "b" bit can be reliably set correctly, and in particular with the algorithm you propose based on IP. >> 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). > > Okay, so it mostly comes down to ICE? It's confusing because RFC5245 > says, "Note that ICE is not intended for NAT traversal for SIP, which is > assumed to be provided via another mechanism [RFC5626]." What that means is that you don't use ICE to set up SIP connections, but SIP uses ICE for NAT traversal for the RTP. -Ekr
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
