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

Commentary: Proposal to clarify " stream fragmentation " . Suggested by Issue . 
 I do n’t understand what section 21.6 is about … the title seems to suggests it is about IP Fragmentation and Reassembly Attacks , but elsewhere the spec already prohibits IP Fragmentation in section 14 ? And I have seen no encouragement to do any form of network - layer fragmentation - so I do n’t understand a security consideration in this topic . Is this therefiore some other thing ? It may about something different where a sender originates data with “ holes ” of missing packet to try and exercise the server ? or soemthing ? What is this ? 
 Hi 21.6 is titled " Stream Fragmentation and Reassembly Attacks " . It refers to streams , not IP packets . The attack involves sending stream frames with holes such as and some receivers might allocate the entire stream receive buffer between 0 and . I found the section pretty clear , but we should make it clear to everyone - could you perhaps suggest text that would make it clearer ? 
 OK . I see . I can try a PR , if I can find words that avoid " fragment " : Is this close enough to start : /An adversarial sender might intentionally omit to send portions of the stream data causing the receiver to commit resources for the omitted data , this could cause a disproportionate receive buffer memory commitment and/or creation of a large and inefficient data structure . 
 Do we really need to avoid the term " fragment " ? It 's not the only overloaded networking term in the spec . Perhaps adding a " Note that stream fragmentation is unrelated to IP fragmentation " could suffice ? 
 I do n't think this clarification is necessary . The context makes it clear what fragmentation this is , and talking about IP fragmentation only leads to confuse the reader . ( I like the first part of your PR though , as I 've noted on my review of it . )
Paragraph (version A):
An adversarial sender might intentionally send fragments of stream
data in an attempt to cause disproportionate receive buffer memory
commitment and/or creation of a large and inefficient data structure.
Paragraph (version B):
An adversarial sender might intentionally not send portions of the
stream data, causing the receiver to commit resources for the unsent
data.  This could cause a disproportionate receive buffer memory
commitment and/or the creation of a large and inefficient data
structure at the receiver.
Draft: draft-ietf-quic-transport

Commentary: Yeah , this is better . 
 The sentence observing whether the ACK frames acknowledging the first packets it sends carry ECN counts , as described in { { ecn - validation } } . seems to not belong into that section . 
 Assuming one enables ECN on Initial and Handshake packets in order to perform ECN validation , then I think it 's the right place ? 
 are you OK with explanation , i.e. , can we close with no action ? 
 Not really happy with it , tbh . The sentence feels completely out of place as it stands now . I think we should either move it to the ECN section ( I think that would make the most sense ) , or at least add an introductory sentence , along these lines : 
 I like the introductory sentence . 
 WFMThis is good , thanks !
Paragraph (version A):
An endpoint verifies support for Explicit Congestion Notification
(ECN) by observing whether the ACK frames acknowledging the first
packets it sends carry ECN counts, as described in ecn-validation.
Paragraph (version B):
Endpoints can use packets sent during the handshake to test for
Explicit Congestion Notification (ECN) support; see ecn.  An endpoint
verifies support for ECN by observing whether the ACK frames
acknowledging the first packets it sends carry ECN counts, as
described in ecn-validation.
Draft: draft-ietf-quic-transport

Commentary: For example , OSX does n't have an API to set this bit ( allegedly this will change with Big Sur ) . Furthermore , not all implementations might have access to an API that allows them to set bits in the IP header . If I remember correctly , this is one of the reasons we made ECN optional . 
 I think you wanted to quote this part ( { { ! IPv4 = RFC0791 } } ) , the DF bit MUST be set to prevent fragmentation on the path . Would a proposal be to make the MUST a SHOULD and say " unless this is not supported by the underlying OS " ? 
 Yes , that was a weird copy - paste error . If we say " unless this is not supported by the underlying OS or the programming language " we can probably even keep the MUST . 
 This is an editorial issue , since the intent of the MUST can not be to require something that is n't possible . 
 This seems fine . What do you think of the short version ?
Paragraph (version A):
UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4
(IPv4), the DF bit MUST be set to prevent fragmentation on the path.
Paragraph (version B):
UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4
(IPv4), the DF bit MUST be set if possible, to prevent fragmentation
on the path.
Draft: draft-ietf-quic-transport

