jiebi/CodeConvo huggingface dataset:
Change:
detail info: fix a typo. change AEAD checksum to AEAD ICV(defined in rfc4106)
Hi martin: is not a standard name of AEAD verification message, which should be , see section 6 of rfc4106

Discussion:
address validation. The 96 bit unique token number is set to a random value using a <del> cryptography- grade random number generator. </del> <ins> cryptography-grade random number generator. </ins> The token key identifier and the corresponding AEAD key and AEAD IV are provisioned by the configuration agent.

The input plaintext for the AEAD is the token body.  The output ciphertext of the AEAD is transmitted in place of the token body. <del> The AEAD Checksum is computed as part of the AEAD encryption process, and is verified during decryption. </del> <ins> The AEAD Integrity Check Value(ICV), defined in Section 6 of RFC4106, is computed as part of the AEAD encryption process, and is verified during decryption. </ins> 7.3.2.

no token. The service SHOULD decrypt incoming tokens.  The service SHOULD drop <del> packets with unknown key sequence, or an AEAD checksum that does not match the expected value.  (By construction, the AEAD checksum will only match if the client IP Address also matches.) </del> <ins> packets with unknown key sequence, or an AEAD ICV that does not match the expected value.  (By construction, the AEAD ICV will only match if the client IP Address also matches.) </ins> <del> If the token checksum passes, and the ODCIL and RSCIL fields are both zero, then this is a NEW_TOKEN token generated by the server. </del> <ins> If the token verification passes, and the ODCIL and RSCIL fields are both zero, then this is a NEW_TOKEN token generated by the server. </ins> Processing of NEW_TOKEN tokens is subtly different from Retry tokens, as described below.
Change:
Made the changes to merge this.
Hi martin: The defination of and brought me a great confusion when I implement the share-state retry service. Though finally I got what the draft want to express, I still suggest we should give more information about them According to section 1.5 of rfc5084: According to section 3.4 of rfc5116 I guess that in current draft is the define in rfc5116, is just a random value(or a incrementing number) to generate . If I were true, please consider my PR for my suggestion.
Additional, it's no need to make the length of (current draft define) variable, just 96 bit is sufficient. Current aes-128-gcm related cipher suites all use this value
We can also add some illustration of , draft use in other place

Discussion:
The tokens are protected using AES128-GCM as follows: <del> The token key and IV are retrieved using the Key Sequence. </del> <ins> The Key Sequence is the 8 bit identifier to retrieve the token key and IV. </ins> <del> The nonce, N, is formed by combining the IV with the 96 bit unique token number.  The 96 bits of the unique token number are left- padded with zeros to the size of the IV.  The exclusive OR of the padded unique token number and the IV forms the AEAD nonce. </del> <ins> The AEAD IV, is a 96 bit data which produced by implementer's custom AEAD IV derivation function. The AEAD nonce, N, is formed by combining the AEAD IV with the 96 bit unique token number.  The 96 bits of the unique token number are left-padded with zeros to the size of the IV.  The exclusive OR of the padded unique token number and the AEAD IV forms the AEAD nonce. </ins> The associated data is a formatted as a pseudo header by combining the cleartext part of the token with the IP address of the client.

The Shared-State Retry Service defined in shared-state-retry describes the format of retry tokens or new tokens protected and encrypted using AES128-GCM.  Each token includes a 96 bit randomly <del> generated unique token number, and an 8 bit identifier of the AES-GCM encryption key.  There are three important security considerations for these tokens: </del> <ins> generated unique token number, and an 8 bit identifier used to get the AES-GCM encryption context.  The AES-GCM encryption context contains a 128 bit key and an AEAD IV.  There are three important security considerations for these tokens: </ins> An attacker that obtains a copy of the encryption key will be able to decrypt and forge tokens.
Change:
Secure ciphers are much more important for Shared State Retry than for the load balancer stuff and Initial Encryption. Therefore, some crypto agility to allow this mechanism to adapt as ciphers deprecate would be good. The key sequence can also imply a cipher, so we'll add that to the data model. Some fields will vary length based on the cipher. We should also make it so everyone MUST support AES128-GCM.

