Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)

"Black, David" <David.Black@dell.com> Wed, 18 March 2020 23:06 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3383A1DF9 for <tsvwg@ietfa.amsl.com>; Wed, 18 Mar 2020 16:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=DLojjI48; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=iWWQPLxk
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 2DrfjxhPS-d1 for <tsvwg@ietfa.amsl.com>; Wed, 18 Mar 2020 16:06:33 -0700 (PDT)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7FFC3A1DF8 for <tsvwg@ietf.org>; Wed, 18 Mar 2020 16:06:32 -0700 (PDT)
Received: from pps.filterd (m0170398.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02IN4DYv014262; Wed, 18 Mar 2020 19:06:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=jZffOtqBGhUTJGjb5mkgftLkDB48cVVyqvmjjAYe63A=; b=DLojjI48XOZBvRVr6lKB4qxkE+Yw5dqkX2iLmRQO4wg6fBKaudrVahhuCuv/6/Xw7GUi 5B6WuemkojUcr1kt7JCjFzZqAErNJCaIBspicS7cJv0qO6jZs/nv4zbZGRSx/EOnNxJX /xap8YgTAv49wJqejes79ddvXSymZTUOwfivTO7/lUq2yXFpt3Noh9YD9NE9cAlkDzJQ 5ZlppJXMnl+ErBFzsZbPoLlwzs/34QbiPfFMGY3zOsPbkhrALR1QQI65wrj3OgJI9Iuj wLdtBotELlzv63XCWo2BuoL7rEh1mOxtpf/fo9nY1kT/GO0qb4FtewZZuaY+7YFx/UFX eQ==
Received: from mx0a-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2yua04dg2n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Mar 2020 19:06:31 -0400
Received: from pps.filterd (m0089484.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02IN4ks5108102; Wed, 18 Mar 2020 19:06:30 -0400
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2106.outbound.protection.outlook.com [104.47.70.106]) by mx0b-00154901.pphosted.com with ESMTP id 2yu9rugesq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 18 Mar 2020 19:06:30 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DTl1LPhri3DZra9+oB24iGKWvWyktHBiJkWGCDHUDsq4LRjKY4AyEuHK/MjgTt?= =?utf-8?q?DZIUKKkil/VzofmKxceTNnnx3+9djGEz54K8o5bJ+MR5ibIGuaR8qbIrZCfvrbTjC?= =?utf-8?q?X6zjX+coOVEpcLQUX/TqIHRORqwAXrKU7TPaK8hbfaYmwU1Oy5PUyg2te4JLAxXZr?= =?utf-8?q?F+o+1rCjpUXhdHYKT/T/ENi/zV1+E5A+cbYqj+KiJ/ofqbyrlnxAG2X3N4g4feV/B?= =?utf-8?q?k82HExG1BtFKyJVCvVIkqGIeJMjMOg57KqF8CQ49bWtalghYBYE7jmXYU6dzAoQ3L?= =?utf-8?q?g8VlRJF5gZb5VKYBlKW2Q=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DjZffOtqBGhUTJGjb5mkgftLkDB48cVVyqvmjjAYe63A=3D=3B_b=3DjVMkXx?= =?utf-8?q?Oy2n6WNWp2FsxXl3e+GQnzPr/L42BwMVBKA7OGMUjSoxYlU45mkbzGC7+1I8WMeZd?= =?utf-8?q?Qs/ctCVr3+j+pcb+TRQu49vpJJ5ofgcKbwBL5PKqI+ZJ3953WrRQxNSiuKlKY9o1k?= =?utf-8?q?1JQcb71QsHRAe3V3pT2sWa8mCNB/BBuqj/SIlWQVq6l0Tsuxw/1H+OOBwG3s3HCz+?= =?utf-8?q?1eo/aWANdTQMBKh0IVHZSZoqZw4LkdisDDG/IJ8AsCgXp3PZ9S3jpn2PoRdTPrQaU?= =?utf-8?q?KDmT1x7YOna5wHj9KhzDFXyScrNttJ912/eovFhdAoqJUXEi/8hCRxjppfXrOOttR?= =?utf-8?q?1pvHGdbHXoA=3D=3D?=
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMe?= =?utf-8?q?ssage-ID=3AContent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCh?= =?utf-8?q?eck=3B_bh=3DjZffOtqBGhUTJGjb5mkgftLkDB48cVVyqvmjjAYe63A=3D=3B_b?= =?utf-8?q?=3DiWWQPLxkpusVouhituA9xfXBGWNNKUMuqma1EN4rg40qAnGxddtXtlgZVkU3Rx?= =?utf-8?q?OgBl/OOQVAcmWHGqYiKtWVheVW17qlporapG02R6ao933OdkVB3qalD2cNPDjHfXj?= =?utf-8?q?RaJXOEKDss+RdRzXpkI1oLpuVIPRuXR6MZdJzt9TK9j4=3D?=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB2959.namprd19.prod.outlook.com (2603:10b6:208:ad::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.22; Wed, 18 Mar 2020 23:06:29 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8d12:8a24:ccb2:b2bd]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8d12:8a24:ccb2:b2bd%3]) with mapi id 15.20.2835.017; Wed, 18 Mar 2020 23:06:29 +0000
From: "Black, David" <David.Black@dell.com>
To: Tom Herbert <tom@herbertland.com>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
Thread-Index: =?utf-8?q?AQHV7U2VoTELGEeiXE+joWgsz7PlOqgvX9WAgBdsGgCAAASegIAA?= =?utf-8?q?ASKAgAAN2wCAAt5zAIABVCKAgAA6yYCAAB1KgIAACFSAgAAJO4CAAAl1AIAAC50Ag?= =?utf-8?q?AADNYCAAACsgIAAGOEAgAMyu+A=3D?=
Date: Wed, 18 Mar 2020 23:06:29 +0000
Message-ID: =?utf-8?q?=3CMN2PR19MB4045E72EC1D5BF0D6D0A8A1B83F70=40MN2PR19MB4?= =?utf-8?q?045=2Enamprd19=2Eprod=2Eoutlook=2Ecom=3E?=
References: <158279435525.6196.11790581771168846041.idtracker@ietfa.amsl.com> <CAPDSy+5e0HYhBJdQm-ZhBcqmqwKGkpaKU8t_9R2_P=nAOs9s2w@mail.gmail.com> <CABcZeBOdDU0zQ+ZNQqu1vDWxQuLUzGqi9MMXPDUs-izZEgVQsg@mail.gmail.com> <CAM4esxTA9mheGALtp4zKKYVV7wNUfhp-0pdt3C62G=tkTQhaDQ@mail.gmail.com> <CABcZeBOPxLWfT3Un=+_DQoaP5Zf0_COJ=cBLsVwMZHGgu5BOHw@mail.gmail.com> <CAM4esxQMPEemk6db6hGTLdt4xetHRhV=9DD51sjd3ppn+SffEw@mail.gmail.com> <CABcZeBMR61e0CsdCg5y8PkQskm0tbR-+BKXWQghavGKBN6PyHA@mail.gmail.com> <abdc3cc8-5948-1b5d-516d-6d736b7ecda2@erg.abdn.ac.uk> <CABcZeBNVZp_H+02D_B-bg56_==W_9feZ_Z91Oc5R+6P4giftnA@mail.gmail.com> <c6b40d15-244b-5f63-8aed-e3eca3373638@erg.abdn.ac.uk> <CALx6S36Ou_L=sgAAVjLTJcEF3f0i6K6+YOkeuJc_qOW6hQt2rw@mail.gmail.com> <2e51ff5a-e502-bcde-24c9-ff2e2fa13ac4@erg.abdn.ac.uk> <CALx6S35kF8YaqK0vxUZ9c6nzZPR8gr2gbae0T2iXTX5jNbeEpA@mail.gmail.com> <964a5c73-2b12-ca87-c558-fe44b5fa39f9@erg.abdn.ac.uk> <CALx6S362N=FjrWoE8bK0AD02TnZvZoKPOWV-O3exz3ZpKJcWxw@mail.gmail.com> <b9155393-9b15-b000-6ccf-de401d78ec21@erg.abdn.ac.uk> <CALx6S34Dm5ZWUoeYEEz8UBo=WnW5-CQA2ZC+-Qu=GjQOHRPqaw@mail.gmail.com>
In-Reply-To: <CALx6S34Dm5ZWUoeYEEz8UBo=WnW5-CQA2ZC+-Qu=GjQOHRPqaw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; =?utf-8?q?MSIP=5FLabel=5F17cb76b2-10b8-4fe1-93d4-2202842406cd=5FSiteId=3D94?= =?utf-8?q?5c199a-83a2-4e80-9f8c-5a91be5752dd=3B?= =?utf-8?q?MSIP=5FLabel=5F17cb76b2-10b8-4fe1-93d4-2202842406cd=5FOwner=3Ddav?= =?utf-8?q?id=2Eblack=40emc=2Ecom=3B_MSIP=5FLabel=5F17cb76b2-10b8-4fe1-93d4-?= =?utf-8?q?2202842406cd=5FSetDate=3D2020-03-18T19=3A43=3A43=2E8094595Z=3B?= MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [72.74.71.221]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6dab1444-602a-41c7-1309-08d7cb90fdfd
x-ms-traffictypediagnostic: MN2PR19MB2959:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: =?utf-8?q?=3CMN2PR19MB2959D4820E5FD95D8F50ED0A83F?= =?utf-8?q?70=40MN2PR19MB2959=2Enamprd19=2Eprod=2Eoutlook=2Ecom=3E?=
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 03468CBA43
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?= =?utf-8?b?MDA5KSgzNzYwMDIpKDM2NjAwNCkoMzk4NjA0MDAwMDIpKDM0NjAwMikoMzk2?= =?utf-8?b?MDAzKSgxMzYwMDMpKDE5OTAwNCkoNzYxMTYwMDYpKDY1MDYwMDcpKDUzNTQ2?= =?utf-8?q?011=29=2866574012=29=285660300002=29=28107886003=29=2833656002=29?= =?utf-8?q?=2852536014=29=2886362001=29=2830864003=29=2864756008=29=28769600?= =?utf-8?b?NSkoNjY1NTYwMDgpKDY2NDQ2MDA4KSg2NjQ3NjAwNykoNjY5NDYwMDcpKDQz?= =?utf-8?b?MjYwMDgpKDY5MTYwMDkpKDI5MDYwMDIpKDgxMTU2MDE0KSg1NTAxNjAwMiko?= =?utf-8?q?81166006=29=28316002=29=28786003=29=2871200400001=29=288936002=29?= =?utf-8?b?KDg2NzYwMDIpKDI2MDA1KSg5Njg2MDAzKSg1NDkwNjAwMykoNDc4NjAwMDAxKSgx?= =?utf-8?q?86003=29=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB2959; H:MN2PR19MB4045.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?N03J4fVu709nwqJeW0aTpg2rCiRmdGY?= =?utf-8?q?GDlzHa4/0wUk/C2QwyxDV/Pd3Wi1YVGLUVLR6W5CP7D/4LkIiLSHNLhRffpgSTP+O?= =?utf-8?q?8T0NJNBS4EHMjydeJvWPuZtpw1SeKa6PHlIWZt/llIej5aw2abxfQIMfBwRicnz2U?= =?utf-8?q?9NU512Y0F9c213OEmJELMiy+FCSqkQsJJ2+hFlE+7pZxNy5IKce75fekqmtiqdk7q?= =?utf-8?q?YtKlvJCw3DtqqyzcuOY3r28c7SDlZQcSuzURXR38Vt9Yu5e26c+hMwvahakkej4jq?= =?utf-8?q?WFoQuDerXx82/sOvmRN6KQ8JDvUYLh/JLgpxizKP4io+N+5guT6jX2jm0bC/woRbx?= =?utf-8?q?4LamE0C3BuIcQvUbF0d+MS+K5WqbLHzn3QVP530INzQxRudagytSpIPraUlTfPo56?= =?utf-8?q?tyX8Lj2tWErYv1KEmpHKD7Kbs1J?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?vVcatI8UdhhhAVZeVgKjRmASu232hm?= =?utf-8?q?m0oq9eflk6BZTqrqW5e3VdOLt18lMX59+QFwB2t0DIFzfyrJfJGkEvXhAcUNyWnSE?= =?utf-8?q?3RWmOvgKd/9Z6lFNiKg/UIr7w4W12BtNGN94VMnXpT+lW4xfj3y+4Mw=3D=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6dab1444-602a-41c7-1309-08d7cb90fdfd
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2020 23:06:29.1999 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?sdT8fmsZkoOa1GOfBu8eP?= =?utf-8?q?qt841omBzW5zkvsS+UDaO7bN8ZJw9m5/ALdC9ZqscOaqInlErjfgpuufHfiJ9XBgQ?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB2959
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-18_07:2020-03-18, 2020-03-18 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 spamscore=0 clxscore=1015 mlxscore=0 bulkscore=0 impostorscore=0 adultscore=0 lowpriorityscore=0 suspectscore=0 mlxlogscore=999 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003180099
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 suspectscore=0 spamscore=0 malwarescore=0 clxscore=1015 priorityscore=1501 bulkscore=0 adultscore=0 phishscore=0 mlxlogscore=999 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003180099
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/opv7rA9yMz5f6jnCd9On9Lb41GE>
Subject: Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2020 23:06:39 -0000

