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

Mirja Kühlewind <> Thu, 27 August 2015 08:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8B12A1B3B48 for <>; Thu, 27 Aug 2015 01:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3QlhuBsDdBx8 for <>; Thu, 27 Aug 2015 01:55:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2EDB51B2F64 for <>; Thu, 27 Aug 2015 01:55:05 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CF19D9321; Thu, 27 Aug 2015 10:55:04 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id vV9MLl2YC2Va; Thu, 27 Aug 2015 10:55:04 +0200 (MEST)
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by (Postfix) with ESMTPSA id 034CED9310; Thu, 27 Aug 2015 10:55:03 +0200 (MEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Mirja Kühlewind <>
In-Reply-To: <>
Date: Thu, 27 Aug 2015 10:55:05 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: David Mazieres expires 2015-11-24 PST <>
X-Mailer: Apple Mail (2.2102)
Archived-At: <>
Cc: Eric Rescorla <>, 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: Thu, 27 Aug 2015 08:55:07 -0000

Hi David,

I believe the point is, if you have already broken the tie via out-of-band signal and both endpoints have already decided who will be the opener (host A) and responder (host B), why do you still need to write this information in the tcp-eno option if this information is already known to the host?


> Am 27.08.2015 um 07:28 schrieb David Mazieres <>:
> 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.  But if it can, then a simplified packet
> trace would be super helpful to this discussion.
>>> 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 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.
>> I agree with this as well and I agree that #2 is a viable position. The open
>> issue for me is whether the "b" bit actually accomplishes that goal.
> Well, it looks like this:
>    A -> B:  SYN ENO<b=0>
>    B -> A:  SYN ENO<b=1>
>    A -> B:  ACK
>    B -> A:  ACK
> You might argue that applications won't break the tie properly, but I
> don't see why you think the "b" bit wouldn't work if they do.
>>> 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.
> Thanks,
> David
> _______________________________________________
> Tcpinc mailing list