Allow fallback algorithms to parse known QUIC versions

[thynson]

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.

[martinduke]

Thanks for filing the issue!

The spec assumes that client-generated connection IDs are random, and Section 3.1 is all about how to handle it.

Adding client coordination to the operating model is a major expansion of scope. Allowing clients to control backend routing introduces security concerns well beyond what can be resolved with encryption.

Furthermore, special rules for Initial Packets introduces version dependence in a way that is unsatisfactory (See Sec. 7).

Adding new rules for unroutable DCIDs due to an alternate structure to client-generated connection IDs requires only modest changes to QUIC-LB, and I would very much prefer that they go in a separate draft that modifies the sections about unroutable DCID handling.

I'm closing this with no action. If there is significant interest on the mailing list to make this happen, I'd be willing to reconsider.

[thynson]

Thanks for the reply.

We're fine with this decision, as in our deployment, both client, server and balancer are under controlled.

And it seems to me that [Section 3.2. Fallback Algorithms] already allowed us to do so, except there is something we violate but, and as a feedback, we would like to propose to change/fix.

Since in our implementation we treat Initial Packet differently, effectively it violates

A fallback algorithm MUST NOT make the routing behavior dependent on
any bits in the first octet of the QUIC packet header, except the
first bit, which indicates a long header.

while the type of packets is something version specific.

Meanwhile, In [7. Version Invariance of QUIC-LB],

Some load balancers might inspect version-specific elements of
packets to make a routing decision. This might include the Server
Name Indication (SNI) extension in the TLS Client Hello.

So I think Section 3.2 should be fixed to make it consist.

[martinduke]

I agree that this could be better written. Reopening.