[tsvwg] draft-ietf-tsvwg-transport-encrypt & extension headers

"Black, David" <David.Black@dell.com> Mon, 02 March 2020 18:17 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 266F03A0E67 for <tsvwg@ietfa.amsl.com>; Mon, 2 Mar 2020 10:17:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=lw+gJq27; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=ZCNJwUNy
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 qwdddUbOfqG2 for <tsvwg@ietfa.amsl.com>; Mon, 2 Mar 2020 10:17:16 -0800 (PST)
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 D0EF53A0E61 for <tsvwg@ietf.org>; Mon, 2 Mar 2020 10:17:15 -0800 (PST)
Received: from pps.filterd (m0170395.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 022IE6fl003422; Mon, 2 Mar 2020 13:17:14 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=smtpout1; bh=iuLR888Ja43w1QAZ3apfXZaxoAQ1HepRPzHZTHqbWBE=; b=lw+gJq27t2n+qf5o5tYQIUFqssoyLFzwiTdaatTcK6bN5yfboRWIFPtDomgDSt+2y6ry QH3C6TAfx/uBqrm+VVuUgoOd0BJzxSke05JSKI+D6qy/FVp9Js2gcLWW4qU9OvBjYQZf 6bYSmBKASnqzjJOurnVWe6v4dn/DEZ3f7+OgUZ9quK6CkKMB6YBHSgDOTtiHIR9wNYkU 9Luso9qRU8R0xQ8QZ6Nqj5IJvgwNqb7MKvRyv2aBrEHgjgG96unyULo1FL5mdk7t5d3c CBlAQRknON6DtsO0trPm+OAdqJI47NnkVLULMCPwDim3mjkpdmBdm2cIDtJIOgdb+yQ8 bw==
Received: from mx0b-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0b-00154904.pphosted.com with ESMTP id 2yfngw6ruc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Mar 2020 13:17:14 -0500
Received: from pps.filterd (m0090350.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 022IE6Vm181256; Mon, 2 Mar 2020 13:17:13 -0500
Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2174.outbound.protection.outlook.com [104.47.57.174]) by mx0b-00154901.pphosted.com with ESMTP id 2yh4em32n0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 02 Mar 2020 13:17:12 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DMgqJW4nCQlF46Fou9ZDCuN3rJPuJZ+eI/rkNZnXS/97HbtxHcADot1kxLcGUu?= =?utf-8?q?k6AkEhcPZkATuRAS0XG/on8LJMoRfx35kld6JLQie6zRs3qvrn1Wzzwl+Ve8EuYF/?= =?utf-8?q?y6ypbxAjD+wAcDDFrNUOVvyyYuXeOGgMtpxZaE7fV78uoyx8/IoJRt3Fvrm1E+/ao?= =?utf-8?q?VatUwGgOJ/MJ5+PSHEETsN/2mqPI4wMmsjbCUF0llwEV239poMTgbTJnpXUkvOyh8?= =?utf-8?q?u49NFE2rVJvIhe955/5/H2osscrAnkS3DnZmGuXgKCkFkI6/+XuDfECPSNfaBUx71?= =?utf-8?q?Un4zRXxp7PYo3OsVea42w=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=3DiuLR888Ja43w1QAZ3apfXZaxoAQ1HepRPzHZTHqbWBE=3D=3B_b=3Dh2tduj?= =?utf-8?q?P00aUuaN3JRPm7f8I9uDTCUdf8MSGngJFPj/jMmZRBDgKMV1xKYNzWhwBWM2zZ1t6?= =?utf-8?q?ZM7SLlf3u4c3x+QwyZCE41Aa2iPkQIXsuFqf7hxkKAP0yxHGEJeuU0fbP0Sp5kR9Y?= =?utf-8?q?OKhIDibLzYjVOh28QeOOYNBBEeIU44sQFgPL19rBMaLpzdjPe67eB6aRP4HQtX+oO?= =?utf-8?q?19h20H0PNLI0chRpZTO6KkGKXMYTUbXghULVySkkYudz1tdC/XcSC6OqraAAGKvzL?= =?utf-8?q?4UXiZKHPIZx/fYn5d6AfLdo+zfJXAPFat44jAE2qMafFko+A+eq130u2zhRFaXwM2?= =?utf-8?q?8ExKHopnLAA=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=3DiuLR888Ja43w1QAZ3apfXZaxoAQ1HepRPzHZTHqbWBE=3D=3B_b?= =?utf-8?q?=3DZCNJwUNyIYJmc8MSt82Rj1HNnosM2Vnzs7ByJY/wDbc7B+FTEGxo5FxV5/AErz?= =?utf-8?q?dKiYc84igHzzv0raaw5LCuSy9aJNSGuoYdTTCgcpaeClyvfMDbblFTPiF8Nu6ItGb?= =?utf-8?q?PxfcN+X3D+UmgEoFNCjEkGzbsadqczi4a9AuA0JFG6xo=3D?=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB3918.namprd19.prod.outlook.com (2603:10b6:208:1e4::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.18; Mon, 2 Mar 2020 18:17:11 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::c476:9aac:4d02:477c]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::c476:9aac:4d02:477c%5]) with mapi id 15.20.2772.018; Mon, 2 Mar 2020 18:17:11 +0000
From: "Black, David" <David.Black@dell.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Tom Herbert <tom@herbertland.com>
CC: tsvwg <tsvwg@ietf.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: draft-ietf-tsvwg-transport-encrypt & extension headers
Thread-Index: AdXwvshhYfXrd2ESTM+SDqbzDVmcMw==
Date: Mon, 2 Mar 2020 18:17:11 +0000
Message-ID: =?utf-8?q?=3CMN2PR19MB40458A412A1A4F77BAC3358183E70=40MN2PR19MB4?= =?utf-8?q?045=2Enamprd19=2Eprod=2Eoutlook=2Ecom=3E?=
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-02T17=3A57=3A04=2E1972736Z=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: [168.159.213.214]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3d004f14-85d2-46bd-880c-08d7bed5ed29
x-ms-traffictypediagnostic: MN2PR19MB3918:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: =?utf-8?q?=3CMN2PR19MB3918B75FBA2A0945EF73A9E983E?= =?utf-8?q?70=40MN2PR19MB3918=2Enamprd19=2Eprod=2Eoutlook=2Ecom=3E?=
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 033054F29A
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?= =?utf-8?b?MDA5KSgzOTg2MDQwMDAwMikoMTM2MDAzKSgzNDYwMDIpKDM2NjAwNCkoMzk2?= =?utf-8?b?MDAzKSgzNzYwMDIpKDE5OTAwNCkoMTg5MDAzKSg3Njk2MDA1KSg4NjM2MjAwMSko?= =?utf-8?q?33656002=29=285660300002=29=286506007=29=28186003=29=2853546011?= =?utf-8?b?KSgyNjAwNSkoMTEwMTM2MDA1KSg1NDkwNjAwMykoOTY4NjAwMykoMzE2MDAyKSg3?= =?utf-8?q?86003=29=2855016002=29=2876116006=29=2864756008=29=2866556008=29?= =?utf-8?q?=2866946007=29=288936002=29=2866574012=29=2881166006=29=288115601?= =?utf-8?b?NCkoODY3NjAwMikoMTA3ODg2MDAzKSg2NjQ3NjAwNykoMjkwNjAwMikoNjY0?= =?utf-8?q?46008=29=2871200400001=29=2852536014=29=284326008=29=28478600001?= =?utf-8?q?=29=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB3918; H:MN2PR19MB4045.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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?9s1drwCII3pTNToAogFi7H/3uXh0Utc?= =?utf-8?q?z+QOrI7XOpdNsrY7BJgH/jhJvfF1aG5KJ+V2eonILBv3IK240WRZn3H9BH2kFZBkt?= =?utf-8?q?HPSvol3BdlotbJ6ZZ2ztZdwEyk2EMdu6EUW3wchUYl5+H7l9EQ1IQYo7EdDcxsm7B?= =?utf-8?q?A1KC4+kN03NnEjOBNw4ls+8KiT7F4YXsvGa2b8r158eakuXz31F6kneTJNRq4+ADS?= =?utf-8?q?yy3KoG42rK4J2UKN//RISvg00ZT2PQ12/ssg9e2SA9iN/eSnxh4b58OueSfHiHYIK?= =?utf-8?q?ZqcsnbIKtpNVEKBsa4qTSpF+arQcNG0/kqgeDUTgG7LtbwKMLQlWHdRUxRWMzkSsr?= =?utf-8?q?dKlv5TesdTuRArU9aG7Xpq8wt0A7YQzmAFENpLmdh2v3WLN6ITDo2in1DiIyLScGN?= =?utf-8?q?erur4eb51yFaBnCQ7AWYFVF/TZX8WS2KO+eo/VCU4jUxSdKOS5Jyd5t4JLlABlneu?= =?utf-8?q?U7WV4G5I5rk98mS5oP5AVONg0faYOVWGf9ypxO0KbHWHgt5Q=3D=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?AvRK1kXbk80L2tShSw8UbSDJQt75gF?= =?utf-8?q?OJcMzAOAtvW2wPRtDoLb5+6EvpyJrv65WqWdUwNL886CUAIKUeS/mph451pZwptoi?= =?utf-8?q?oPDTEvf3g6YPgLqQGk4GesF4IB23tCXCsp41Q03qaQvDiuehi/sWEBg=3D=3D?=
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB40458A412A1A4F77BAC3358183E70MN2PR19MB4045namp_"
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3d004f14-85d2-46bd-880c-08d7bed5ed29
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 18:17:11.0725 (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?Qef/dWU5UsEHlmjmscGaO?= =?utf-8?q?r4GeyhDgl6galaBKajSQi5JazjWRXdLN+bi8qrpEYeP6DTRMI2PdAz13oN94qIGow?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3918
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-02_07:2020-03-02, 2020-03-02 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 mlxlogscore=999 spamscore=0 mlxscore=0 lowpriorityscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 clxscore=1011 adultscore=0 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003020119
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 lowpriorityscore=0 priorityscore=1501 mlxscore=0 adultscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 clxscore=1015 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003020118
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/YRsHEt5tMEak4P2glcu50PhPHrg>
Subject: [tsvwg] draft-ietf-tsvwg-transport-encrypt & extension headers
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: Mon, 02 Mar 2020 18:17:18 -0000

Returning to Tom’s original comment, writing as draft shepherd (not as a WG chair) towards figuring out what to do, I believe Tom’s comment is focused on this paragraph in Section 5.2:

   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.  IPv4
   network options are often not supported (or are carried on a slower
   processing path) and some IPv6 networks have been observed to drop
   packets that set an IPv6 header extension (e.g., results from 2016 in
   [RFC7872<https://tools.ietf.org/html/rfc7872>])>]).

The rest of the material in Section 5 appears to be relatively neutral on this topic, and if one consults the other references cited in that section (RFC 8558, draft-ietf-ippm-ioam-data, and RFC 8250), one finds that all of them mention IPv6 extensions/options, and tend to do so without strongly opining on deployability.  Beyond that, I tend to view Tom’s (correct, AFAIK) statement about standards compliance as being peripheral to this draft’s focus on operational and other practical considerations.  So, the above paragraph could be reworded to improve balance while still conveying the important information, e.g.:

   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
   packets that set an IPv6 header extension (e.g., results from 2016 in
   [RFC7872<https://tools.ietf.org/html/rfc7872>])>]).

It would be helpful to cite a reference that covers IPv4 options and especially pitfalls in using them, e.g., the consequences of slower and resource-limited processing paths.  The extensive discussion of Router Alert in RFC 6398 (BCP 168) would be one possibility.

Thanks, --David (as draft shepherd, not as WG chair)

From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Spencer Dawkins at IETF
Sent: Friday, February 28, 2020 4:02 PM
To: Tom Herbert
Cc: tsvwg
Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt


[EXTERNAL EMAIL]
Hi, Tom,

On Fri, Feb 28, 2020 at 2:31 PM Tom Herbert <tom@herbertland..com<mailto:tom@herbertland.com>> wrote:
While the draft certainly has improved both in tone and content, I
still feel like there is one area that is very under-represented.
Namely the possibility of using extension headers to carry necessary
transport information that the network needs. I have brought this up
several times, and don't believe it has been adequately addressed.

Section 5 discusses extension headers (in a rather offhand manner). It

You're talking about Section 5.2, right?

is presented in a very negative light focused on the why they won't
work. The crux of the argument in the draft is that extension headers
are not deployable, RFC7872 is referenced as the basis for that
conclusion. But as we pointed out, and even acknowledged in the draft
text now, that is from 2016, so the data and questionable. But even if
it were still relevant the conclusion drawn from it that EHs are not
usable in any form is highly debatable.

What the draft fails to mention is that Hop-by-Hop extensions headers
are the ONLY protocol conformant way to signal intermediate nodes with
data, including transport layer information, other than what is
contained in the IP header. Intermediate nodes that parse packets
beyond the network layer are not protocol conformant. This is not just
an academic purist statement, this is DPI which is what has led to
protocol ossification and hence is a primary motivation for transport
headers being encrypted in the first place (see QUIC reasoning on
this). Extension headers are also being dismissed because of protocol
non-conformance in intermediate nodes. As often noted, RFC8200 has
relaxed requirements concerning HBH options so that intermediate nodes
can ignore. I believe that RFC8200 was published after RFC7828
potential impact of that change was not measured.

So then one interpretation of the draft is that it is trying to
justify one type of protocol non-conformance, on the basis it is
useful in practice, yet on the other hand rejects the correct solution
to the problem on the because of another type of protocol
non-conformance making it not deployable. There seems to be a
significant irony at work here.

ISTM that the draft (if we're talking about 5.2) is talking about interdomain use of hop-by-hop extension headers, which might reasonably be deployed in a domain that you make decisions about (the subject of 5.1), but are (let's say) more challenging to deploy if you're expecting them to work between arbitrary endpoints attached to arbitrary domains, interconnected over arbitrary topologies.

I don't disagree with the points you're making, but ISTM that if the working group wants to say hop-by-hop extension headers can be a plan, that should appear in 5.1, unless someone can point to at least one success story of hop-by-hop extension headers being widely deployed and used across domain boundaries.

Best,

Spencer

Tom