Original text:
A server encodes one of its assigned server IDs in any CID it generates using the relevant configuration. <del> 4.4. All connection IDs use the following format: Each configuration specifies the length of the Server ID and Nonce fields, with limits defined for each algorithm.  When using a given configuration, the server MUST generate CIDs of length equal to the lengths of these three fields. The Server ID is assigned to each server in accordance with sid- allocation.  Dynamically allocated SIDs are limited to seven octets or fewer.  Statically allocated ones have different limits for each algorithm. The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers. The Nonce is selected by the server when it generates a CID.  As the name implies, a server MUST use a nonce no more than once when generating a CID for a given server ID and unique set of configuration parameters. The nonce length MUST be at least 4 octets.  Additional limits on its length are different for each algorithm.  See cid-entropy for limits on nonce generation. As QUIC version 1 limits connection IDs to 20 octets, the server ID and nonce lengths MUST sum to 19 octets or less. </del> 5. <del> Encryption in the algorithms below uses the AES-128-ECB cipher. Future standards could add new algorithms that use other ciphers to provide cryptographic agility in accordance with RFC7696.  QUIC-LB implementations SHOULD be extensible to support new algorithms. </del> 5.1. <del> The Plaintext CID Algorithm makes no attempt to obscure the mapping of connections to servers, significantly increasing linkability. </del>  <del> 5.1.1. </del>  <del> See cid-format. </del>  <del> 5.1.2. </del>  <del> On each incoming packet, the load balancer extracts consecutive octets, beginning with the second octet.  These bytes represent the server ID.  It ignores the nonce. </del>  <del> 5.1.3. </del>  <del> When a server needs a new connection ID, it encodes one of its assigned server IDs in consecutive octets beginning with the second and chooses a nonce.  This nonce MUST appear to be random (see cid- entropy). </del>  <del> 5.2. </del>  <del> The Encrypted Short CID algorithm provides cryptographic protection at the cost of additional per-packet processing at the load balancer to decrypt every incoming connection ID, unless the load balancer maintains state for the routing information of any given 4-tuple. </del>  <del> 5.2.1. </del>  <del> The nonce length MUST be no fewer than 4 octets.  The nonce SHOULD be at least as long as the server ID in order to save the load balancer an encryption pass; see below. </del>  <del> The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. </del>  <del> 5.2.2. </del>  <del> 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.  See cid-entropy for nonce generation considerations. </del>  <del> The server encrypts the server ID using the following four pass algorithm, which leverages 128-bit AES Electronic Codebook (ECB) mode, much like QUIC header protection. </del>  <del> In the text below, ^ is the XOR function and || is concatenation. The truncate() function takes the most significant octets of its argument, so that the XOR function operates on fields of the same length.  The expand() function outputs 16 octets, with its first argument in the most significant bits, its second argument in the least significant bits, and zeros in all other positions.  Thus, </del>  The example at the end of this section helps to clarify the steps described below. example, 0x7040b81b55ccf3 would split into a left_0 of 0x7040b81 and right_0 of 0xb55ccf3. <del> Encrypt left_0.  The encryption is 128-bit AES-ECB with the key provided by the configuration agent, and the plaintext argument is an expanded version of left_0 where left_0 constitutes the most significant bits, 0x01 is the least significant octet, and all other bits are zero. </del>  <del> XOR the most significant bits of the ciphertext with right_0 to </del>  form right_1. <del> Thus steps 3 and 4 can be expressed as "right_1 = right_0 ^ truncate(AES_ECB(key, expand(left_0, 0x01)) " </del>  Repeat steps 3 and 4, but use them to compute left_1 by expanding <del> and encrypting right_1 with the least significant octet as 0x02 and XOR the results with left_0. </del>  <del> "left_1 = left_0 ^ truncate(AES_ECB(key, expand(right_1), 0x02)) " </del>  Repeat steps 3 and 4, but use them to compute right_2 by expanding and encrypting left_1 with the least significant octet as 0x03 and XOR the results with right_1. <del> "right_2 = right_1 ^ truncate(AES_ECB(key, expand(left_1, 0x03)) " </del>  Repeat steps 3 and 4, but use them to compute left_2 by expanding <del> and encrypting right_2 with the least significant octet as 0x04 and XOR the results with left_1. </del>  <del> "left_2 = left_1 ^ truncate(AES_ECB(key, expand(right_2), 0x04)) " </del>  The server concatenates left_2 with right_2 to form the ciphertext CID, which it appends to the first octet. Note that the plaintext is of odd octet length, so the middle octet will be split evenly left_0 and right_0. <del> 5.2.3. </del>  <del> 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 server ID.  The nonce immediately follows. </del>  <del> The load balancer decrypts the nonce and the server ID using the reverse of the algorithm above. </del>  First, split the ciphertext CID (excluding the first octet) into its equal- length components left_2 and right_2.  Then follow the process (i.e., the nonce is at least as large as the server ID).  If the server ID is longer, a fourth pass is necessary: <del> "right_0 = right_1 ^ truncate(AES_ECB(key, expand(left_0, 0x01))) " </del>  and the load balancer has to concatenate left_0 and right_0 to obtain the complete server ID. <del> 5.3. The Encrypted Long CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, protects the server ID with a single encryption pass.  However, it also requires connection IDs of at least 17 octets, increasing overhead of client-to-server packets. 5.3.1. The server ID length MUST be no more than 12 octets.  The nonce and server ID MUST sum to at least 16 octets. The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. 5.3.2. Upon receipt of a QUIC packet, the load balancer reads the first octet to obtain the config rotation bits.  It then decrypts the subsequent 16 octets using AES-ECB decryption and the chosen key. The first octets of the plaintext contains the server id. 5.3.3. The server encrypts both its server ID and enough octets in a nonce to form a 16-octet block using the configured AES-ECB key.  Note that any remaining octets in the nonce are transmitted as plaintext, and should consider the constraints in cid-entropy. </del> 6. QUIC-LB requires no per-connection state at the load balancer.  The QUIC-LB requires common configuration to synchronize understanding of encodings and guarantee explicit consent of the server. <del> The load balancer and server MUST agree on a routing algorithm and the relevant parameters for that algorithm. All algorithm configurations can have a server ID length, nonce length, and key.  However, for Plaintext CID, there is no key. </del>  The load balancer MUST receive the full table of mappings, and each server must receive its assigned SID(s), from the configuration (IP address, UDP port, client-generated destination Connection ID) remain constant for all packets sent on the same connection. <del> Dynamic server ID allocation is dependent on client-generated Destination CIDs in Initial Packets being at least 8 octets in length.  If they are not, the load balancer may not be able to extract a valid server ID to add to its table.  Configuring a shorter server ID length can increase robustness to a change. </del> While this document does not update the commitments in RFC8999, the additional assumptions are minimal and narrowly scoped, and provide a likely set of constants that load balancers can use with minimal risk QUIC-LB is intended to prevent linkability.  Attacks would therefore attempt to subvert this purpose. <del> Note that the Plaintext CID algorithm makes no attempt to obscure the server mapping, and therefore does not address these concerns.  It exists to allow consistent CID encoding for compatibility across a network infrastructure, which makes QUIC robust to NAT rebinding. Servers that are running the Plaintext CID algorithm SHOULD only use it to generate new CIDs for the Server Initial Packet and SHOULD NOT send CIDs in QUIC NEW_CONNECTION_ID frames, except that it sends one new Connection ID in the event of config rotation config-rotation. Doing so might falsely suggest to the client that said CIDs were generated in a secure fashion. </del>  A linkability attack would find some means of determining that two connection IDs route to the same server.  As described above, there map to the same server.  It could then apply analytical techniques to try to obtain the server encoding. <del> The Encrypted CID algorithms provide robust protection against any sort of linkage.  The Plaintext CID algorithm makes no attempt to protect this encoding. </del>  Were this analysis to obtain the server encoding, then on-path observers might apply this analysis to correlating different client have each other's stateless reset token unless that key has changed in the interim. <del> The Encrypted Short and Encrypted Long algorithms need to generate different cipher text for each generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the CID are reserved for a nonce that, if used only once, will result in unique cipher text for each Connection ID. </del>  If servers simply increment the nonce by one with each generated connection ID, then it is safe to use the existing keys until any Whether or not it implements the counter method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys. <del> Both the Plaintext CID and Encrypted Long CID algorithms send parts of their nonce in plaintext.  Servers MUST generate nonces so that the plaintext portion appears to be random.  Observable correlations between plaintext nonces would provide trivial linkability between individual connections, rather than just to a common server. </del>  For any algorithm, configuration agents SHOULD implement an out-of- band method to discover when servers are in danger of exhausting

