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

[David Mazieres <[e-mail]>]

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 very much
want to understand the point, because I think it might warrant changes
to TCP-ENO.  Can you possibly walk me through a simple example where
TCP-SO can work without an in-band "b" bit or tie-breaker value?

>> 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.

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.

>> 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]."  And then
RFC5626 talks about TCP but not simultaneous open.  So far, RFC5382 and
RFC6544 are the only modern RFCs I've found discussing TCP-SO.

David