Re: QUIC-LB issues

Watson Ladd <watsonbladd@gmail.com> Wed, 03 June 2020 00:28 UTC

Return-Path: <watsonbladd@gmail.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 623903A1153 for <quic@ietfa.amsl.com>; Tue, 2 Jun 2020 17:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HMUz6PfYmwnA for <quic@ietfa.amsl.com>; Tue, 2 Jun 2020 17:28:05 -0700 (PDT)
Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE3B3A1158 for <quic@ietf.org>; Tue, 2 Jun 2020 17:28:05 -0700 (PDT)
Received: by mail-lf1-x144.google.com with SMTP id c21so191354lfb.3 for <quic@ietf.org>; Tue, 02 Jun 2020 17:28:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=i/MhagO1CB39m03+Pmzou/FCUIG86HhK6pFD7Gs54TI=; b=avv9l0wUZoMPo/3hT7Zm2U27fFzQCJOdQOYupnL4w9iH5Zw/80z14BdJ5uODkG6mUW DWDzJP4xqAU6XafOJN4um4tVXdaKNydRAgVaxRzDM3zQfgx3BRN1d3fWzUFZw7kCDKYk TCgHkspd5hKAerzhKbSHtPYzaNGiW6goDH6RymmGw1mvy4IJSD+BsMf8FKfFfCpf99k8 UAw+3t3p861vtcDkimE+zBW6IjCDnN3TpytQJNGgHbYLnXtvQeFdeOhj/YjZJXq08sRl bkniPBvDhE3/vzObRCKiNg84Z4q+O14SzwpRlcbHyBXAHCP7I/KItFiAPMtPs/pfyTXN AVxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=i/MhagO1CB39m03+Pmzou/FCUIG86HhK6pFD7Gs54TI=; b=SJxCwu2sKRgfiGVCdEQ36j6V/yLXInf3TUijf4KnS4AWz0Jr5hHmbrcmGzhuqk/p5Z xrwvcfMETJzRBI1U9xwepSl8+dJO6npLH0mdCzluRuaaCH8jtH0crpu/+PJM+jNJDVsK +U3lIwiphtL6Gv0IEVBUSS6/BglWiXwfHdd+n2rIe84EHOxUcaW7nvdUnN9+7tIXSR1d Ekb8jiEjjIGRwy2lzO0On9u6jmV/MZCOid0C+8qMn0hrYMDVtky0U68vPeF/+l7zqDB+ Ax2+8sZivrcRXyo3SNZsWFCYciFhZhNXbouN37the8wNZa+Y1pNyG0ottmUEPF2fAmV9 k/FQ==
X-Gm-Message-State: AOAM533WrPDoR0Y2iLRZMKqOoq2hTAJOYvXjKM2yFe0unwbJ9TmZu9Vx lZZFKidZgoXYFOgIYtv+sWzh5xTkM+f34yYpEdY=
X-Google-Smtp-Source: ABdhPJy641rbSYR7MzTX7vjVJHLYTNdQff57dNTTU76S+t0JWvhgaSPLhC7Q54PS5Qlz7r1JjVMwSa6xjgmot6Amk2k=
X-Received: by 2002:a19:6cd:: with SMTP id 196mr956998lfg.216.1591144078354; Tue, 02 Jun 2020 17:27:58 -0700 (PDT)
MIME-Version: 1.0
References: <CAM4esxQG=YXThMA6uW3Y=3Qjt5xv8vOt92+FQ7GebcFGFVoH_g@mail.gmail.com> <SN2PR00MB0173119C2F79216A5C0D3750B38E0@SN2PR00MB0173.namprd00.prod.outlook.com> <E1EB91DF-54F9-43E7-90F3-42ED042CB71D@ericsson.com> <CH2PR00MB0726D9D56D3B42831D74A620B68B0@CH2PR00MB0726.namprd00.prod.outlook.com>
In-Reply-To: <CH2PR00MB0726D9D56D3B42831D74A620B68B0@CH2PR00MB0726.namprd00.prod.outlook.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Tue, 02 Jun 2020 20:27:46 -0400
Message-ID: <CACsn0c=4JmjLn8Zq66urtkLAL98KcYu81aoXEF8Ct7aJi4hUaA@mail.gmail.com>
Subject: Re: QUIC-LB issues
To: Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>
Cc: Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, Nick Banks <nibanks=40microsoft.com@dmarc.ietf.org>, Martin Duke <martin.h.duke@gmail.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/XoZsnDSm44LUKf-s2Ql6VbR5w84>
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: Wed, 03 Jun 2020 00:28:07 -0000

On Tue, Jun 2, 2020 at 12:15 PM Praveen Balasubramanian
<pravb=40microsoft.com@dmarc.ietf.org> wrote:
>
> >>“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.”
>
> That’s quite an onerous requirement and its unclear what is meant by correlation. And since it has nothing to do with interop I don’t understand how the MUST NOT can be verified.

Many security related MUSTs have nothing to do with interop. As for
what correlation of connections means it means that given a set of
connection IDs and the packets it should be impossible to group those
into connections with greater then chance success.

>
>
>
> From: QUIC <quic-bounces@ietf.org> On Behalf Of Mirja Kuehlewind
> Sent: Tuesday, June 2, 2020 3:34 AM
> To: Nick Banks <nibanks=40microsoft.com@dmarc.ietf.org>; Martin Duke <martin.h.duke@gmail.com>; IETF QUIC WG <quic@ietf.org>
> Subject: [EXTERNAL] Re: QUIC-LB issues
>
>
>
> 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.”
>
>
>
> Mirja
>
>
>
>
>
>
>
> From: QUIC <quic-bounces@ietf.org> on behalf of Nick Banks <nibanks=40microsoft.com@dmarc.ietf.org>
> Date: Thursday, 28. May 2020 at 16:41
> To: Martin Duke <martin.h.duke@gmail.com>, IETF QUIC WG <quic@ietf.org>
> 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.
>
>
>
> 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 lately. There is at least one issue that could use some broader community input.
>
>
>
> https://github.com/quicwg/load-balancers/issues/8
>
>
>
> 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, 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.
>
>
>
> https://github.com/quicwg/load-balancers/issues/16
>
>
>
> 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?



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.