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

"Holland, Jake" <jholland@akamai.com> Sat, 04 February 2017 07:19 UTC

Return-Path: <jholland@akamai.com>
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 A843E128B38 for <tcpinc@ietfa.amsl.com>; Fri, 3 Feb 2017 23:19:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.9
X-Spam-Level:
X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
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 lVCbVXs0P_I8 for <tcpinc@ietfa.amsl.com>; Fri, 3 Feb 2017 23:19:56 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id F3738126CD8 for <tcpinc@ietf.org>; Fri, 3 Feb 2017 23:19:55 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3F047433528; Sat, 4 Feb 2017 07:19:55 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 28A39433403; Sat, 4 Feb 2017 07:19:55 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1486192795; bh=NsEGIHO4pez73n/kU01PGLUEMxa/nhkpry+BoTGOKZw=; l=5318; h=From:To:Date:References:In-Reply-To:From; b=VSnFVMnZ0Aq8cUdhQ8F+JOJ/UkVX+XjSuwrAKhfAn+6QO28slP7E339pBWyJgopbp rjdVqRTnieX2p5ySlJWaeY+pAHvBJW/RH0A1LE0zhpy7ifuDbpDncDCpa8i/c3anHz yHg6ElLTVl4q/wsgbmOTrpDbqhaGO47kKd0fOtQ0=
Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 255D01FC8D; Sat, 4 Feb 2017 07:19:55 +0000 (GMT)
Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 4 Feb 2017 02:19:54 -0500
Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) by usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) with mapi id 15.00.1178.000; Fri, 3 Feb 2017 23:19:54 -0800
From: "Holland, Jake" <jholland@akamai.com>
To: David Mazieres expires 2017-05-04 PDT <mazieres-rpftec6qtnb8edwhne83y7ez4s@temporary-address.scs.stanford.edu>, "tcpinc@ietf.org" <tcpinc@ietf.org>
Thread-Topic: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
Thread-Index: AQHSfaH8bHX24B8Ba06t1pm3vEt1naFXQ4GAgAC4JQCAAKuKAP//y7SA
Date: Sat, 04 Feb 2017 07:19:54 +0000
Message-ID: <A0905A32-A224-4F51-8AC3-8CA01E259AE2@akamai.com>
References: <D668D28F-42BB-40A4-81D1-1FF2D3D95ECB@akamai.com> <87fujvonza.fsf@ta.scs.stanford.edu> <1FD85C9B-BE52-4E9F-A6D9-54BAD0425C8A@akamai.com> <87o9yin11j.fsf@ta.scs.stanford.edu>
In-Reply-To: <87o9yin11j.fsf@ta.scs.stanford.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1d.0.161209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.113.170]
Content-Type: text/plain; charset="utf-8"
Content-ID: <DCF3FADE290E1746901058C95721745A@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/XaERRizIccqoNvNFcr5_49uM6zw>
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: Sat, 04 Feb 2017 07:19:57 -0000

On 2/3/17, 6:27 PM, "David Mazieres" <dm-list-tcpcrypt@scs.stanford.edu> wrote:
>"Holland, Jake" <jholland@akamai.com> writes:
>> Should my app set the a-bit? I think this version of the ENO draft
>> says yes, because I have altered my behavior in the presence of
>> encrypted TCP (and it wasn’t practical for me to authenticate, so I
>> qualify as an exception for the first SHOULD from 5.1). I publish my
>> app this way, and it’s downloaded by a few hundred folks with
>> accolades about my security-consciousness.
>
>You definitely should not set the "a" bit.  The "a" bit is there if you
>need it, but there is (or should be) no implication that you "SHOULD"
>set it in cases where it is not required.  Header bits are a precious
>resource, so if anything applications SHOULD NOT use the "a" bit if they
>do not need to.

This answer has a big part of the insight I needed, thanks.

>So perhaps the clarification is that you SHOULD avoid using the "a" bit
>unless you absolutely need to, and when you do use it, since there's
>only one "a" bit, you SHOULD slot in a mechanism that has hooks for
>future compatibility.

(UIC = Updated-insight Comment)

UIC #1: Yes, something that conveys the above message effectively would be a key edit, I think.

UIC #2: On a related note, I will point to the initial definition for the a-bit in section 4.2:
      The application-aware bit "a" is an out-of-band signal indicating
      that the application on the sending host is aware of TCP-ENO and
      has been extended to alter its behavior in the presence of 
      encrypted TCP.  

I think this initial definition doesn’t convey the right semantics for the backward-compatibility that you’ve outlined as the primary purpose for this bit, and it probably needs to do so. This is the main reason I thought the draft said my example app should set the a-bit.

If the a-bit is intended to be used as a mechanism for backward compatibility for legacy protocols that didn’t have one built in previously, in order to avoid misunderstandings I think you’ll need to make that point in a more specific and deliberate explanation of that purpose. Ideally, somewhere there will also be good recommendations on how to achieve a smooth transition, and probably an applicability paragraph or sub-section that outlines the key characteristics of protocols that can derive a benefit.

UIC #3: On another related note, I will also add that I think “application aware” is a misnomer for these semantics.

When a higher-level protocol is extended in a way that makes use of this feature, the updated protocol specification should define how updated apps must behave in order to comply with the updated protocol, and should do so with a definition that permits interoperability with the prior version of the protocol.

This is not about any choices an application makes or any awareness that an application has, except in the sense that the application risks incompatibility if it sets the bit without reference to an updated version of the protocol specification that defines semantics for how each side should handle a matched a-bit.

So this is perhaps something like a “Legacy protocol upgraded” bit, which should be set only when a higher level protocol has been updated by a new specification that defines the semantics for how to interpret the bit within the new version of that protocol.


I know that’s a lot of wide-ranging edits to propose, and I’m sorry about that. But I do think that making this point a lot more clear in the document would make a big difference in avoiding confusion.

Thanks for taking the time to understand my objections fully and explain the misunderstandings patiently. I think this is a very good doc, and I hope this discussion has been helpful in improving it a little further.

- Jake