Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
Joe Touch <touch@isi.edu> Wed, 08 March 2017 05:52 UTC
Return-Path: <touch@isi.edu>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C761293F9 for <tcpinc@ietfa.amsl.com>; Tue, 7 Mar 2017 21:52:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9af5F_scRjW for <tcpinc@ietfa.amsl.com>; Tue, 7 Mar 2017 21:52:40 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE5F1293D9 for <tcpinc@ietf.org>; Tue, 7 Mar 2017 21:52:40 -0800 (PST)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (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 <mazieres-b3puawqzytcd7dzhf5sqyiyb62@temporary-address.scs.stanford.edu>, Wesley Eddy <wes@mti-systems.com>, tcpinc@ietf.org
References: <CAJU8_nUGxd0yo2htZg6LY_gSHy8xAjSOY9w4zKFLbVDw+CtZDg@mail.gmail.com> <16c01c14-0896-c8fd-d7c4-e1dd7254420f@mti-systems.com> <87y3wyaw7o.fsf@ta.scs.stanford.edu> <9f7dd5ae-79b0-41fe-0601-674476cc7f6a@mti-systems.com> <878togwcce.fsf@ta.scs.stanford.edu>
From: Joe Touch <touch@isi.edu>
Message-ID: <331e9ec1-0693-e987-29ef-6bfde3c93fc4@isi.edu>
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: <878togwcce.fsf@ta.scs.stanford.edu>
Content-Type: multipart/alternative; boundary="------------D8394AEB4A080AF46A4ADF41"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/uPdT1C6tPLgfzc25HUpZeo88zh4>
Subject: Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Mar 2017 05:52:42 -0000
On 3/7/2017 9:45 PM, dm-list-tcpcrypt@scs.stanford.edu wrote: > Wesley Eddy <wes@mti-systems.com> 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 <http://www.isi.edu/touch/pubs/infocomm99/>,” in /Proc. IEEE Infocom/, 1999, pp. 1573-1583. Joe
- [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Kyle Rose
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Wesley Eddy
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Joe Touch
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno David Mazieres
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Joe Touch
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Wesley Eddy
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno dm-list-tcpcrypt
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Joe Touch
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Joe Touch
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Joe Touch