Hi Tom,
[writing as draft shepherd]

I understand where this is going, but I think that the initial proposed text (below) has gone over to unbalanced in the other direction, and the draft ought to wind up somewhere in the middle.

Here's the TL;DR summary of the two things I would suggest doing next:

[A-Draft authors] Edit draft with a goal of placing roughly equal emphasis on  <selective exposure of information from encrypted transport protocol headers> and <design of new transport protocols> as motivations and intended uses of this draft.  That looks like it will help respond to Ekr's comment.

[B-Tom] Edit/expand final paragraph of new text on network support for IPv6 Hop-by-Hop options to provide more details about what sort of devices are responsible for the observed problems.
----------------------------
In more detail ...backing out to a higher level, the proposed new text articulates three rationales for use of IPv6 Hop-by-Hop options:

	1.  Transport protocol independence.
	2.  Explicit control of exposed content.
	3.  Standards compliance by comparison to alternatives such as IPv4 options and DPI.

Of these three, I view rationale #2 (Explicit control of exposed content) as crucial, because it appears to also be related to Ekr's comment.  Digging into that comment and related discussion, my initial take is that the draft has (in 20/20 hindsight) not paid enough attention to selective exposure of information from encrypted transport protocol headers by comparison to design of new transport protocols.  In particular, I concur with Martin's observation: "I suspect loss bits are not the last time someone will want to expose more info [from QUIC transport headers]." ... and I would still concur even if he weren't an incoming Transport AD ;-).