Commentary: Text says Services offered over loopback interfaces ( that is , the IPv6 address : :1 or the IPv4 address 127.0.0.1 ) often lack proper authentication . On v4 , loopback is technically the entire 127.0.0.0/8 network , not just that one address . But I wonder if we need the parenthetical anyway ?
Paragraph (version A):
Services offered over loopback interfaces (that is, the IPv6 address
::1 or the IPv4 address 127.0.0.1) often lack proper authentication.
Endpoints MAY prevent connection attempts or migration to a loopback
address.  Endpoints SHOULD NOT allow connections or migration to a
loopback address if the same service was previously available at a
different interface or if the address was provided by a service at a
non-loopback address.  Endpoints that depend on these capabilities
could offer an option to disable these protections.
Paragraph (version B):
Services offered over loopback interfaces often lack proper
authentication.  Endpoints MAY prevent connection attempts or
migration to a loopback address.  Endpoints SHOULD NOT allow
connections or migration to a loopback address if the same service
was previously available at a different interface or if the address
was provided by a service at a non-loopback address.  Endpoints that
depend on these capabilities could offer an option to disable these
protections.
Draft: draft-ietf-quic-transport

Commentary: Error codes do use varints , but packet numbers ( in the header ) do n't .
Paragraph (version A):
Versions (versions) and error codes (error-codes) are described using
integers, but do not use this encoding.
Paragraph (version B):
Versions (versions) and packet numbers sent in the header (packet-
encoding) are described using integers, but do not use this encoding.
Draft: draft-ietf-quic-transport

Commentary: Looks fine , but I like suggestion
Paragraph (version B):
Violations of the protocol lead to an immediate close.
Paragraph (version A):
Disposing of connection state prior to exiting the closing or
draining state could cause could result in an endpoint generating a
stateless reset unnecessarily when it receives a late-arriving
packet.  Endpoints that have some alternative means to ensure that
late-arriving packets do not induce a response, such as those that
are able to close the UDP socket, MAY end these states earlier to
allow for faster resource recovery.  Servers that retain an open
socket for accepting new connections SHOULD NOT end the closing or
draining states early.
Paragraph (version B):
Disposing of connection state prior to exiting the closing or
draining state could result in an endpoint generating a stateless
reset unnecessarily when it receives a late-arriving packet.
Endpoints that have some alternative means to ensure that late-
arriving packets do not induce a response, such as those that are
able to close the UDP socket, MAY end these states earlier to allow
for faster resource recovery.  Servers that retain an open socket for
accepting new connections SHOULD NOT end the closing or draining
states early.
Draft: draft-ietf-quic-http

Commentary: RFC3986 was included in the references twice .
Paragraph (version A):
Contains the authority portion of the target URI (Section 3.2 of
RFC3986).  The authority MUST NOT include the deprecated
"userinfo" subcomponent for "http" or "https" schemed URIs.
Paragraph (version B):
Contains the authority portion of the target URI (Section 3.2 of
URI).  The authority MUST NOT include the deprecated "userinfo"
subcomponent for "http" or "https" schemed URIs.
Draft: draft-ietf-quic-recovery

Commentary: This draft already has an informative reference to RACK , so it seems sensible to note the small difference in time threshold .
Paragraph (version B):
TCP's RACK (RACK) specifies a slightly larger threshold,
equivalent to 5/4, for a similar purpose.  Experience with QUIC
shows that 9/8 works well.
Draft: draft-ietf-quic-transport

Commentary: Thanks . Some grammar nits , but this is good .
Paragraph (version A):
Each endpoint validates transport parameters set by the peer.  The
client confirms that the retry_source_connection_id transport
parameter is absent if it did not process a Retry packet.
Paragraph (version A):
A client that attempts to send 0-RTT data MUST remember all other
transport parameters used by the server.  The server can remember
these transport parameters, or store an integrity-protected copy of
the values in the ticket and recover the information when accepting
0-RTT data.  A server uses the transport parameters in determining
whether to accept 0-RTT data.
Paragraph (version B):
A client that attempts to send 0-RTT data MUST remember all other
transport parameters used by the server that it is able to process.
The server can remember these transport parameters, or store an
integrity-protected copy of the values in the ticket and recover the
information when accepting 0-RTT data.  A server uses the transport
parameters in determining whether to accept 0-RTT data.
Paragraph (version A):
A server MUST either reject 0-RTT data or abort a handshake if the
implied values for transport parameters cannot be supported.
Paragraph (version B):
A server MUST reject 0-RTT data if the restored values for transport
parameters cannot be supported.
Draft: draft-ietf-quic-transport

