Increasing QUIC connection ID size

Victor Vasiliev <> Thu, 11 January 2018 23:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BCDC129C6A for <>; Thu, 11 Jan 2018 15:16:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 gtrUOXJLgAmg for <>; Thu, 11 Jan 2018 15:16:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A075D129C51 for <>; Thu, 11 Jan 2018 15:16:12 -0800 (PST)
Received: by with SMTP id c14so3973119qkh.4 for <>; Thu, 11 Jan 2018 15:16:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=tB4Yv18KlAatFQ4f6kxJFg+rYvjkrh6s775rIdWHVWA=; b=KhSVOmJTTjR1lOg1z6ovF0CM+yyH75IeqzYSzTt+b7+RTvXi+vBZQFrIpznVfby89j goWA8DNCAgCfHtaUtHfSI+fPKAh9qSCFgAm5L621gqL7PkWc6X38v1iG2qYSHeYthGv6 xJuSHCDI3YGGJnjvE0drfQ2/8/Wyd8J5WPu46deXM/uqYWNliGjj5KkolRL7A8R1JQWe /EloyTrmU6V8jCDxnG9KpQiY/r6AgBYw8Etmi7e8/6QRAVy/zwQOiI1uqqSZjxfUvDFs JPrm+OyLjmK3i2nvtzD0vgguPjf2JLbyuod1VEOOGr2MEodCCylq6bOi3H/+Fyvl783n 03+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tB4Yv18KlAatFQ4f6kxJFg+rYvjkrh6s775rIdWHVWA=; b=FXe1EAk2txj8Px7fOQyFlw/dHXCUC8mvcsrHp0ViR+BZvEUnKeqO+UuOvN4KIC1hjn WPuTpwl5XiYTUNUrl/BsvRqfH4665yAeuidDdn4bj2rqS327W9SgeXVk4TTUFwa3a1nk DtgWjJbws2qWgDB0KgIAjolDaVq5MxQX5IKEqcDaqN5YLj+yPZRF4BjlJtwT3iyfWQwP m+U4jao35D+4mrVKbsc7TEcq9PEBvhxaps5rOjIHwlhFsPn7NRKHfPq5ig//KX4xV0kY xFeZAA4nl1D/aMl1a2cNxyDmQBKh7Y6uybVmsy8DPy6JQ0YyKjFBwa2YhHruXDqGrDOa 70gA==
X-Gm-Message-State: AKwxytdoKDHT9q18p2+lKwc4U5gnkg7u3G0E020K1ajphmZPlFue5bkN t6wq4lWQqftEMgRiZwBspVFtMnXNWKKuHLjQIAUL/y2U9w0=
X-Google-Smtp-Source: ACJfBouuLZbtHMfs46//9ASm0aAXFny1+W5L0XwC6J+SGo265OZAxaWHr8kXmUx7mdffkbp3I+1BtA0ITA444i06UwA=
X-Received: by with SMTP id 18mr32446229qkz.214.1515712571179; Thu, 11 Jan 2018 15:16:11 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 11 Jan 2018 15:16:10 -0800 (PST)
From: Victor Vasiliev <>
Date: Thu, 11 Jan 2018 18:16:10 -0500
Message-ID: <>
Subject: Increasing QUIC connection ID size
Content-Type: multipart/alternative; boundary="001a1147b2c063b7ac05628855bc"
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: Thu, 11 Jan 2018 23:16:15 -0000

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:

   1. Store some routing metadata in the connection ID.
   2. Have some entropy that allows distinguish users with identical
   routing metadata.
   3. Have a checksum to ensure the validity of routing information
   4. 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:

   1. Do we want to address this problem at this point in standardization
   2. 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.