QUIC-LB issues

Martin Duke <martin.h.duke@gmail.com> Tue, 26 May 2020 18:20 UTC

Return-Path: <martin.h.duke@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 2E9C03A0A92 for <quic@ietfa.amsl.com>; Tue, 26 May 2020 11:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=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 NNZuFVykKYU7 for <quic@ietfa.amsl.com>; Tue, 26 May 2020 11:20:24 -0700 (PDT)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 85A143A0A9E for <quic@ietf.org>; Tue, 26 May 2020 11:20:24 -0700 (PDT)
Received: by mail-il1-x12a.google.com with SMTP id r2so10287549ila.4 for <quic@ietf.org>; Tue, 26 May 2020 11:20:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=QzJg/Ub8ahm9Q20k5o0dEsNe2QvusRj8iCr4+3qAyv4=; b=hTBKIYjMMKWdse/w2AVhKz0sjTIcW86odCPF/G9YXdDAkmocmATj0PDyR1NQ6alTqV scwvEFRM2JqkjBMHFjkXuzVuld1FN5aAcR72SET4qbd9An1pvJPSprIHPn0i4hKEfS71 ZPbvWQoe0hBRTmQCz6/RUky0v8MWjT6uUirGkGppf5YaPhTO6JbdT80Zc9H8RmtteDkm HD/9PT/W4/s/ya8fne5sIskiAtuDUN6fh5tN6BHeNGA7F3TX3a+IaMGSxezdMprHiOB7 zf/Cu7zR20gvbOuSNn/VNnFnTj2OV/2Y0GDdp4GsiJAAUOoVaxr0XNuFmy7Dr/+6F71u Didw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QzJg/Ub8ahm9Q20k5o0dEsNe2QvusRj8iCr4+3qAyv4=; b=H4okghiDjfzpa2yJAXhbdw1bRPD0SBkR+lJbVY3dCtZJjsPC9iHHHGy4UCTHqQncwd lI27JUdGcv0JaFrp/deIybVJXlG82xkTN2Un2eY7KfArMPC9MiErbyzAPqUZU2HRfiQf yjTGyddEgKDbD0lis0/P95f49aRS7CbhrDyzs9jHt+AVi0IfQUohHxIGhAavqrrRyY71 +dtYtM7dXfoMbMnT7Z/9E17S38oS1nYJ9gSn4djTwqin8oBIKE+17ZI6JBIBfaA7qrja obnoVJCAFNCXcwibNobCB+JEDjO9zxU3SXjLLHjudfWnx+p7zEfrjWre5Xl5RSaESkQX S3kA==
X-Gm-Message-State: AOAM531ibGterpsFUSBJ2dZKasieou1I6V0ElGMn29ha4e0p3eVlatA4 p2/O0g/LFqo5OWuzAlenMMhYTqi3Y98sebtqWxho3cqo
X-Google-Smtp-Source: ABdhPJxNppr0HKS6Glh3m03AYWhfzriyp35rDbzqNYI/afHXFj+ELPkg947lpM+o4+q7fpDqi7m9JSMt3LWRs8YcRQE=
X-Received: by 2002:a05:6e02:965:: with SMTP id q5mr2321459ilt.272.1590517223600; Tue, 26 May 2020 11:20:23 -0700 (PDT)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 26 May 2020 11:20:11 -0700
Message-ID: <CAM4esxQG=YXThMA6uW3Y=3Qjt5xv8vOt92+FQ7GebcFGFVoH_g@mail.gmail.com>
Subject: QUIC-LB issues
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001f367905a6912699"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/B2mGb0QmfR7unxjiunBm4_7EXbY>
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: Tue, 26 May 2020 18:20:26 -0000

Hello all,

There hasn't been much activity in QUIC-LB
<https://quicwg.github.io/load-balancers/draft-ietf-quic-load-balancers.html>
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
<https://quicwg.org/load-balancers/draft-ietf-quic-load-balancers.html#name-security>,
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://quicwg.org/load-balancers/draft-ietf-quic-load-balancers.html#name-plaintext-cid-algorithm>
?
2. Should this document include the Obfuscated CID (OCID) algorithm
<https://quicwg.org/load-balancers/draft-ietf-quic-load-balancers.html#name-obfuscated-cid-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?