Re: Increasing QUIC connection ID size

[Willy Tarreau <[e-mail]>]

On Fri, Jan 12, 2018 at 01:05:02AM +0000, Roberto Peon wrote:
> Correct/agreed. The L4 'router' must be able to decrypt/interpret the data in
> order to act upon it. This requires sharing of some key material.

At least we need to keep in mind that it's critical to ensure consistency
between all front nodes (think DNS+anycast BGP+ECMP LB before reaching the
L7 LB). It's critical that all equipments in the path are able to coherently
find the correct path to the origin node without having to actually learn
anything from the packets. And synchronizing keys between multiple nodes
is often a pain (though never impossible).

At the HTTP workshop 2 years ago, I proposed to place some upfront routing
information on TLS to save LBs from having to decrypting the stream to
find what server the stream had to be sent to. The proposal was to have
a small ID, typically 16 bits, for this. In my opinion this is another
option we can consider here : with only 16 bits, you can easily store a
server ID in a reasonable farm size (even dynamic), but you don't have
enough information to track users. So it could remain accessible in
clear, saving front nodes from having to decrypt anything or share keys.

Willy