Re: [tcpinc] draft-bittau-tcpinc-tcpeno-02

Joe Touch <> Mon, 21 September 2015 22:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 910EE1AC445 for <>; Mon, 21 Sep 2015 15:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KbYGCIF2702V for <>; Mon, 21 Sep 2015 15:09:30 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0274F1AC442 for <>; Mon, 21 Sep 2015 15:09:29 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t8LM8qNS008439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 21 Sep 2015 15:08:53 -0700 (PDT)
To: David Mazieres expires 2015-12-19 PST <>, "Scharf, Michael (Michael)" <>, tcpinc <>
References: <> <>
From: Joe Touch <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Mon, 21 Sep 2015 15:08:51 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: t8LM8qNS008439
X-ISI-4-69-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [tcpinc] draft-bittau-tcpinc-tcpeno-02
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: Mon, 21 Sep 2015 22:09:31 -0000

On 9/20/2015 12:58 PM, David Mazieres wrote:
> "Scharf, Michael (Michael)" <> writes:
>> * Section 2, page 4: "Provide signaling through which applications can
>> better take advantage of TCP-level encryption (for instance by
>> improving authentication mechanisms in the presence of TCP-level
>> encryption)." Since authentication is listed here: How does this
>> option interact with TCP-AO? For instance, I think this document could
>> perhaps discuss what a receiver may do if a SYN segment both with
>> TCP-ENO and TCP-AO options is received. This is a question much closer
>> to the SYN handshake negotiation mechanics than various other sections
>> of the document.
> The higher-layer authentication taking advantage of TCP-level encryption
> is at a higher layer than TCP-AO. 

This is very confusing to me. There are four layers in a TCP segment:

	- link (e.g., WiFi WEP)
	- network (e.g., IPsec)
	- transport (e.g., TCP-AO or TCP-ENO-negotiated protection)
	- application (e.g., SSL)

> In particular, it would take place by
> exchanging bytes over the TCP connection itself.  Hence, I see only one
> reasonable approach:  First check TCP-AO.  If TCP-AO discards the
> packet, then TCP-ENO is irrelevant.  Otherwise, proceed as usual with

See my other message.

Also note that TCP-AO covers the TCP options only as a choice; it should
be made clear whether leaving that choice open is compatible with
TCP-ENO. See Section 9 of RFC5925.

Even though it is experimental, interaction with TCP-AO-NAT should
probably also be addressed (RFC6978).

>> * Section 8: Why does TCP-ENO not allocate an TCP Experimental Option
>> Experiment Identifier according to RFC 6994? That would be an easy
>> solution to enable experiments with multiple interoperable
>> implementations over the Internet, prior to assignment of a TCP option
>> kind number. Keep in mind that an experimental document requires an
>> explicit IESG action for TCP option kind assignment. In the past, TSV
>> has asked for this IESG action several times. In those cases, there
>> has been very strong consensus in the corresponding working group
>> regarding the codepoint assignment, backed by reasonable interest by
>> TCP stack vendors in the protocol.
> The WG has debated this point before, and there didn't seem to be
> consensus. Some favor experimental option kinds.  Others believe this
> will cause problems when we switch from experimental to regular.  (If I
> recall, an example of that problem was NAT-T.)
> The reality is that we've been using option kinds 69 and 70 in the wild
> for encryption for many years, in software that's available for several
> OS distros.  Before that, options 16 and 17 were allocated to encryption
> and could safely be reused given that the old encryption scheme is no
> longer or was never in use.  IANA has marked 69-70 as "Reserved (known
> unauthorized use without proper IANA assignment)." 

IANA marked *all* unused TCP option kind codepoints as RESERVED. The
only thing different about some of the code points is that they are also
marked as having at least one known, unauthorized use.

You're assuming that you're the only ones who used that codepoint.

Given how you squatted on them without permission or coordination, I
find that amusing.