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

Eric Rescorla <> Fri, 28 August 2015 17:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7C6151A1A86 for <>; Fri, 28 Aug 2015 10:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OPeu3KCQ3VrJ for <>; Fri, 28 Aug 2015 10:15:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 508471A01FC for <>; Fri, 28 Aug 2015 10:15:32 -0700 (PDT)
Received: by wiae7 with SMTP id e7so2964248wia.0 for <>; Fri, 28 Aug 2015 10:15:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2ofXiQb96toxiw5Ki95dsq/bydN9PE1wkxhmSYHOJU0=; b=eY0nUE5RqRjAe8zKnkaMrtJgtxcDPotVv/NVr9RU5ztuMpIeEV06oPk7GAYsE72uL4 n4e3wVDMvJXmHUaDOD4n5QergpEbgcRaujUw4zPjL462QU6w7O4UnfIQlDMeJuNHsm+E yLHaQUYxAaTjCp9BoErIvDTXuybzuTgIBlY8x9INAVhPlGdhkljL8SBjPg54Yr5bJsVZ QfZPhiOx2coV2qmH/JweI7T72dW6H1e3NLSRk+8Fp2GoC74hU0rZ9kKP0rsx/8WTx36x PidWBtRn2rjP9TYDQXHzI5PJFRnGAYWGpNYX95rNnUJbmWcLgZJ29sYj3G8zV4DJnWC4 iXWA==
X-Gm-Message-State: ALoCoQmdLfNmiOVqzdBQn9eLDaG/DoHtfsxn1W2y0UDsoYKenSqeopya8qT0SdFAQVgaLBeXfK9y
X-Received: by with SMTP id oo4mr12117865wjc.81.1440782131018; Fri, 28 Aug 2015 10:15:31 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 28 Aug 2015 10:14:51 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Fri, 28 Aug 2015 10:14:51 -0700
Message-ID: <>
To: David Mazieres expires 2015-11-24 PST <>
Content-Type: multipart/alternative; boundary="089e0141a0921e7233051e623bad"
Archived-At: <>
Cc: tcpinc <>
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 17:15:35 -0000

On Wed, Aug 26, 2015 at 10:28 PM, David Mazieres <> wrote:

> Eric Rescorla <> 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
signaling because you can't publish something and have it be valid 10
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: (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"?

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