Change:
8.1. Any attacker might open a connection to the server infrastructure and <del> aggressively retire connection IDs to obtain a large sample of IDs that map to the same server.  It could then apply analytical techniques to try to obtain the server encoding. </del> <ins> aggressively simulate migration to obtain a large sample of IDs that map to the same server.  It could then apply analytical techniques to try to obtain the server encoding. </ins> <del> The Encrypted CID algorithm provides robust entropy to making any sort of linkage.  The Obfuscated CID obscures the mapping and prevents trivial brute-force attacks to determine the routing </del> <ins> The Stream and Block Cipher CID algorithms provide robust entropy to making any sort of linkage.  The Obfuscated CID obscures the mapping and prevents trivial brute-force attacks to determine the routing </ins> parameters, but does not provide robust protection against sophisticated attacks.

Discussion:
I found some text that still references the in-band protocol mechanisms. I tried to update terminology here (and in Security Considerations) without changing any design decisions, so that we can bracket those discussions. In particular, would change the intent of the config-rotation bits that we are trying to enforce here. This also touches the normative text about PCID that is the subject of , though I believe this PR doesn't apply any change to the status quo.
As server clusters increase in size, the need to reallocate server identifiers becomes more acute. In one model, the configuration ID is used to indicate a stable routing configuration. Server identifiers for a given configuration ID are routed to the same server, no matter how many other instances are added or removed. In order to allow for changes in the cluster, the configuration ID is used so that old servers can be removed from consideration and new ones added. If these changes happen frequently enough, the number of bits allocated to identifying a configuration might be insufficient. Why not make the length of the identifier flexible? That might mean that you need to make the length of the length similarly configurable.
It was not the intent of these bits to support long-lived configurations, instead supporting key rotation, upgrades, and the like. I would much rather people overprovisioned the server ID space than using this tool, TBH. However, the only cost is limiting the theoretical size of CIDs. At the moment, we can support up to 64B, future-proofing the encodings against future versions of QUIC. I'm open to another bit for this, but how would a configurable number of CR bits work with multiple configurations? How does a config that needs 5 bits and one that needs 2 coexist, especially if the latter needs length self-encoding?
As we talk through the implications of mutually mistrustful servers in , I think the case for adding another bit is compelling. I'm going to remove the needs-discussion label and come up with a PR that takes another bit.
I'm returning this to needs-discussion, as NAME points out there is a privacy tradeoff here. If the config codespace is large, it's straightforward to have each mistrustful server have its own totally unique config. On the other hand, keeping this long-lived config difference leaks the type of flow.

