Re: QUIC-LB issues

Mirja Kuehlewind <> Tue, 02 June 2020 10:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B969F3A00AD for <>; Tue, 2 Jun 2020 03:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WmwMJZ0pDCF9 for <>; Tue, 2 Jun 2020 03:34:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 639EC3A003E for <>; Tue, 2 Jun 2020 03:34:15 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=fdiMOauqHDOBbLueWkafSzMYjdmz+e5jUYM1Hj9qoN2x8lM3J4DiTOdAWcxoRSkClbHyRbd8AV7+LiZTXZo6dBLY63JkzoiC0y81p3Pd4KimgeNTclY1odLGPFutArgR5M0NZR62QxQmf8AoFT8ABBpcMUTmZELV/BOwMexhOswapGDhvl4XfcHpYa/LInsGmggoCApY4Fr/T2PBlo7RM0kH2LYLcOoM0KaAE0JIIQ8xVIu+lk8GYufEXXK4s4JXBR9gVdbmZZkZA+5hi7vX5goNsTdCV+5Ak/QVyUVTjaQ7MkT97JBxGv8JD2yM3jiwN8jb3aeOilqt8iOWE3zlcg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZzrhAC+hyBDin1+DbQ4bxN/Z+fn2RO8fwnsG/CDO/aE=; b=EYtBRkajP/ASe86ePhuSG+ZDFx83bvJQW8usHazS53mama0dG9uWwfyogMStR2Ytt5LvI7+QFDDpxwVwWfaoT5gHOxp1Rvx+T2pGUe3N2hISeW35kdZUhSENyE344HC84i/e4/0OLeLjNISAR/jecMxQ6SmzbrjifYcmkIi7KpOZxD2R56k86KqpgxzEoL7qaJGUS6IdBNH303jnZV5vc2ongJK/3563yh/uPMTGVDcNyn3YgfslNyyd1B12pa7fw8C3lxba704xw40ufUYmVlOHJe+RM4pzhwSzTO8ds87awLbWNvBSvrtrLKqUrOaZdMRC2KiBkf/4iEVxf5kbZg==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZzrhAC+hyBDin1+DbQ4bxN/Z+fn2RO8fwnsG/CDO/aE=; b=h0MkWsCmU4Ds/szeQwMKUr3+oJpFUpIBu9bg/SW3f2ufPHKKxbGlMrhaLrvkSGFrI8KzMFxcOxqG2VSXhZjS0bZpr5IKqMbFCsNuF1mp5TyexPlhkcHH7Rn/e3NozMFqZAGnH5XJwPjma2DgOWcHy7YGfdDbozmhcQaREdlGFGA=
Received: from (2603:10a6:208:75::30) by (2603:10a6:208:49::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.12; Tue, 2 Jun 2020 10:34:10 +0000
Received: from ([fe80::5c92:87f1:124a:e912]) by ([fe80::5c92:87f1:124a:e912%5]) with mapi id 15.20.3066.016; Tue, 2 Jun 2020 10:34:10 +0000
From: Mirja Kuehlewind <>
To: Nick Banks <>, Martin Duke <>, IETF QUIC WG <>
Subject: Re: QUIC-LB issues
Thread-Topic: QUIC-LB issues
Thread-Index: AQHWM4peMP6XQ3CTwkSqaQwuavGX3ai9lQcAgAe4HgA=
Date: Tue, 2 Jun 2020 10:34:10 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/16.37.20051002
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: [2003:de:e700:7a00:4b4:966:e26f:f909]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: daa80ef6-2e34-4626-a73c-08d806e07c97
x-ms-traffictypediagnostic: AM0PR07MB4113:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0422860ED4
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: TKNDQXmt6LkPWj4DEExkArf+a3p3zp/mUnDfHHwUivAlTfY6IDMY3MNOZ4YOuT4fy3ijn1hSNc90rNRCokCJrCQ3AWIlZFpbhpFFNoG65V58VajcaAB1p3XHJDu+wxuCBzqY5lgkCTCPZmAu93S+AtcOW6Me7qsw9jyb5q40dHm7Uihh5XjwGa0DNSNJiUujZIajtpHU8TgnGiEN0vSpoZdWq6lKWo35eyRhAq2loVQeLd9BxWG8loJfFUVq9GMG/ncZRixAH/MaSL4J8f9ZP695VRyoMIVIH4W/a6tmRTNDH62kCNe5g9kFw2HSd6F6qq3VOUwH9CPQ1KsFsSviEkwVTljeCaafP9xIXqApkuIwNQD38iWLwCgJJ/A65IEiqRDDuB0DLjwDaMUVEiqLaQ==
x-forefront-antispam-report: CIP:; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM;; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(366004)(376002)(39860400002)(396003)(86362001)(110136005)(316002)(36756003)(5660300002)(478600001)(8936002)(33656002)(166002)(64756008)(66476007)(66556008)(66446008)(83380400001)(966005)(6512007)(8676002)(6486002)(53546011)(83080400001)(71200400001)(2906002)(6506007)(186003)(2616005)(3480700007)(66946007)(44832011)(76116006); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: GAn5It0Top+VPJ2I6OYQIC6nVe8kTr6XXCAPfsYxbOkBjy72bapLAUx0jahzbdFDeRfhaBSJo8trhVtBeKJOH/THfWa/JMgMPkiIDjS1hUNOjm5PMgMELfhlPwh9+Ounm19DA0P4G6OUnj0891lMmKz5b8kC3iQ8cKQqeD3lCf7fTtsbf3IF3TzXegga152gRmBmqj/8EDN7rPDXUb7s26llm++nKGmZ8VPCo7WtjyDz1/eDOyKDpPQps8gjxClbKsLPXJCyM9lekIIyu15YBGhYyQJ69xWx8SvaH93hxVylKbgDQxmvZL3QILVWkUs2x64cPbs2rZnZuysQAlDeW3Ri+uamjJxhErg0lKaVOy8s7+nFw/HOl1IQZxiWf3SIJ+I8yKTRvMBdrJJrSPglZs2beY92fGar+V9C0JELsid7z7+PX3rNhHJ3zZO5b8+VIMfCTRt+mYCJJL5wR7nzQRd38gFnpwe+IXrOzRQxNfDVbtZkHbVUFXQxeVLgle2cgm9W6NonrejfWZqSxE1Fah68pjmd5rMZjvUYMr6jpKU=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_E1EB91DF54F943E790F342ED042CB71Dericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: daa80ef6-2e34-4626-a73c-08d806e07c97
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2020 10:34:10.4290 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /LUEN1wb6N1V4DNyAWmfWxsh6MCYUamNyjbs46TJ2vdIW0H6/E39I8PvNmNraBEdMGahq1UT+L1VifqvzztCgiw0BtPYubSBM3nsY7XEn0I=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4113
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Jun 2020 10:34:19 -0000

Hi Martin,

I can’t provide you any feedback on implementation or deployment plans but given these algorithms are used with one domain, I would assume that some plaintext algorithms would be used anyway even if not documented in this draft. Therefore I would rather like see all the different approaches documented and discussed here. And there is already a clear warning in the security consideration section.

Not sure about the need for a new transport parameter. I guess given the server selects the CID there could always be a risk that they are somehow linkable. There is no way for the client to check that. So if a client really, really wants to ensure that there is no linkability, it probably generally has to disable migration entirely.

However, I would also like to note that the current transport draft says the following:
“Connection IDs MUST NOT contain any information that can be used by an external observer (that is, one that does not cooperate with the issuer) to correlate them with other connection IDs for the same connection.”


From: QUIC <> on behalf of Nick Banks <>
Date: Thursday, 28. May 2020 at 16:41
To: Martin Duke <>om>, IETF QUIC WG <>
Subject: RE: QUIC-LB issues

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.

- Nick

From: QUIC <> On Behalf Of Martin Duke
Sent: Tuesday, May 26, 2020 11:20 AM
Subject: QUIC-LB issues

Hello all,

There hasn't been much activity in QUIC-LB<> lately. There is at least one issue that could use some broader community input.<>

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<>26reserved%3D0>, 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<>?
2. Should this document include the Obfuscated CID (OCID) algorithm<>?


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.<>

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?