RE: QUIC-LB issues

Nick Banks <nibanks@microsoft.com> Thu, 28 May 2020 14:41 UTC

Return-Path: <nibanks@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 8C3083A0E3B for <quic@ietfa.amsl.com>; Thu, 28 May 2020 07:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, 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 5rcUcZDa5bpd for <quic@ietfa.amsl.com>; Thu, 28 May 2020 07:41:29 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640096.outbound.protection.outlook.com [40.107.64.96]) (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 6EA433A0B2D for <quic@ietf.org>; Thu, 28 May 2020 07:41:29 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ONgjxQb0Lw/dxJVWfr2l9hs++byUWJD7s8f9A9moyc8uF4ysJqN5gnkrIHgdP9UNwnjcOKr4UqIGdHJpbxj6bNvWS96Vq33ecsAW5Re+Lqrs65JSvnHQEyO+SZ54OTwMrvdnxpQQcP0EA42cVMCGeaJ+g0hcpTZx86hshR3ZLYB2oI/Y0LkZXcRDynXREMgRg6YNC0td0qdcZNopjl4WDovE2vNGDH0HNtvxmApcFvggLISX1+5PY3J75yjdqRnPp7x9SV+gTe4gIUjHs8CuQjaBp1XURlW59YEfQnEhSpapTQUBZHogUXj5plT6qjXj5IW7I9MSrvGVaMVB3FpDhQ==
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=weN77tKuJhKNCxiGlCwecio4TG+YtYt1Q7Qsw5Lbijk=; b=TvmM+hn7JnQctyOl7UrYgjgwXwetOcsCIj0TtlrcavejBIN1jIoFBe6X9gdeVvcjOfQ8j57yMQeNF525Gq2JhUTMh4Sp+cnPHOBYDXS2u9wjDMIPO6HuR0C9JWEB9WZ+nlgruS0dBUIA6eEPpM6G5X5zg00UslgvPnpydxWw9U6m98s3CPQd95asZ1zUb50FskZyKnt7i51YytFfo9K05v7DDbgtACEfFTlC5diineaKYvQ7HgAEp1w3oIPho+5U7DQfe+xmO4geYveSm/xGGumS86QW/zOHXJDsbiYOiBl2I4izQWiwFvx76ZcMsxHN1LyqF/JKYWP3jY3A60ikuQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=weN77tKuJhKNCxiGlCwecio4TG+YtYt1Q7Qsw5Lbijk=; b=NKqNv7DO8lQ2RvQPZNDAcxIkUwoHU24+jQDMXXJy5APNiDEEngue8McLab9igzHO4XQWP8+nf6vCz/9elLJffLnzKtrZC12vjyJ42dRoB68e2A2q53IcVwgxGdWuKebrRlf5Nfhw/LF+gZ+b9au91mLeqi0Fx4upGdF/+NUlHRc=
Received: from SN2PR00MB0173.namprd00.prod.outlook.com (2603:10b6:804:14::15) by SN6PR00MB0368.namprd00.prod.outlook.com (2603:10b6:805:c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3077.0; Thu, 28 May 2020 14:41:22 +0000
Received: from SN2PR00MB0173.namprd00.prod.outlook.com ([fe80::dcb1:7cd2:83ab:964f]) by SN2PR00MB0173.namprd00.prod.outlook.com ([fe80::dcb1:7cd2:83ab:964f%14]) with mapi id 15.20.3088.000; Thu, 28 May 2020 14:41:22 +0000
From: Nick Banks <nibanks@microsoft.com>
To: Martin Duke <martin.h.duke@gmail.com>, IETF QUIC WG <quic@ietf.org>
Subject: RE: QUIC-LB issues
Thread-Topic: QUIC-LB issues
Thread-Index: AQHWM4pcADgmfU/HckejiEL9tB/4zai9j1LQ
Date: Thu, 28 May 2020 14:41:22 +0000
Message-ID: <SN2PR00MB0173119C2F79216A5C0D3750B38E0@SN2PR00MB0173.namprd00.prod.outlook.com>
References: <CAM4esxQG=YXThMA6uW3Y=3Qjt5xv8vOt92+FQ7GebcFGFVoH_g@mail.gmail.com>
In-Reply-To: <CAM4esxQG=YXThMA6uW3Y=3Qjt5xv8vOt92+FQ7GebcFGFVoH_g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:7:3cad:efb9:a9da:fbcf]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 54e0877d-6e9c-404c-19f5-08d803153106
x-ms-traffictypediagnostic: SN6PR00MB0368:
x-microsoft-antispam-prvs: <SN6PR00MB0368291CB61C8872DC77C081B38E0@SN6PR00MB0368.namprd00.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0417A3FFD2
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +MA9G9iKoTA+SJg/NZ4sqfQuZuEBfy7f3YViZEbQCw3uwrS2vMJxV0sc/SChnkm/gduh2UCHmtcqgsBZfHM9kPSWQ1EyktxY6sCANKaKgYIpvgh8ttiPzHwzAIOmU/auobqNpESmFEmMhQr+WUmyTp0+mxff/Nx5dtFTjXrY+jCg5jFPXROMA7IkcvBv8NF+EQNqyvMsv+tkXuzxOE4hoQq1Y0UX6gJW+Xfz+khUgx1vNd2qryCEwdUm7DHxXB3yrjPIYipHE9x3vmZAJy9LKqQ6l/c/D5bd+YAMJlpEcC2nZObLyEI3Bni/D3XYXzKlHXLh7ecC4BVo4S36GlEUeG87qzIlGl7TLjwU8a6ZK0oM6oXlPZvbo02WcWdP68adgrFLYMxBgKon1ZcyyKX6pg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN2PR00MB0173.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(376002)(39860400002)(366004)(346002)(5660300002)(10290500003)(8990500004)(52536014)(2906002)(83080400001)(8676002)(966005)(3480700007)(82960400001)(71200400001)(82950400001)(478600001)(83380400001)(316002)(55016002)(6506007)(53546011)(186003)(110136005)(8936002)(166002)(76116006)(66946007)(66556008)(86362001)(9686003)(66446008)(66476007)(7696005)(33656002)(64756008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 89XmR4o/mXjk0sWhdJtTqcCwkeAN1uU5OK0PGAgBcDRDwi0wnFZAza1KO8xPdLq3bGIA5X8zkjPhv9KXA4lrzuLjoQm4xDZMLUQrtWTLyCzvAMiGHkr1q7eposhhOpUA7PHYrTAaAzQkkTS3NwipCyT9DNuf7fCaLCJJr9mt93Sqptrfu/xjXJwiXJboGW5JkjzLrP+MxeKsKFUt2DkJq175PfPU0TYHIHtxWHtS9OJHIHE+Zb885hX5+lHIeybVEalXeX9C9wWSL7x4P4sGS6J7mYY5wwmSzembEziElw4r2Tlqm2LudfLwXHeO/di/2ZPxwrS1V4deblyWDrefilpEOjmYgNdWLnmxUo6JNvp6O6aEmMqFYW1kD062E4MDEnPORy7DIOlWqtdmtvCX8Rn4NsXtlrpzskenO9eL225c4pcWCXjWOEi5VZn1V4ZQAWSwgmviud0h1Rr4sniqwC4hAZWN/eLFwRZ+GaA0/GoXVGNL11hj5qMdLgqkdrUrdgeV7PXiotnRSkuSNg4C8w95YW9gnfuhoK34aWQeaQw=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_SN2PR00MB0173119C2F79216A5C0D3750B38E0SN2PR00MB0173namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN2PR00MB0173.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 54e0877d-6e9c-404c-19f5-08d803153106
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 14:41:22.3835 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3Z+WuKPL6r+H2bU1weTnoWZTX5b/EvgLSW8zunBOlrthTBQOYqpU0xtBwiAyW0QWgtW5CI0z4CjWBjPWW9uxCg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0368
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/zQlf3Llsxlp5i3FzNwFErv-UbkY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 28 May 2020 14:41:32 -0000

Hello Martin & WG,

For Azure, we’re in the process of building a load balancing scheme on top of the Plaintext CID algorithm, so we’d definitely like to keep it in the document. The complicated nature of some of our scenarios (multiple containers per-DIP, all behind a single LB; with all components generally independent) currently prevents us from practically supporting anything more than the most basic algorithm. Additionally, whether it’s adopted by the WG or something Azure specific, we will likely require an in-band communication to communicate the Server ID to all the routing components involved.

We may eventually adopt one of the ciphertext algorithms in the future, but I doubt we’d ever add support for the Obfuscated CID algorithm.

On the topic of issue #8, we disagree that the possible information exposure when using the Plaintext CID algorithm is enough reason to declare the CIDs as “guessable”. So we’d be against recommending/requiring that migration be disabled when using the plaintext algorithm. Additionally, in our opinion, if migration is not supported/allowed by the server, then there isn’t really any reason to do anything more than IP tuple load balancing at all. The whole point of QUIC-LB is to provide for load balancing solutions that survive tuple changes.

Thanks,
- Nick

From: QUIC <quic-bounces@ietf.org> On Behalf Of Martin Duke
Sent: Tuesday, May 26, 2020 11:20 AM
To: IETF QUIC WG <quic@ietf.org>
Subject: QUIC-LB issues

Hello all,

There hasn't been much activity in QUIC-LB<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fquicwg.github.io%2Fload-balancers%2Fdraft-ietf-quic-load-balancers.html&data=02%7C01%7Cnibanks%40microsoft.com%7C05fd68c21cb64747efbb08d801a17dca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261140403852523&sdata=i0k%2BSRBnx7vbaamu%2BXMgkDDYkeqB6b0i%2Birjt8DYYNU%3D&reserved=0> lately. There is at least one issue that could use some broader community input.

https://github.com/quicwg/load-balancers/issues/8<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fload-balancers%2Fissues%2F8&data=02%7C01%7Cnibanks%40microsoft.com%7C05fd68c21cb64747efbb08d801a17dca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261140403862517&sdata=46zC4KbxRXVLkAe5H7uQJHwrkVzZE1mEstmOTTMqAOM%3D&reserved=0>

The core issue is that there are 4 algorithms to encode the server ID, 2 ciphertext and 2 plaintext. Of the two plaintext algorithms, one is blindingly obvious (just encode it a known field) and the other applies quite a bit of obfuscation. The obfuscated version has undergone some informal analysis vs. brute force attacks, but I doubt crypto experts would be impressed.

The QUIC WG reflex has generally been to encrypt everything possible. There are two reasons theseplaintext algorithms exist:
1) As section 2.2 describes<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fquicwg.org%2Fload-balancers%2Fdraft-ietf-quic-load-balancers.html%23name-security&data=02%7C01%7Cnibanks%40microsoft.com%7C05fd68c21cb64747efbb08d801a17dca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261140403862517&sdata=DJHWhnx3nRJmbFhixhd1X%2FdSRo0zXdOGtKed6lvyGy0%3D&reserved=0>amp;reserved=0>, there is no such thing as perfect protection from linkability, so even full encryption is only moving things along a continuum. It is not nearly as bright a line as, say, https vs. http.
2) What little feedback we've gotten from people that make layer 4 cloud load balancers has been pretty negative about adding encryption to their implementations. I can probably get F5 to adopt it, but other than that the deployment story is not solid on the load balancer side. There is still much work to do here on outreach to the big cloud providers.

