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

[Eric Rescorla <[e-mail]>]

On Wed, Aug 26, 2015 at 10:28 PM, David Mazieres <
[e-mail]> wrote:

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