Commentary: WFM ,  ?
Paragraph (version A):
A receiver can use an autotuning mechanism to tune the frequency and
amount of advertised additional credit based on a round-trip time
estimate and the rate at which the receiving application consumes
data, similar to common TCP implementations.  As an optimization, an
endpoint could send frames related to flow control only when there
are other frames to send or when a peer is blocked, ensuring that
flow control does not cause extra packets to be sent.
Paragraph (version B):
A receiver can use an autotuning mechanism to tune the frequency and
amount of advertised additional credit based on a round-trip time
estimate and the rate at which the receiving application consumes
data, similar to common TCP implementations.  As an optimization, an
endpoint could send frames related to flow control only when there
are other frames to send, ensuring that flow control does not cause
extra packets to be sent.
Paragraph (version A):
Endpoints need to eventually agree on the amount of flow control
credit that has been consumed, to avoid either exceeding flow control
limits or deadlocking.
Paragraph (version B):
Endpoints need to eventually agree on the amount of flow control
credit that has been consumed on every stream, to be able to account
for all bytes for connection-level flow control.
Paragraph (version A):
RESET_STREAM terminates one direction of a stream abruptly.  For a
bidirectional stream, RESET_STREAM has no effect on data flow in the
opposite direction.  Both endpoints MUST maintain flow control state
for the stream in the unterminated direction until that direction
enters a terminal state, or until one of the endpoints sends
CONNECTION_CLOSE.
Paragraph (version B):
RESET_STREAM terminates one direction of a stream abruptly.  For a
bidirectional stream, RESET_STREAM has no effect on data flow in the
opposite direction.  Both endpoints MUST maintain flow control state
for the stream in the unterminated direction until that direction
enters a terminal state.
Paragraph (version A):
An endpoint that is unable to open a new stream due to the peer's
limits SHOULD send a STREAMS_BLOCKED frame (frame-streams-blocked).
This signal is considered useful for debugging.  An endpoint MUST NOT
wait to receive this signal before advertising additional credit,
since doing so will mean that the peer will be blocked for at least
an entire round trip, and potentially for longer if the peer chooses
not to send STREAMS_BLOCKED frames.
Paragraph (version B):
An endpoint that is unable to open a new stream due to the peer's
limits SHOULD send a STREAMS_BLOCKED frame (frame-streams-blocked).
This signal is considered useful for debugging.  An endpoint MUST NOT
wait to receive this signal before advertising additional credit,
since doing so will mean that the peer will be blocked for at least
an entire round trip, and potentially indefinitely if the peer
chooses not to send STREAMS_BLOCKED frames.
Draft: draft-ietf-quic-transport

Commentary: One nit , but this is good .
Paragraph (version A):
Invalid packets that lack strong integrity protection, such as
Initial, Retry, or Version Negotiation, MAY be discarded.  An
endpoint MUST generate a connection error if processing the contents
of these packets prior to discovering an error resulted in changes to
connection state that cannot be reverted.
Paragraph (version B):
Invalid packets that lack strong integrity protection, such as
Initial, Retry, or Version Negotiation, MAY be discarded.  An
endpoint MUST generate a connection error if processing the contents
of these packets prior to discovering an error, unless it fully
reverts these changes.
Paragraph (version A):
If a client receives a packet that has an unsupported version, it
MUST discard that packet.
Paragraph (version B):
If a client receives a packet that uses a different version than it
initially selected, it MUST discard that packet.
Paragraph (version A):
if Early Data is supported, retrieve application-controlled data
from the client's resumption ticket and enable rejecting Early
Data based on that information.
Paragraph (version B):
if Early Data is supported, retrieve application-controlled data
from the client's resumption ticket and accept or reject Early
Data based on that information.
Draft: draft-ietf-quic-tls

