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

David Mazieres <> Fri, 28 August 2015 20:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 01FEE1A8766 for <>; Fri, 28 Aug 2015 13:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.91
X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rY72_VZDWQY2 for <>; Fri, 28 Aug 2015 13:22:30 -0700 (PDT)
Received: from ( [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6EA921A1EFE for <>; Fri, 28 Aug 2015 13:22:30 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id t7SKMU5X012920 for <>; Fri, 28 Aug 2015 13:22:30 -0700 (PDT)
Received: (from dm@localhost) by (8.14.7/8.14.7/Submit) id t7SKMTJl010309; Fri, 28 Aug 2015 13:22:30 -0700 (PDT)
X-Authentication-Warning: dm set sender to using -f
From: David Mazieres <>
To: tcpinc <>
In-Reply-To: <>
Date: Fri, 28 Aug 2015 12:21:54 -0700
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Aug 2015 20:22:32 -0000

Eric Rescorla <> 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: (host), (srflx)
> B: (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.