Change:
Although more complex, the three-pass algorithm seems strictly better.
I like it, but there is some imprecision in the text. I would like to see something about detecting corruption, probably in the load balancer actions.

Discussion:
Load balancers SHOULD drop packets with non-compliant DCIDs in a short header. <ins> A QUIC-LB configuration MAY significantly over-provision the server ID space (i.e., provide far more codepoints than there are servers) to increase the probability that a randomly generated Destination Connection ID is non- compliant. </ins> Load balancers MUST forward packets with compliant DCIDs to a server in accordance with the chosen routing algorithm.

the earliest octets from the destination connection ID as necessary to match the nonce length.  The server ID immediately follows. <del> The load balancer decrypts the server ID using 128-bit AES Electronic Codebook (ECB) mode, much like QUIC header protection.  The nonce octets are zero-padded to 16 octets.  AES-ECB encrypts this nonce using its key to generate a mask which it applies to the encrypted server id. server_id = encrypted_server_id ^ AES-ECB(key, padded-nonce) For example, if the nonce length is 10 octets and the server ID length is 2 octets, the connection ID can be as small as 13 octets. The load balancer uses the the second through eleventh of the connection ID for the nonce, zero-pads it to 16 octets using the first 6 octets of the token, and uses this to decrypt the server ID in the twelfth and thirteenth octet. The output of the decryption is the server ID that the load balancer uses for routing. 4.3.3. When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the server ID octets.  Servers MAY opt to have a longer connection ID beyond the nonce and server ID.  The nonce and additional bits MAY encode additional information, but SHOULD appear essentially random to observers. The server decrypts the server ID using 128-bit AES Electronic Codebook (ECB) mode, much like QUIC header protection.  The nonce octets are zero-padded to 16 octets using the as many of the first octets of the token as necessary.  AES-ECB encrypts this nonce using its key to generate a mask which it applies to the server id. encrypted_server_id = server_id ^ AES-ECB(key, padded-nonce) 4.4. The Triple Stream Cipher CID algorithm is a variant of the stream cipher algorithm stream-cipher-cid-algorithm that provides true cryptographic protection and also mitigates the malleability issues with a simple stream cipher application.  The CID format is the the same as depicted in stream-cipher-cid-format. 4.4.1. The configuration agent actions are the same as in stream-cipher-cid- format-configuration. 4.4.2. Upon receipt of a QUIC packet, the load balancer extracts as many of the earliest octets from the destination connection ID as necessary to match the nonce length.  The server ID immediately follows. </del> The load balancer decrypts the nonce and the server ID using the following three pass algorithm:

server_id = server_id_intermediate ^ AES-ECB(key, padded-nonce) <ins> For example, if the nonce length is 10 octets and the server ID length is 2 octets, the connection ID can be as small as 13 octets. The load balancer uses the the second through eleventh octets of the connection ID for the nonce, zero-pads it to 16 octets, uses xors the result with the twelfth and thirteenth octet.  The result is padded with 14 octets of zeros and encrypted to obtain a mask that is xored with the nonce octets.  Finally, the nonce octets are padded with six octets of zeros, encrypted, and the first two octets xored with the server ID octets to obtain the actual server ID. </ins> This three-pass algorithm is a simplified version of the FFX <del> algorithm.  It has the same connection ID length requirements as the Stream Cipher CID Algorithm, with the additional property that each encrypted nonce value depends on all server ID bits, and each encrypted server ID bit depends on all nonce bits and all server ID bits.  This mitigates attacks against stream ciphers in which attackers simply flip encrypted server-ID bits. </del> <ins> algorithm, with the property that each encrypted nonce value depends on all server ID bits, and each encrypted server ID bit depends on all nonce bits and all server ID bits.  This mitigates attacks against stream ciphers in which attackers simply flip encrypted server-ID bits. </ins> The output of the decryption is the server ID that the load balancer uses for routing. <del> 4.4.3. </del> <ins> 4.3.3. </ins> When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the

server. The server encrypts the server ID using exactly the algorithm as <del> described in triple-stream-cipher-load-balancer-actions, performing the three passes in reverse order. </del> <ins> described in stream-cipher-load-balancer-actions, performing the three passes in reverse order. </ins> <del> 4.5. </del> <ins> 4.4. </ins> The Block Cipher CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, provides higher cryptographic

it also requires connection IDs of at least 17 octets, increasing overhead of client-to-server packets. <del> 4.5.1. </del> <ins> 4.4.1. </ins> The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently

The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. <del> 4.5.2. </del> <ins> 4.4.2. </ins> Upon receipt of a QUIC packet, the load balancer reads the first octet to obtain the config rotation bits.  It then decrypts the

opaque server data in that order.  The load balancer uses the server ID octets for routing. <del> 4.5.3. </del> <ins> 4.4.3. </ins> When generating a routable connection ID, the server MUST choose a connection ID length between 17 and 20 octets.  The server writes its