Commentary: Three minor changes here ; separate if needed : The section title refers to frames , but the content discusses packets The text refers to a RETRY packet ; packet types are not shouting - case Retry is not the only way to verify liveness prior to handshake completion ( e.g. Connection ID on packets with a multi - round - trip handshake ) ; reference to address validation for more context
Paragraph (version A):
The client has not demonstrated liveness, unless a RETRY packet
was used.
Paragraph (version B):
The client has not demonstrated liveness, unless the server has
validated the client's address with a Retry packet or other means;
see Section 8.1 of QUIC-TRANSPORT.
Draft: draft-ietf-quic-http

Commentary: In the HTTP/3 draft 30 , section 4.4 on   says and then adds in 10.4 ( ) I do n't think normative requirements belong in security considerations except in reference to that requirement elsewhere . Also , requirements in general should clearly state who is responsible for implementing them , whereas the latter requirement implies a client ( maybe ) . And sending CANCEL_PUSH is kind of like the MUST NOT , but not really the same thing ; it seems a bit weak in response given that the server just tried to poison the client . I think the server MUST is an interop requirement because the client MUST NOT is a critical security requirement . I think both should be described in   and merely noted in the Security Considerations , since they are really important . Way more important than the spec reads now . My guess is that this is editorial , but is the kind of thing that should be fixed before IESG last call . 
 The reason it 's only a SHOULD CANCEL_PUSH is that the server ca n't know with certainty for which origins the client considers it authoritative . The server only knows for which origins it believes that it 's authoritative . So having received a push the client considers out - of - bounds , the client ca n't know for sure whether it 's a poisoning attempt or simply a difference in view . Yes , I think this is editorial , since the core request is to relocate existing text without changing the normative requirements .
Paragraph (version A):
Clients SHOULD send a CANCEL_PUSH frame upon receipt of a
PUSH_PROMISE frame carrying a request that is not cacheable, is not
known to be safe, that indicates the presence of a request body, or
for which it does not consider the server authoritative.
Paragraph (version B):
Clients SHOULD send a CANCEL_PUSH frame upon receipt of a
PUSH_PROMISE frame carrying a request that is not cacheable, is not
known to be safe, that indicates the presence of a request body, or
for which it does not consider the server authoritative.  Any
corresponding responses MUST NOT be used or cached.
Paragraph (version A):
Pushed responses for which an origin server is not authoritative (see
connection-reuse) MUST NOT be used or cached.
Paragraph (version B):
Clients are required to reject pushed responses for which an origin
server is not authoritative; see server-push.
Draft: draft-ietf-quic-transport

Commentary: I also think it might be worthwhile to move much of this section to security considerations , leaving only the requirements here .  ? 
 This is already in the security considerations section , so we 're good . Though it 's hard to see , because the section is already so large . 
 I find Martin 's argument that QUIC servers are able to control their topology well enough to prevent request forgery attacks somewhat persuasive . However : think the document should be clearer that if you ca n't do this you ca n't deploy QUIC as a server . should add text indicating that a candidate extension to allow migration by the client would need to deal with this ( likely by adding one of the countermeasures we decided not to ass ) . This is a very long specification and otherwise the institutional knowledge about this issue is likely to be lost . 
 If people agree , I can provide PRs for these . 
 These sound like good additions that I would welcome . ( I would write the PR , but I do n't trust myself , I 'd appreciate you providing text . ) 
 Sounds like a good path forward . 
 Do you mean migration by the server ? 
 I 'm not clear on the grammar , but I mean " the server address changing " 
 FWIW , when we 've talked about a server migration extension before , it was usually in the form of a frame that mimics the preferred_address TP , prompting the client to probe the new address and actually make the change . That approach seems like it limits the attacks to those already possible with SPA , though it broadens the window / number of attempts . 
 Could people take a look at the PR ? Would like to move this along . 
 Thanks for writing this up . My only comment is that this is two points and therefore two paragraphs .
