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

Joe Touch <> Wed, 08 March 2017 05:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27C761293F9 for <>; Tue, 7 Mar 2017 21:52:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 w9af5F_scRjW for <>; Tue, 7 Mar 2017 21:52:40 -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 7DE5F1293D9 for <>; Tue, 7 Mar 2017 21:52:40 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v285q6jl006003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Mar 2017 21:52:08 -0800 (PST)
To: David Mazieres expires 2017-06-05 PDT <>, Wesley Eddy <>,
References: <> <> <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Tue, 07 Mar 2017 21:52:05 -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: multipart/alternative; boundary="------------D8394AEB4A080AF46A4ADF41"
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 05:52:42 -0000

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.

>    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.