Reviewer comments:
narrows single-pass encryption to a special-case optimization, and simplifies presentation of the design.
There's a lot of needless bitshifting in the current algorithm. When reading from the right, each byte has to be shifted 4 bits and ORed with the neighboring byte, as currently written. There's an easier way. When encrypting side X (= { left, right }) and XORing with side Y. Set Y to zero. Set the index value (= 1..4) in the furthest byte that has been zeroed. Encrypt to get ciphertext XOR Y with the bits in the same position as Y.
There has quietly been some work on tightening up the QUIC-LB specification. At the moment, we are still short on implementations but I am hearing something might happen soon. Anyway, Christian Huitema has made substantial contributions to the security properties of Stream Cipher CID, which allows smallish CIDs, by making it a three-pass algorithm. We still have the "Block Cipher CID option" which requires CIDs of at least 17 bytes; AFAICT the only advantage at this point is that it can be decoded with 1 block encryption operation instead of three. In principle, QUIC-LB load balancers can be run with no per-connection state, in which case this would be a per-packet operation. I strongly suspect that real LBs will keep some per-4tuple state, as they do today; if so, this crypto operation only needs to occur once per packet where the 4-tuple is new. If so, the CPU impact is vanishingly small except in a storm of garbage packets. So AFAICT, the use case for Block Cipher is as follows: Willing to run one crypto operation per packet/new 4-tuple Not OK with doing three crypto operations satisfied with 17B + CIDs I strongly suspect this does not describe a real implementer, and am inclined to simply delete this in my effort to simplify the design. Nevertheless, I'm taking this to the list in case someone thinks this is an important use case.
I am pretty confident about the properties of the stream cipher, but I am not a cryptographer Should we ask a review from the CFRG?
I implemented block cipher cid in my proxy server. It is a bit sad to hear that it is going to be removed from the spec, but I have no strong opinion to against that. If it is removed I'll just remove the reference to quic lb spec and call it our own. The good thing of block cipher cid is that its implementation is quite easy. 17 bytes cid has good entropy for random bits to manage several cid per connection.
NAME It's not gone yet! At the very least, we're going to do the crypto review.
FWIW, h2o also uses 17-byte CID backed by AES-ECB. Our server-id is 64-bit. While that might sound a bit large, it is good to have some additional space that can be used for detecting broken packets carrying bogus CIDs. Also, we do not retain 4-tuple state for each connection, because we do not want to retain connection state for all the server cluster. Instead, we decrypt CID of each packet. Our format is different from what is in QUIC-LB (our design predates the first revision of the draft), so we do not mind support for block ciphers getting removed from the document. I'm just pointing out that there are use cases where block ciphers are sufficient.
NAME thanks for the field report. While you're not conforming to the standard today, I hope you'll consider h2o servers eventually supporting the standard (at last optionally) so they can be used with migration with commodity load balancers. Would the lack of a block cipher make a meaningful difference in your willingness to do so?
if you've implemented this, please join the #quic-lb channel and we should do interop once the spec settles down
NAME Implementing the Stream Cipher CID algorithm is easy for the backend servers. IMO the practical concerns are related to load balancers. Each of the three-pass AES-ECB operation has dependency on earlier passes. That means that it is impossible to run these passes in parallel. My napkin calculation tells me that the CPU cycles required for running Stream Cipher CID algorithm on each full-sized packet would cost like 30% of decrypting a full-sized packet. There would be at least two ways to mitigate this problem. One is process multiple packets in parallel. The other is cache information, as you've suggested in this issue. If the load balancer developers are happy to accept this complexity (for saving few bytes of CID), then I do not think I have a reason to argue against.
Please don't make decisions now about the cost of three passes. The CFRG review might very well ask us to increase the number of passes, especially if the nonce is something like a counter instead of a random number. Consider for example the usage pattern in which after a key rotation all servers in the cluster set their nonce to exactly 1. In effect, that means we are almost down to two passes, and that may arguably be too few. Or maybe not. Review will tell. If I look at the literature, 3 passes is the absolute minimum for achieving an acceptable level of mixing, but there are papers recommending 5, 6 or even 12 passes.
NAME thank you for the caution. Then I wonder if we need to decide the fate of block cipher CIDs, before the design of stream cipher CIDs become more stable.
I am not resolving this issue until the crypto review is complete.
It's unfortunately that routing by will meet some problems, image this scenario: The right way SHOULD be that quic-lb route all packets through CID, then the cpu cost can't be avoid, but I still approve the usage of stream cipher, from a safety point of view.
Good point, I'll consider this when I
reduced the Block CID (now "single-pass encryption") to the special case where noncelen + sidlen == 16.
Given the work in , I'm disinclined to remove this special case. Closing.
That works. The macros are clever, and you may want to explain the cleverness somewhere. It is obvious to me that you want to align "right" and "left" to an even number of bytes, adding a null nibble at the left or right or at the right of left. That will indeed save a lot of bit twiddling. Found an unrelated typo.

