jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-quic-load-balancers

Commentary: 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 .
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.
All wire formats will be depicted using the notation defined in
Section 1.3 of RFC9000.
Draft: draft-ietf-quic-load-balancers

Commentary: 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 .
Attackers in this privileged position are intrinsically able to map
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.
Attackers in this privileged position are intrinsically able to map
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.
Draft: draft-ietf-quic-load-balancers

Commentary: This needs a normative reference . There is likely a NIST SP with a number you can use somewhere .
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.
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.
Draft: draft-ietf-quic-load-balancers

Commentary: is probably not your intent , but that is what you get with this phrasing . I think that the point is that the values are not predictable to entities other than the one generating it . This appears in several places in the document . 
 Well uses " indistinguishable from random " :-) But OK , I 'll seek a new formulation .
A server not using this functionality SHOULD make the six bits appear
to be random.
A server not using this functionality SHOULD choose the six bits so
as to have no observable relationship to previous connection IDs
issued for that connection.
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.
If there is no key in the configuration, the server MUST fill the
Nonce field with bytes that have no observable relationship to the
field in previously issued connection IDs.  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).
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 NOT provide any
observable correlation to previous connection IDs for that connection
(e.g., the bytes can be chosen at random).
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.
Servers are forbidden from generating linkable plaintext nonces,
because observable correlations between plaintext nonces would
provide trivial linkability between individual connections, rather
than just to a common server.
Draft: draft-ietf-quic-load-balancers

Commentary: 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 .
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.
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 old server using the "Retire
Prior To" field in that frame.
Draft: draft-ietf-quic-load-balancers

Commentary: In ( Section 4.1 ] ( ) , these fields are not defined : They probably should be .
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.
Draft: draft-ietf-quic-load-balancers

Commentary: Better not to deal with creating a new definition here . Especially one that uses the word " forward " .  .
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
the last tier.  The forward load balancers would simply treat the
least significant bits of the server ID as part of the nonce.
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
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.
Draft: draft-ietf-quic-load-balancers

Commentary: As they relate to invariants .
The maximum Connection ID length could be below the minimum necessary
to use all or part of this specification.  The minimum Connection ID
length could exceed the limits in this specification.
A QUIC version might define limits on connection ID length that make
some or all of the mechanisms in this document unusable.  For
example, a maximum connection ID length could be below the minimum
necessary to use all or part of this specification; or, the minimum
connection ID length could be larger than the largest value in this
specification.
Draft: draft-ietf-quic-load-balancers

Commentary: This only applies if the CID varies in length ( so say that ) . Also , it only applies if the common stem does n'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 .
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
servers, it is impractical to efficiently lookup these keys if the
connection ID does not self-encode its own length.
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
servers, it might be impractical to efficiently lookup keys if the
connection ID varies in length and does not self-encode its own
length.
Draft: draft-ietf-quic-load-balancers

Commentary: 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 )
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.
Draft: draft-ietf-quic-load-balancers

Commentary:    in security section . Fix specification of Four Passes decryption Fix number of kramdown issues . 
 I think this simple PR is ready . 
 Thank you , this is perfect . 
 We 're awaiting more data to fully understand this , but we may need to allow 4 , 6 , or 12 passes as configuration options . 
 Fixed by , but we 're instead going to go with in lieu of doing this . 
 The analysis in the second crypto review should be in the security considerations . 
 I believe there is an edge case where a partially chosen plaintext is possible . 1 ) The load balancer is supporting both an encrypted and unencrypted config , on different codepoints , that happen to use the same server ID mapping 2 ) The server is generating encrypted CIDs . 3 ) The attacker sends an initial packet sends an unencrypted CID . 4 ) Any server generated CID is therefore using the unencrypted server ID as plaintext . The random nonce should generally protect us , but maybe not ? Anyway , security considerations could say something like " unencrypted and encrypted CIDs MUST NOT use the same server ID assignments because ... " . 
 Fixed by
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.
The encrypted 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.
The Four Pass Encryption algorithm is structured as a 4-round Feistel
network with non-bijective round function.  As such, it does not
offer a very high security level against distinguishing attacks, as
explained in Patarin2008.  Attackers can mount these attacks if they
are in possession of O(SQRT(len/2)) pairs of ciphertext and known
corresponding plain text, where "len" is the sum of the lengths of
the Server ID and the Nonce.
The authors considered increasing the number of passes from 4 to 12,
which would definitely block these attacks.  However, this would
require 12 round of AES decryption by load balancers accessing the
CID, a cost deemed prohibitive in the planned deployments.
The attacks described in Patarin2008 rely on known plain text.  In a
normal deployment, the plain text is only known by the server that
generates the ID and by the load balancer that decrypts the content
of the CID.  Attackers would have to compensate by guesses about the
allocation of server identifiers or the generation of nonces.  The
these attacks are thus mitigated by making nonces hard to guess, as
specified in cid-entropy, and by rules related to mixed deployments
that use both clear text CID and encrypted CID, for example when
transitioning from clear text to encryption.  Such deployments MUST
use different server ID allocations for the clear text and the
encrypted versions.
These attacks cannot be mounted against the Single Pass Encryption
algorithm.
Draft: draft-ietf-quic-load-balancers

Commentary: the in - solidarity bot should have flagged this and it is an easy fix
If these assumptions are invalid, this specification is likely to
lead to loss of packets that contain unroutable DCIDs, and in extreme
cases connection failure.
If these assumptions are not valid, this specification is likely to
lead to loss of packets that contain unroutable DCIDs, and in extreme
cases connection failure.
Draft: draft-ietf-quic-load-balancers

