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

Wesley Eddy <> Mon, 27 February 2017 02:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35F56129A8E for <>; Sun, 26 Feb 2017 18:39:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ztcUfYWBT8BO for <>; Sun, 26 Feb 2017 18:39:10 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B74D5129618 for <>; Sun, 26 Feb 2017 18:39:10 -0800 (PST)
Received: by with SMTP id u188so77975580qkc.2 for <>; Sun, 26 Feb 2017 18:39:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=SaWkSOYLOk+7nO61UIHtGLH6D0RHR7TEMnR25lsW0iA=; b=A9RWoecvMZibSqPl+OQKlbyN8F/imRzNqYjiVd9sVvFmHSdlP52MHciAEwgmLcP4h9 4XIXmRAeoIV4R/hDJgBuys1YM1Q99ZLv7Rz6mJuP0LixmZTjvSpYk9etZgt6nBhw5Xwy WxXj+g6DuFyzzEvSjaLqUQe6aVSQ8svWuEevBCXxpxsqnIrJeNE44980CdIixitBKBUV XmC3PDI7QtJGqZYbWD7AkxWISn4alfQgAjxdO70lD0qL3TvxiXwwkwqN4K7ayhJOoAYX 2oKpCnL26nU21NbV7Bk70bcsTb0PcHQvF4p5JzWIZiHt07AKywshuaT5en8dS2W+2B7v 36Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SaWkSOYLOk+7nO61UIHtGLH6D0RHR7TEMnR25lsW0iA=; b=le2bxBCjapXbm6Kla4Lk1uNGmJHH5bXdtYbCUB4d89LWdeopIZZFwUTAFYJwpcKR2Q 6IDcGx5DtIIJhLZaDWUIAVNv/x16jFYiQvBBt8HaA/QrAqeDWN4no/ilhn6vdPi7fVdn XlN+T4MDKdHgjNjek1jJaLCwOsqWrek8TzlA97B92vq8hMK+Z97dkYW8SxFO+rieRrM3 scHfYF+A5r9PJwyBlD9droFXezvuT560IzHgiY1ihCT5+wuJT6KxpN4HH+SIXdNbHf4y dB3Yvt1vzeIAMnY24yQ+wmIxNjYCO+QG2rqNF/7PaaxNijWB7KizB7HWP9XsqDbg864F koGg==
X-Gm-Message-State: AMke39k2z+9d+myIqEgu/OZk3mEcdJ6ILhd3sHljIRfcGHN572eDTKPEiTsIig9E1UbctQ==
X-Received: by with SMTP id q38mr6496274qtg.126.1488163149604; Sun, 26 Feb 2017 18:39:09 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id e16sm9588900qkj.64.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Feb 2017 18:39:09 -0800 (PST)
To: David Mazieres expires 2017-05-23 PDT <>,
References: <> <> <>
From: Wesley Eddy <>
Message-ID: <>
Date: Sun, 26 Feb 2017 21:39:02 -0500
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"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Mon, 27 Feb 2017 02:39:12 -0000

On 2/22/2017 1:58 PM, 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...

Saying "reset the connection" is interesting to me, because technically 
there is not yet any connection (there are TCBs at each side, but 
neither has entered ESTABLISHED state).  The reset that's sent should 
probably *not* acknowledge any data that may have been on the SYN-ACK, 
which seems important to state.  That way, if some application's 
transaction erroneously started due to data on the SYN, any response 
piggybacking the SYN-ACK would not be acknowledged, and the RST should 
cause the application transaction to fail.

>          To avoid unexpected connection resets, ENO implementations MUST
>          disable the use of data in SYN-only segments by default.

In my opinion, it might be better to disable the use of data in SYN-only 
segments unless the peer's ENO capability is already known through some 
means (e.g. TCB cache from prior connections).