Discussion:
MUST NOT reject tokens because they lack opaque data and therefore the packet number. <ins> Shared-state Retry Services use the AES-128-ECB cipher.  Future standards could add new algorithms that use other ciphers to provide cryptographic agility in accordance with RFC7696.  Retry Service and server implementations SHOULD be extensible to support new algorithms. </ins> 7.3.1. On the wire, the token is presented as:
Change:
Intended to
Some text on how a server cluster might support moving of connections from one server instance to another would be useful. The current design might permit portability under certain conditions, but there are things that might need to be considered, such as the way in stateless resets are generated.
Are you referring to load balancing already existing connections to a new server? Are you envisioning the first server issuing new CIDs (that point to the new server) and setting Retire Prior To to retire the old CIDs so that future traffic redirect to the new server? How do you imagine the rest of the connection state would get moved?
This applies to cases where clusters are rebalanced, where instances go down and others are expected to pick up the slack, and all similar cases. In some cases this requires an unspecified mechanism for transferring state between instances. In others, the instance might remain constant but the identifiers used might need to rotate. This is likely addressed by using Retire Prior To as you say. Text on that would help.
Good idea, it wouldn't hurt to have a short non-normative section on this.
Seems fine.

Discussion:
7. <ins> This section discusses considerations for some deployment scenarios not implied by the specification above. 7.1. </ins> Some network architectures may have multiple tiers of low-state load balancers, where a first tier of devices makes a routing decision to the next tier, and so on until packets reach the server.  Although

numbers of load-balancing tiers, as the maximum server ID space is quite large. <ins> 7.2. Some deployments may transparently move a connection from one server to another.  The means of transferring connection state between servers is out of scope of this document. To support a handover, a server involved in the transition could issue CIDs that map to the new server via a NEW_CONNECTION_ID frame, and retire CIDs associated with the new server using the "Retire Prior To" field in that frame. Alternately, if the old server is going offline, the load balancer could simply map its server ID to the new server's address. </ins> 8. QUIC-LB is intended to prevent linkability.  Attacks would therefore
Change:
Some have noted that "Stream Cipher" is now a misnomer. So this PR renames them.

Discussion:
5.2. <del> The Stream Cipher CID algorithm provides cryptographic protection at the cost of additional per-packet processing at the load balancer to decrypt every incoming connection ID. </del> <ins> 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. </ins> 5.2.1.

considerations. The server encrypts the server ID using exactly the algorithm as <del> described in stream-cipher-load-balancer-actions, performing the </del> <ins> described in encrypted-short-load-balancer-actions, performing the </ins> three passes in reverse order. 5.3. <del> The Block Cipher CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, provides higher cryptographic protection and detection of unroutable connection IDs.  However, it also requires connection IDs of at least 17 octets, increasing overhead of client-to-server packets. </del> <ins> 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. </ins> 5.3.1.

map to the same server.  It could then apply analytical techniques to try to obtain the server encoding. <del> The Stream and Block Cipher CID algorithms provide robust protection against any sort of linkage.  The Plaintext CID algorithm makes no attempt to protect this encoding. </del> <ins> The Encrypted CID algorithms provide robust protection against any sort of linkage.  The Plaintext CID algorithm makes no attempt to protect this encoding. </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. <del> The Stream Cipher and Block Cipher algorithms need to generate </del> <ins> The Encrypted Short and Encrypted Long algorithms need to generate </ins> 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

zero.  Whether or not it implements this method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys. <del> Both the Plaintext CID and Block Cipher CID algorithms send parts of their nonce in plaintext.  Servers MUST generate nonces so that the plaintext portion appears to be random.  Observable correlations </del> <ins> 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 </ins> between plaintext nonces would provide trivial linkability between individual connections, rather than just to a common server.
Change:
Many server architectures have multiple processes. There are many ways to properly route packets between them, but many have severely limited capabilities. Add some non-normative text about options here: run QUIC-LB at the demultiplexer, packet toss, register connection IDs at the demultiplexer, or rewrite the CID with the decrypted one at the LB (which has security limitations)

