Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[Eric Rescorla <[e-mail]>]

On Fri, Aug 28, 2015 at 12:21 PM, David Mazieres expires 2015-11-26 PST <
[e-mail]>
wrote:

> Eric Rescorla <[e-mail]> 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