So, I recommend editing the draft  to better balance <selective exposure of information from encrypted transport protocol headers> as a motivation for the draft with  <design of new transport protocols>.  These changes ought to start early in the draft, e.g., work selective exposure of encrypted header information into the first sentence of this paragraph of the Introduction:

   The direction in which the use of transport header confidentiality
   evolves could have significant implications on the way the Internet
   architecture develops, and therefore needs to be considered as a part
   of protocol design.  This include considering whether the endpoints
   permit network devices to observe a specific field of the transport
   header; whether the devices could modify that field; and whether any
   modification can be detected by the receiving endpoint.

Then, somewhere in or near Section 5 of the draft, it would be useful to add a brief discussion of the possible means of exposing such information.  That would be a good place to deal with transport-independence vs. transport-specificity of exposed information, which encompasses rationale #1, and including IPv6 Hop-by-Hop options [RFC8200] is a fine example of a transport-independent approach. 

Turning to rationale #3, I tend to take a dim view of standards compliance as an end in-and-of itself in a draft like this that has a strong network operational emphasis.  It would be reasonable to explain why the example of IPv6 hop-by-hop options is superior to IPv4 options, but DPI, which often goes well beyond the transport protocol headers, seems beyond the immediate focus of this draft.

One more thing ... the topic of network non-support for extension headers keeps coming up as something that needs carefully crafted text.   Starting from the paragraph proposed below:

   Some networks drop extension headers because of non-conformant
   intermediate devices. In order to make their use viable, fixes and
   workarounds are needed. Once class of workarounds would involving
   probing to destinations to deduce what paths are amenable use of
   Hop-by-Hop options extension headers (this might be in the same spirit
   of Happy Eyeballs for IPv6).

