Change:
packets MUST define a mechanism that is robust against version downgrade attacks. <ins> 21.10. Deployments should limit the ability of an attacker to target a new connection to a particular server instance.  This means that client- controlled fields, such as the initial Destination Connection ID used on Initial and 0-RTT packets SHOULD NOT be used by themselves to make routing decisions.  Ideally, routing decisions are made independently of client-selected values; a Source Connection ID can be selected to route later packets to the same server. </ins> 22. 22.1.

Discussion:
I went to and found that the offending text was already removed, so we're most of the way there. I added a note to the Security Considerations about not letting clients dictate your routing decisions.
In Section 7.2, the spec makes an implicit assumption that the CID of the Initial packet is used for routing: makes this even more explicit: However, in the discussion of , part of the conclusion was that, to protect from malicious clients, load balancers cannot safely permit client-chosen fields to influence the routing of their packets to a particular server. IIRC, this was also discussed in New York. Did we mean that? If so, we have conflicting text.
I'd say sometimes it's safe and sometimes it's not and there are pros and cons of different approaches. You mention conflicting text, can you point out the text that conflicts with the sections you quoted above in this issue?
I tend to agree with Ian, but an Initial that follows a stateless reset would have to be routed consistently. I assume this reset driven routing cannot (trivially) be abused due to integrity checks in the reset, but I don't recall the details.
Conflicting as in, we have text (quoted) which contradicts my understanding of our decision. I think if we decide to go with what we'd discussed before (don't trust the CID of Initial/0-RTT), we should add some Security Considerations text about that.
NAME I presume you mean Retry. The server can specify any CID in the Retry, but I'd expect the routing to be achieved by IP:port consistency throughout the handshake.
I mean Retry, of course. You cannot assume IP/port consistency because the routing will in some cases happen behind an external load balancer that exposes a single public IP and routes to a specific internal IP based on CID.
If a middlebox can tell the difference between and original and a Retry driven Initial packet, it would be possible configure the middlebox to a) route randomly on first initial, or b) route consistently on first initial, and for both a) and b) route consistently after a retry. In the case b) the middlebox could force a retry when it thinks there is overload either accidentally, or through an attack. If the Retry is verified properly, it is not possible to forge a successful CID in this case.

All of this should be possible, and trivial to do, but need some reading up to see what is the current state of affairs. I think middleboxes might not be able to detect a Retry driven initial but endpoints are since a Retry can only happen once.
Nah, I think a retry would not make sense in the above, or least not where you end up with the same external loadbalancer and public IP. In that case the load balancer could just internally swap endpoint. So NAME is probably right about IP/port stability. EDIT: disagreeing with myself again: if the load balancer is distributed, but has a single IP, and if is mostly stateless and depends on the CID for actual routing, it does indeed need a Retry even if the IP/port is the same.
My answer is that both are true and that they can co-exist. While the server can't rely on the randomized connection ID being good, it might choose to allow routing based on that value under normal circumstances. The recommendation that a client not tamper with fields that might alter routing is a sensible one. As is the recommendation that a server not attach too much significance to values chosen by clients.
NAME : I don't think there is any text that suggests a server "not attach too much significance to values chosen by clients". Do folks think it might be useful to add to Security Considerations?
Obviously I think we should. :-) If we think there's a place for both, then let's give both some airtime in the spec.
Discussed in Tokyo; add Security Considerations text about an attacker's ability to influence server selection, but don't normatively forbid the use of the ODCID in routing decisions.
I think the point NAME is making is a sensible one. The explicit text that Mike has quoted is implying that servers SHOULD use Client-chosen CID for routing. After all, this purpose is explicitly stated, without any caveats, right there in the spec. I would rather see that quoted text removed altogether. It is enough to state that "A client SHOULD select an initial Destination Connection ID length long enough to satisfy the minimum size requirements for every QUIC version it supports". This is accurate and not misleading.
Fix NAME suggestions and we're good.