Discussion:
6.2. <ins> QUIC servers might have QUIC running on multiple processes listening on the same address, and have a need to demultiplex between them.  In principle, this demultiplexer is a Layer 4 load balancer, and the guidance in lb-chains applies.  However, in many deployments the demultiplexer lacks the capability to perform decryption operations. There are some other techniques that might work, depending on the capabilities of the server architecture. Some bytes of the server ID are reserved to encode the process ID. The demultiplexer might operate based on the 4-tuple or other legacy indicator, but the receiving server process extracts the server ID, and if it does not match the one for that process, the process could "toss" the packet to the correct destination process. Each process could register the connection IDs it generates with the demultiplexer, which routes those connection IDs accordingly. Some bytes of the server ID are reserved to encode the process ID. The load balancer writes the decrypted connection ID into the packet.  The demultiplexer reads the process ID from the relevant bytes and routes it accordingly.  The receiving server process immediately re-encrypts the connection ID in deliver the packet to the correct connection and successfully authenticate the packet. While this requires coordination between load balancer and server, this document does not standardize the technique because it is unsafe to use unless the path between load balancer and server is fully secure.  An observer at that point can determine the server mapping via the IP address of the destination server, but the process ID provides additional linkability information. 6.3. </ins> Some deployments may transparently move a connection from one server to another.  The means of transferring connection state between servers is out of scope of this document.
Change:
This only applies if the CID varies in length (so say that). Also, it only applies if the common stem doesn't otherwise distinguish itself enough to allow an efficient lookup (so say "might" rather than get into all that). In other words, it's probably inefficient, but not necessarily so.

Discussion:
Local hardware cryptographic offload devices may accelerate QUIC servers by receiving keys from the QUIC implementation indexed to the connection ID.  However, on physical devices operating multiple QUIC <del> servers, it is impractical to efficiently lookup these keys if the connection ID does not self-encode its own length. </del> <ins> servers, it might be impractical to efficiently lookup keys if the connection ID varies in length and does not self-encode its own length. </ins> Note that this is a function of particular server devices and is irrelevant to load balancers.  As such, load balancers MAY omit this
Change:
Better not to deal with creating a new definition here. Especially one that uses the word "forward". Reword.

Discussion:
If the number of necessary server IDs per next hop is uniform, a simple implementation would use successively longer server IDs at each tier of load balancing, and the server configuration would match <del> the last tier.  The forward load balancers would simply treat the least significant bits of the server ID as part of the nonce. </del> <ins> the last tier.  Load balancers closer to the client can then treat any parts of the server ID they did not use as part of the nonce. </ins> 6.2.
Change:
In (Section 4.1](URL), these fields are not defined: They probably should be.

Discussion:
All connection IDs use the following format: <ins> The First Octet field serves one or two purposes, as defined in first-octet. The Server ID field encodes the information necessary for the load balancer to route a packet with that connection ID.  It is often encrypted. The server uses the Nonce field to make sure that each connection ID it generates is unique, even though they all use the same Server ID. </ins> 4.2. The configuration agent assigns a server ID to every server in its
Change:
This only works if the cutover is immediate. "going offline" suggests something progressive, which means that this strategy only works if you suddenly start holding a bunch of state. There a lots of caveats here, to the point that I'd probably just drop this whole paragraph.

Discussion:
To support a handover, a server involved in the transition could issue CIDs that map to the new server via a NEW_CONNECTION_ID frame, <del> and retire CIDs associated with the new server using the "Retire </del> <ins> and retire CIDs associated with the old server using the "Retire </ins> Prior To" field in that frame. <del> Alternately, if the old server is going offline, the load balancer could simply map its server ID to the new server's address. </del> 7. The server ID encodings, and requirements for their handling, are
Change:
This needs a normative reference. There is likely a NIST SP with a number you can use somewhere.

Discussion:
complete.  Otherwise, there are further steps, as described in the two following subsections. <del> 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. </del> <ins> Encryption below uses the AES-128-ECB cipher NIST-AES-ECB.  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> 4.3.1.
Change:
I would think that you instead want to say if the nonce part is chosen in a manner that is unpredictable to the adversary, or encrypted.

Discussion:
8.2. Attackers in this privileged position are intrinsically able to map <del> two connection IDs to the same server.  The QUIC-LB algorithms do prevent the linkage of two connection IDs to the same individual connection if servers make reasonable selections when generating new IDs for that connection. </del> <ins> two connection IDs to the same server.  These algorithms ensure that two connection IDs for the same connection cannot be identified as such as long as the server chooses the first octet and any plaintext nonce correctly. </ins> 8.3.
Change:
Fixing . I love deleting this much text!
This might be achieved as follows:
I'll should also point out that there is optional and you can also do: For any value of , though presumably is at least , it could reasonably be any value up to .

