Draft: rfc9000

Commentary: one comment but rest lgtm -- thanks !
Paragraph (version A):
The receiver only sends MAX_STREAM_DATA frames in the "Recv" state.
A receiver MAY send a STOP_SENDING frame in any state where it has
not received a RESET_STREAM frame - that is, states other than "Reset
Recvd" or "Reset Read".  However, there is little value in sending
STOP_SENDING frames in the "Data Recvd" state, as all stream data has
been received.  A sender could receive either of these two types of
frames in any state as a result of delayed delivery of packets.
Paragraph (version B):
The receiver only sends MAX_STREAM_DATA frames in the "Recv" state.
A receiver MAY send a STOP_SENDING frame in any state where it has
not received a RESET_STREAM frame - that is, states other than "Reset
Recvd" or "Reset Read".  However, there is little value in sending a
STOP_SENDING frame in the "Data Recvd" state, as all stream data has
been received.  A sender could receive either of these two types of
frames in any state as a result of delayed delivery of packets.
Paragraph (version A):
A client MUST NOT use remembered values for the following parameters:
ack_delay_exponent, max_ack_delay, initial_source_connection_id,
original_destination_connection_id, preferred_address,
retry_source_connection_id, and stateless_reset_token.  The client
MUST use the server's new values in the handshake instead; if the
server does not provide new values, default values are used.
Paragraph (version B):
A client MUST NOT use remembered values for the following parameters:
ack_delay_exponent, max_ack_delay, initial_source_connection_id,
original_destination_connection_id, preferred_address,
retry_source_connection_id, and stateless_reset_token.  The client
MUST use the server's new values in the handshake instead; if the
server does not provide new values, the default values are used.
Paragraph (version A):
Omitting or setting a zero value for certain transport parameters can
result in 0-RTT data being enabled but not usable.  The applicable
subset of transport parameters that permit the sending of application
data SHOULD be set to non-zero values for 0-RTT.  This includes
initial_max_data and either (1) initial_max_streams_bidi and
initial_max_stream_data_bidi_remote, or (2) initial_max_streams_uni
and initial_max_stream_data_uni.
Paragraph (version B):
Omitting or setting a zero value for certain transport parameters can
result in 0-RTT data being enabled but not usable.  The applicable
subset of transport parameters that permit the sending of application
data SHOULD be set to non-zero values for 0-RTT.  This includes
initial_max_data and either (1) initial_max_streams_bidi and
initial_max_stream_data_bidi_remote or (2) initial_max_streams_uni
and initial_max_stream_data_uni.
Paragraph (version A):
When sending frames in 0-RTT packets, a client MUST only use
remembered transport parameters; importantly, it MUST NOT use updated
values that it learns from the server's updated transport parameters
or from frames received in 1-RTT packets.  Updated values of
transport parameters from the handshake apply only to 1-RTT packets.
For instance, flow control limits from remembered transport
parameters apply to all 0-RTT packets even if those values are
increased by the handshake or by frames sent in 1-RTT packets.  A
server MAY treat use of updated transport parameters in 0-RTT as a
connection error of type PROTOCOL_VIOLATION.
Paragraph (version B):
When sending frames in 0-RTT packets, a client MUST only use
remembered transport parameters; importantly, it MUST NOT use updated
values that it learns from the server's updated transport parameters
or from frames received in 1-RTT packets.  Updated values of
transport parameters from the handshake apply only to 1-RTT packets.
For instance, flow control limits from remembered transport
parameters apply to all 0-RTT packets even if those values are
increased by the handshake or by frames sent in 1-RTT packets.  A
server MAY treat the use of updated transport parameters in 0-RTT as
a connection error of type PROTOCOL_VIOLATION.
Paragraph (version A):
Loss of an Initial or Handshake packet from the server can cause a
deadlock if the client does not send additional Initial or Handshake
packets.  A deadlock could occur when the server reaches its anti-
amplification limit and the client has received acknowledgments for
all the data it has sent.  In this case, when the client has no
reason to send additional packets, the server will be unable to send
more data because it has not validated the client's address.  To
prevent this deadlock, clients MUST send a packet on a Probe Timeout
(PTO, see Section 6.2 of QUIC-RECOVERY).  Specifically, the client
MUST send an Initial packet in a UDP datagram that contains at least
1200 bytes if it does not have Handshake keys, and otherwise send a
Handshake packet.
Paragraph (version B):
Loss of an Initial or Handshake packet from the server can cause a
deadlock if the client does not send additional Initial or Handshake
packets.  A deadlock could occur when the server reaches its anti-
amplification limit and the client has received acknowledgments for
all the data it has sent.  In this case, when the client has no
reason to send additional packets, the server will be unable to send
more data because it has not validated the client's address.  To
prevent this deadlock, clients MUST send a packet on a Probe Timeout
(PTO); see Section 6.2 of QUIC-RECOVERY.  Specifically, the client
MUST send an Initial packet in a UDP datagram that contains at least
1200 bytes if it does not have Handshake keys, and otherwise send a
Handshake packet.
Paragraph (version A):
This defense is imperfect, but this is not considered a serious
problem.  If the path via the attack is reliably faster than the
original path despite multiple attempts to use that original path, it
is not possible to distinguish between attack and an improvement in
routing.
Paragraph (version B):
This defense is imperfect, but this is not considered a serious
problem.  If the path via the attack is reliably faster than the
original path despite multiple attempts to use that original path, it
is not possible to distinguish between an attack and an improvement
in routing.
Paragraph (version A):
If a max_idle_timeout is specified by each endpoint in its transport
parameters (transport-parameter-definitions), the connection is
silently closed and its state is discarded when it remains idle for
longer than the minimum of the max_idle_timeout value advertised by
both endpoints.
Paragraph (version B):
If a max_idle_timeout is specified by either endpoint in its
transport parameters (transport-parameter-definitions), the
connection is silently closed and its state is discarded when it
remains idle for longer than the minimum of the max_idle_timeout
value advertised by both endpoints.
Paragraph (version A):
A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be
assured that the server has accepted 0-RTT.  Sending a
CONNECTION_CLOSE frame in an Initial packet makes it more likely
that the server can receive the close signal, even if the
application error code might not be received.
Paragraph (version A):
Prior to confirming the handshake, a peer might be unable to
process 1-RTT packets, so an endpoint SHOULD send CONNECTION_CLOSE
in both Handshake and 1-RTT packets.  A server SHOULD also send
CONNECTION_CLOSE in an Initial packet.
Paragraph (version B):
A client that sends a CONNECTION_CLOSE frame in a 0-RTT packet
cannot be assured that the server has accepted 0-RTT.  Sending a
CONNECTION_CLOSE frame in an Initial packet makes it more likely
that the server can receive the close signal, even if the
application error code might not be received.
Paragraph (version B):
Prior to confirming the handshake, a peer might be unable to
process 1-RTT packets, so an endpoint SHOULD send a
CONNECTION_CLOSE frame in both Handshake and 1-RTT packets.  A
server SHOULD also send a CONNECTION_CLOSE frame in an Initial
packet.
Paragraph (version A):
Coalescing packets in order of increasing encryption levels (Initial,
0-RTT, Handshake, 1-RTT; see Section 4.1.4 of QUIC-TLS) makes it more
likely the receiver will be able to process all the packets in a
single pass.  A packet with a short header does not include a length,
so it can only be the last packet included in a UDP datagram.  An
endpoint SHOULD include multiple frames in a single packet if they
are to be sent at the same encryption level, instead of coalescing
multiple packets at the same encryption level.
Paragraph (version B):
Coalescing packets in order of increasing encryption levels (Initial,
0-RTT, Handshake, 1-RTT; see Section 4.1.4 of QUIC-TLS) makes it more
likely that the receiver will be able to process all the packets in a
single pass.  A packet with a short header does not include a length,
so it can only be the last packet included in a UDP datagram.  An
endpoint SHOULD include multiple frames in a single packet if they
are to be sent at the same encryption level, instead of coalescing
multiple packets at the same encryption level.
Paragraph (version A):
Every QUIC packet that is coalesced into a single UDP datagram is
separate and complete.  The receiver of coalesced QUIC packets MUST
individually process each QUIC packet and separately acknowledge
them, as if they were received as the payload of different UDP
datagrams.  For example, if decryption fails (because the keys are
not available or any other reason), the receiver MAY either discard
or buffer the packet for later processing and MUST attempt to process
the remaining packets.
Paragraph (version B):
Every QUIC packet that is coalesced into a single UDP datagram is
separate and complete.  The receiver of coalesced QUIC packets MUST
individually process each QUIC packet and separately acknowledge
them, as if they were received as the payload of different UDP
datagrams.  For example, if decryption fails (because the keys are
not available or for any other reason), the receiver MAY either
discard or buffer the packet for later processing and MUST attempt to
process the remaining packets.
Paragraph (version A):
Endpoints rely on timely acknowledgment to detect loss; see Section 6
of QUIC-RECOVERY.  Window-based congestion controllers, such as the
one in Section 7 of QUIC-RECOVERY, rely on acknowledgments to manage
their congestion window.  In both cases, delaying acknowledgments can
adversely affect performance.
Paragraph (version B):
Endpoints rely on timely acknowledgment to detect loss; see Section 6
of QUIC-RECOVERY.  Window-based congestion controllers, such as the
one described in Section 7 of QUIC-RECOVERY, rely on acknowledgments
to manage their congestion window.  In both cases, delaying
acknowledgments can adversely affect performance.
Paragraph (version A):
Even though a sender is encouraged to assemble frames containing up-
to-date information every time it sends a packet, it is not forbidden
to retransmit copies of frames from lost packets.  A sender that
retransmits copies of frames needs to handle decreases in available
payload size due to changes in packet number length, connection ID
length, and path MTU.  A receiver MUST accept packets containing an
outdated frame, such as a MAX_DATA frame carrying a smaller maximum
data than one found in an older packet.
Paragraph (version B):
Even though a sender is encouraged to assemble frames containing up-
to-date information every time it sends a packet, it is not forbidden
to retransmit copies of frames from lost packets.  A sender that
retransmits copies of frames needs to handle decreases in available
payload size due to changes in packet number length, connection ID
length, and path MTU.  A receiver MUST accept packets containing an
outdated frame, such as a MAX_DATA frame carrying a smaller maximum
data value than one found in an older packet.
Paragraph (version A):
Even if an endpoint does not set an ECT field in packets it sends,
the endpoint MUST provide feedback about ECN markings it receives, if
these are accessible.  Failing to report the ECN counts will cause
the sender to disable use of ECN for this connection.
Paragraph (version B):
Even if an endpoint does not set an ECT field in packets it sends,
the endpoint MUST provide feedback about ECN markings it receives, if
these are accessible.  Failing to report the ECN counts will cause
the sender to disable the use of ECN for this connection.
Paragraph (version A):
It is possible for faulty network devices to corrupt or erroneously
drop packets that carry a non-zero ECN codepoint.  To ensure
connectivity in the presence of such devices, an endpoint validates
the ECN counts for each network path and disables use of ECN on that
path if errors are detected.
Paragraph (version B):
It is possible for faulty network devices to corrupt or erroneously
drop packets that carry a non-zero ECN codepoint.  To ensure
connectivity in the presence of such devices, an endpoint validates
the ECN counts for each network path and disables the use of ECN on
that path if errors are detected.
Paragraph (version A):
An endpoint MUST NOT increase PMTU based on ICMP messages; see Item 6
in Section 3 of DPLPMTUD.  Any reduction in QUIC's maximum datagram
size in response to ICMP messages MAY be provisional until QUIC's
loss detection algorithm determines that the quoted packet has
actually been lost.
Paragraph (version B):
An endpoint MUST NOT increase the PMTU based on ICMP messages; see
Item 6 in Section 3 of DPLPMTUD.  Any reduction in QUIC's maximum
datagram size in response to ICMP messages MAY be provisional until
QUIC's loss detection algorithm determines that the quoted packet has
actually been lost.
Paragraph (version A):
This means that integers are encoded on 1, 2, 4, or 8 bytes and can
encode 6-, 14-, 30-, or 62-bit values respectively.  integer-summary
summarizes the encoding properties.
Paragraph (version B):
This means that integers are encoded on 1, 2, 4, or 8 bytes and can
encode 6-, 14-, 30-, or 62-bit values, respectively.  integer-summary
summarizes the encoding properties.
Paragraph (version A):
The byte following the Destination Connection ID contains the
length in bytes of the Source Connection ID field that follows it.
This length is encoded as a 8-bit unsigned integer.  In QUIC
version 1, this value MUST NOT exceed 20 bytes.  Endpoints that
receive a version 1 long header with a value larger than 20 MUST
drop the packet.  In order to properly form a Version Negotiation
packet, servers SHOULD be able to read longer connection IDs from
other QUIC versions.
Paragraph (version B):
The byte following the Destination Connection ID contains the
length in bytes of the Source Connection ID field that follows it.
This length is encoded as an 8-bit unsigned integer.  In QUIC
version 1, this value MUST NOT exceed 20 bytes.  Endpoints that
receive a version 1 long header with a value larger than 20 MUST
drop the packet.  In order to properly form a Version Negotiation
packet, servers SHOULD be able to read longer connection IDs from
other QUIC versions.
Paragraph (version A):
An Initial packet uses long headers with a type value of 0x00.  It
carries the first CRYPTO frames sent by the client and server to
perform key exchange, and carries ACKs in either direction.
Paragraph (version B):
An Initial packet uses long headers with a type value of 0x00.  It
carries the first CRYPTO frames sent by the client and server to
perform key exchange, and it carries ACK frames in either direction.
Paragraph (version A):
In order to prevent tampering by version-unaware middleboxes, Initial
packets are protected with connection- and version-specific keys
(Initial keys) as described in QUIC-TLS.  This does not provide
confidentiality or integrity against attackers that can observe
packets, but it does prevent attackers that cannot observe packets
from spoofing Initial packets.
Paragraph (version B):
In order to prevent tampering by version-unaware middleboxes, Initial
packets are protected with connection- and version-specific keys
(Initial keys) as described in QUIC-TLS.  This protection does not
provide confidentiality or integrity against attackers that can
observe packets, but it does prevent attackers that cannot observe
packets from spoofing Initial packets.
Paragraph (version A):
A client sets the Destination Connection ID field of this Initial
packet to the value from the Source Connection ID in the Retry
packet.  Changing Destination Connection ID also results in a change
to the keys used to protect the Initial packet.  It also sets the
Token field to the token provided in the Retry.  The client MUST NOT
change the Source Connection ID because the server could include the
connection ID as part of its token validation logic; see token-
integrity.
Paragraph (version B):
A client sets the Destination Connection ID field of this Initial
packet to the value from the Source Connection ID field in the Retry
packet.  Changing the Destination Connection ID field also results in
a change to the keys used to protect the Initial packet.  It also
sets the Token field to the token provided in the Retry packet.  The
client MUST NOT change the Source Connection ID because the server
could include the connection ID as part of its token validation
logic; see token-integrity.
Paragraph (version A):
The Connection ID and Stateless Reset Token fields of a preferred
address are identical in syntax and semantics to the corresponding
fields of a NEW_CONNECTION_ID frame (frame-new-connection-id).  A
server that chooses a zero-length connection ID MUST NOT provide a
preferred address.  Similarly, a server MUST NOT include a zero-
length connection ID in this transport parameter.  A client MUST
treat violation of these requirements as a connection error of
type TRANSPORT_PARAMETER_ERROR.
Paragraph (version B):
The Connection ID and Stateless Reset Token fields of a preferred
address are identical in syntax and semantics to the corresponding
fields of a NEW_CONNECTION_ID frame (frame-new-connection-id).  A
server that chooses a zero-length connection ID MUST NOT provide a
preferred address.  Similarly, a server MUST NOT include a zero-
length connection ID in this transport parameter.  A client MUST
treat a violation of these requirements as a connection error of
type TRANSPORT_PARAMETER_ERROR.
Paragraph (version A):
PATH_RESPONSE frames are formatted as shown in fig-path-response.
The format of a PATH_RESPONSE frame is identical to the
PATH_CHALLENGE frame; see frame-path-challenge.
Paragraph (version B):
PATH_RESPONSE frames are formatted as shown in fig-path-response.
The format of a PATH_RESPONSE frame is identical to that of the
PATH_CHALLENGE frame; see frame-path-challenge.
Paragraph (version A):
An endpoint has determined that the network path is incapable of
supporting QUIC.  An endpoint is unlikely to receive
CONNECTION_CLOSE carrying this code except when the path does not
support a large enough MTU.
Paragraph (version B):
An endpoint has determined that the network path is incapable of
supporting QUIC.  An endpoint is unlikely to receive a
CONNECTION_CLOSE frame carrying this code except when the path
does not support a large enough MTU.
Paragraph (version A):
An on-path or off-path attacker can force a handshake to fail by
replacing or racing Initial packets.  Once valid Initial packets have
been exchanged, subsequent Handshake packets are protected with the
Handshake keys and an on-path attacker cannot force handshake failure
other than by dropping packets to cause endpoints to abandon the
attempt.
Paragraph (version B):
An on-path or off-path attacker can force a handshake to fail by
replacing or racing Initial packets.  Once valid Initial packets have
been exchanged, subsequent Handshake packets are protected with the
Handshake keys, and an on-path attacker cannot force handshake
failure other than by dropping packets to cause endpoints to abandon
the attempt.
Paragraph (version A):
The Source and Destination Connection ID fields are the primary means
of protection against off-path attack during the handshake; see
validate-handshake.  These are required to match those set by a peer.
Except for Initial and Stateless Reset packets, an endpoint only
accepts packets that include a Destination Connection ID field that
matches a value the endpoint previously chose.  This is the only
protection offered for Version Negotiation packets.
Paragraph (version B):
The Source and Destination Connection ID fields are the primary means
of protection against an off-path attack during the handshake; see
validate-handshake.  These are required to match those set by a peer.
Except for Initial and Stateless Reset packets, an endpoint only
accepts packets that include a Destination Connection ID field that
matches a value the endpoint previously chose.  This is the only
protection offered for Version Negotiation packets.
Paragraph (version A):
For request forgery to be effective, an attacker needs to be able to
influence what packets the peer sends and where these packets are
sent.  If an attacker can target a vulnerable service with a
controlled payload, that service might perform actions that are
attributed to the attacker's peer but decided by the attacker.
Paragraph (version B):
For request forgery to be effective, an attacker needs to be able to
influence what packets the peer sends and where these packets are
sent.  If an attacker can target a vulnerable service with a
controlled payload, that service might perform actions that are
attributed to the attacker's peer but are decided by the attacker.
Paragraph (version A):
Clients could avoid using NEW_TOKEN if the server address changes.
However, not including a Token field could adversely affect
performance.  Servers could rely on NEW_TOKEN to enable sending of
data in excess of the three-times limit on sending data; see
validate-handshake.  In particular, this affects cases where clients
use 0-RTT to request data from servers.
Paragraph (version B):
Clients could avoid using NEW_TOKEN if the server address changes.
However, not including a Token field could adversely affect
performance.  Servers could rely on NEW_TOKEN to enable the sending
of data in excess of the three-times limit on sending data; see
validate-handshake.  In particular, this affects cases where clients
use 0-RTT to request data from servers.
Paragraph (version A):
This document does not offer any additional countermeasures that are
specific to use of preferred addresses and can be implemented by
endpoints.  The generic measures described in forgery-generic could
be used as further mitigation.
Paragraph (version B):
This document does not offer any additional countermeasures that are
specific to the use of preferred addresses and can be implemented by
endpoints.  The generic measures described in forgery-generic could
be used as further mitigation.
Paragraph (version A):
The most effective defense against request forgery attacks is to
modify vulnerable services to use strong authentication.  However,
this is not always something that is within the control of a QUIC
deployment.  This section outlines some other steps that QUIC
endpoints could take unilaterally.  These additional steps are all
discretionary, because, depending on circumstances, they could
interfere with or prevent legitimate uses.
Paragraph (version B):
The most effective defense against request forgery attacks is to
modify vulnerable services to use strong authentication.  However,
this is not always something that is within the control of a QUIC
deployment.  This section outlines some other steps that QUIC
endpoints could take unilaterally.  These additional steps are all
discretionary because, depending on circumstances, they could
interfere with or prevent legitimate uses.
Paragraph (version A):
Similarly, endpoints could regard a change in address to link-local
address RFC4291 or an address in a private-use range RFC1918 from a
global, unique-local RFC4193, or non-private address as a potential
attempt at request forgery.  Endpoints could refuse to use these
addresses entirely, but that carries a significant risk of
interfering with legitimate uses.  Endpoints SHOULD NOT refuse to use
an address unless they have specific knowledge about the network
indicating that sending datagrams to unvalidated addresses in a given
range is not safe.
Paragraph (version B):
Similarly, endpoints could regard a change in address to a link-local
address RFC4291 or an address in a private-use range RFC1918 from a
global, unique-local RFC4193, or non-private address as a potential
attempt at request forgery.  Endpoints could refuse to use these
addresses entirely, but that carries a significant risk of
interfering with legitimate uses.  Endpoints SHOULD NOT refuse to use
an address unless they have specific knowledge about the network
indicating that sending datagrams to unvalidated addresses in a given
range is not safe.
Paragraph (version A):
The number of active streams is limited by the
initial_max_streams_bidi and initial_max_streams_uni transport
parameters as updated by any received MAX_STREAMS frames, as
explained in controlling-concurrency.  If chosen judiciously, these
limits mitigate the effect of the stream commitment attack.  However,
setting the limit too low could affect performance when applications
expect to open large number of streams.
Paragraph (version B):
The number of active streams is limited by the
initial_max_streams_bidi and initial_max_streams_uni transport
parameters as updated by any received MAX_STREAMS frames, as
explained in controlling-concurrency.  If chosen judiciously, these
limits mitigate the effect of the stream commitment attack.  However,
setting the limit too low could affect performance when applications
expect to open a large number of streams.
Paragraph (version A):
A limited on-path attacker can duplicate and send packets with
modified ECN fields to affect the sender's rate.  If duplicate
packets are discarded by a receiver, an attacker will need to race
the duplicate packet against the original to be successful in this
attack.  Therefore, QUIC endpoints ignore the ECN field on an IP
packet unless at least one QUIC packet in that IP packet is
successfully processed; see ecn.
Paragraph (version B):
A limited on-path attacker can duplicate and send packets with
modified ECN fields to affect the sender's rate.  If duplicate
packets are discarded by a receiver, an attacker will need to race
the duplicate packet against the original to be successful in this
attack.  Therefore, QUIC endpoints ignore the ECN field in an IP
packet unless at least one QUIC packet in that IP packet is
successfully processed; see ecn.
Paragraph (version A):
A request might be made to remove an unused provisional registration
from the registry to reclaim space in a registry, or portion of the
registry (such as the 64-16383 range for codepoints that use
variable-length encodings).  This SHOULD be done only for the
codepoints with the earliest recorded date, and entries that have
been updated less than a year prior SHOULD NOT be reclaimed.
Paragraph (version B):
A request might be made to remove an unused provisional registration
from the registry to reclaim space in a registry, or a portion of the
registry (such as the 64-16383 range for codepoints that use
variable-length encodings).  This SHOULD be done only for the
codepoints with the earliest recorded date, and entries that have
been updated less than a year prior SHOULD NOT be reclaimed.