Possibly, an open source implementation (I'm working on it...) might assuage their fears. An implementation that implements both LB-side encrypted algorithms is less than 80 lines of C, not including openssl or the separate code to configure the LB properly.

The design team had consensus to include all of these options, with some intending to support them in their products. Beyond that, Martin T is the only person I'm aware of to have engaged on the PT options, and he was pretty negative about them. What is the sense of the group as a whole?
1. Should this document include the Plaintext CID (PCID) algorithm<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fquicwg.org%2Fload-balancers%2Fdraft-ietf-quic-load-balancers.html%23name-plaintext-cid-algorithm&data=02%7C01%7Cnibanks%40microsoft.com%7C05fd68c21cb64747efbb08d801a17dca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261140403872510&sdata=wQhEr0a5jBiRPU1JF9vwB7Zo3szACXN8NHxqWikFcWE%3D&reserved=0>?
2. Should this document include the Obfuscated CID (OCID) algorithm<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fquicwg.org%2Fload-balancers%2Fdraft-ietf-quic-load-balancers.html%23name-obfuscated-cid-algorithm&data=02%7C01%7Cnibanks%40microsoft.com%7C05fd68c21cb64747efbb08d801a17dca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261140403872510&sdata=3RB9PqEFW15jRQF2kK14%2F4m%2FVMMcC1iCfOVOpwizh5c%3D&reserved=0>?

*****

On a related note: one issue with the plaintext/obfuscated algorithms is that they are chosen by the server but the consequences of linkability are borne by the client. The current draft says that the non-obfuscated algorithm SHOULD be accompanied by a disable_active_migration parameter; that's potentially an overloaded codepoint.

https://github.com/quicwg/load-balancers/issues/16<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fload-balancers%2Fissues%2F16&data=02%7C01%7Cnibanks%40microsoft.com%7C05fd68c21cb64747efbb08d801a17dca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261140403882505&sdata=yKGXyRzuJqnHOEWeHuxeiHhNXzCa9tOibrAPk5meqKQ%3D&reserved=0>

An alternative would be to create a new transport parameter that would allow the server to explicitly say what it is doing. Clients could then decide whether or not to migrate with their eyes wide open. On the other hand, this leaks some information about the encoding into the network.

3. Assuming we have at least one unencrypted algorithm, is this server TP a good idea or not?