Draft: draft-ietf-quic-transport

Commentary: This contains a lot of changes , but these seem to all be editorial . is unable to engage here for a little while , but we should take that opportunity to provide feedback . 
 Who holds the pen on this PR ? 
  , ( cc  ) I think , if I understand , that we now have text that is " mostly " correctable from the comments . I supect the proposed changes fix most ( all ? ) of the confusion I originally had . You own the edit token . I do n't think I have edit permission to fix the PR text where the PR comments propose a change , but you likely can edit ! - or you can make this possible for me to do , and I will re - edit these in . I think  has a few remaining issues , which I think I 'd sympathise with , but talking off - list I think the resolution of the comments in the PR edit may go a long way to alaso address these changes . I do n't know how best to progress , should we try to land the ECN rewrite making all agreed corrections , and then review what is left ?    here is to have  review this and merge it for -30 unless there is something that comes up . 
 you both hold blocking reviews on this . There are enough comments here that I was n't able to work out whether we 'd addressed those comments . Can you check and again and let us know if this is still blocking ? 
 Nope , your change is probably preferable . I should have re - read the text more closely before posting the suggestion . 
 ( Broken out of . ) That ’s possible , meaning try again to use ECN ? I think the text needs to be clearer , that this can be used to enable ECN to be used within the connection . 
 are you OK with ? 
 I think PR 4037 needs surgery . The intent seems pretty clear . I believe root cause of the comments originate from text that is n't perfected . There 's lots of colloquial terminology mistakes wrt ECN , some repetition , a few para ordering problems and few sentences needing polish . If we fix all these then maybe ( nearly ) all the issues will disappear . ... can I offer to edit the PR text in this section ? 
 Suggestions for text would be greatly appreciated . 
 could you send text soon , please ? 
 This text is being discussed in a PR 
 since is merged now , can we close this issue ? 
 Let us do that , yes . 
 I flagged some minor nits , but otherwise good to go . I made a suggestion on the 4 packets in a datagram issue that resolves it for me . PTAL and otherwise I think this is fine .
