You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Usually, the DCID in the Initial Packet is chosen by the clients with a random value, the current QUIC-LB draft does not mention much about it.
It would be great if the final RFC allowed that, in certain deployments, the clients and the load balancers may assume the DCID of Initial Packets are in a particular format so that some routing strategy can be applied, as long as the DCID is unpredictable with at least 64 bits random entropy, thus not weaken the requirements in section 7.2 of RFC9000.
For example, the client may construct the DCID of the initial packet with a hashed client identifier and a random nonce of 8 bytes, and the load balancers will route the initial packets based on the hashed client identifier if the DCID is in a recognized format, otherwise fallback to the way how the unroutable CID is handled. Of course, such construct comes with security concerns, and probably should be encrypted, e.g. in the same way as how the routable CID is encrypted, with a key that needs to be exchanged/negotiated out of bands.
The text was updated successfully, but these errors were encountered:
thynson
changed the title
Allow the load balancer to apply certain routing strategy on DCID of Initial Packet
Allow the load balancer to assume DCID format of Initial Packet and apply certain routing strategy on it
Jun 18, 2024
Usually, the DCID in the Initial Packet is chosen by the clients with a random value, the current QUIC-LB draft does not mention much about it.
It would be great if the final RFC allowed that, in certain deployments, the clients and the load balancers may assume the DCID of Initial Packets are in a particular format so that some routing strategy can be applied, as long as the DCID is unpredictable with at least 64 bits random entropy, thus not weaken the requirements in section 7.2 of RFC9000.
For example, the client may construct the DCID of the initial packet with a hashed client identifier and a random nonce of 8 bytes, and the load balancers will route the initial packets based on the hashed client identifier if the DCID is in a recognized format, otherwise fallback to the way how the unroutable CID is handled. Of course, such construct comes with security concerns, and probably should be encrypted, e.g. in the same way as how the routable CID is encrypted, with a key that needs to be exchanged/negotiated out of bands.
The text was updated successfully, but these errors were encountered: