Provide Signal that SCID is client assigned

[mikkelfj]

In QUIC v1 the first CID (OCID) is client assigned although most CID's are assigned by the authority controlling the receiving endpoint.

I propose to make it publicly visible via invariants which endpoint authored or authorized the CID. This obviously requires a change to invariants.

Such a signal could be single header bit similar to how long/short packets are identified.

It could be useful in resolving some LB issues with traffic routing in v1, but even if this is not used by v1, other QUIC versions might regret not having this signal.

Now, there is nothing in the invariants stating how CIDs are constructed, so by all means it could happen by a vote by the general british population. But, realistically, there are two endpoints and two responsible parties so it can be stated in invariants who authorized the CID even if it is unknown how or by whom.

It would require a change to invariants. But for the sanity of current and future QUIC versions, I believe it is important to know if a CID is assigned by client where a CID is normally assigned by the destinations authority.

See also discussion here: #2834

[mikkelfj]

Note that long header packets is not a good choice of signal because if forces a decision to use client chosen CID's for all future long packet. There might be an overlap in v1, but v2 should be able to make its own choices. Hence an extra bit in the header. We have two unused.

[DavidSchinazi]

@mikkelfj can you elaborate on how one could use this new explicit signal? What problem does this solve?

[mikkelfj]

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 make a fast decision cannot trust client generated CIDs 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 not enable it 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.

[DavidSchinazi]

I'm not sure I understand. As a load balancer, you can only trust a server-issued CID if it decrypts correctly. Since you're therefore checking decryption for each packet, then you already have access to the bit, the connection is server-issued if it decrypts. Or are you suggesting that there are times where you don't attempt decryption?

[kazuho]

I agree with @DavidSchinazi. The load balancer has to prove if the CID is in fact server-generated. Then, there's no benefit, computational-wise, between having the bit exposed vs. having the bit embedded in the CID.

[mikkelfj]

You can have 4 byte CID's that are designed to route to specific infrastructure but not enough to fully trust. But I agree that in many cases authenticating the CID can provide the information needed.

[mikkelfj]

Consider deployments where it is not always practical to share secrets between LB and endpoints, such as in public cloud hosting.

[martinthomson]

We have discussed this several times in the past and concluded not to do this. I'm not seeing any new information here, so I'm going to propose that we close this issue with no action.

[larseggert]

I think the discussion supports closing with no action