Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

<philip.eardley@bt.com> Thu, 24 October 2019 14:38 UTC

Return-Path: <philip.eardley@bt.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 0F64F120961 for <tsvwg@ietfa.amsl.com>; Thu, 24 Oct 2019 07:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level:
X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.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 xZwzhkRpiima for <tsvwg@ietfa.amsl.com>; Thu, 24 Oct 2019 07:38:19 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F704120113 for <tsvwg@ietf.org>; Thu, 24 Oct 2019 07:38:17 -0700 (PDT)
Received: from tpw09926dag08g.domain1.systemhost.net (10.9.202.43) by RDW083A009ED65.bt.com (10.187.98.35) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 24 Oct 2019 15:33:15 +0100
Received: from tpw09926dag05g.domain1.systemhost.net (10.9.202.28) by tpw09926dag08g.domain1.systemhost.net (10.9.202.43) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 24 Oct 2019 15:38:14 +0100
Received: from bwp09926083.bt.com (10.36.82.114) by tpw09926dag05g.domain1.systemhost.net (10.9.202.28) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 24 Oct 2019 15:38:14 +0100
Received: from GBR01-LO2-obe.outbound.protection.outlook.com (104.47.21.51) by smtpe1.intersmtp.com (10.36.82.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 24 Oct 2019 15:38:12 +0100
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C8omS2cTPDy/XBtGD26By+2399uYbv+AN/AMyU+fIVDsW5tcZnDXciH5Amtp2qfArUxyy8JKBA8ewXdY0c8PFdIC8W11NcK3vuuD2pDEWp+LqS7tZC49ZCNm53EdKd5JL+ZfbFBpSxd4HNkU42/QW4VaJcfX5hQ61DuznxySolVIx4HepvK/H8yFPcISi+5H04zQBVMDx839pxqIEMePIaVI6wxyTlyvw15i/pFdCs/hA5cW3Q5RJ4jODRdSlKcpzX0p65ql89/4AmCVZzg4r3dYMRMRwqRA0ACD7rUVavDjuJQ31JGDwjc0IPNPGub9SjrHL2mfPsLYs1Y0O53fnQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GGYEIlVOcd1jVtKh6v9HqSngAa1qEvztgBjDTK2dY0Q=; b=f6P7wpXkGtjdDOyE5BNWGNhldx50a6XTOLlQnZ1TtTJx5A/Rlr44TMGzetVHt11nxvxqUyyQ8CYy5Kbw5hMXQDH0Du3BjcLIp0GWlC5AfGre4fmDKlzA5fsCowiOu9HXS8h+JLmDzAafLj+rvRyLbg6PJzkSnBEARRuHkqoG4TKs58mupEiJcOmVsvVTNEvZ9bR65koKBPg0iq6KHT8fEzohF+g+6EUueljfauPVuv0ppC9KCS1DtlF8zw4B9Xud037/4nFmq0Gbjl9AG3NfVcSOrgxa+lmorJ4Y0eW9agS3fd9iiLlsJvfuos+BZxqAYQhRxQnnzOaiAZ590eX8jg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bt.com; dmarc=pass action=none header.from=bt.com; dkim=pass header.d=bt.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GGYEIlVOcd1jVtKh6v9HqSngAa1qEvztgBjDTK2dY0Q=; b=dvTVc/1i+Z1zuX47oxQ92FowJI8l8YEGfBlj1Rmhvy4HWNcHWe328tD5EYTQSMpwS1MlO2HexVI47pJiHHbCoAyYf0V+XNXaDAM6SS1D92g2nPdw50xklGgceBkiTZhY3Chr7JEXczeEgTnyVdw7AVTVaUvtERNDBdttL39zXvw=
Received: from CWLP123MB2579.GBRP123.PROD.OUTLOOK.COM (20.176.58.79) by CWLP123MB2708.GBRP123.PROD.OUTLOOK.COM (20.180.138.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2367.24; Thu, 24 Oct 2019 14:38:13 +0000
Received: from CWLP123MB2579.GBRP123.PROD.OUTLOOK.COM ([fe80::5c43:4d65:4081:f8a8]) by CWLP123MB2579.GBRP123.PROD.OUTLOOK.COM ([fe80::5c43:4d65:4081:f8a8%5]) with mapi id 15.20.2387.021; Thu, 24 Oct 2019 14:38:13 +0000
From: <philip.eardley@bt.com>
To: <Nicolas.Kuhn@cnes.fr>, <huitema@huitema.net>, <tom@herbertland.com>, <ilubashe@akamai.com>
CC: <touch@strayalpha.com>, <tsvwg@ietf.org>
Thread-Topic: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
Thread-Index: AQHVfq5vElfHtRujjkWlymkhQNySOqdSYS0AgATOJQCABRNfAIAAHq4AgAF4WwCAAAnvgIAGqCgAgACvPICAAD/fgIAEMNcAgAATJ3A=
Date: Thu, 24 Oct 2019 14:38:13 +0000
Message-ID: <CWLP123MB257982F95FE59290A4B6AA94EB6A0@CWLP123MB2579.GBRP123.PROD.OUTLOOK.COM>
References: <CE03DB3D7B45C245BCA0D2432779493630766752@MX307CL04.corp.emc.com> <e8c30f3f-606f-0c0d-a7dd-b2bb6f31a9fd@huitema.net> <A2F184BB-E352-4AE6-B7A0-FDF6D8851DFB@strayalpha.com> <CALx6S36VYt+LVxWM_ZRos7VK6GArNbenpFD3yaPdqedvkoHpoQ@mail.gmail.com> <9c7df6fe717c43739454a91f8080cffa@ustx2ex-dag1mb6.msg.corp.akamai.com> <CALx6S361-wmgGWcTQHNsXnJEPkdCbvOhSCGwd5a9R0RQ_E=CCg@mail.gmail.com> <8543343a39a04d5baca64ce2a3085ac9@ustx2ex-dag1mb6.msg.corp.akamai.com> <CALx6S36FonVeU25YJEq_7PaNrfvX4ABLFv5VLbb6QKE==G5Xfg@mail.gmail.com> <00cf55e3462e44be8bcb908c453c3eef@ustx2ex-dag1mb5.msg.corp.akamai.com> <CALx6S34aQOUwqd5a2EJK10noUwW4qJQaEfsL4i-2VFpUU5=ytA@mail.gmail.com> <e5679768-6d59-8c5e-3f96-1f89fd8a21af@huitema.net> <F3B0A07CFD358240926B78A680E166FF1ECD586B@TW-MBX-P03.cnesnet.ad.cnes.fr>
In-Reply-To: <F3B0A07CFD358240926B78A680E166FF1ECD586B@TW-MBX-P03.cnesnet.ad.cnes.fr>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com;
x-originating-ip: [193.113.37.9]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c944035d-837d-403a-6683-08d7588fcc8b
x-ms-traffictypediagnostic: CWLP123MB2708:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <CWLP123MB270839A02C370479FD0CE2A6EB6A0@CWLP123MB2708.GBRP123.PROD.OUTLOOK.COM>
x-antispam-2: 1
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 0200DDA8BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(376002)(396003)(136003)(366004)(189003)(199004)(51444003)(110136005)(66574012)(54906003)(25786009)(186003)(33656002)(256004)(316002)(66066001)(64756008)(66556008)(66446008)(66946007)(14454004)(76116006)(66476007)(86362001)(6436002)(229853002)(476003)(6246003)(74316002)(446003)(11346002)(7736002)(6506007)(81156014)(2906002)(236005)(8676002)(486006)(8936002)(102836004)(4326008)(81166006)(76176011)(53546011)(606006)(99286004)(5660300002)(55016002)(26005)(7696005)(6306002)(9686003)(54896002)(790700001)(71200400001)(3846002)(71190400001)(6116002)(966005)(52536014)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:CWLP123MB2708; H:CWLP123MB2579.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: dUNmPNDfSx8CLukIswCM9wRYulS4w/Py96DrFx5OH3HqpTwKEhpH50f2F23MO7w/olYd5cTpEXTv4WQTHrOvqql+Hmc69PJ6Gre/ZYHs+2uNv0uF6LWgeT8Yq0SsFIEaDWyTWsRV5zmo+HtOvdgX4pTXiDpJk9qbakU5iylNl4e7Uj4sQVhWXYect8xKcihjGxdrcxnLH2fDR5UbEZ9x+GaETXBRIM1Tmbd1xfXNLE8fC7riDVW5fseEitKL8pBFO9sG+Fdy5AWq4OR6n//jg3FReEkd27pGYWuQFEQ9F3m6/aJm30niN17jFTOKtpUVwhlvY5eLaU47P7psTr/OMnalHdQyMdE/nqCbhHKPi1id/MpuDs1j96iRxQJMja8E/WaJAk9eQl+HP3BbN7d89dXCAMaTaOddZdUNf0nIOOBGJbAi4tpFZVaBvptCszv6irwlngHK4GNys4ertV7SYSgKUogJ1EL49ToZJFTDLbk=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CWLP123MB257982F95FE59290A4B6AA94EB6A0CWLP123MB2579GBRP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c944035d-837d-403a-6683-08d7588fcc8b
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2019 14:38:13.0620 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: sucHLarG2KbzcmPTyHRZhnXhCPGgjQuDYZFVuOC+7fLjRI2Jhemb13KQ5qHjZD6FwYP40c+6L5CXoV9kTb41mg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWLP123MB2708
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Report: 3 Rules triggered * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6662
X-NAI-Spam-Version: 2.2.0.9309 : core <6662> : inlines <7155> : streams <1836561> : uri <2927127>
X-OriginatorOrg: bt.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/fgf-x5whIyAtbAOdej4SvUNxIsM>
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
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: Thu, 24 Oct 2019 14:38:23 -0000

Nico,

Please can you explain your comment about the L bit: “only Q bit (upstream loss) is doable (L bit must be sent by sender for end-to-end loss evaluation)” Surely both the Q & the L bit are set by the sender?

I’d prefer a generic solution rather than one for one transport protocol.

I think it’s worth looking at https://tools.ietf.org/html/rfc7837    This defined an IPv6<https://tools.ietf.org/html/rfc7837%20This%20defined%20an%20IPv6> destination option for carrying ConEx markings in IPv6 datagrams. I think its L bit is identical to your L bit. RFC7837 also has 4 reserved bits so a bis would have plenty of room for Q bit.

https://tools.ietf.org/html/rfc7837#section-3  discusses why the WG chose a destination option.

There seems to me a lot of similarity between the Conex work and this work, both in objectives & method. The Q bit is new since conex, and seems to offer some advantage of a clearer signal about upstream loss, under some assumptions.

Best wishes,
phil

From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Kuhn Nicolas
Sent: 24 October 2019 11:20
To: 'Christian Huitema' <huitema@huitema.net>et>; Tom Herbert <tom@herbertland.com>om>; Lubashev, Igor <ilubashe@akamai.com>
Cc: Joe Touch <touch@strayalpha.com>om>; tsvwg@ietf.org
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

Hi,

As far as I can see, there are different ways of signaling losses that are being discussed.
Here is an attempt of discussing advantages and drawbacks of each approach.
I believe that going for : short-term QUIC-bits and long-term TSVWG-bits is a good way forward. Moreover, this does not prevent from also having layer IP solutions.

-              Using IP level bits
Advantage : long term solution that is compatible for any upper-layer protocol
Drawback : compatibility with L2 tunnel solutions, problems in making it for IPv4 and IPv6 and only Q bit (upstream loss) is doable (L bit must be sent by sender for end-to-end loss evaluation)
-              Using new QUIC bits
Advantage : quick deployment of the solution and simple solution
Drawback : specific to QUIC
-              Generic transport solution
Advantage : standard solution for any transport
Drawback : “time-to-market” and only Q bit (upstream loss) is doable (L bit must be sent by sender for end-to-end loss evaluation)
-              Using OAM information
Advantage : management plane focusing on management functions – clearer interfaces between control, data and management planes
Drawback : need for standard interfaces between the different equipment that may follow other standard (IEEE, 3GPP) and management of “old” network still in operation

The privacy issues that are said to be specific to QUIC solution are inherent to any solution IMHO.

My 2cts,

Nico


De : tsvwg <tsvwg-bounces@ietf.org<mailto:tsvwg-bounces@ietf.org>> De la part de Christian Huitema
Envoyé : lundi 21 octobre 2019 20:20
À : Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>>; Lubashev, Igor <ilubashe@akamai.com<mailto:ilubashe@akamai.com>>
Cc : Joe Touch <touch@strayalpha.com<mailto:touch@strayalpha.com>>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>
Objet : Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019



On 10/21/2019 7:31 AM, Tom Herbert wrote:
Igor,

That misses the point of the statement. There are many protocols that don't have ubiquitous support over the Internet-- EH, IP fragmentation, any transport protocol other than TCP and sometimes UDP, and even IPv6. If "ubiquitous support" is required for deployment then we can never deploy new protocols or any protocol that is atypical to intermediate devices. So, unless we're planning on never doing anything new on the Internet, we need to address this.


The goal of any "for the network" signal is improved QoS.  Hence, if there is a non-trivial chance that inclusion of such signal will actually degrade QoS (by causing packets with the signal to be dropped), no sender will include such signals (and "happy eyeballs" style code is too complex and risky for the benefit).

As architecturally "ugly" as it sounds, I can only see the QUIC header and the most significant TTL bits as viable alternatives to be deployable widely on the Internet for IPv4.  For IPv6, even HBH and Dest Options are still too "risky" for packets, but that is likely to be improving.

You forgot to mention efforts to encode information in IP addresses, overload bits in the flow label, or other DPI parsing of UDP payload (like tunnels over UDP), and other creative ways to "find" bits that can be repuposed. There're all hacks! IP is designed to be an extensible protocol without the need for these. Pursuing such hacks, instead of using the defined mechanisms of extensibility, ostensibly solves some short term problems, but in the long run perpetuates protocol ossification and stifles evolution of the Internet.



If we want to not rely on hacks, I believe that we have to somehow change the network protocol. I have followed the development of the spin bit in QUIC, and the attempts to use more bits and provide for example indications of packet losses. There are typically two issues: privacy and practicality. Let's not discuss privacy here, except by assuming that privacy-sensitive deployments will find a need to "bleach" the signals. The signals are still useful for connection management as long as a large enough fraction of the connections are not bleached.

I think that solving the "practicality" issue requires moving the signal to the IP layer. The experiments by Orange show that you only need a small number of bits to monitor latency and loss rate from within the network - 2 or maybe 3 bits would do. If these bits are in the transport header, the network monitor has first to find out what transport protocol is in use, and possibly what version. With encrypted transports, that could soon become a daunting task. On the other hand, if the bits are at some fixed position in the IP header, monitoring becomes much simpler.

My personal preference would be to associate these bits with an IPv6 "flow" label, or for IPv4 the five-tuple. Latency is associated with routing and with applications, and in theory all packets in a flow share the same routing and the same kind of end-to-end processing. Of course, there are deployment issues, bleaching issues, etc. But the logic remains: associating latency and loss measurement with a packet flow makes the most sense. Moving that to the IP header also makes sense -- after all, it is very similar to ECN signals. The broad line of the solution would thus be:

1) Steal a couple of end to end bits, or maybe just 4 to 8 Diffserv code points

2) Use these bits to encode the "spin" and "loss" indications, and distinguish them from the "bleached" signal

3) Compute the "spin" and "loss" indications per end-to-end flow, and make that part of the spec.

There are obvious deployment issue, bleaching paths and all that. But at the same time, the information is meant to benefit network management, so there will be a strong incentive for network managers to ensure that it flows freely. Thus, it is not hopeless.

-- Christian Huitema