RE: QUIC-LB issues

[Nick Banks <[e-mail]>]

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 <[e-mail]> On Behalf Of Martin Duke
Sent: Tuesday, May 26, 2020 11:20 AM
To: IETF QUIC WG <[e-mail]>
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>, 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?