Revised text:
A server encodes one of its assigned server IDs in any CID it generates using the relevant configuration.  5.  5.1.  <ins> All connection IDs use the following format: </ins>  <ins> 5.2. </ins>  <ins> The configuration agent assigns a server ID to every server in its pool in accordance with sid-allocation, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers. </ins>  <ins> Each configuration specifies the length of the Server ID and Nonce fields, with limits defined for each algorithm. </ins>  <ins> Optionally, it also defines a 16-octet key.  Note that failure to define a key means that observers can determine the assigned server of any connection, significantly increasing the linkability of QUIC address migration. </ins>  <ins> The nonce length MUST be at least 4 octets.  The server ID length MUST be at least 1 octet. </ins>  <ins> As QUIC version 1 limits connection IDs to 20 octets, the server ID and nonce lengths MUST sum to 19 octets or less. </ins>  <ins> 5.3. </ins>  <ins> The server writes the first octet and its server ID into their respective fields. If there is no key in the configuration, the server MUST fill the Nonce field with bytes that appear to be random.  If there is a key, the server fills the nonce field with a nonce of its choosing.  See cid-entropy for details. The server MAY append additional bytes to the connection ID, up to the limit specified in that version of QUIC, for its own use.  These bytes MUST NOT provide observers with any information that could link two connection IDs to the same connection, client, or server.  In particular, all servers using a configuration MUST consistently add the same length to each connection ID, to preserve the linkability objectives of QUIC-LB.  Any additional bytes SHOULD appear random unless individual servers are not distinguishable (e.g. any server using that configuration appends identical bytes to every connection ID). If there is no key in the configuration, the Connection ID is complete.  Otherwise, there are further steps, as described in the two following subsections. Encryption below uses the AES-128-ECB cipher.  Future standards could add new algorithms that use other ciphers to provide cryptographic agility in accordance with RFC7696.  QUIC-LB implementations SHOULD be extensible to support new algorithms. </ins>  <ins> 5.3.1. </ins>  <ins> When the nonce length and server ID length sum to exactly 16 octets, the server MUST use a single-pass encryption algorithm.  All connection ID octets except the first form an AES-ECB block.  This block is encrypted once, and the result forms the second through seventeenth most significant bytes of the connection ID. </ins>  <ins> 5.3.2. </ins>  <ins> Any other field length requires four passes for encryption and at least three for decryption.  To understand this algorithm, it is useful to define four functions that minimize the amount of bit- shifting necessary in the event that there are an odd number of octets. </ins>  <ins> The expand_left() function outputs 16 octets, with its first argument in the most significant bits, its second argument in the least significant byte, and zeros in all other positions.  Thus, </ins>  <ins> expand_right() is similar, except that the second argument is in the most significant byte, and the first argument is in the least significant bits.  Therefore, </ins>  <ins> Similarly, truncate_left() and truncate_right() take the most significant and least significant bits, respectively, from a ciphertext.  For example, to take 28 bits of a ciphertext: </ins> The example at the end of this section helps to clarify the steps described below. example, 0x7040b81b55ccf3 would split into a left_0 of 0x7040b81 and right_0 of 0xb55ccf3.  <ins> Encrypt the result of expand_left(left_0) to obtain a ciphertext. </ins>  <ins> XOR the least significant bits of the ciphertext with right_0 to </ins> form right_1.  <ins> Thus steps 3 and 4 can be expressed as "right_1 = right_0 ^ truncate_right( AES_ECB(key, expand_left(left_0, 0x01)), len(right_0)) " </ins> Repeat steps 3 and 4, but use them to compute left_1 by expanding  <ins> and encrypting right_1 with the most significant octet as 0x02 and XOR the results with left_0. </ins>  <ins> "left_1 = left_0 ^ truncate_left( AES_ECB(key, expand_right(right_1, 0x02)), len(left_0)) " </ins> Repeat steps 3 and 4, but use them to compute right_2 by expanding and encrypting left_1 with the least significant octet as 0x03 and XOR the results with right_1.  <ins> "right_2 = right_1 ^ truncate_right( AES_ECB(key, expand_left(left_1, 0x03)), len(right_1)) " </ins> Repeat steps 3 and 4, but use them to compute left_2 by expanding  <ins> and encrypting right_2 with the most significant octet as 0x04 and XOR the results with left_1. </ins>  <ins> "left_2 = left_1 ^ truncate_left( AES_ECB(key, expand_right(right_2, 0x04)), len(left_1)) " </ins> The server concatenates left_2 with right_2 to form the ciphertext CID, which it appends to the first octet. Note that the plaintext is of odd octet length, so the middle octet will be split evenly left_0 and right_0.  <ins> 5.4. On each incoming packet, the load balancer extracts consecutive octets, beginning with the second octet.  If there is no key, the first octets correspond to the server ID. If there is a key, the load balancer takes one of two actions: 5.4.1. </ins>  <ins> If server ID length and nonce length sum to exactly 16 octets, they form a ciphertext block.  The load balancer decrypts the block using the AES-ECB key and extracts the server ID from the most significant bytes of the resulting plaintext. </ins>  <ins> 5.4.2. </ins> First, split the ciphertext CID (excluding the first octet) into its equal- length components left_2 and right_2.  Then follow the process (i.e., the nonce is at least as large as the server ID).  If the server ID is longer, a fourth pass is necessary:  <ins> "right_0 = right_1 ^ truncate_right(AES_ECB(key, expand_left(left_0, 0x01))) " </ins> and the load balancer has to concatenate left_0 and right_0 to obtain the complete server ID.  6. QUIC-LB requires no per-connection state at the load balancer.  The QUIC-LB requires common configuration to synchronize understanding of encodings and guarantee explicit consent of the server.  <ins> The load balancer and server MUST agree on the connection ID encoding parameters, which include the server ID length and nonce length.  A key is optional. </ins> The load balancer MUST receive the full table of mappings, and each server must receive its assigned SID(s), from the configuration (IP address, UDP port, client-generated destination Connection ID) remain constant for all packets sent on the same connection.  While this document does not update the commitments in RFC8999, the additional assumptions are minimal and narrowly scoped, and provide a likely set of constants that load balancers can use with minimal risk QUIC-LB is intended to prevent linkability.  Attacks would therefore attempt to subvert this purpose.  <ins> Note that without a key for the encoding, QUIC-LB makes no attempt to obscure the server mapping, and therefore does not address these concerns.  Without a key, QUIC-LB merely allows consistent CID encoding for compatibility across a' network infrastructure, which makes QUIC robust to NAT rebinding.  Servers that are encoding their server ID without a key algorithm SHOULD only use it to generate new CIDs for the Server Initial Packet and SHOULD NOT send CIDs in QUIC NEW_CONNECTION_ID frames, except that it sends one new Connection ID in the event of config rotation config-rotation.  Doing so might falsely suggest to the client that said CIDs were generated in a secure fashion. </ins> A linkability attack would find some means of determining that two connection IDs route to the same server.  As described above, there map to the same server.  It could then apply analytical techniques to try to obtain the server encoding.  <ins> An encrypted encoding provides robust protection against this.  An unencrypted one provides none. </ins> Were this analysis to obtain the server encoding, then on-path observers might apply this analysis to correlating different client have each other's stateless reset token unless that key has changed in the interim.  <ins> The encrypte mode needs to generate different cipher text for each generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the CID are reserved for a nonce that, if used only once, will result in unique cipher text for each Connection ID. </ins> If servers simply increment the nonce by one with each generated connection ID, then it is safe to use the existing keys until any Whether or not it implements the counter method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys.  <ins> If the nonce is sent in plaintext, servers MUST generate nonces so that they appear to be random.  Observable correlations between plaintext nonces would provide trivial linkability between individual connections, rather than just to a common server. </ins> For any algorithm, configuration agents SHOULD implement an out-of- band method to discover when servers are in danger of exhausting