I would want to see more details on what sort of non-conformant devices cause problems, in particular routers.  This is because to the extent that routers are responsible, there's a much steeper hill to climb for a good level of support (e.g., reduced likelihood of a Happy Eyeballs approach working well in general).

Thanks, --David

> -----Original Message-----
> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Tom Herbert
> Sent: Monday, March 16, 2020 2:53 PM
> To: Gorry Fairhurst
> Cc: tsvwg@ietf.org
> Subject: Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
> 
> 
> [EXTERNAL EMAIL]
> 
> On Mon, Mar 16, 2020 at 10:23 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> wrote:
> >
> > Tom, please comment on David's proposed text - he's the shepherd for
> > this WG document, and it would be useful to know you thoughts.
> >
> 
> Hi Gorry,
> 
> David's text only softens the language that implies extension headers
> are not considered a viable option.
> 
> May I suggest this text?:
> 
> IPv6 Hop-by-Hop options [RFC8200] could be used by hosts to convey and
> signal arbitrary information to intermediate network devices. This
> potentially includes the ability to selectively expose transport layer
> information in network headers that is useful to network node. The use
> of Hop-by-Hop options to expose transport information has several
> advantages over the practice of extracting information directly from
> transport layer headers:
> 
> * Hop-by-Hop options work with any transport protocol. Intermediate
> nodes do not have to worry about parsing various transport protocols,
> they only need to handle the Hop-by-Hop option. This facilitates the
> deployment of new transport protocols, use of encrypted transport
> protocols, arbitrary encapsulations that contain transport protocols,
> etc. This eschews the use Deep Packet Inspection (DPI) since
> intermediate devices only neet to process network layer headers
> (Hop-by-Hop options immediately follow the IPv6 header).
> 
> * Hop-by-Hop options are explicit so that the end host or application
> control their content. This means that the user can decide what
> transport layer information is exposed and when. For instance, if the
> destination of a communication is in the local trusted network then
> the user may be willing to expose some transport information per the
> network's request in order to receive some tangible benefit, but for
> some random destination in the Internet minimal exposure of
> information is more likely desired.
> 
> * Hop-by-Hop options are the only protocol conformant method to expose
> arbitrary information to the network (IPv4 options also are, but they
> are too limited). Their design conforms to the end-to-end architecture
> of the Internet, and they are robust. Other methods, in particular DPI
> to extract information from transport layer headers, are not
> conformant nor robust and are a cause of protocol ossification which
> is a primary motivation for encrypting transport headers.
> 
> Some networks drop extension headers because of non-conformant
> intermediate devices. In order to make their use viable, fixes and
> workarounds are needed. Once class of workarounds would involving
> probing to destinations to deduce what paths are amenable use of
> Hop-by-Hop options extension headers (this might be in the same spirit
> of Happy Eyeballs for IPv6).
> 
> 
> 
> > On 16/03/2020 17:21, Tom Herbert wrote:
> > > On Mon, Mar 16, 2020 at 10:10 AM Gorry Fairhurst
> <gorry@erg.abdn.ac.uk> wrote:
> > >>
> > >> On 16/03/2020 16:28, Tom Herbert wrote:
> > >>> On Mon, Mar 16, 2020 at 8:54 AM Gorry Fairhurst
> <gorry@erg.abdn.ac.uk> wrote:
> > >>>> On 16/03/2020 15:21, Tom Herbert wrote:
> > >>>>
> > >>>> On Mon, Mar 16, 2020 at 7:52 AM Gorry Fairhurst
> <gorry@erg.abdn.ac.uk> wrote:
> > >>>>
> > >>>> On 16/03/2020 13:06, Eric Rescorla wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Mon, Mar 16, 2020 at 2:36 AM Gorry Fairhurst
> <gorry@erg.abdn.ac.uk> wrote:
> > >>>>
> > >>>> Ekr,
> > >>>>
> > >>>> On 15/03/2020 13:19, Eric Rescorla wrote:
> > >>>>
> > >>>> Let me try to expand my point a bit.
> > >>>>
> > >>>> Longstanding practice is for entities in the middle of the network to
> > >>>> use signals that were intended for the endpoint for their own
> > >>>> purposes.  With QUIC (and a lesser extent SCTP/DTLS), those signals
> > >>>> are being encrypted and thus unavailable to those non-endpoint
> > >>>> entities; this draft is mostly devoted to documenting the negative
> > >>>> impact of that change on the operations of those entities.
> > >>>>
> > >>>> I disagree that this is "documenting the negative impact of that
> change".
> > >>>>
> > >>>> The draft is about how this protocol information has and is being used.
> As long as I can remember, there has been devices that utilise some of this
> information, at the edge of an enterprise there is often at least one device with
> this role; within a managed network there are devices; etc. If the trend to use
> encrypted methods continues, some of these practices need to be re-assessed,
> and the functions more widely understood than in an era when nearly
> everything was thought to be TCP or "multimedia".
> > >>>>
> > >>>> I'm not sure what you're arguing here. What I said above is that
> > >>>> this draft was "mostly devoted to documenting the negative
> > >>>> impact of that change on the operations of those entities."
> > >>>> In other words, it lists a bunch of things that people do now
> > >>>> that will stop working. Do you not think that much of the
> > >>>> material in this draft is of that form?
> > >>>>
> > >>>> -Ekr
> > >>>>
> > >>>> So the conclusion, para 2 states:
> > >>>>
> > >>>> "   This document has described some current practises, and the
> > >>>>      implications for some stakeholders, when transport layer header
> > >>>>      encryption is used.  It does not judge whether these practises are
> > >>>>      necessary, or endorse the use of any specific practise.
> > >>>>
> > >>>> Gorry,
> > >>>>
> > >>>> Section 5.2 states:
> > >>>>
> > >>>> "Current measurement results suggest that it could currently be
> > >>>> undesirable to rely on methods requiring end-to-end support of network
> > >>>> options or extension headers across the Internet."
> > >>>>
> > >>>> That _is_ a subjective judgment
> > >>>>
> > >>>> That would be better to reference 6Man debate - however, the words
> are chosen carefully: "to rely upon ... across the Internet"
> > >>>>
> > >>>> Prievously David suggested to you:
> > >>>>
> > >>>> "Additional considerations apply to use of methods requiring end-to-end
> support of network options or extension headers across the Internet.  IPv4
> network options may not be supported (or may utilize a slower processing path)
> and some IPv6 networks have been observed to drop npackets that set an IPv6
> header extension (e.g., results from 2016 in    [RFC7872])."
> > >>>>
> > >>>>
> > >>>> - if you think that needs more explanation, we could perhaps expand a
> little more about the IETF view on this, please suggest an alternative.
> > >>>>
> > >>> Gorry,
> > >>>
> > >>> It's not clear to me what the intent is here. If the intent is to
> > >>> suggest that extension headers should be evaluated as a potential
> > >>> alternative then I think there should be some discussion on how they
> > >>> could work for exposing transport layer information and what the
> > >>> benefits are. AFAIK, extension headers are the _only_ protocol
> > >>> conformant method there is to expose arbitrary information to networks
> > >>> which would include transport layer information-- that should be
> > >>> mentioned.
> > >> This was discussed on the TSVWG list, and at the time we decided not to
> > >> speculate on new methods not currently deployed.
> > >>
> > > Gorry,
> > >
> > > But that's exactly what the draft is doing wrt extension headers. IMO
> > > either this topic needs to be given more balanced discussion about the
> > > possibility of using the mechanism, or all discussion about it should
> > > be removed from the draft in the spirit that the draft is not making
> > > recommendations or judgments about alternatives.
> > >
> > > Tom
> > >
> > >
> > >>> Also, there is one question that really needs to be
> > >>> addressed and is mostly ignored by this draft: what specific transport
> > >>> information do networks needs and when do they need?
> > >> That's a good question. It's not this draft's remit.
> > >>> It should be
> > >>> obvious that even if hosts or applications are willing to expose
> > >>> transport layer information then they'll want to do that very
> > >>> selectively. Some data might be appropriate to expose, some not. There
> > >>> needs to be a lot more discussion on this.
> > >> Indeed.
> > >>> As for extension headers being dropped by some networks, that is true..
> > >>> But that is not the same thing as saying they are undesirable and that
> > >>> the problems, some of which are caused by the very network devices
> > >>> that might need the transport information, can't be fixed. Besides,
> > >>> extension headers are the first protocol that are dropped by networks,
> > >>> even just a couple of years ago IPv6 was also commonly dropped by a
> > >>> lot of networks, but that wasn't a reason for IETF to stop working on
> > >>> it. IMO, instead of accepting protocol ossification, we should fix it
> > >>> or work around it.
> > >>>
> > >>> Tom
> > >> I suggest we add a little to the text David' proposed and also cite the
> > >> references to uses of ext headers?
> > >>
> > >> Gorry
> > >>
> > >>
> > >>>> (Editor-hat off: I'm pretty sure Extension Headers are viable in some
> places, and not currently in other places, expecting this to work end-to-end
> could be unduly pessimistic. Anticipating this would never work would be wrong
> also.)
> > >>>>
> > >>>>    about a technique that is not
> > >>>> currently used with little discussion on why they're undesirable or
> > >>>> what needs to be done to make them desirable.  As I've said before, I
> > >>>> think the document is too easily dismisses this alternative.
> > >>>>
> > >>>> You think this dismissses this? I don't believe that was an intent. Would
> it help to suggest text that includes: RFC6564
> > >>>> or perhaps: {RFC8250; draft-ietf-ippm-ioam-ipv6-options; draft-ietf-
> 6man-segment-routing-header}?
> > >>>>
> > >>>> If the
> > >>>> point of this document is to describe the implications of transport
> > >>>> header encryption without any diligent consideration of alternatives
> > >>>> to expose the necessary transport information to the network, then I
> > >>>> suggest that the discussion of extension headers and other
> > >>>> alternatives should be removed and deferred to other documents.
> > >>>>
> > >>>> Tom
> > >>>>
> > >>>> Gorry
> > >>>>
> > >>>> I agree many existing tools would stop working if IPsec formed the
> majority of traffic, same for QUIC. I think when considering what to do next, it
> can be useful to work from the current position and understand the
> implications of changes that are being proposed/used/whatever.
> > >>>>
> > >>>> At least from my personal position, this document was providing some
> input to that thinking. So, I do not understand your issue.
> > >>>>
> > >>>> Gorry