RE: Getting to consensus on packet number encryption

Praveen Balasubramanian <pravb@microsoft.com> Wed, 04 April 2018 23:39 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 B4940126FB3 for <quic@ietfa.amsl.com>; Wed, 4 Apr 2018 16:39:10 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 9y9VhmuoiqLg for <quic@ietfa.amsl.com>; Wed, 4 Apr 2018 16:39:08 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0098.outbound.protection.outlook.com [104.47.38.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF6E126C2F for <quic@ietf.org>; Wed, 4 Apr 2018 16:39:08 -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=KqNDlV/G3Q+MEVUr4PEHuzp0BpgXV0/hXXpOMIKfKVE=; b=G+cOLTVcgYTohvP0c24hjFz3DBloxzlqM7rG7m/qUJQUlNCPp/51Ya6eSYO6DbAByyH7YLdoJIQVzgKOXxCB2HvSqM1PEiOu1CUxbj5Otp9xM+xgCPNMI/SsbJ+ndqhOsgvC0cjasvSeSgZCqDiaLvW8qNiia9PNqhuZvy9PXDQ=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0822.namprd21.prod.outlook.com (10.173.192.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Wed, 4 Apr 2018 23:39:05 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Wed, 4 Apr 2018 23:39:05 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: Mark Nottingham <mnot@mnot.net>
CC: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Lars Eggert <lars@eggert.org>, IETF QUIC WG <quic@ietf.org>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Subject: RE: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GYaiUVNrU6h0aiyBQtEo3l9KPwZ0sAgAC4ugCAAARcAIAAFTbwgAAHuICAAAJF8A==
Date: Wed, 04 Apr 2018 23:39:05 +0000
Message-ID: <CY4PR21MB06306E80E651B762DAD2C853B6A40@CY4PR21MB0630.namprd21.prod.outlook.com>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <F9FCC213-62B9-437C-ADF9-1277E6090317@gmail.com> <CABcZeBM3PfPkqVxPMcWM-Noyk=M2eCFWZw2Eq-XytbHM=0T9Uw@mail.gmail.com> <CAN1APdfjuvd1eBWCYedsbpi1mx9_+Xa6VvZ3aq_Bhhc+HN67ug@mail.gmail.com> <CABcZeBMtQBwsAF85i=xHmWN3PuGRkJEci+_PjS3LDXi7NgHyYg@mail.gmail.com> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <CABcZeBNfPsJtLErBn1=iGKuLjJMo=jEB5OLxDuU7FxjJv=+b=A@mail.gmail.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <BBB8D1DE-25F8-4F3D-B274-C317848DE872@akamai.com> <CAN1APdd=47b2eXkvMg+Q_+P254xo4vo-Tu-YQu6XoUGMByO_eQ@mail.gmail.com> <CAKcm_gMpz4MpdmrHLtC8MvTf5uO9LjD915jM-i2LfpKY384O2w@mail.gmail.com> <HE1PR0702MB3611A67E764EE1C7D1644FAD84AD0@HE1PR0702MB3611.eurprd07.prod.outlook.com> <d8e35569-e939-4064-9ec4-2cccfba2f341@huitema.net> <CACpbDccqKoF-Y1poHMN2cLOK9GOuvtMTPsF-QEen3b30kUo9bg@mail.gmail.com> <CAKcm_gNffwpraF-H2LQBF33vUhYFx0bi_UXJ3N14k4Xj4NmWUw@mail.gmail.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <B176FC07-887D-4135-B01E-FE8B4986A5EE@mnot.net> <CAKcm_gOCeocLyrYpOS7Ud332xdz3xHSH0psPN8T6BGRjoL9ptQ@mail.gmail.com> <CY4PR21MB0630FA0EDD343396AD414641B6A40@CY4PR21MB0630.namprd21.prod.outlook.com> <9F724A02-0131-43DB-B1D1-0BFCEEE898D5@mnot.net>
In-Reply-To: <9F724A02-0131-43DB-B1D1-0BFCEEE898D5@mnot.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:a::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0822; 7:X2VkQJOA2UrTVwN7E3IVC73ZwnbfJ9jyKmAE/Z4DVBxkbALeKaxfSYWOxNBb9TIxkppTaDCA2SLBygRXLJHLAcpuUKrngpKwNc7XX1vPXWYHaW9dJ5fGjmiJUNxtgu04dUS637tM4HZF8g8Q/1y49o3X/TnwpcVMCLS4SjqG+dyogEccnnG8wxRJw27qkCkHXhSWzCAacztM/+yTNHwIUF4d1P7aZVqpdMnYV6gjHdwO0Ns06Wg07UfopP7g6Q+O; 20:agkVid5YADXqtcD4PxqWUEQ+XuJjhLjruOwSXGCt+6rh2of5gxl+BWQQSUtR4a5cjjcc2v6fUVNSYTzT8YIWUbBqiGciRMbQDb5CQ3gdEfaq2CpW5RaHj7Nogtv9PJI/foxNxw5X3ehdbDT9qE2akxtt5VGEnmCsMQeih8GPtLU=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 38213b7c-1633-4e00-ad4c-08d59a854105
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0822;
x-ms-traffictypediagnostic: CY4PR21MB0822:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-microsoft-antispam-prvs: <CY4PR21MB0822A24A6D67E72A3F9F75FBB6A40@CY4PR21MB0822.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(189930954265078)(100405760836317)(219752817060721);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501327)(52105095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0822; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0822;
x-forefront-prvs: 0632519F33
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(346002)(366004)(396003)(376002)(13464003)(199004)(189003)(53546011)(6506007)(102836004)(54906003)(6116002)(186003)(11346002)(446003)(99286004)(93886005)(25786009)(10290500003)(476003)(486006)(46003)(6436002)(4326008)(7696005)(76176011)(106356001)(86612001)(33656002)(9686003)(55016002)(6306002)(97736004)(14454004)(3280700002)(68736007)(53936002)(2900100001)(5660300001)(81166006)(81156014)(105586002)(8676002)(8936002)(74316002)(6246003)(10090500001)(8990500004)(2906002)(86362001)(3660700001)(229853002)(22452003)(316002)(5250100002)(478600001)(6916009)(966005)(7736002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0822; H:CY4PR21MB0630.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)
x-microsoft-antispam-message-info: qu5KjDgK/HUGMfWsz9szXCige3PIvevJhzKZ3zOLMHjjXubgNskw0IBRtxxBHI4E+IOlthf9NR3Tgm2eQ6+PciMS7AdpUTOOpzymlPpyXVIh0FxhJG5uVYfcnF3RFv6G2bb2n/AtcoyQXRNArlBk1LD6XuUDB0Y9LeX5yT8aYQqepk3rxW2nS8mGvnkXsLtsdIkVWhRVrvRtFDxq7jYVX/ieyfDUqjP4AeA1jMKbHIxn92QImD7b1gm2ToS8+FjIsswbpFSVC8ya3vE08z6sx1sUQZtCVY/5HWtL7x/ENLOU94xSAyzDC8Zo0gxdtoXF1djuUF3UREKCIu05F2T+mfN2W+8G+rKczQOdXff7tK3ucLhFmLc5gzUSS7lwlF3MP+UnZdyA/zt4/E7k2PCLuNV4pHHMtkGicxjU4xM3Tdo=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 38213b7c-1633-4e00-ad4c-08d59a854105
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 23:39:05.3621 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0822
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rclR7HB8Au0Fu7kJReQx6Xy-988>
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: Wed, 04 Apr 2018 23:39:11 -0000

Yes I am not opposed to including migration in V1 if its a negotiated option. By "leave the draft as is" I meant it for connections that will not migrate. Parking lot problem/ migration  doesn’t apply to: devices connected to just one network, OS policy preventing aggressive use of metered networks, desktops and laptops with just wifi or ethernet, all datacenter servers, and Internet facing servers behind legacy load balancers. It’s not universal.

-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net] 
Sent: Wednesday, April 4, 2018 4:27 PM
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: Ian Swett <ianswett=40google.com@dmarc.ietf.org>; Lars Eggert <lars@eggert.org>; IETF QUIC WG <quic@ietf.org>; Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Subject: Re: Getting to consensus on packet number encryption

Hi Praveen,

On 5 Apr 2018, at 9:22 am, Praveen Balasubramanian <pravb@microsoft.com> wrote:
> 
> PNE is one way forward for doing connection migration without linkability. I wouldn’t call it the most pragmatic since it has performance implications.
>  
> Any objections to the following?
> 1. Leave the current draft as is for the common case (no migration no multipath).

Just noting -- one of the things that came up in Melbourne was that migration for the "parking lot problem" -- i.e., wifi to cellular, or vice versa -- *is* in-scope for QUICv1, in many people's minds. 

> Make sure we have some provision for greasing the PN to prevent ossification. If PN jumps are needed for this (apart from a random starting PN) we should have a PR modifying current draft.
> 2. For connection migration the options are:
> a. Explore multiple PN spaces for connection migration (and eventually 
> multipath), OR b. Make PNE (and hence connection migration) an optional negotiated extension in V1 with the caveat that we will  revisit this  for V2 when we do multipath. This is required anyways because servers must be able to tell client that they cannot support migration since they are behind a legacy load balancer.

--
Mark Nottingham   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=02%7C01%7Cpravb%40microsoft.com%7C1ac1708c2f024d3ce96608d59a83a010%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636584812483586746&sdata=pMVsnysCkFFkvsmFjaDwuDWKshPBycW8XDYbA70sU3A%3D&reserved=0