Discussion:
1.2. All wire formats will be depicted using the notation defined in <del> Section 1.3 of RFC9000.  There is one addition: the function len() refers to the length of a field which can serve as a limit on a different field, so that the lengths of two fields can be concisely defined as limited to a sum, for example: x(A..B) y(C..B-len(x)) indicates that x can be of any length between A and B, and y can be of any length between C and B provided that (len(x) + len(y)) does not exceed B. The example below illustrates the basic framework: </del> <ins> Section 1.3 of RFC9000. </ins> 2.
Change:
Carefully phrased language that considers NAME 's suggestion that SCID may not be stable across versions, and tries to suggest (IP, port, DCID) as a suitable long header hash without making promises on behalf of quic-invariants.
NAME sayeth on the list: It would be useful to include something like this in Section 4 as a non-normative hint on what fields to use, since our hint currently consists of an example that just uses the DCID. Similarly, make that assumption clearer in Section 8.
For what it's worth, Google's load balancer only uses destination CIDs for routing. We always pick 64bit CIDs during the handshake so we can assume that short headers always carry 64bit CIDs.
Do all CIDs resolve to a valid server ID?
NAME do you not care about an attacker specifically crafting destination CIDs to attack a particular server?
NAME We do not have a concept of server ID, but yes every CID routes to a server. NAME We do not care about that attack. I haven't seen any indication that it can actually cause harm in real life.
NAME very well, then you have no non-compliant DCIDs. You would only need to upgrade your LBs for new versions if they allowed client-chosen DCIDs < 8 bytes.

Discussion:
QUIC.  For example, a non-compliant DCID might be converted to an integer and divided by the number of servers, with the modulus used to forward the packet.  The number of servers is usually consistent <del> on the time scale of a QUIC connection handshake. </del> <ins> on the time scale of a QUIC connection handshake.  See also version- invariance. </ins> Load balancers SHOULD drop packets with non-compliant DCIDs in a short header.

The use of client-generated incoming DCIDs does not persist beyond a few round trips in the connection. <del> In this interval, some exposed fields (e.g.  UDP address and port, source and client-generated destination Connection ID) remain constant for all packets in the connection.  For example, 0RTT and Initial packets use the same CIDs and ports. </del> <ins> While the client is using DCIDs it generated, some exposed fields (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 QUIC- INVARIANTS, the additional assumptions are minimal and narrowly scoped, and provide a likely set of constants that load balancers can use with minimal risk of version- dependence. </ins> If these assumptions are invalid, this specification is likely to lead to loss of packets that contain non-compliant DCIDs, and in
Change:
Updated the test vectors for the latest version of the spec, added PCID, and made them usable to test server implementations.

Discussion:
ID Length, Key, and Zero-Padding Length.  The Server ID is unique to each server, but the others MUST be global. <ins> Note that server IDs are opaque bytes, not integers, so there is no notion of network order or host order. </ins> A full QUIC-LB configuration MUST also specify the information content of the first CID octet and the presence and mode of any Retry Service.
Change:
As the draft describes: 'The date-time string is a total of 20 octets and encodes the time the token was generated. The format of date-time is described in Section 5.6 of [RFC3339].' this needs 20 octets in ascii, may be the unix time which is the the number of seconds since the Unix epoch in 8 octets is a better choice in transmission and computing ?
NAME have a look at the PR, please

Discussion:
packet.  The client IP address is 16 octets.  If an IPv4 address, the last 12 octets are zeroes. <del> date-time: The date-time string is a total of 20 octets and encodes the time the token was generated.  The format of date-time is described in Section 5.6 of RFC3339.  This ASCII field MUST use the "Z" character for time-offset. </del> <ins> Timestamp: The timestamp is a 64-bit integer, in network order, that expresses the number of seconds in POSIX time (see Sec. 4.16 of TIME_T). </ins> Opaque Data: The server may use this field to encode additional information, such as congestion window, RTT, or MTU.  Opaque data
Change:
Some load balancers today switch based on the SNI. Obviously, this is not version-invariant. We should add some language about this. What should such an LB when it encounters an unknown version? It probably has no choice but to forward it based on CID and hope for the best.
If the differing domains trust each other, the servers could helpfully generate Retry packets to redirect the client to the right place. This assumes a bunch of shared state, and that those servers support the same version while the LB does not. Of course, if version support differs, the VN process has serious problems.
Maybe encrypt sni will be the real standard later(see URL), I just think that there is no need for quic lb considering sni

Discussion:
lead to loss of packets that contain non-compliant DCIDs, and in extreme cases connection failure. <ins> Some load balancers might inspect elements of the Server Name Indication (SNI) extension in the TLS Client Hello to make a routing decision.  Note that the format and cryptographic protection of this information may change in future versions or extensions of TLS or QUIC, and therefore this functionality is inherently not version- invariant. </ins> 10. QUIC-LB is intended to prevent linkability.  Attacks would therefore