RE: Getting to consensus on packet number encryption

Praveen Balasubramanian <pravb@microsoft.com> Tue, 01 May 2018 18:59 UTC

Return-Path: <pravb@microsoft.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65F3126B6D for <quic@ietfa.amsl.com>; Tue, 1 May 2018 11:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level:
X-Spam-Status: No, score=-2.009 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=microsoft.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 IWuE4o09X8HK for <quic@ietfa.amsl.com>; Tue, 1 May 2018 11:59:29 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe48::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E78E1201F2 for <quic@ietf.org>; Tue, 1 May 2018 11:59:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CpqTmWbYUWjbm7QFCq6tj4UO4A6O/60HabWUwJOffL0=; b=HNMc/R6E5Vbi/Ah5x5KYCMQPM9oV1Bk7Xrahxc9kWj5MW8FQnAEW+c19FHn0XbMaMDLpFkgZ4ZyirOD4RVXQIx1IhcJPAXLhBFgAzfx97hbIbBtTT7Ym3WOli6ZOb0twS+Lp+2wdK0RfPDxuBHsFuON14vptjSzmEhhT5RdgIBo=
Received: from MWHPR21MB0638.namprd21.prod.outlook.com (10.175.141.139) by MWHPR21MB0157.namprd21.prod.outlook.com (10.173.52.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.735.5; Tue, 1 May 2018 18:59:27 +0000
Received: from MWHPR21MB0638.namprd21.prod.outlook.com ([fe80::6d48:f7af:d267:2021]) by MWHPR21MB0638.namprd21.prod.outlook.com ([fe80::6d48:f7af:d267:2021%7]) with mapi id 15.20.0735.006; Tue, 1 May 2018 18:59:27 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: "Lubashev, Igor" <ilubashe@akamai.com>, Ted Hardie <ted.ietf@gmail.com>, "Brian Trammell (IETF)" <ietf@trammell.ch>
CC: IETF QUIC WG <quic@ietf.org>, Roberto Peon <fenix@fb.com>, "Salz, Rich" <rsalz@akamai.com>, Benjamin Kaduk <bkaduk@akamai.com>
Subject: RE: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwZ0sAgAC4ugCAAARcAIAAFTbwgAALYgCAAAAgYIAAEcIAgACR+YCAB09lAIAFXyIAgAVK+oCAAJlSAIABxdSAgACOHICAB/EyAIACo7YAgACiMICAAADPgIAAIs8AgAAm/YCAABExgIAABpMAgAAK5wCAAPIgAIAA5wcAgACzcYCAAHHMgIAEe1cAgAABEACAABL8QIAA89MAgAABeQCAAC8kAIAAC7UAgAARLwCAAA0zAIAAD7YAgAAE15A=
Date: Tue, 01 May 2018 18:59:26 +0000
Message-ID: <MWHPR21MB0638014E783CE63F5D30DE38B6810@MWHPR21MB0638.namprd21.prod.outlook.com>
References: <CANatvzwCYrOZULG3iVmDFp97nr=M5=Gufo8TZjOGQVFUpsn0bQ@mail.gmail.com> <CAAedzxqDcPXJUE83KVnDiU23PvqDcTCrc6rRMw09FexjJA-Y6Q@mail.gmail.com> <CANatvzwjYE6EdvFtOXJMVQnutbVQ4YY+=XsQFzKwHzqWzZ4U+w@mail.gmail.com> <d32ade7b56bf4651952659307c08893b@usma1ex-dag1mb5.msg.corp.akamai.com> <CANatvzwHtCn8rLB8npf3i7PGyYZhVDRd2uojh5hv3uxtFPEsSA@mail.gmail.com> <58447D8E-782C-431C-8FC3-71124B10A047@trammell.ch> <CACpbDcdfF9w3qqrH1eB0sGU_4vheD9aMP5EXnp1o3Y19N19NUg@mail.gmail.com> <e8b4931a-3931-5b8d-8dad-3ca1939d5542@huitema.net> <CAKcm_gPaj3o-VTdA_0+Kk+nTcVJrYcs_BMyOiDGXKub3gB=GLg@mail.gmail.com> <MWHPR21MB063869878060E850137210FEB6820@MWHPR21MB0638.namprd21.prod.outlook.com> <20180501121906.GA5742@akamai.com> <F63059EA-BA14-4886-A4FB-AA5F04AC164B@akamai.com> <BY2PR15MB07757EAB6A818F1D8D8CCED9CD810@BY2PR15MB0775.namprd15.prod.outlook.com> <CA+9kkMCpxve3CKhQk45YKbvyOyQ6kvzyhpJhrTq1UM-QM+ms2Q@mail.gmail.com> <89893592-7135-4C24-BE1E-4B0FFD1A2E97@trammell.ch> <CA+9kkMCUTRrM9SPEz=Q5GDgU7whryZ1cRdj-O3=GP=-vOr-X+A@mail.gmail.com> <ba56bca23f5747e5abdfec137de37481@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <ba56bca23f5747e5abdfec137de37481@usma1ex-dag1mb5.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:7::316]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0157; 7:34IBcNIGQO5pAv1Qykg1lGRPxOhlRS8L1eufbIvtMYG44fToMg6Geptq7UAe4GdR52NhdxMQAnawf1ljSv1TkxEOuhv41/f1qab/PrcUn2U3z+V00Yo+Ue+4Ba18bJbpw93f6qyMhpHEeP8vQxm4ZmzlWp/N+51lLWNSI7O9AGt5opMohQxaGmfgtFAmwhNsZxXkbn42bMhnfGZkkPmIZVbgIVxc9ORRUYxQwwQ4RfiACNeDaBhy64ZphOPPq0g5; 20:ZVGOZmyZBP8q2FtfJf0dJHYo+hL2pFv9aLrGPv8FR7xZB2sahZZegjfoRfkN+ZHqp8khlO2rNB7cCEXvvTthDeNGNoHcbwNs7Fc6Fwpzwrxbp7xShKYLKODFjL7IbwdXQQ/VM/KW23851nTUUtI+Vm52Jb1SS9/S73jnRBI7NGo=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7193020); SRVR:MWHPR21MB0157;
x-ms-traffictypediagnostic: MWHPR21MB0157:
x-microsoft-antispam-prvs: <MWHPR21MB0157E276D0B3F3DDAC8860CEB6810@MWHPR21MB0157.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(67672495146484)(100405760836317)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231254)(2018427008)(944501410)(52105095)(3002001)(93006095)(93001095)(6055026)(6041310)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR21MB0157; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0157;
x-forefront-prvs: 06592CCE58
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(396003)(376002)(366004)(39860400002)(199004)(189003)(99286004)(6506007)(53546011)(106356001)(76176011)(46003)(5250100002)(7696005)(59450400001)(93886005)(10090500001)(14454004)(74316002)(68736007)(110136005)(316002)(22452003)(54906003)(446003)(19609705001)(2900100001)(5660300001)(102836004)(11346002)(486006)(476003)(81166006)(8676002)(6306002)(7736002)(186003)(790700001)(6346003)(229853002)(33656002)(6116002)(55016002)(4326008)(6436002)(8936002)(81156014)(54896002)(53936002)(236005)(9686003)(86362001)(97736004)(39060400002)(86612001)(8990500004)(105586002)(3660700001)(3280700002)(2906002)(6246003)(10290500003)(25786009)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0157; H:MWHPR21MB0638.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-microsoft-antispam-message-info: nidPNIIsKnHkdieyQ3nSssD++DRJdnXt3n3KbOq/dovuKb6zFyQetuVcIFwRPdF60RdpEQEE6MUwQcb0U29tZa9aw/hgu0LNq65uYZ6GhQuZAVL+CMj8NpXYXA9WUzuPrWC/xnwsXEFtNejrCI73kRQ/+Y7fLn3f30auvJsc+w3nKnJ0+aLxHt6ddYMQGk2x
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0638014E783CE63F5D30DE38B6810MWHPR21MB0638namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 3bb5bf03-745c-4d1f-f372-08d5af95a974
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3bb5bf03-745c-4d1f-f372-08d5af95a974
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2018 18:59:27.0234 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0157
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/UEkDekfWKdK2Ns_taTuFHGoE2wA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 May 2018 18:59:36 -0000

