Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Wed, 08 March 2017 05:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDABC1293E8 for <>; Tue, 7 Mar 2017 21:45:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QJ1oM3j7wlLH for <>; Tue, 7 Mar 2017 21:45:38 -0800 (PST)
Received: from ( [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 08A01126B6D for <>; Tue, 7 Mar 2017 21:45:38 -0800 (PST)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id v285jbcb057786; Tue, 7 Mar 2017 21:45:37 -0800 (PST)
Received: (from dm@localhost) by (8.15.2/8.15.2/Submit) id v285jbaJ005687; Tue, 7 Mar 2017 21:45:37 -0800 (PST)
To: Wesley Eddy <>,
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 07 Mar 2017 21:45:37 -0800
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: David Mazieres expires 2017-06-05 PDT <>
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:45:39 -0000

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

I would ideally like to use RFC793 as much as possible as a
"subroutine," because your suggestion of specifying exactly what must be
in the RST segment risks contradicting RFC793.  Hence, my idea that you
can transition to CLOSED and pretend you were closed when you got the
segment.  By maybe I should say "CLOSED or LISTEN" (in keeping with
RFC793), or maybe this is a bad idea for some other reason, so I'd
appreciate some feedback from the list on how best to do this.  Any
feedback helps, but specific wording suggestions are even better...