Re: [tcpinc] AD review of tcp-eno

Joe Touch <touch@isi.edu> Thu, 27 July 2017 14:25 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 79269127444; Thu, 27 Jul 2017 07:25:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhgT_leP1wg9; Thu, 27 Jul 2017 07:25:54 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 0DD30132167; Thu, 27 Jul 2017 07:25:54 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6REPSL3027120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Jul 2017 07:25:38 -0700 (PDT)
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, draft-ietf-tcpinc-tcpeno.all@ietf.org
Cc: tcpinc <tcpinc@ietf.org>
References: <55B07DA5-E274-4720-A919-83483094B9A0@tik.ee.ethz.ch> <80C705CD-8A24-49A9-A1B8-6FA7B2162941@kuehlewind.net>
From: Joe Touch <touch@isi.edu>
Message-ID: <baad59c7-03cb-738a-e1b9-185931fe96a2@isi.edu>
Date: Thu, 27 Jul 2017 07:25:27 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <80C705CD-8A24-49A9-A1B8-6FA7B2162941@kuehlewind.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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/ZCh4gXNNbH1Kx8J6z_nrhNuC6G0>
Subject: Re: [tcpinc] AD review of tcp-eno
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 27 Jul 2017 14:25:56 -0000

On 7/27/2017 6:14 AM, Mirja Kuehlewind (IETF) wrote:
> ...
>> I’m afraid we need a new revision before IETF Last Call because the RFC should only specify the actually TCP option and not the experimental one. So you can simply remove the experimental one in Figure 1, 2 and 3 (as well as sec 4.8) and only note in the IANA section that this experimental assignment also exists, as it is already done.
First, as an Experimental RFC, I don't think it would be appropriate to
assign a codepoint that requires a standards-track doc.

Second, regardless of whether the IESG decides to override that
requirement, this document needs to address how to handle packets with
the ExID values that have already been assigned if they are considered
to be part of the transition plan (though it would be better to describe
a transition plan). Per RFC6994, the authors do need to address this
issue, especially indicating that connections should *not* include both
variants in the same segment.

Finally, IMO, if a TCP option codepoint is assigned, I strongly
recommend not poisoning the codepoint space with a "fresh" assignment,
nor should the developers be rewarded for squatting on a value. The only
appropriate solution IMO, in that case, would be to assign this option
to a codepoint already squatted **by another party**. In that case,
their deployment would appropriately suffer from the impact of squatting.

>> Other minor comments:
...
>> 2) I’m wondering if it would make sense to specify at the beginning of section 4.7 another requirement that TEPs SHOULD only specify the use of SYN data if there is some a-priori knowledge that the other end is likely to support tcp-eno and the tep (e.g. due to previous successful connections aka session resumption, or application knowledge).
That section does not appear to address the case where non-user data in
the SYN is received by a legacy receiver, either because of first
contact or in contacting a host that has changed configuration since
last contact. In such cases, there is no way to support transparent
fallback as required by RFC 1122 -- which is why it is avoided at all
costs. AFAICT, this optimization is too hazardous to include at all.

Joe