Assuming it's routed based on SNI, it leaks the SNI of each CID, and in that sense also increases linkability.
Alright, I've reflected on this a bit more. In general, different server entities will have different external IP addresses and/or ports, so the load balancer can distinguish the correct QUIC-LB config without resorting to the CR bits. As IP and port are visible to everyone, there is no privacy leakage. The problem occurs when mutually mistrustful servers share the same IP/port and are switched on something else. That "something" may be something present only in the client hello, with the classical load balancer simply using the 4tuple after that. The only thing I am aware of in practice is the SNI. If there are others, please say so in this thread. If the SNI is encrypted, the unprivileged LB envisioned in QUIC-LB does not have access to it. So we can assume this use case only applies to unencrypted SNI. Option 1: mistrustful servers share the same config. a third party will be able to extract your server mapping, but in practice it will be hard for an attacker to obtain this position on purpose. If this is the best outcome, we can stick with 2 config rotation bits. Option 2: Issue them different config rotation codepoints. So an observer can see the SNI and associate it with certain CR bits; if the client later migrates, it will still be able to associate that connection with that SNI. If this is better than Option 1, we should probably add a third config rotation bit. Other (minor) costs of having 3 config rotation bits: length self-encoding can only support 31 byte connection IDs, instead of 63 (obviously this is only relevant for hypothetical future versions of QUIC) each config can have its own set of server IDs. So there is considerably more config state at the LB. As SIDs can be up to 18B, it's 18B x (# of servers) x (# of config rotation codepoints). This memory footprint will roughly double by going from 3 to 7 codepoints. I've talked myself into Option 1 as being a mildly better situation, thus sticking with 2 CR bits.

Update: the ECHO design might allow the LB privileged access to the SNI, so it might be encrypted. However, an attacker could connect to the domains at that IP and obtain the config rotation bits. So option 2 actually circumvents ESNI entirely!
Closing -- I have received no pushback on doing nothing (leaving it at 2 bits), so I'm going to do nothing.
There is a requirement that it be difficult for a party other than the server and load balancer to guess a CID that will be accepted as valid for a target connection. This requirement needs to be validated for the schemes described in the draft. This might impose some constraints on the designs chosen. For instance, I don't believe that the plaintext algorithm meets this goal. The server ID can take all the available space, which is probably wrong. Clearly it is impossible to create sufficient connection IDs for even a single connection if there is only one valid identifier per server. However, it might be argued that even an 18 byte server ID makes it too easy to guess a valid connection ID for a connection (just 16 guesses would be enough to get a 50% chance at that). So it seems to me that a shorter connection ID is necessary. The same applies to any attempt at obfuscation. The encrypted versions might be similarly challenging to get right. The For Server Use field in the stream cipher variant needs to be sufficiently long as to avoid engineered collisions. The value used for the stream cipher is malleable, which means that an attacker isn't prevented from guessing. In many ways, this is more challenging than the plaintext variant because the nonce consumes space. The zero-padding in the block cipher mode might be the best way of preventing guessing, if it were sufficiently long. Similarly, if "Encrypted bits for server use" were sufficiently sparsely populated, then guessing can be hard enough.
What exactly does "a CID that will be accepted as valid for a target connection" mean? What is exactly making this requirement?
A connection ID that is accepted as valid for a target connection is any value that will cause packets to be routed to the node that serves that connection. The transport draft :
I think this issue is conflating two different things: 1) Is it easy to generate a CID that has a high probability of being considered valid by the LB?

For all but BCID with zero-padding, the answer is clearly "yes" unless the SID space is sparsely populated. But that doesn't make them valid at the server. Moreover, if I am just trying to get random packets past the LB, it's far more productive to just generate a bunch of Initials. In the absence of an LB, all CIDs get through to the server, so I don't understand why this is a problem. 2) The transport draft language (it seems to me) exists mostly to prevent linkability in migration events. Although I've mentioned several times that linkability is a continuum, it is pretty clear that PCID fails at this and OCID makes it harder but no one would bet the house on it being truly secure -- hence the name. I think we're due for an actual WG discussion on OCID, but for PCID would it be sufficient for you, MT, if we said that servers using PCID MUST use disable_migration? To be honest, I thought I had already done this but it's not there.
I really want to push back hard on any restrictions around migration for the Plaintext CID algorithm. It is by far the simplest and cheapest algorithm to support in the LB, and IMO must remain a valid option for QUIC load balancing. As far as giving any information to an external observer, it's possible an external observer can work out the Server ID for each CID. Whether this is practically useful information depends on the number of connections being managed by the individual servers. IMO, we cannot restrict the full set of QUIC features to only work on the most complex and costly algorithms. Some solutions may never implement them.
Ah wait, I found the text in security considerations: So it's a SHOULD right now.
To summarize the issue with Plaintext CID. This is the easiest to implement, so is mostly likely to be adopted. However: 1) This makes DoS attacks on a single server quite straightforward. There is no consensus as to whether single-server DoS is a threat to mitigate or not. 2) Makes connection IDs more linkable. 3) Unless we add a server transport parameter for it, the client has no idea they're more linkable. 4) We could prohibit migration to fix the linkability problem.

5) If we prohibit migration, than the only reason to do plaintext CIDs, instead of just 5-tuple routing, is to support NAT rebinding. To some extent, Obfuscated CID might have similar issues.
The discussion at IETF 109 suggested that the level of linkability associated with the PCID algorithm did not violate the spirit of quic-transport (see NAME and NAME in the QUIC-LB segment here: URL)