Re: [quicwg/base-drafts] Provide Signal that SCID is client assigned (#2838)

[MikkelFJ <[e-mail]>]

An LB may use this signal as an indication that it may choose an arbitrary endpoint without the need for consistent routing and consequently QUIC versions should be designed accordingly.

Load Balancers need to make qualified decision on how to route traffic, especially when the connection is being established. If the LB is always willing to do a cryptographic validation of the CID, it can use that as a signal but a load balancer that needs to a fast decision cannot trust client generated CID's because they might just have poor entropy, or they might be constructed to DoS a single endpoint.

The signal could also be encoded as a bit in the CID itself, but that is just moving a header bit.
Some have proposed using the long header to detect if the CID is client generated, but that prevents the long header from switching to server chosen CID early, and it would ossify in LB at the peril of future QUIC versions.

A common solution for CID'less routing is to use a 4-tuple hash, instead of a client CID, but that requires that you know that you need to do it, as opposed to using a server generated CID. A 4-tuple hash will not work behind a proxy where the original source IP is lost. It will also not work in future non-IP networks where CID is used for routing alone. Today QUIC v1 requires the handshake to be 4-tuple stable which is probably fine, but it is not necessarily fine in all future versions or all kinds of deployments.

Of course an endpoint can lie about the CID bit, but that should be enable to successfully establish or maintain a connection. Other on-path entities could manipulate the bit, but the same can be said for other header parts that might affect routing.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2838#issuecomment-505227174