Yeah this doesn’t have to be unilateral and is a negotiation. Either side is free to terminate the handshake and fall back to TCP if it doesn’t want to support the transforms being offered in the negotiation. This works perfectly fine for the intra-DC use cases.

From: Lubashev, Igor [mailto:ilubashe@akamai.com]
Sent: Tuesday, May 1, 2018 11:40 AM
To: Ted Hardie <ted.ietf@gmail.com>; Brian Trammell (IETF) <ietf@trammell.ch>
Cc: Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>; Roberto Peon <fenix@fb.com>; Salz, Rich <rsalz@akamai.com>; Benjamin Kaduk <bkaduk@akamai.com>
Subject: RE: Getting to consensus on packet number encryption


  *   But having  QUIC negotiate this outside of the version does not make sense to me, because there is no way for an initiator or a responding peer to judge whether the other side's assertion of safety is well-founded or even well-meant.

Would it satisfy your concerns, if _both_ peers need to express interest in having PNE off for the PNE to be “negotiated off”?


From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Tuesday, May 01, 2018 1:44 PM
To: Brian Trammell (IETF) <ietf@trammell.ch<mailto:ietf@trammell.ch>>
Cc: Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org<mailto:pravb=40microsoft.com@dmarc.ietf.org>>; IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>; Roberto Peon <fenix@fb.com<mailto:fenix@fb.com>>; Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org<mailto:rsalz=40akamai.com@dmarc.ietf.org>>; Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org<mailto:bkaduk=40akamai.com@dmarc.ietf.org>>
Subject: Re: Getting to consensus on packet number encryption

