Re: Increasing QUIC connection ID size

[Martin Thomson <[e-mail]>]

Hi Victor,

I've opened an issue for this here:
https://github.com/quicwg/base-drafts/issues/1052

On Fri, Jan 12, 2018 at 10:16 AM, Victor Vasiliev <[e-mail]> 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.