Paragraph (version A):
Frames are used in QUIC to communicate between endpoints.  One or
more frames are assembled into packets.  QUIC authenticates all
packets and encrypts as much as is practical.  QUIC packets are
carried in UDP datagrams to better facilitate deployment in existing
systems and networks.
Paragraph (version B):
Frames are used in QUIC to communicate between endpoints.  One or
more frames are assembled into packets.  QUIC authenticates all
packets and encrypts as much as is practical.  QUIC packets are
carried in UDP datagrams (UDP) to better facilitate deployment in
existing systems and networks.
Paragraph (version B):
An application protocol can also request to be informed of state
changes on streams, including when the peer has opened or reset a
stream, when a peer aborts reading on a stream, when new data is
available, and when data can or cannot be written to the stream due
to flow control.
Paragraph (version B):
An endpoint limits the cumulative number of incoming streams a peer
can open.  Only streams with a stream ID less than (max_stream * 4 +
initial_stream_id_for_type) can be opened; see stream-id-types.
Initial limits are set in the transport parameters; see transport-
parameter-definitions.  Subsequent limits are advertised using
MAX_STREAMS frames; see frame-max-streams.  Separate limits apply to
unidirectional and bidirectional streams.
Paragraph (version B):
An endpoint SHOULD supply a new connection ID when the peer retires a
connection ID.  If an endpoint provided fewer connection IDs than the
peer's active_connection_id_limit, it MAY supply a new connection ID
when it receives a packet with a previously unused connection ID.  An
endpoint MAY limit the total number of connection IDs issued for each
connection to avoid the risk of running out of connection IDs; see
reset-token.  An endpoint MAY also limit the issuance of connection
IDs to reduce the amount of per-path state it maintains, such as path
validation status, as its peer might interact with it over as many
paths as there are issued connection IDs.
Paragraph (version B):
Valid packets sent to clients always include a Destination Connection
ID that matches a value the client selects.  Clients that choose to
receive zero-length connection IDs can use the local address and port
to identify a connection.  Packets that do not match an existing
connection, based on Destination Connection ID or, if this value is
zero-length, local IP address and port, are discarded.
Paragraph (version B):
This document does not define an API for QUIC, but instead defines a
set of functions for QUIC connections that application protocols can
rely upon.  An application protocol can assume that an implementation
of QUIC provides an interface that includes the operations described
in this section.  An implementation designed for use with a specific
application protocol might provide only those operations that are
used by that protocol.
Paragraph (version B):
The definition of a new transport parameter (new-transport-
parameters) MUST specify whether storing the transport parameter for
0-RTT is mandatory, optional, or prohibited.  A client need not store
a transport parameter it cannot process.
Paragraph (version B):
Upon receiving the client's Initial packet, the server can request
address validation by sending a Retry packet (packet-retry)
containing a token.  This token MUST be repeated by the client in all
Initial packets it sends for that connection after it receives the
Retry packet.
Paragraph (version B):
In response to processing an Initial containing a token that was
provided in a Retry packet, a server cannot send another Retry
packet; it can only refuse the connection or permit it to proceed.
Paragraph (version B):
Path validation tests that packets sent on a path to a peer are
received by that peer.  Path validation is used to ensure that
packets received from a migrating peer do not carry a spoofed source
address.
Paragraph (version A):
To initiate path validation, an endpoint sends a PATH_CHALLENGE frame
containing a random payload on the path to be validated.
Paragraph (version B):
To initiate path validation, an endpoint sends a PATH_CHALLENGE frame
containing an unpredictable payload on the path to be validated.
Paragraph (version B):
Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE
frame is not adequate validation, since the acknowledgment can be
spoofed by a malicious peer.
Paragraph (version A):
This style of attack relies on the attacker using a path that is
approximately as fast as the direct path between endpoints.  The
attack is more reliable if relatively few packets are sent or if
packet loss coincides with the attempted attack.
Paragraph (version B):
This style of attack relies on the attacker using a path that has
approximately the same characteristics as the direct path between
endpoints.  The attack is more reliable if relatively few packets are
sent or if packet loss coincides with the attempted attack.
Paragraph (version B):
At any time, endpoints MAY change the Destination Connection ID they
transmit with to a value that has not been used on another path.
Paragraph (version B):
Migrating a connection to a new server address mid-connection is not
supported by the version of QUIC specified in this document.  If a
client receives packets from a new server address when the client has
not initiated a migration to that address, the client SHOULD discard
these packets.
Paragraph (version A):
If path validation succeeds, the client SHOULD immediately begin
sending all future packets to the new server address using the new
connection ID and discontinue use of the old server address.  If path
validation fails, the client MUST continue sending all future packets
to the server's original IP address.
Paragraph (version B):
As soon as path validation succeeds, the client SHOULD begin sending
all future packets to the new server address using the new connection
ID and discontinue use of the old server address.  If path validation
fails, the client MUST continue sending all future packets to the
server's original IP address.
Paragraph (version B):
A client that migrates to a preferred address MUST validate the
address it chooses before migrating; see forgery-spa.
Paragraph (version B):
After sending a CONNECTION_CLOSE frame, an endpoint immediately
enters the closing state; see closing.  After receiving a
CONNECTION_CLOSE frame, endpoints enter the draining state; see
draining.
Paragraph (version B):
An immediate close can be used after an application protocol has
arranged to close a connection.  This might be after the application
protocol negotiates a graceful shutdown.  The application protocol
can exchange messages that are needed for both application endpoints
to agree that the connection can be closed, after which the
application requests that QUIC close the connection.  When QUIC
consequently closes the connection, a CONNECTION_CLOSE frame with an
application-supplied error code will be used to signal closure to the
peer.
Paragraph (version B):
Once its closing or draining state ends, an endpoint SHOULD discard
all connection state.  The endpoint MAY send a stateless reset in
response to any further incoming packets belonging to this
connection.
Paragraph (version B):
An endpoint enters the closing state after initiating an immediate
close.
Paragraph (version B):
In the closing state, an endpoint retains only enough information to
generate a packet containing a CONNECTION_CLOSE frame and to identify
packets as belonging to the connection.  An endpoint in the closing
state sends a packet containing a CONNECTION_CLOSE frame in response
to any incoming packet that it attributes to the connection.
Paragraph (version B):
An endpoint SHOULD limit the rate at which it generates packets in
the closing state.  For instance, an endpoint could wait for a
progressively increasing number of received packets or amount of time
before responding to received packets.
Paragraph (version B):
An endpoint's selected connection ID and the QUIC version are
sufficient information to identify packets for a closing connection;
the endpoint MAY discard all other connection state.  An endpoint
that is closing is not required to process any received frame.  An
endpoint MAY retain packet protection keys for incoming packets to
allow it to read and process a CONNECTION_CLOSE frame.
Paragraph (version A):
After receiving a CONNECTION_CLOSE frame, endpoints enter the
draining state.  An endpoint that receives a CONNECTION_CLOSE frame
MAY send a single packet containing a CONNECTION_CLOSE frame before
entering the draining state, using a CONNECTION_CLOSE frame and a
NO_ERROR code if appropriate.  An endpoint MUST NOT send further
packets, which could result in a constant exchange of
CONNECTION_CLOSE frames until the closing period on either peer
ended.
Paragraph (version B):
While in the closing state, an endpoint could receive packets from a
new source address, possibly indicating a connection migration; see
migration.  An endpoint in the closing state MUST either discard
packets received from an unvalidated address or limit the cumulative
size of packets it sends to an unvalidated address to three times the
size of packets it receives from that address.
Paragraph (version B):
An endpoint is not expected to handle key updates when it is closing
(Section 6 of QUIC-TLS).  A key update might prevent the endpoint
from moving from the closing state to the draining state, as the
endpoint will not be able to process subsequently received packets,
but it otherwise has no impact.
Paragraph (version B):
The draining state is entered once an endpoint receives a
CONNECTION_CLOSE frame, which indicates that its peer is closing or
draining.  While otherwise identical to the closing state, an
endpoint in the draining state MUST NOT send any packets.  Retaining
packet protection keys is unnecessary once a connection is in the
draining state.
Paragraph (version B):
An endpoint that receives a CONNECTION_CLOSE frame MAY send a single
packet containing a CONNECTION_CLOSE frame before entering the
draining state, using a NO_ERROR code if appropriate.  An endpoint
MUST NOT send further packets.  Doing so could result in a constant
exchange of CONNECTION_CLOSE frames until one of the endpoints exits
the closing state.
Paragraph (version A):
The draining state is entered once an endpoint receives a signal that
its peer is closing or draining.  While otherwise identical to the
closing state, an endpoint in the draining state MUST NOT send any
packets.  Retaining packet protection keys is unnecessary once a
connection is in the draining state.
Paragraph (version A):
Once the closing or draining period has ended, an endpoint SHOULD
discard all connection state.  This results in new packets on the
connection being handled generically.  For instance, an endpoint MAY
send a stateless reset in response to any further incoming packets.
Paragraph (version A):
The draining and closing periods do not apply when a stateless reset
(stateless-reset) is sent.
Paragraph (version A):
An endpoint is not expected to handle key updates when it is closing
or draining.  A key update might prevent the endpoint from moving
from the closing state to draining, but it otherwise has no impact.
Paragraph (version A):
Every packet SHOULD be acknowledged at least once, and ack-eliciting
packets MUST be acknowledged at least once within the maximum delay
an endpoint communicated using the max_ack_delay transport parameter;
see transport-parameter-definitions.  max_ack_delay declares an
explicit contract: an endpoint promises to never intentionally delay
acknowledgments of an ack-eliciting packet by more than the indicated
value.  If it does, any excess accrues to the RTT estimate and could
result in spurious or delayed retransmissions from the peer.  For
Initial and Handshake packets, a max_ack_delay of 0 is used.  The
sender uses the receiver's max_ack_delay value in determining
timeouts for timer-based retransmission, as detailed in Section 6.2
of QUIC-RECOVERY.
Paragraph (version B):
Every packet SHOULD be acknowledged at least once, and ack-eliciting
packets MUST be acknowledged at least once within the maximum delay
an endpoint communicated using the max_ack_delay transport parameter;
see transport-parameter-definitions.  max_ack_delay declares an
explicit contract: an endpoint promises to never intentionally delay
acknowledgments of an ack-eliciting packet by more than the indicated
value.  If it does, any excess accrues to the RTT estimate and could
result in spurious or delayed retransmissions from the peer.  A
sender uses the receiver's max_ack_delay value in determining
timeouts for timer-based retransmission, as detailed in Section 6.2
of QUIC-RECOVERY.
Paragraph (version B):
An endpoint MUST acknowledge all ack-eliciting Initial and Handshake
packets immediately and all ack-eliciting 0-RTT and 1-RTT packets
within its advertised max_ack_delay, with the following exception.
Prior to handshake confirmation, an endpoint might not have packet
protection keys for decrypting Handshake, 0-RTT, or 1-RTT packets
when they are received.  It might therefore buffer them and
acknowledge them when the requisite keys become available.
Paragraph (version B):
when the packet has a packet number larger than the highest-
numbered ack-eliciting packet that has been received and there are
missing packets between that packet and this packet.
Paragraph (version A):
An endpoint measures the delays intentionally introduced between the
time the packet with the largest packet number is received and the
time an acknowledgment is sent.  The endpoint encodes this
acknowledgement delay in the ACK Delay field of an ACK frame; see
frame-ack.  This allows the receiver of the ACK frame to adjust for
any intentional delays, which is important for getting a better
estimate of the path RTT when acknowledgments are delayed.  A packet
might be held in the OS kernel or elsewhere on the host before being
processed.  An endpoint MUST NOT include delays that it does not
control when populating the ACK Delay field in an ACK frame.
Paragraph (version A):
Since the acknowledgement delay is not used for Initial and Handshake
packets, the ACK Delay field in acknowledgements for those packet
types SHOULD be set to 0.
Paragraph (version B):
An endpoint measures the delays intentionally introduced between the
time the packet with the largest packet number is received and the
time an acknowledgment is sent.  The endpoint encodes this
acknowledgement delay in the ACK Delay field of an ACK frame; see
frame-ack.  This allows the receiver of the ACK frame to adjust for
any intentional delays, which is important for getting a better
estimate of the path RTT when acknowledgments are delayed.
Paragraph (version B):
A packet might be held in the OS kernel or elsewhere on the host
before being processed.  An endpoint MUST NOT include delays that it
does not control when populating the ACK Delay field in an ACK frame.
However, endpoints SHOULD include buffering delays caused by
unavailability of decryption keys, since these delays can be large
and are likely to be non-repeating.
Paragraph (version B):
When the measured acknowledgement delay is larger than its
max_ack_delay, an endpoint SHOULD report the measured delay.  This
information is especially useful during the handshake when delays
might be large; see sending-acknowledgements.
Paragraph (version B):
A sender SHOULD avoid retransmitting information from packets once
they are acknowledged.  This includes packets that are acknowledged
after being declared lost, which can happen in the presence of
network reordering.  Doing so requires senders to retain information
about packets after they are declared lost.  A sender can discard
this information after a period of time elapses that adequately
allows for reordering, such as a PTO (Section 6.2 of QUIC-RECOVERY),
or on other events, such as reaching a memory limit.
Paragraph (version A):
An IP packet that results in no QUIC packets being processed does not
increase ECN counts.  A QUIC packet detected by a receiver as a
duplicate does not affect the receiver's local ECN codepoint counts;
see security-ecn for relevant security concerns.
Paragraph (version A):
If an endpoint receives a QUIC packet without an ECT or CE codepoint
in the IP packet header, it responds per generating-acks with an ACK
frame without increasing any ECN counts.  If an endpoint does not
implement ECN support or does not have access to received ECN
codepoints, it does not increase ECN counts.
Paragraph (version A):
Coalesced packets (see packet-coalesce) mean that several packets can
share the same IP header.  The ECN counts for the ECN codepoint
received in the associated IP header are incremented once for each
QUIC packet, not per enclosing IP packet or UDP datagram.
Paragraph (version A):
To reduce the chances of misinterpreting congestive loss as packets
dropped by a faulty network element, an endpoint could set the ECT(0)
codepoint for only the first ten outgoing packets on a path, or for a
period of three RTTs, whichever occurs first.
Paragraph (version A):
Other methods of probing paths for ECN support are possible, as are
different marking strategies.  Implementations MAY use other methods
defined in RFCs; see RFC8311.  Implementations that use the ECT(1)
codepoint need to perform ECN validation using ECT(1) counts.
Paragraph (version A):
Erroneous application of ECN marks in the network can result in
degraded connection performance.  An endpoint that receives an ACK
frame with ECN counts therefore validates the counts before using
them.  It performs this validation by comparing newly received counts
against those from the last successfully processed ACK frame.  Any
increase in ECN counts is validated based on the markings that were
applied to packets that are newly acknowledged in the ACK frame.
Paragraph (version A):
If an ACK frame newly acknowledges a packet that the endpoint sent
with either ECT(0) or ECT(1) codepoints set, ECN validation fails if
ECN counts are not present in the ACK frame.  This check detects a
network element that zeroes out ECN bits or a peer that is unable to
access ECN markings.
Paragraph (version A):
ECN validation fails if the sum of the increase in ECT(0) and ECN-CE
counts is less than the number of newly acknowledged packets that
were originally sent with an ECT(0) marking.  Similarly, ECN
validation fails if the sum of the increases to ECT(1) and ECN-CE
counts is less than the number of newly acknowledged packets sent
with an ECT(1) marking.  These checks can detect removal of ECN
markings in the network.
Paragraph (version A):
An endpoint could miss acknowledgements for a packet when ACK frames
are lost.  It is therefore possible for the total increase in ECT(0),
ECT(1), and ECN-CE counts to be greater than the number of packets
acknowledged in an ACK frame.  This is why counts are permitted to be
larger than might be accounted for by newly acknowledged packets.
Paragraph (version A):
ECN validation MAY fail if the total count for an ECT(0) or ECT(1)
marking exceeds the total number of packets sent with the
corresponding marking.  In particular, an endpoint that never applies
a particular marking can fail validation when a non-zero count for
the corresponding marking is received.  This check can detect when
packets are marked ECT(0) or ECT(1) in the network.
Paragraph (version A):
Processing ECN counts out of order can result in validation failure.
An endpoint SHOULD skip ECN validation on an ACK frame that does not
increase the largest acknowledged packet number.
Paragraph (version B):
QUIC endpoints can use Explicit Congestion Notification (ECN) RFC3168
to detect and respond to network congestion.  ECN allows an endpoint
to set an ECT codepoint in the ECN field of an IP packet.  A network
node can then indicate congestion by setting the CE codepoint in the
ECN field instead of dropping the packet RFC8087.  Endpoints react to
reported congestion by reducing their sending rate in response, as
described in QUIC-RECOVERY.
Paragraph (version B):
To enable ECN, a sending QUIC endpoint first determines whether a
path supports ECN marking and whether the peer reports the ECN values
in received IP headers; see ecn-validation.
Paragraph (version B):
Use of ECN requires the receiving endpoint to read the ECN field from
an IP packet, which is not possible on all platforms.  If an endpoint
does not implement ECN support or does not have access to received
ECN fields, it does not report ECN counts for packets it receives.
Paragraph (version B):
Even if an endpoint does not set an ECT field on 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):
On receiving an IP packet with an ECT(0), ECT(1) or CE codepoint, an
ECN-enabled endpoint accesses the ECN field and increases the
corresponding ECT(0), ECT(1), or CE count.  These ECN counts are
included in subsequent ACK frames; see generating-acks and frame-ack.
Paragraph (version B):
Each packet number space maintains separate acknowledgement state and
separate ECN counts.  Coalesced QUIC packets (see packet-coalesce)
share the same IP header so the ECN counts are incremented once for
each coalesced QUIC packet.
Paragraph (version B):
For example, if one each of an Initial, Handshake, and 1-RTT QUIC
packet are coalesced into a single UDP datagram, the ECN counts for
all three packet number spaces will be incremented by one each, based
on the ECN field of the single IP header.
Paragraph (version B):
ECN counts are only incremented when QUIC packets from the received
IP packet are processed.  As such, duplicate QUIC packets are not
processed and do not increase ECN counts; see security-ecn for
relevant security concerns.
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 use of ECN on that
path if errors are detected.
Paragraph (version B):
The endpoint sets an ECT(0) codepoint in the IP header of early
outgoing packets sent on a new path to the peer (RFC8311).
Paragraph (version B):
The endpoint monitors whether all packets sent with an ECT
codepoint are eventually deemed lost (Section 6 of QUIC-RECOVERY),
indicating that ECN validation has failed.
Paragraph (version B):
If an endpoint has cause to expect that IP packets with an ECT
codepoint might be dropped by a faulty network element, the endpoint
could set an ECT codepoint for only the first ten outgoing packets on
a path, or for a period of three RTTs.  If all packets marked with
non-zero ECN codepoints are subsequently lost, it can disable marking
on the assumption that the marking causes in loss.
Paragraph (version B):
An endpoint thus attempts to use ECN and validates this for each new
connection, when switching to a server's preferred address, and on
active connection migration to a new path.  ecn-alg describes one
possible algorithm.
Paragraph (version B):
Other methods of probing paths for ECN support are possible, as are
different marking strategies.  Implementations MAY use other methods
defined in RFCs; see RFC8311.  Implementations that use the ECT(1)
codepoint need to perform ECN validation using the reported ECT(1)
counts.
Paragraph (version B):
Erroneous application of CE markings by the network can result in
degraded connection performance.  An endpoint that receives an ACK
frame with ECN counts therefore validates the counts before using
them.  It performs this validation by comparing newly received counts
against those from the last successfully processed ACK frame.  Any
increase in the ECN counts is validated based on the ECN markings
that were applied to packets that are newly acknowledged in the ACK
frame.
Paragraph (version B):
If an ACK frame newly acknowledges a packet that the endpoint sent
with either the ECT(0) or ECT(1) codepoint set, ECN validation fails
if the corresponding ECN counts are not present in the ACK frame.
This check detects a network element that zeroes the ECN field or a
peer that does not report ECN markings.
Paragraph (version B):
ECN validation also fails if the sum of the increase in ECT(0) and
ECN-CE counts is less than the number of newly acknowledged packets
that were originally sent with an ECT(0) marking.  Similarly, ECN
validation fails if the sum of the increases to ECT(1) and ECN-CE
counts is less than the number of newly acknowledged packets sent
with an ECT(1) marking.  These checks can detect remarking of ECN-CE
markings by the network.
Paragraph (version B):
An endpoint could miss acknowledgements for a packet when ACK frames
are lost.  It is therefore possible for the total increase in ECT(0),
ECT(1), and ECN-CE counts to be greater than the number of packets
that are newly acknowledged by an ACK frame.  This is why ECN counts
are permitted to be larger than the total number of packets that are
acknowledged.
Paragraph (version B):
Validating ECN counts from reordered ACK frames can result in
failure.  An endpoint MUST NOT fail ECN validation as a result of
processing an ACK frame that does not increase the largest
acknowledged packet number.
Paragraph (version B):
ECN validation can fail if the received total count for either ECT(0)
or ECT(1) exceeds the total number of packets sent with each
corresponding ECT codepoint.  In particular, validation will fail
when an endpoint receives a non-zero ECN count corresponding to an
ECT codepoint that it never applied.  This check detects when packets
are remarked to ECT(0) or ECT(1) in the network.
Paragraph (version B):
If validation fails, then the endpoint MUST disable ECN.  It stops
setting the ECT codepoint in IP packets that it sends, assuming that
either the network path or the peer does not support ECN.
Paragraph (version B):
Even if validation fails, an endpoint MAY revalidate ECN for the same
path at any later time in the connection.  An endpoint could continue
to periodically attempt validation.
Paragraph (version B):
Upon successful validation, an endpoint MAY continue to set an ECT
codepoint in subsequent packets it sends, with the expectation that
the path is ECN-capable.  Network routing and path elements can
however change mid-connection; an endpoint MUST disable ECN if
validation later fails.
Paragraph (version B):
A client MUST NOT reset the packet number for any packet number space
after processing a Retry packet.  In particular, 0-RTT packets
contain confidential information that will most likely be
retransmitted on receiving a Retry packet.  The keys used to protect
these new 0-RTT packets will not change as a result of responding to
a Retry packet.  However, the data sent in these packets could be
different than what was sent earlier.  Sending these new packets with
the same packet number is likely to compromise the packet protection
for those packets because the same key and nonce could be used to
protect different content.  A server MAY abort the connection if it
detects that the client reset the packet number.
Paragraph (version B):
An endpoint has reached the confidentiality or integrity limit for
the AEAD algorithm used by the given connection.
Paragraph (version B):
A request forgery attack occurs where an endpoint causes its peer to
issue a request towards a victim, with the request controlled by the
endpoint.  Request forgery attacks aim to provide an attacker with
access to capabilities of its peer that might otherwise be
unavailable to the attacker.  For a networking protocol, a request
forgery attack is often used to exploit any implicit authorization
conferred on the peer by the victim due to the peer's location in the
network.
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 decided by the attacker.
Paragraph (version B):
For example, cross-site request forgery CSRF exploits on the Web
cause a client to issue requests that include authorization cookies
COOKIE, allowing one site access to information and actions that are
intended to be restricted to a different site.
Paragraph (version B):
As QUIC runs over UDP, the primary attack modality of concern is one
where an attacker can select the address to which its peer sends UDP
datagrams and can control some of the unprotected content of those
packets.  As much of the data sent by QUIC endpoints is protected,
this includes control over ciphertext.  An attack is successful if an
attacker can cause a peer to send a UDP datagram to a host that will
perform some action based on content in the datagram.
Paragraph (version B):
This section discusses ways in which QUIC might be used for request
forgery attacks.
Paragraph (version B):
This section also describes limited countermeasures that can be
implemented by QUIC endpoints.  These mitigations can be employed
unilaterally by a QUIC implementation or deployment, without
potential targets for request forgery attacks taking action.  However
these countermeasures could be insufficient if UDP-based services do
not properly authorize requests.
Paragraph (version B):
Outside of the encrypted portion of packets, QUIC offers an endpoint
several options for controlling the content of UDP datagrams that its
peer sends.  The Destination Connection ID field offers direct
control over bytes that appear early in packets sent by the peer; see
connection-id.  The Token field in Initial packets offers a server
control over other bytes of Initial packets; see packet-initial.
Paragraph (version B):
There are no measures in this version of QUIC to prevent indirect
control over the encrypted portions of packets.  It is necessary to
assume that endpoints are able to control the contents of frames that
a peer sends, especially those frames that convey application data,
such as STREAM frames.  Though this depends to some degree on details
of the application protocol, some control is possible in many
protocol usage contexts.  As the attacker has access to packet
protection keys, they are likely to be capable of predicting how a
peer will encrypt future packets.  Successful control over datagram
content then only requires that the attacker be able to predict the
packet number and placement of frames in packets with some amount of
reliability.
Paragraph (version B):
This section assumes that limiting control over datagram content is
not feasible.  The focus of the mitigations in subsequent sections is
on limiting the ways in which datagrams that are sent prior to
address validation can be used for request forgery.
Paragraph (version B):
An attacker acting as a server can choose the IP address and port on
which it advertises its availability, so Initial packets from clients
are assumed to be available for use in this sort of attack.  The
address validation implicit in the handshake ensures that - for a new
connection - a client will not send other types of packet to a
destination that does not understand QUIC or is not willing to accept
a QUIC connection.
Paragraph (version B):
Initial packet protection (Section 5.2 of QUIC-TLS) makes it
difficult for servers to control the content of Initial packets sent
by clients.  A client choosing an unpredictable Destination
Connection ID ensures that servers are unable to control any of the
encrypted portion of Initial packets from clients.
Paragraph (version B):
However, the Token field is open to server control and does allow a
server to use clients to mount request forgery attacks.  Use of
tokens provided with the NEW_TOKEN frame (validate-future) offers the
only option for request forgery during connection establishment.
Paragraph (version B):
Clients however are not obligated to use the NEW_TOKEN frame.
Request forgery attacks that rely on the Token field can be avoided
if clients send an empty Token field when the server address has
changed from when the NEW_TOKEN frame was received.
Paragraph (version B):
Sending a Retry packet (packet-retry) offers a server the option to
change the Token field.  After sending a Retry, the server can also
control the Destination Connection ID field of subsequent Initial
packets from the client.  This also might allow indirect control over
the encrypted content of Initial packets.  However, the exchange of a
Retry packet validates the server's address, thereby preventing the
use of subsequent Initial packets for request forgery.
Paragraph (version B):
Servers can specify a preferred address, which clients then migrate
to after confirming the handshake; see preferred-address.  The
Destination Connection ID field of packets that the client sends to a
preferred address can be used for request forgery.
Paragraph (version B):
A client MUST NOT send non-probing frames to a preferred address
prior to validating that address; see address-validation.  This
greatly reduces the options that a server has to control the
encrypted portion of datagrams.
Paragraph (version B):
Clients are able to present a spoofed source address as part of an
apparent connection migration to cause a server to send datagrams to
that address.
Paragraph (version B):
The Destination Connection ID field in any packets that a server
subsequently sends to this spoofed address can be used for request
forgery.  A client might also be able to influence the ciphertext.
Paragraph (version B):
A server that only sends probing packets (probing) to an address
prior to address validation provides an attacker with only limited
control over the encrypted portion of datagrams.  However,
particularly for NAT rebinding, this can adversely affect
performance.  If the server sends frames carrying application data,
an attacker might be able to control most of the content of
datagrams.
Paragraph (version B):
This document does not offer specific countermeasures that can be
implemented by endpoints aside from the generic measures described in
forgery-generic.  However, countermeasures for address spoofing at
the network level, in particular ingress filtering BCP38, are
especially effective against attacks that use spoofing and originate
from an external network.
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 others steps that QUIC
endpoints could take unilaterally.  These additional steps are all
discretionary as, depending on circumstances, they could interfere
with or prevent legitimate uses.
Paragraph (version B):
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):
Endpoints MAY choose to reduce the risk of request forgery by not
including values from NEW_TOKEN frames in Initial packets or by only
sending probing frames in packets prior to completing address
validation.  Note that this does not prevent an attacker from using
the Destination Connection ID field for an attack.
Paragraph (version B):
Endpoints are not expected to have specific information about the
location of servers that could be vulnerable targets of a request
forgery attack.  However, it might be possible over time to identify
specific UDP ports that are common targets of attacks or particular
patterns in datagrams that are used for attacks.  Endpoints MAY
choose to avoid sending datagrams to these ports or not send
datagrams that match these patterns prior to validating the
destination address.  Endpoints MAY retire connection IDs containing
patterns known to be problematic without using them.
Paragraph (version B):
Modifying endpoints to apply these protections is more efficient
than deploying network-based protections, as endpoints do not need
to perform any additional processing when sending to an address
that has been validated.
Paragraph (version A):
An on-path attacker could manipulate the value of ECN codepoints in
the IP header to influence the sender's rate.  RFC3168 discusses
manipulations and their effects in more detail.
Paragraph (version B):
An on-path attacker could manipulate the value of ECN fields in the
IP header to influence the sender's rate.  RFC3168 discusses
manipulations and their effects in more detail.