Re: Increasing QUIC connection ID size

Martin Thomson <> Mon, 15 January 2018 09:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 346E012D942 for <>; Mon, 15 Jan 2018 01:41:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nSBYgW-jINHQ for <>; Mon, 15 Jan 2018 01:41:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C4B712D885 for <>; Mon, 15 Jan 2018 01:41:47 -0800 (PST)
Received: by with SMTP id t20so801885ote.11 for <>; Mon, 15 Jan 2018 01:41:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=h2mak2NOwgIEhPwAvVgXc5pvv1hGIPis74SSm7Dg1Lg=; b=Cy9BsiOTmnZAcoguopnvRmMC4jJeD71g4htBdqtU+Hv+gJIrg9qFlXxUp9iUFYEAK2 ZImwi0Ykoe+KBzLbEOcCJAGs4Cx/2Z2JZgqth2quboy1btY6b1/thJ+9s1tBFRyVgmH0 8pR400jIyFWwFAxus+etc986ckiiyqXaqCxhw5sSLtM9kuQu9iVpKkpWLXu/WLBHcqA3 R1kr1v6AKrvk4IkiB/H0ZQ3LXxZCgMDiFLEy0BV6duTlb+Pcky2B2zHE9Va6TpUmUE0z VdBP1CKVR/J5Ila3DsNB0AiDA/fZY03SJVfDhXulYPC3Ejl5ZVx8h1UmaQvGTFtirfRc d0mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=h2mak2NOwgIEhPwAvVgXc5pvv1hGIPis74SSm7Dg1Lg=; b=iDE5rnbupqW1hjj6a07hoCKQj5x/fzX/ZrpQdsPr7IhlMOcGf2qiUxTfvC/VJ1LiqG jPYJXx4BisLmbrJu+ACVdaWa0mBzq5KeTJx4rBSqcRmdMNbyY0/VinIhk4SOKZUnWRwj Ce6UJs39esvu8QzFL6OEV0J3RmnMFPR/0WWdcy0wCMq4K7ueXeQ/C5jAoWa2oCbfXQkZ bDuhLXQ+9uCBjgL5EQuYcwFBdq6aHiACW/IsIHTgwXAL+u1/oZ1KPQlzSjQWVyGp6eAo 3hrzDa80A5XewmOgT5KhY7kS++EXhSvK2daLv1Y+zlQWjXXfUwyGiiO/NyI8nEOSQZlg u/lw==
X-Gm-Message-State: AKwxytc6tZcc9fw9R5WUNX6ATgecxtOGkxvcPdmKbutvn6KeGiFaRdmu i/TCbS9SQoQUcS5B6eo41lxqlTPeV7cmCv2oqLY=
X-Google-Smtp-Source: ACJfBov3TIc/N0AQxOjngh5Q3OzGkawrYyufAoPmSVjNbcmr/HUGb7NUI70BCzwo7LQ3GQVgLxnPJB8to136kENkbSg=
X-Received: by with SMTP id z38mr21046893oti.16.1516009306698; Mon, 15 Jan 2018 01:41:46 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 15 Jan 2018 01:41:45 -0800 (PST)
In-Reply-To: <>
References: <>
From: Martin Thomson <>
Date: Mon, 15 Jan 2018 20:41:45 +1100
Message-ID: <>
Subject: Re: Increasing QUIC connection ID size
To: Victor Vasiliev <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.22
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: Mon, 15 Jan 2018 09:41:49 -0000

Hi Victor,

I've opened an issue for this here:

On Fri, Jan 12, 2018 at 10:16 AM, Victor Vasiliev <> wrote:
> Hi everyone,
> In the current version of QUIC, the connection ID size is fixed to be a
> 64-bit opaque blob, and that is set as an invariant in the protocol.
> I’ve looked into possibility of using a connection ID to encode the specific
> server details into it (to provide stability of the connection in case of
> load balancing changes, especially BGP flaps for anycast IPs), and have
> chatted about this with other people I knew were interested in this.  It
> seems like 64 bits might be too small for this purpose, and we might want to
> leave an opportunity to extend the connection ID size.
> The basic idea is that you want to be able to:
> Store some routing metadata in the connection ID.
> Have some entropy that allows distinguish users with identical routing
> metadata.
> Have a checksum to ensure the validity of routing information
> Encrypt the information above to prevent disclosing the route information
> and allow generating uncorrelatable connection IDs.
> There are two underlying issues here.  The first problem is that all of this
> does not fit well into 64 bits, and you have to seriously compromise on the
> strength of the checksum (which is bad especially if you want it to be a MAC
> rather than a checksum).  The second problem is that encrypting 64-bit
> values fast is actually fairly hard since the block ciphers easily available
> in hardware have 128-bit block size, and the performance requirements on
> load balancers are tighter than on servers.
> In other words, having a 128-bit connection ID provides for an easy secure
> way to generate unlinkable connection IDs on migration.
> So, the problem we’re trying to solve is that the connection ID is too
> small.  There are two questions I believe the working group should answer at
> this point:
> Do we want to address this problem at this point in standardization process?
> If we don’t address this problem right now, how do we structure the standard
> in a way that we can extend the connection ID in the future?
> There are multiple ways to solve the problem of making connection ID larger.
> One is to just add extra bit to the “omit connection ID” field to allow
> 128-bit connection IDs.  Another approach is to allow connection ID size to
> be explicitly specified by the server, and then assume that the load
> balancer knows that size and no one else on the path needs to read it.
> There’s also a question of how much of connection IDs do middleboxes
> (excluding load balancers and other boxes owned by the same entity as either
> client or server) need to know.  We could go for both “middleboxes should be
> always able to read the entire ID” and “middleboxes should not read
> connection IDs at all options”, but I think there’s also a room for more
> flexible formulations like “middleboxes always get first 64 bits and they
> have useful entropy to distinguish connections”.
>   -- Victor.