Paragraph (version B):
Because the migration attack described in request-forgery-with-
spoofed-migration is quite powerful and does not have adequate
countermeasures, QUIC server implementations should assume that
attackers can cause them to generate arbitrary UDP payloads to
arbitrary destinations.  QUIC servers SHOULD NOT be deployed in
networks that also have inadequately secured UDP endpoints.
Paragraph (version B):
Although it is not generally possible to ensure that clients are not
co-located with vulnerable endpoints, this version of QUIC does not
allow servers to migrate, thus preventing spoofed migration attacks
on clients.  Any future extension which allows server migration MUST
also define countermeasures for forgery attacks.
Draft: draft-ietf-quic-transport

Commentary: I noticed this in the Transport Draft ( ID-30 ): Is this intentional ? Should an invalid transport parameter result in a frame encoding error ? 
 I believe this aligns with our principles that a framing error which can be detected with no connection context is a FRAMEENCODINGERROR . Is there another error you 'd suggest ? 
 My concern is that transport parameter values have nothing to do with framing and using FRAMEENCODINGERROR is therefore misleading . 
 We only ever applied this principle to frames though , so I 'm not sure we can use it as a precedent here . The name is indeed confusing , as it 's FRAMEENCODINGERROR and not FRAMINGERROR or ENCODINGERROR . 
 I always rationalized this as " the encoded content of the CRYPTO frame is erroneous " . 
 Well , if we 've been through this before , I wo n't insist -- it 's just something that jumped out at me . 
 That 's even more confusing . The CRYPTO frame itself is totally fine . I 'd be in favor of changing it to a TRANSPORTPARAMETERERROR .
Paragraph (version A):
If a max_streams transport parameter or MAX_STREAMS frame is received
with a value greater than 2^60, this would allow a maximum stream ID
that cannot be expressed as a variable-length integer; see integer-
encoding.  If either is received, the connection MUST be closed
immediately with a connection error of type FRAME_ENCODING_ERROR; see
immediate-close.
Paragraph (version B):
If a max_streams transport parameter or a MAX_STREAMS frame is
received with a value greater than 2^60, this would allow a maximum
stream ID that cannot be expressed as a variable-length integer; see
integer-encoding.  If either is received, the connection MUST be
closed immediately with a connection error of type
TRANSPORT_PARAMETER_ERROR if the offending value was received in a
transport parameter or of type FRAME_ENCODING_ERROR if it was
received in a frame; see immediate-close.
Draft: draft-ietf-quic-transport

Commentary: WFM.Thank you for the PR , !
Paragraph (version A):
Prior to receiving an acknowledgement for a packet number space, the
full packet number MUST be included.
Paragraph (version B):
Prior to receiving an acknowledgement for a packet number space, the
full packet number MUST be included; it is not to be truncated as
described below.
Draft: draft-ietf-quic-transport

Commentary: An update to I read the 4091 text as implying that probes were sent upon a loss .
Paragraph (version A):
To avoid excessively small idle timeout periods, endpoints MUST
increase the idle timeout period to be at least three times the
current Probe Timeout (PTO).  This allows for multiple PTOs to
expire, and therefore multiple probes to be sent in the event of
loss, prior to idle timeout.
Paragraph (version B):
To avoid excessively small idle timeout periods, endpoints MUST
increase the idle timeout period to be at least three times the
current Probe Timeout (PTO).  This allows for multiple PTOs to
expire, and therefore multiple probes to be sent and lost, prior to
idle timeout.
Draft: draft-ietf-quic-transport

Commentary: I think this was the intent of the sentence , but I kept not being able to parse it so .
Paragraph (version A):
To avoid excessively small idle timeout periods, endpoints MUST
increase the idle timeout period to be at least three times the
current Probe Timeout (PTO).  This allows for multiple PTOs to expire
prior to idle timeout, ensuring the idle timeout does not expire as a
result of a single packet loss.
Paragraph (version B):
To avoid excessively small idle timeout periods, endpoints MUST
increase the idle timeout period to be at least three times the
current Probe Timeout (PTO).  This allows for multiple PTOs to
expire, and therefore multiple probes to be sent in the event of
loss, prior to idle timeout.