On Tue, May 1, 2018 at 9:56 AM, Brian Trammell (IETF) <ietf@trammell.ch<mailto:ietf@trammell.ch>> wrote:
hi Ted, all,

At this point I've pretty much come around to the opinion we should just land 1079 and discuss the rest, but this conversation continues to have me worried that we're coming to consensus on a feature we do not fully understand the applicability and limitations of.
I also think that just landing 1079 and moving on is the right thing to do.

PNE's primary utility is anti-ossification. While it reduces the amount of information available to an attacker attempting to achieve linkability of flows across a purposeful path migration, or with a single-PN-space multipath design, it does not eliminate it, so expecting more than a marginal privacy benefit from the feature per se is setting oneself up for disappointment.

The reason to disable PNE in (admittedly ill-defined) "datacenter" environments is to trade off the (~1%ish) overhead for ossification protection you know you don't need because you didn't deploy anything that tries to abuse the packet number.

(on which, more below; and on preview, what Praveen said)

> On 1 May 2018, at 17:55, Ted Hardie <ted.ietf@gmail.com<mailto:ted.ietf@gmail.com>> wrote:
>
> On Tue, May 1, 2018 at 8:13 AM, Roberto Peon <fenix@fb.com<mailto:fenix@fb.com>> wrote:
> Also, Prism.
>
> -=R
>
>
>
> That's a little more succinct than I would be, but yes.  How does an application know that the flow it is initiating will traverse a topology that is deemed to be within a controlled environment?  You can say "configuration" but I fear it will turn up on a post-it  if you do.  Loads shift, resources move, and suddenly you find that host which used to be in the same rack, being down, has load-shifted to the next instance,  in a datacenter 500 miles away across a very different network.
>
> Many modern deployments are also in someone else's data center, so saying "Data center networks" doesn't say much about why you're trusting the network inside.

The "load-shifted to the next instance" example is an interesting one iff said load shifting causes the traffic that used to cross a private network to transit the open Internet instead.

Well, a long-haul link, certainly.  That may or may not be "the open Internet" and the chances of it traversing a completely unknown middlebox are low.  The chances of it passing by an unknown observer, on the other hand, are not currently known but are presumed to be high.

Is this a thing that ever happens in any of the environments that get called "datacenter" for networking technology purposes?

So, the way I look at this boils down to:
If the linkability or ossification concerns with packet numbers in the clear are justified, you either need to have it on all the time or have very clear methods for determining when the concerns are not present.  The protocol is not aware of the l2 or l3 topology between an initiator and its peer, much less the management of that path.

So the clear methods for determination really boil down to "someone turns this off when they think it is right to do so".  Flows entirely within the domain of control of a single provider might be a case where folks think it is right to do so.  A subset of that domain of control is when the flow has no long-haul links (for however you want to define that), the shorthand for which is "datacenter network" (though it might well also be a small complex of datacenters, an enterprise campus, or similar).  But the key is that you believe that the topology between peer A and peer B has no middleboxes outside of the shared domain of control that might ossify the behavior and no observers whose use of this data concerns you.
If you control both peers and the network between them, using a QUIC version where this is always turned off might make sense.  But having  QUIC negotiate this outside of the version does not make sense to me, because there is no way for an initiator or a responding peer to judge whether the other side's assertion of safety is well-founded or even well-meant.  If it has no independent data on this (and the protocol provides none), this allows one side or the other to unilaterally turn off an anti-ossification and anti-linkability feature for whatever gain it wants.  Since we're trying to optimize for the long-term flexibility of the protocol, allowing that particular point optimization seems contrary to our interests, much less the privacy interests of the peers.

regards,
Ted

Cheers,

Brian

> Ted
>
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
>
> -------- Original message --------
> From: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org<mailto:40akamai.com@dmarc.ietf.org>>
> Date: 5/1/18 5:25 AM (GMT-08:00)
> To: Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org<mailto:40akamai.com@dmarc.ietf.org>>, Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org<mailto:40microsoft.com@dmarc.ietf.org>>
> Cc: IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>
> Subject: Re: Getting to consensus on packet number encryption
>
>     > I disagree that we need any more data for not doing PNE in the datacenter. Why would we add an extra encrypt-decrypt step for no obvious benefit?
>
> I am concerned that people will mis-interpret the meaning of a datacenter, and think that a bunch of servers, or even a rack, in an open colo space is a "datacenter."  Computers keep getting faster.
>
>