Poor guidance on rejecting short CIDs

[gloinul]

Detecting Conflict section (2.4) states:

"Since very short Connection IDs are more likely to lead to conflicts, particularly zero-length Connection IDs, a proxy MAY choose to reject all requests for very short Connection IDs as conflicts, in anticipation of future conflicts."

So I think there need to be a framing question for the below. Is the goal here to have multiple different clients with connection-ID to reuse a common server-socket. So that all clients behind a particular MASQUE server wanting to reach popular-service UDP-port=443 will use the same server socket?

If that is the case then I can partially understand the MAY to avoid causing clients with long CIDs getting its different CID using different 5-tuples towards the target.

How much analysis have you done for what consequences that will result. Having multiple non-coordinated traffic flows share the same 5-tuple will make it very much like a tunnel flow, however this one will most likely be directed to a server. Will that have any strange affect on load-balancing, denial of service mitigation. I see that a bot behind a particular MASQUE service could attempting to share 5-tuple with other clients and use that to DoS those other flows by triggering DoS mitigations for this flow.

Also, are you really meaning reject, or simply detect the collision and give the client a new server-socket?

If multiple MASQUE client's are not sharing the server-socket then I think this is an unnecessary recommendation that causes issues without any benefit.

So the client that attempt to map multiple QUIC CIDs, that might even be the same QUIC connection, to a particular server-socket will likely do this by being aware of this. Thus it will coordinate so that it doesn't conflict. Even if they are uncoordinated there are no point of rejecting a working mapping because it might result in failure later. If the mapping fails, then the proxy simply creates a new server-socket and give it to the client. Rejecting the mapping prior to a conflict occurring and thus using more resource unnecessarily.

In the case of totally uncoordinated QUIC connection where one use short CIDs and the other long ones, then I think if there are any considerations to avoid issues for this, that should fall on the client rather than the server to not attempt to map these two connections to the same server-side socket. This collision algorithm is simple and can be run by the client also for those resource it requests.

[gloinul]

An addition here is that maybe there is a need to tease this apart for what occurs on the client-proxy 5-tuple and what happens on the proxy-target 5-tuple. I was very much only thinking of the later when I wrote the above.

For the client-proxy I think we should discuss if there are need for additional client-proxy 5-tuples (different client side UDP ports) to deal with the conflicts from completely uncoordinated CID usage to enable forwarding of these packets? That would require the ports to established and likely some path probing to be done, so possibly a conflict would require additional QUIC connection establishment to the proxy?

[tfpauly]

Connection ID awareness doesn't force a server to reuse a UDP socket, but it allows it.

Depending on the proxy configuration, if it knows it needs to always optimize for forwarding mode, the proxy MAY choose to reject clients that are requesting zero-length CIDs, because it shows that they might be misconfigured and will interfere with the forwarding operation.

I think the key point here is that the clients are always aware they are proxying, and thus are able to choose good CID lengths; this isn't entirely uncoordinated.