Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

Joe Touch <> Wed, 22 February 2017 19:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8B621299BA for <>; Wed, 22 Feb 2017 11:17:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KPhNfxan-DKy for <>; Wed, 22 Feb 2017 11:16:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AAB2F129965 for <>; Wed, 22 Feb 2017 11:16:59 -0800 (PST)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v1MJGJQj012708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Feb 2017 11:16:20 -0800 (PST)
To: David Mazieres expires 2017-05-23 PDT <>, Wesley Eddy <>,
References: <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Wed, 22 Feb 2017 11:16:18 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Feb 2017 19:17:01 -0000

On 2/22/2017 10:58 AM, David Mazieres wrote:
> Wesley Eddy <> writes:
>> 1) edge cases where you're communicating with non-ENO hosts, that do not 
>> discard data on SYNs (for whatever reason), and may pollute the data 
>> stream delivered to the application, breaking the goals of TCPINC to 
>> work without impacting the application's TCP mapping
>> 2) cases where other TCP extensions (perhaps yet to-be-defined) do 
>> something in conflict with that data
> Can you make concrete suggestions for wording changes?  In particular,
> we intended to address the points you raised with the following language
> of section 4.7:
> 1)
>         If a host sends a SYN-only SYN+ENO segment bearing data and
>         subsequently receives a SYN-ACK segment without an ENO option,
>         that host MUST reset the connection even if the SYN-ACK segment
>         does not acknowledge the SYN data...
>         To avoid unexpected connection resets, ENO implementations MUST
>         disable the use of data in SYN-only segments by default.

It might be useful to explain the rationale briefly.

It might also be useful to explain what happens next. AFAICT, the reset
should just terminate the connection. I.e., a TCP ENO implementation
MUST NOT internally retry a failed ENO connection with a non-ENO
connection (it would break the semantics of of the TCP API to do so with
different source port numbers because the user might have pinned them,
and you can't wait for a retry because that would cause the API to stall
longer than TCP SYN timeouts expect).

> 2)
>         More specifically, a host that implements ENO MUST discard the
>         data in a received SYN+ENO segment if any of the following
>         applies:
>         ...
>         * The SYN segment contains a non-empty TFO option or any other
>           TCP option implying a conflicting definition of SYN data.

MUST discard the data
MUST NOT cache the data, even if not ACKd

And, IMO, SHOULD refuse the connection (the other end is clearly asking
something that could be dangerous and if they don't know better, you
might be better off not trusting that connection to continue)