Commentary: in accordance with the 2nd crypto review 
 In the second crypto review ( ) there was a note that plaintexts of different lengths might end up with similar results , if the extra bits were zeros . The suggestion to fix this was to update the path index to also include the length . 
 Looks good , except for the missing parenthesis .
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,
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,
The expand_left() function outputs 16 octets, with its first argument
in the most significant bits, its second argument in the least
significant byte, its third argument in the second least significant
byte, and zeros in all other positions.  Thus,
expand_right() is similar, except that the second argument is in the
most significant byte, the third is in the second most significant
byte, and the first argument is in the least significant bits.
Therefore,
Encrypt the result of expand_left(left_0) to obtain a ciphertext.
Repeat steps 3 and 4, but use them to compute left_1 by expanding
and encrypting right_1 with the most significant octet as 0x02 and
XOR the results with left_0.
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.
Repeat steps 3 and 4, but use them to compute left_2 by expanding
and encrypting right_2 with the most significant octet as 0x04 and
XOR the results with left_1.
Encrypt the result of expand_left(left_0, index)) to obtain a
ciphertext, where 'index' is one octet: the two most significant
bits of which are 0b00, and the six least significant bits are the
length of the resulting connection ID in bytes, cid_len.
Repeat steps 3 and 4, but use them to compute left_1 by expanding
and encrypting right_1 with the most significant octet as the
concatenation of 0b01 and cid_len, and XOR the results with
left_0.
Repeat steps 3 and 4, but use them to compute right_2 by expanding
and encrypting left_1 with the least significant octet as the
concatenation of 0b10 and cid_len, and XOR the results with
right_1.
Repeat steps 3 and 4, but use them to compute left_2 by expanding
and encrypting right_2 with the most significant octet as the
concatenation of 0b11 ands cid_len, and XOR the results with
left_1.
The maximum Connection ID length could be below the minimum necessary
for one or more encoding algorithms.
The maximum Connection ID length could be below the minimum necessary
to use all or part of this specification.  The minimum Connection ID
length could exceed the limits in this specification.
Draft: draft-ietf-quic-load-balancers

Commentary: Definitely an edge case , but the LB will spray stateless resets everywhere because the CID is random . If the LB tracks fourtuples , though , it should n't be a problem . 
 Maybe make this part of a thing about stateless LBs . 
 So , what 's the plan ? 
 raises an interesting point about stateless LBs in .
For protocols where 4-tuple load balancing is sufficient, it is
straightforward to deliver ICMP packets from the network to the
correct server, by reading the echoed IP and transport-layer headers
to obtain the 4-tuple.  When routing is based on connection ID,
further measures are required, as most QUIC packets that trigger ICMP
responses will only contain a client-generated connection ID that
contains no routing information.
To solve this problem, load balancers MAY maintain a mapping of
Client IP and port to server ID based on recently observed packets.
Alternatively, servers MAY implement the technique described in
Section 14.4.1 of RFC9000 to increase the likelihood a Source
Connection ID is included in ICMP responses to Path Maximum
Transmission Unit (PMTU) probes.  Load balancers MAY parse the echoed
packet to extract the Source Connection ID, if it contains a QUIC
long header, and extract the Server ID as if it were in a Destination
CID.
QUIC-LB requires no per-connection state at the load balancer.  The
load balancer can extract the server ID from the connection ID of
each incoming packet and route that packet accordingly.
The load balancer only extracts the server ID once per incoming
4-tuple.  When the CID is encrypted, this substantially reduces
computational load.
Incoming Stateless Reset packets and ICMP messages are easily
routed to the correct origin server.
In addition to the increased state requirements, however, load
balancers cannot detect the CONNECTION_CLOSE frame to indicate the
end of the connection, so they rely on a timeout to delete connection
state.  There are numerous considerations around setting such a
timeout.
In the event a connection ends, freeing an IP and port, and a
different connection migrates to that IP and port before the timeout,
the load balancer will misroute the different connection's packets to
the original server.  A short timeout limits the likelihood of such a
misrouting.
Furthermore, if a short timeout causes premature deletion of state,
the routing is easily recoverable by decoding an incoming Connection
ID.  However, a short timeout also reduces the chance that an
incoming Stateless Reset is correctly routed.
Servers MAY implement the technique described in Section 14.4.1 of
RFC9000 in case the load balancer is stateless, to increase the
likelihood a Source Connection ID is included in ICMP responses to
Path Maximum Transmission Unit (PMTU) probes.  Load balancers MAY
parse the echoed packet to extract the Source Connection ID, if it
contains a QUIC long header, and extract the Server ID as if it were
in a Destination CID.
Draft: draft-ietf-quic-load-balancers

Commentary: Some have noted that " Stream Cipher " is now a misnomer . So this PR renames them .
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.
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.
The server encrypts the server ID using exactly the algorithm as
described in stream-cipher-load-balancer-actions, performing the
three passes in reverse order.
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.
The server encrypts the server ID using exactly the algorithm as
described in encrypted-short-load-balancer-actions, performing the
three passes in reverse order.
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.
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.
The Encrypted CID algorithms provide robust protection against any
sort of linkage.  The Plaintext CID algorithm makes no attempt to
protect this encoding.
The Stream Cipher and Block Cipher 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.
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.
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
between plaintext nonces would provide trivial linkability between
individual connections, rather than just to a common server.
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.
Draft: draft-ietf-quic-load-balancers

Commentary: The CID format figure has been removed since draft - ietf - quic - load - balancers-08
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.  The CID format is depicted
below.
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.
Draft: draft-ietf-quic-load-balancers

Commentary: Forgot to update this text before .
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.
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.