Re: Increasing QUIC connection ID size

Ian Swett <> Fri, 12 January 2018 13:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32F2312D77D for <>; Fri, 12 Jan 2018 05:58:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Status: No, score=-2.01 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_NONE=-0.0001, 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 FDV7gIqxUgpO for <>; Fri, 12 Jan 2018 05:58:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3BE112E869 for <>; Fri, 12 Jan 2018 05:58:46 -0800 (PST)
Received: by with SMTP id t63so5950540iod.0 for <>; Fri, 12 Jan 2018 05:58:46 -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; bh=d61a15hbM8tQPqvEbUviDoe3In+rQO0/WiAFrCrzqpg=; b=g0qI3lxKZEV0GxCwkvxb6Vt5yLAa8GYFaR+y+BTXtGrXnp7u27cTIuBurB2Ayv2AQW bwX375IYd10JKHX+vpboB42VnsGLwBWcjYxSfkO2ePxoRPQWm95U2XxRnQzrn6ktvAvb hqlFoRUaQ/BIA1Aq1foe1g35XflpM3pp52FdqYJX32TpNLYGswISGeF+43lfqT8WZ8/w oNJ3oqfTrlF0lUvdYU/zQau5Ih1++2C+p85bxlMJ0rf34y6Wl9tW9KK2GIBwbenKA0gM LHrDoe17vem1j3WORTpfV2ZpGjoQcoMpC1S6Al53QBsuQJ+GyWjAr14Vmp1wDoIAzVs3 EMLQ==
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; bh=d61a15hbM8tQPqvEbUviDoe3In+rQO0/WiAFrCrzqpg=; b=HoH8qpBxa9Wuy61CCdNQfwJnTd1szC0IWt+bYtxXI3i8DzSPKplux1Vw9XXNQK85R4 aNPY4JiMnxW98lEkbu/gjjN4VYmC6AGs2rJGiv2Gm8VN9FVqjuyuLAZoEHw1l15Og8vi U0FJ4jQuK+pEPQcil1he9zkTTeCNbnu4Z/g3AuYObk/3+wJiGWNf8benOa3xUw3LB7Yc xV4QI6t2i1OhJz4vRQ+fiRTg4GSpvJfnR3b7Ddto4pZ1v03K+eqLtiCF29yxO89gmGaA 5jOZ7iHg+bzmlPQP4hNxT/TYL9q/arLBhYnN9i4+OnpnQ5FvNkxx8gFd1iT/aCNBCX2q Q9KA==
X-Gm-Message-State: AKwxytdI7AXyddyYFUPjz8mNzGS1+zz5rpEoZ844fdhS4NXQWuJt5uiZ LAuTR/4vNR4CWHoPxM85eQBa0CigQTB/ltu93/trJQ==
X-Google-Smtp-Source: ACJfBotDTUqAKOYhx2pHfDHgBVO7iLVPnDgPM31/LLynBNhRpH45+fNtuL54feKtAEtIqfyQDGplLfPrCfqoG9lEdlg=
X-Received: by with SMTP id d2mr23801780iob.170.1515765525676; Fri, 12 Jan 2018 05:58:45 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 12 Jan 2018 05:58:24 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Ian Swett <>
Date: Fri, 12 Jan 2018 08:58:24 -0500
Message-ID: <>
Subject: Re: Increasing QUIC connection ID size
To: Christian Huitema <>
Content-Type: multipart/alternative; boundary="f4f5e803beb0b910af056294a93d"
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: Fri, 12 Jan 2018 13:58:50 -0000

I would like to leave QUIC open for longer connection IDs in future
versions, so I'd like to specify the invariants in such a way that longer
connection Ids wouldn't violate them(ie: Victor's suggestion
of “middleboxes always get first 64 bits and they have useful entropy to
distinguish connections”.) but I'm reluctant to include 128 bit connection
IDs in v1 at this point.

I would also echo Christian's sentiment that the incremental overhead
starts becoming fairly large.

On Thu, Jan 11, 2018 at 9:47 PM, Christian Huitema <>

> We have a prototype implementation in Picoquic in which the connection ID
> can be split so some bits are random and some bits are used for routing to
> a specific server -- thanks Igor for that. It makes for nice experiments,
> but it is a denial of service waiting to happen. For example, attackers
> could set the bits in such a way as to target a specific server in a pool,
> or they could learn which connections are on the same server and use that
> later for some kind of same server attack. It would be better if that
> information was not in clear text. In fact, the picoquic implementation use
> a callback to ask for the new value -- presumably from the router. That
> callback could return anything, including an encrypted value.
> On the other hand, it is not clear to me that we need full encryption. For
> example, assume that the server that needs a connection ID can ask it from
> the router. The router could pick one at random, make sure that it is
> properly documented in the routing tables and that there is no collision,
> and then pass it back to the server. No encryption needed, but of course
> lots of state.
> If the router does not want to keep the state, it can indeed create a
> connection ID by encrypting a <nonce, server-ID> tuple. But it does not
> follow that the encryption needs to be 128 bits. For example, it could use
> a 64 bit algorithm like Blowfish.
> So I am not sure that we actually need to change the length. And I am a
> bit concerned by the incremental overhead if the connection ID suddenly
> becomes very large.
> On 1/11/2018 2:25 PM, Mikkel Fahnøe Jørgensen wrote:
> Actually, on encryption of connection ID, this is not so simple.
> We must assume there is only a single key for many connections because the
> router is not part of a key exchange. This unique value or counter used for
> encrypting a single block cannot be the same for two different connections
> ID’s, but it can be public. This means that it must be stored in the packet
> header. And, as it turns out, random connection ID chosen by a trusted
> source, can be used for such a unique value. But then it must be used to
> encrypt and/or authenticate something else carrying the actual routing
> information. So now you start to really need some extra payload.
> Alternatively the routing information is entirely random such as content
> hashed routing. Then you only need to authenticate the routing data. You
> can do that with a HMAC, and CMAC could probably also work. The additional
> benefit is that you can probably get away with 64-bits for all routing
> information possibly including the auth tag. Say 48 bits of routing data
> and 16 bits of auth tag.
> Kind Regards,
> Mikkel Fahnøe Jørgensen
> On 12 January 2018 at 00.57.21, Lubashev, Igor (
> wrote:
> I am interested in exploring this proposal, since it allows for more
> flexible schemes of encoding routing metadata and a checksum.  I would also
> like to be explicit about the connection ID size in a packet header,
> though, since it greatly simplifies the implementation.
>    - Igor
> *From:* Victor Vasiliev []
> *Sent:* Thursday, January 11, 2018 6:16 PM
> *To:* IETF QUIC WG <>
> *Subject:* Increasing QUIC connection ID size
> 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
>    process?
>    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.