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

Joe Touch <> Wed, 08 March 2017 06:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76BDC129418 for <>; Tue, 7 Mar 2017 22:24:14 -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 gFWjNhar7Y-i for <>; Tue, 7 Mar 2017 22:24:13 -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 00A3E1293D9 for <>; Tue, 7 Mar 2017 22:24:12 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v286NTk1011091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Mar 2017 22:23:31 -0800 (PST)
To: David Mazieres expires 2017-06-05 PDT <>, Wesley Eddy <>,
References: <> <> <> <> <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Tue, 07 Mar 2017 22:23:29 -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="utf-8"
Content-Transfer-Encoding: 8bit
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, 08 Mar 2017 06:24:14 -0000

On 3/7/2017 10:12 PM, David Mazieres expires 2017-06-05 PDT wrote:
> Joe Touch <> writes:
>> On 3/7/2017 9:45 PM, wrote:
>>> Wesley Eddy <> writes:
>>>>>          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.
>>> I'm trying to tie up loose ends here, and think this is the only
>>> relevant point from the mailing list that we may have not yet have
>>> satisfactorily addressed in our working draft.  Several points in
>>> section 4.7 use the term "reset the connection."  I've now attempted to
>>> define the term more pedantically the first time I use it.  Here's the
>>> new language:
>>>    If a host sends a SYN+ENO segment with data and receives
>>>    acknowledgment for the data, but the SYN TEP governing the data is
>>>    not the negotiated TEP (either because a different TEP was negotiated
>>>    or because ENO failed to negotiate encryption), then the host MUST
>> FWIW, I would just jump right to the following, which avoids giving
>> unnecessary detail:
>>    abort the connection. Proceeding in any other fashion risks
>> misinterpreted SYN data.
> Thanks, that's how we had it before (well, "reset the connection" was
> what we had before).  But Wesley made me worry that the phrase "reset
> the connection" might not be specific enough.  Is "abort" better than
> "reset"?
Per RFC793:

Abort is an event that the TCP API implements (and can be called by
users, the OS, etc.).

Reset is a message that TCP issues/receives, and happens within the
protocol in reaction to message receipt, timer expiration, or API events.

This is why "reset the connection" is imprecise, whereas "abort the
connection" is not. ;-)

>>>    reset the TCP connection by transitioning to TCP's CLOSED state and
>>>                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>    responding to the acknowledgment with a reset segment as if the
>>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>    connection had never existed.  Proceeding in any other fashion risks
>>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>    misinterpreted SYN data.
>> If you do say which state to end up in, I would think you would want to
>> transition to TIME-WAIT, otherwise the connection could reopen using the
>> same socket pair and you may have a hazard condition.
>> See: T. Faber, J. Touch, and W. Yue, “The TIME-WAIT state in TCP and Its
>> Effect on Busy Servers <>,” in
>> /Proc. IEEE Infocom/, 1999, pp. 1573-1583.
> Right, this is exactly why I'm worried about getting too specific.  What
> I want to say is something like "abort the connection" with an implicit
> reference to best current practice.  If most people think "abort the
> connection" or "reset the connection" is unambiguous, then I'll go with
> that.
> Is there a reason you said "abort" rather than "reset"?  I was thinking
> reset might be better because of reset generation, but would defer to
> you on which word is better.

There is. See above.