Re: Increasing QUIC connection ID size

[Christian Huitema <[e-mail]>]

On 1/12/2018 3:06 PM, Jana Iyengar wrote:
> I'm not entirely convinced of the overhead concern. In the common HTTP
> case, we expect server->client to not carry CIDs, so this is a NOP in
> the commonly bandwidth-limited case.

Not just the transmission overhead. You are also increasing the memory
footprint of the connection context, which stores at least 2 CNX-ID, and
maybe more if we want to support migration.

But I agree that this is not the end of the world.

Also, following Victor's message, I was doing the maths on the size of
the ID. 64 bits allows for 24 bits of server ID, 32 bits of client
nonce, and 8 bits of zero -- for checking. 8 bits check will still let
0.4% of forged packets through, which is probably OK since the server
acts as a backstop. 24 bits would work for 16M servers, which should be
OK, but assumes that servers have a unique serial ID, which is not
necessarily OK. Then 32 bits look like they allow 4G connections per
server, but we start seeing collisions after 65K connections per server,
which seems not good. So, yes, 64 bits probably will be very tight if we
want the router to be stateless.

> I do think that this makes CID generation at servers substantially
> simpler -- you can simply add 1 to the current CID to generate a new
> one, and encryption makes it unlinkable to the previous one. This is a
> substantial benefit.

Yes, you can do that without relying on a secure random generator, and
thus without exposing more of the state of the crypto PRNG. Which is
nice. Another advantage, if the router can reliably map connection-ID to
servers, then we don't need to have the same reset secret for every server.

Just one request. If we do make a change, please go for a fixed size.

-- Christian Huitema