RE: Packet number encryption

Praveen Balasubramanian <pravb@microsoft.com> Mon, 05 February 2018 17:25 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 9D0FD1270AB for <quic@ietfa.amsl.com>; Mon, 5 Feb 2018 09:25:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 Swq4KwzqPtSl for <quic@ietfa.amsl.com>; Mon, 5 Feb 2018 09:24:59 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0120.outbound.protection.outlook.com [104.47.36.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208811273B1 for <quic@ietf.org>; Mon, 5 Feb 2018 09:24:58 -0800 (PST)
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=f5KNe2XamIlsYG610TEwkv7hFfMaEfvs9HjsJGIqSWY=; b=WLuQ8ymf5QmexfW9mwd9l9x8KUww2OIcWhibTWKWjGi2GMqgwTBOdUTySVV4dhzew7sNtE+dAi+osvZmbWY3UWPSXU8NJCe3q7ZPDUY//A6b5bUynC49iTnBe0lG425fLAue6x9PT1SxaUu1IHBOf+G+HALKvkf4CyyfEIUyqyE=
Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0503.namprd21.prod.outlook.com (10.172.122.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Mon, 5 Feb 2018 17:24:56 +0000
Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Mon, 5 Feb 2018 17:24:56 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: Jana Iyengar <jri@google.com>, "Salz, Rich" <rsalz@akamai.com>
CC: "Lubashev, Igor" <ilubashe@akamai.com>, Roberto Peon <fenix@fb.com>, QUIC WG <quic@ietf.org>
Subject: RE: Packet number encryption
Thread-Topic: Packet number encryption
Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaA=
Date: Mon, 05 Feb 2018 17:24:56 +0000
Message-ID: <CY4PR21MB01334E30C7AF6AE75F58EEFDB6FE0@CY4PR21MB0133.namprd21.prod.outlook.com>
References: <CABkgnnVyo3MmWtVULiV=FJTnR528qfY8-OmKGWAs0bCvri-a_g@mail.gmail.com> <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <CABcZeBMbwdwyC9TxxHBLYaZKfNB-FG2wCGjqUZ_mNR-A1R47FA@mail.gmail.com> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <CABkgnnWRQSAufwPss+qf=xAzCwRYeNNH8XLPm3yFaHxOb+ba4g@mail.gmail.com> <BF80500A-6277-45DC-8525-9C3FE138B76D@tik.ee.ethz.ch> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <F990E064-E6F8-41A3-B791-F776C9955E15@nokia.com> <CAGD1bZab0GaZFsHwC+nw3AxxC4VusxMJ6oDanzk3dSDdWKAXdw@mail.gmail.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <BY2PR15MB07757473DB9788558B902EB5CDF80@BY2PR15MB0775.namprd15.prod.outlook.com> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <e529144067624fcba636fc8c24ee3ff4@usma1ex-dag1mb5.msg.corp.akamai.com> <BY2PR15MB07754D83A1721F2BD742359BCDFE0@BY2PR15MB0775.namprd15.prod.outlook.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <CAGD1bZaUuNxqpDkn62B0wWcFD8=mCUWrAwWGG-rAOxH7Mf1=cQ@mail.gmail.com>
In-Reply-To: <CAGD1bZaUuNxqpDkn62B0wWcFD8=mCUWrAwWGG-rAOxH7Mf1=cQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:5::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0503; 7:riCnB4OTEmnCzF4N9souJbnFwxuJnnZd/o17yWpza3N7noKwPN60I4kc4VgvTh9rKz5nR+OrZqDH9pp3bz+CMlB/veoa8s3hXRP/lWQ2QMXIEvaCCt6MeLvA3who+ip/wf2xxMlaDTHILC97bfNqarPjdDpy+KYzh1ZIeW3TJmy7pCI2XJTOu8HNpaVdKDWAW42wCOW1Nfp3smm1L8umZQlIcvGw/wCPz4LKJEEiYkK/O05IEnIYu9yudufej/yv
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ed057d99-7430-4eab-c5e8-08d56cbd607d
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:CY4PR21MB0503;
x-ms-traffictypediagnostic: CY4PR21MB0503:
x-microsoft-antispam-prvs: <CY4PR21MB0503C342B4FD0876F993A9B9B6FE0@CY4PR21MB0503.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(67672495146484)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231101)(2400082)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0503; BCL:0; PCL:0; RULEID:(3232008); SRVR:CY4PR21MB0503;
x-forefront-prvs: 0574D4712B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(39380400002)(376002)(346002)(396003)(199004)(189003)(6116002)(790700001)(229853002)(186003)(59450400001)(102836004)(53546011)(6506007)(74316002)(6436002)(5660300001)(55016002)(2950100002)(77096007)(68736007)(2906002)(8990500004)(4326008)(3660700001)(10290500003)(86362001)(7116003)(3280700002)(14454004)(76176011)(6346003)(19609705001)(7736002)(7696005)(97736004)(99286004)(478600001)(25786009)(10090500001)(81156014)(8936002)(81166006)(106356001)(105586002)(54906003)(110136005)(8676002)(316002)(3480700004)(236005)(9686003)(6306002)(86612001)(53936002)(54896002)(6246003)(33656002)(22452003)(2900100001)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0503; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
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: yQREeLlf1gGPF8zJphWDcS+TT5l26gC5enOyJ+HdI+tcwLhLBIAF31/M6ym1OVrN4UnDoMDVfSJNHOo1t6UKYQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB01334E30C7AF6AE75F58EEFDB6FE0CY4PR21MB0133namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ed057d99-7430-4eab-c5e8-08d56cbd607d
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 17:24:56.4736 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0503
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/b0o2bU4Pf6I1SNghHxO8XhTxf5w>
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: Mon, 05 Feb 2018 17:25:03 -0000

>> This was definitely true for implementations of TCP, but that is TCP's problem, not the network's
Flow classification happens through the network and also on the end host with RSS where a flow is mapped to a core. This allows for building high performance receive processing that could be lock free for the most part. The only downside of ECMP on the network and RSS on the CPU is that a single flow will not take multiple paths or get processed on more than one core. Windows on server machines today can saturate 25-35 Gbps for a single TCP connection before being CPU limited. This is a  reasonable trade off because I don’t know of cases where a single flow is driving more than that amount of traffic. Assumptions about how flows get classified help make for more efficient processing. They also lead to consistent latency. You do not want the traffic to take a bi-modal or N-modal paths (on the network or the host) to being processed because the fluctuations in latency will hurt the workload. I am not arguing for TCP not being resilient to reordering but IMO that should be the uncommon case not the common case. With QUIC if streams were exposed on the network you could take advantage of stream level ECMP and RSS to scale better than TCP but we have chosen to keep the 4-tuple (or the 5-tuple) as the flow classifier on the network which is ok by me since it leads to TCP parity.

Thanks

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Sunday, February 4, 2018 8:35 PM
To: Salz, Rich <rsalz@akamai.com>
Cc: Lubashev, Igor <ilubashe@akamai.com>; Roberto Peon <fenix@fb.com>; QUIC WG <quic@ietf.org>
Subject: Re: Packet number encryption

Privacy-protection can't be a user choice, for the reasons others have noted on this thread.

That said, my primary argument is for encryption to avoid ossification. Not that it matters now, but I'll note that much of GQUIC's original motivation for encrypting headers was to avoid ossification.

I'll reiterate that fields we expose will get ossified and there are long-term ecosystem effects to this. Let me illustrate this with precisely the packet number field. Middleboxes commonly assume that a TCP flow can only handle packets in-order. This assumption comes from the fact that TCP implementations get poor performance when packets are reordered. This was definitely true for implementations of TCP, but that is TCP's problem, not the network's. However, almost all load-balancers I know of now will pin all packets within a TCP flow to one path, leading to sub-optimal performance in the network, and destroying incentives for the endpoints to deploy reordering-resilient TCP implementations (even though there are plenty of ways of doing this.)

Exposing QUIC's packet number field (as any field) is likely to have similar consequences and a similar ecosystem arc.


On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich <rsalz@akamai.com<mailto:rsalz@akamai.com>> wrote:

> Optional security tends to devolve to non-secure.



That’s a great aphorism.  And sadly all too true.