Original text:
21.  21.1. <del> As an encrypted and authenticated transport QUIC provides a range of protections against denial of service.  Once the cryptographic handshake is complete, QUIC endpoints discard most packets that are not authenticated, greatly limiting the ability of an attacker to interfere with existing connections. </del>  <del> Once a connection is established QUIC endpoints might accept some unauthenticated ICMP packets (see pmtud), but the use of these packets is extremely limited.  The only other type of packet that an endpoint might accept is a stateless reset (stateless-reset), which relies on the token being kept secret until it is used. </del>  <del> During the creation of a connection, QUIC only provides protection against attack from off the network path.  All QUIC packets contain proof that the recipient saw a preceding packet from its peer. </del>  <del> Addresses cannot change during the handshake, so endpoints can discard packets that are received on a different network path. </del>  <del> The Source and Destination Connection ID fields are the primary means of protection against off-path attack during the handshake.  These are required to match those set by a peer.  Except for an 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. </del>  <del> The Destination Connection ID field in an Initial packet is selected by a client to be unpredictable, which serves an additional purpose. The packets that carry the cryptographic handshake are protected with a key that is derived from this connection ID and salt specific to the QUIC version.  This allows endpoints to use the same process for authenticating packets that they receive as they use after the cryptographic handshake completes.  Packets that cannot be authenticated are discarded.  Protecting packets in this fashion provides a strong assurance that the sender of the packet saw the Initial packet and understood it. </del>  <del> These protections are not intended to be effective against an attacker that is able to receive QUIC packets prior to the connection being established.  Such an attacker can potentially send packets that will be accepted by QUIC endpoints.  This version of QUIC attempts to detect this sort of attack, but it expects that endpoints will fail to establish a connection rather than recovering.  For the most part, the cryptographic handshake protocol QUIC-TLS is responsible for detecting tampering during the handshake. Endpoints are permitted to use other methods to detect and attempt to recover from interference with the handshake.  Invalid packets may be identified and discarded using other methods, but no specific method is mandated in this document. </del>  <del> 21.2. </del>  <del> An attacker might be able to receive an address validation token (address-validation) from a server and then release the IP address it used to acquire that token.  At a later time, the attacker may initiate a 0-RTT connection with a server by spoofing this same address, which might now address a different (victim) endpoint.  The attacker can thus potentially cause the server to send an initial congestion window's worth of data towards the victim. </del>  <del> Servers SHOULD provide mitigations for this attack by limiting the usage and lifetime of address validation tokens; see validate-future. </del>  <del> 21.3. </del>  <del> An endpoint that acknowledges packets it has not received might cause a congestion controller to permit sending at rates beyond what the network supports.  An endpoint MAY skip packet numbers when sending packets to detect this behavior.  An endpoint can then immediately close the connection with a connection error of type PROTOCOL_VIOLATION; see immediate-close. </del>  <del> 21.4. </del>  <del> 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. </del>  <del> 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. 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. </del>  <del> 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. </del>  <del> This section discusses ways in which QUIC might be used for request forgery attacks. </del>  <del> 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. </del>  <del> 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. </del>  <del> 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. </del>  <del> 21.4.1. </del>  <del> QUIC offers some opportunities for an attacker to influence or control where its peer sends UDP datagrams: </del>  <del> initial connection establishment (handshake), where a server is able to choose where a client sends datagrams, for example by populating DNS records; </del>  <del> preferred addresses (preferred-address), where a server is able to choose where a client sends datagrams; and </del>  <del> spoofed connection migrations (address-spoofing), where a client is able to use source address spoofing to select where a server sends subsequent datagrams. </del>  <del> In all three cases, the attacker can cause its peer to send datagrams to a victim that might not understand QUIC.  That is, these packets are sent by the peer prior to address validation; see address- validation. </del>  <del> 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. </del>  <del> 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. </del>  <del> 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. </del>  <del> 21.4.2. </del>  <del> 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. </del>  <del> 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. </del>  <del> 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. </del>  <del> 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. </del>  <del> 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. </del>  <del> 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. </del>  <del> 21.4.3. </del>  <del> 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. </del>  <del> 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. </del>  <del> 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. </del>  <del> 21.4.4. </del>  <del> 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. </del>  <del> 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. </del>  <del> 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. </del>  <del> 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. </del>  <del> 21.4.5. </del>  <del> 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. </del>  <del> 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. </del>  <del> 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. </del>  <del> 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. </del>  <del> 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. </del>  <del> 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. </del>  <del> 21.5. </del>  <del> The attacks commonly known as Slowloris (SLOWLORIS) try to keep many connections to the target endpoint open and hold them open as long as possible.  These attacks can be executed against a QUIC endpoint by generating the minimum amount of activity necessary to avoid being closed for inactivity.  This might involve sending small amounts of data, gradually opening flow control windows in order to control the sender rate, or manufacturing ACK frames that simulate a high loss rate. </del>  <del> QUIC deployments SHOULD provide mitigations for the Slowloris attacks, such as increasing the maximum number of clients the server will allow, limiting the number of connections a single IP address is allowed to make, imposing restrictions on the minimum transfer speed a connection is allowed to have, and restricting the length of time an endpoint is allowed to stay connected. </del>  <del> 21.6. </del>  <del> 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. </del>  <del> An adversarial receiver might intentionally not acknowledge packets containing stream data in an attempt to force the sender to store the unacknowledged stream data for retransmission. </del>  <del> The attack on receivers is mitigated if flow control windows correspond to available memory.  However, some receivers will over- commit memory and advertise flow control offsets in the aggregate that exceed actual available memory.  The over-commitment strategy can lead to better performance when endpoints are well behaved, but renders endpoints vulnerable to the stream fragmentation attack. </del>  <del> QUIC deployments SHOULD provide mitigations against stream fragmentation attacks.  Mitigations could consist of avoiding over- committing memory, limiting the size of tracking data structures, delaying reassembly of STREAM frames, implementing heuristics based on the age and duration of reassembly holes, or some combination. </del>  <del> 21.7. </del>  <del> An adversarial endpoint can open a large number of streams, exhausting state on an endpoint.  The adversarial endpoint could repeat the process on a large number of connections, in a manner similar to SYN flooding attacks in TCP. </del>  <del> Normally, clients will open streams sequentially, as explained in stream-id.  However, when several streams are initiated at short intervals, loss or reordering may cause STREAM frames that open streams to be received out of sequence.  On receiving a higher- numbered stream ID, a receiver is required to open all intervening streams of the same type; see stream-recv-states.  Thus, on a new connection, opening stream 4000000 opens 1 million and 1 client- initiated bidirectional streams. </del>  <del> The number of active streams is limited by the initial_max_streams_bidi and initial_max_streams_uni transport parameters, 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. </del>  <del> 21.8. </del>  <del> QUIC and TLS both contain frames or messages that have legitimate uses in some contexts, but that can be abused to cause a peer to expend processing resources without having any observable impact on the state of the connection. </del>  <del> Messages can also be used to change and revert state in small or inconsequential ways, such as by sending small increments to flow control limits. </del>  <del> If processing costs are disproportionately large in comparison to bandwidth consumption or effect on state, then this could allow a malicious peer to exhaust processing capacity. </del>  <del> While there are legitimate uses for all messages, implementations SHOULD track cost of processing relative to progress and treat excessive quantities of any non-productive packets as indicative of an attack.  Endpoints MAY respond to this condition with a connection error, or by dropping packets. </del>  <del> 21.9. </del>  <del> 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. </del>  <del> An on-the-side 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 off-path 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. </del>  <del> 21.10. </del>  <del> Stateless resets create a possible denial of service attack analogous to a TCP reset injection.  This attack is possible if an attacker is able to cause a stateless reset token to be generated for a connection with a selected connection ID.  An attacker that can cause this token to be generated can reset an active connection with the same connection ID. </del>  <del> If a packet can be routed to different instances that share a static key, for example by changing an IP address or port, then an attacker can cause the server to send a stateless reset.  To defend against this style of denial of service, endpoints that share a static key for stateless reset (see reset-token) MUST be arranged so that packets with a given connection ID always arrive at an instance that has connection state, unless that connection is no longer active. </del>  <del> More generally, servers MUST NOT generate a stateless reset if a connection with the corresponding connection ID could be active on any endpoint using the same static key. </del>  <del> In the case of a cluster that uses dynamic load balancing, it is possible that a change in load balancer configuration could occur while an active instance retains connection state.  Even if an instance retains connection state, the change in routing and resulting stateless reset will result in the connection being terminated.  If there is no chance of the packet being routed to the correct instance, it is better to send a stateless reset than wait for the connection to time out.  However, this is acceptable only if the routing cannot be influenced by an attacker. </del>  <del> 21.11. </del>  <del> This document defines QUIC Version Negotiation packets in version- negotiation that can be used to negotiate the QUIC version used between two endpoints.  However, this document does not specify how this negotiation will be performed between this version and subsequent future versions.  In particular, Version Negotiation packets do not contain any mechanism to prevent version downgrade attacks.  Future versions of QUIC that use Version Negotiation packets MUST define a mechanism that is robust against version downgrade attacks. </del>  <del> 21.12. </del>  <del> Deployments should limit the ability of an attacker to target a new connection to a particular server instance.  This means that client- controlled fields, such as the initial Destination Connection ID used on Initial and 0-RTT packets SHOULD NOT be used by themselves to make routing decisions.  Ideally, routing decisions are made independently of client-selected values; a Source Connection ID can be selected to route later packets to the same server. </del>  <del> 21.13. </del>  <del> The length of QUIC packets can reveal information about the length of the content of those packets.  The PADDING frame is provided so that endpoints have some ability to obscure the length of packet content; see frame-padding. </del>  <del> Note however that defeating traffic analysis is challenging and the subject of active research.  Length is not the only way that information might leak.  Endpoints might also reveal sensitive information through other side channels, such as the timing of packets. </del>  <del> 21.14. </del>  <del> A complete security analysis of QUIC is outside the scope of this document.  This section provides an informal description of the desired security properties as an aid to implementors and to help guide protocol analysis. </del>  <del> QUIC assumes the threat model described in SEC-CONS and provides protections against many of the attacks that arise from that model. </del>  <del> For this purpose, attacks are divided into passive and active attacks.  Passive attackers have the capability to read packets from the network, while active attackers also have the capability to write packets into the network.  However, a passive attack may involve an attacker with the ability to cause a routing change or other modification in the path taken by packets that comprise a connection. </del>  <del> Attackers are additionally categorized as either on-path attackers or off-path attackers; see Section 3.5 of SEC-CONS.  An on-path attacker can read, modify, or remove any packet it observes such that it no longer reaches its destination, while an off-path attacker observes the packets, but cannot prevent the original packet from reaching its intended destination.  Both types of attackers can also transmit arbitrary packets. </del>  <del> Properties of the handshake, protected packets, and connection migration are considered separately. </del>  <del> 21.14.1. </del>  <del> The QUIC handshake incorporates the TLS 1.3 handshake and inherits the cryptographic properties described in Appendix E.1 of TLS13. Many of the security properties of QUIC depend on the TLS handshake providing these properties.  Any attack on the TLS handshake could affect QUIC. </del>  <del> Any attack on the TLS handshake that compromises the secrecy or uniqueness of session keys affects other security guarantees provided by QUIC that depends on these keys.  For instance, migration (migration) depends on the efficacy of confidentiality protections, both for the negotiation of keys using the TLS handshake and for QUIC packet protection, to avoid linkability across network paths. </del>  <del> An attack on the integrity of the TLS handshake might allow an attacker to affect the selection of application protocol or QUIC version. </del>  <del> In addition to the properties provided by TLS, the QUIC handshake provides some defense against DoS attacks on the handshake. </del>  <del> 21.14.1.1. </del>  <del> Address validation (address-validation) is used to verify that an entity that claims a given address is able to receive packets at that address.  Address validation limits amplification attack targets to addresses for which an attacker can observe packets. </del>  <del> Prior to validation, endpoints are limited in what they are able to send.  During the handshake, a server cannot send more than three times the data it receives; clients that initiate new connections or migrate to a new network path are limited. </del>  <del> 21.14.1.2. </del>  <del> Computing the server's first flight for a full handshake is potentially expensive, requiring both a signature and a key exchange computation.  In order to prevent computational DoS attacks, the Retry packet provides a cheap token exchange mechanism that allows servers to validate a client's IP address prior to doing any expensive computations at the cost of a single round trip.  After a successful handshake, servers can issue new tokens to a client, which will allow new connection establishment without incurring this cost. </del>  <del> 21.14.1.3. </del>  <del> 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. </del>  <del> An on-path attacker can also replace the addresses of packets on either side and therefore cause the client or server to have an incorrect view of the remote addresses.  Such an attack is indistinguishable from the functions performed by a NAT. </del>  <del> 21.14.1.4. </del>  <del> The entire handshake is cryptographically protected, with the Initial packets being encrypted with per-version keys and the Handshake and later packets being encrypted with keys derived from the TLS key exchange.  Further, parameter negotiation is folded into the TLS transcript and thus provides the same integrity guarantees as ordinary TLS negotiation.  An attacker can observe the client's transport parameters (as long as it knows the version-specific salt) but cannot observe the server's transport parameters and cannot influence parameter negotiation. </del>  <del> Connection IDs are unencrypted but integrity protected in all packets. </del>  <del> This version of QUIC does not incorporate a version negotiation mechanism; implementations of incompatible versions will simply fail to establish a connection. </del>  <del> 21.14.2. </del>  <del> Packet protection (packet-protected) provides authentication and encryption of all packets except Version Negotiation packets, though Initial and Retry packets have limited encryption and authentication based on version-specific inputs; see QUIC-TLS for more details. This section considers passive and active attacks against protected packets. </del>  <del> Both on-path and off-path attackers can mount a passive attack in which they save observed packets for an offline attack against packet protection at a future time; this is true for any observer of any packet on any network. </del>  <del> A blind attacker, one who injects packets without being able to observe valid packets for a connection, is unlikely to be successful, since packet protection ensures that valid packets are only generated by endpoints that possess the key material established during the handshake; see handshake and handshake-properties.  Similarly, any active attacker that observes packets and attempts to insert new data or modify existing data in those packets should not be able to generate packets deemed valid by the receiving endpoint. </del>  <del> A spoofing attack, in which an active attacker rewrites unprotected parts of a packet that it forwards or injects, such as the source or destination address, is only effective if the attacker can forward packets to the original endpoint.  Packet protection ensures that the packet payloads can only be processed by the endpoints that completed the handshake, and invalid packets are ignored by those endpoints. </del>  <del> An attacker can also modify the boundaries between packets and UDP datagrams, causing multiple packets to be coalesced into a single datagram, or splitting coalesced packets into multiple datagrams. Aside from datagrams containing Initial packets, which require padding, modification of how packets are arranged in datagrams has no functional effect on a connection, although it might change some performance characteristics. </del>  <del> 21.14.3. </del>  <del> Connection Migration (migration) provides endpoints with the ability to transition between IP addresses and ports on multiple paths, using one path at a time for transmission and receipt of non-probing frames.  Path validation (migrate-validate) establishes that a peer is both willing and able to receive packets sent on a particular path.  This helps reduce the effects of address spoofing by limiting the number of packets sent to a spoofed address. </del>  <del> This section describes the intended security properties of connection migration when under various types of DoS attacks. </del>  <del> 21.14.3.1. </del>  <del> An attacker that can cause a packet it observes to no longer reach its intended destination is considered an on-path attacker.  When an attacker is present between a client and server, endpoints are required to send packets through the attacker to establish connectivity on a given path. </del>  <del> An on-path attacker can: </del>  <del> Inspect packets </del>  <del> Modify IP and UDP packet headers </del>  <del> Inject new packets </del>  <del> Delay packets </del>  <del> Reorder packets </del>  <del> Drop packets </del>  <del> Split and merge datagrams along packet boundaries </del>  <del> An on-path attacker cannot: </del>  <del> Modify an authenticated portion of a packet and cause the recipient to accept that packet </del>  <del> An on-path attacker has the opportunity to modify the packets that it observes, however any modifications to an authenticated portion of a packet will cause it to be dropped by the receiving endpoint as invalid, as packet payloads are both authenticated and encrypted. </del>  <del> In the presence of an on-path attacker, QUIC aims to provide the following properties: </del>  <del> An on-path attacker can prevent use of a path for a connection, causing it to fail if it cannot use a different path that does not contain the attacker.  This can be achieved by dropping all packets, modifying them so that they fail to decrypt, or other methods. </del>  <del> An on-path attacker can prevent migration to a new path for which the attacker is also on-path by causing path validation to fail on the new path. </del>  <del> An on-path attacker cannot prevent a client from migrating to a path for which the attacker is not on-path. </del>  <del> An on-path attacker can reduce the throughput of a connection by delaying packets or dropping them. </del>  <del> An on-path attacker cannot cause an endpoint to accept a packet for which it has modified an authenticated portion of that packet. </del>  <del> 21.14.3.2. </del>  <del> An off-path attacker is not directly on the path between a client and server, but could be able to obtain copies of some or all packets sent between the client and the server.  It is also able to send copies of those packets to either endpoint. </del>  <del> An off-path attacker can: </del>  <del> Inspect packets </del>  <del> Inject new packets </del>  <del> Reorder injected packets </del>  <del> An off-path attacker cannot: </del>  <del> Modify any part of a packet </del>  <del> Delay packets </del>  <del> Drop packets </del>  <del> Reorder original packets </del>  <del> An off-path attacker can modify packets that it has observed and inject them back into the network, potentially with spoofed source and destination addresses. </del>  <del> For the purposes of this discussion, it is assumed that an off-path attacker has the ability to observe, modify, and re-inject a packet into the network that will reach the destination endpoint prior to the arrival of the original packet observed by the attacker.  In other words, an attacker has the ability to consistently "win" a race with the legitimate packets between the endpoints, potentially causing the original packet to be ignored by the recipient. </del>  <del> It is also assumed that an attacker has the resources necessary to affect NAT state, potentially both causing an endpoint to lose its NAT binding, and an attacker to obtain the same port for use with its traffic. </del>  <del> In the presence of an off-path attacker, QUIC aims to provide the following properties: </del>  <del> An off-path attacker can race packets and attempt to become a "limited" on-path attacker. </del>  <del> An off-path attacker can cause path validation to succeed for forwarded packets with the source address listed as the off-path attacker as long as it can provide improved connectivity between the client and the server. </del>  <del> An off-path attacker cannot cause a connection to close once the handshake has completed. </del>  <del> An off-path attacker cannot cause migration to a new path to fail if it cannot observe the new path. </del>  <del> An off-path attacker can become a limited on-path attacker during migration to a new path for which it is also an off-path attacker. </del>  <del> An off-path attacker can become a limited on-path attacker by affecting shared NAT state such that it sends packets to the server from the same IP address and port that the client originally used. </del>  <del> 21.14.3.3. </del>  <del> A limited on-path attacker is an off-path attacker that has offered improved routing of packets by duplicating and forwarding original packets between the server and the client, causing those packets to arrive before the original copies such that the original packets are dropped by the destination endpoint. </del>  <del> A limited on-path attacker differs from an on-path attacker in that it is not on the original path between endpoints, and therefore the original packets sent by an endpoint are still reaching their destination.  This means that a future failure to route copied packets to the destination faster than their original path will not prevent the original packets from reaching the destination. </del>  <del> A limited on-path attacker can: </del>  <del> Inspect packets </del>  <del> Inject new packets </del>  <del> Modify unencrypted packet headers </del>  <del> Reorder packets </del>  <del> A limited on-path attacker cannot: </del>  <del> Delay packets so that they arrive later than packets sent on the original path </del>  <del> Drop packets </del>  <del> Modify the authenticated and encrypted portion of a packet and cause the recipient to accept that packet </del>  <del> A limited on-path attacker can only delay packets up to the point that the original packets arrive before the duplicate packets, meaning that it cannot offer routing with worse latency than the original path.  If a limited on-path attacker drops packets, the original copy will still arrive at the destination endpoint. </del>  <del> In the presence of a limited on-path attacker, QUIC aims to provide the following properties: </del>  <del> A limited on-path attacker cannot cause a connection to close once the handshake has completed. </del>  <del> A limited on-path attacker cannot cause an idle connection to close if the client is first to resume activity. </del>  <del> A limited on-path attacker can cause an idle connection to be deemed lost if the server is the first to resume activity. </del>  <del> Note that these guarantees are the same guarantees provided for any NAT, for the same reasons. </del>  22.

Reviewer comments:
It may be useful to review the commits separately; the first commit reorders sections without modifying text, while the second commit contains a new paragraph added to the beginning of the section.
An introduction to this long section would be useful I find it strange that having read 12 previous security analysis subsections I arrive at this section. I am surprised that the overview is not section 21.1
I'm going to trust that you just reordered, because the diff tool is completely unable to process this changeset.

Revised text:
21. <ins> The goal of QUIC is to provide a secure transport connection. security-properties provides an overview of those properties; subsequent sections discuss constraints and caveats regarding these properties, including descriptions of known attacks and countermeasures. </ins> 21.1.  <ins> A complete security analysis of QUIC is outside the scope of this document.  This section provides an informal description of the desired security properties as an aid to implementors and to help guide protocol analysis. </ins>  <ins> QUIC assumes the threat model described in SEC-CONS and provides protections against many of the attacks that arise from that model. </ins>  <ins> For this purpose, attacks are divided into passive and active attacks.  Passive attackers have the capability to read packets from the network, while active attackers also have the capability to write packets into the network.  However, a passive attack may involve an attacker with the ability to cause a routing change or other modification in the path taken by packets that comprise a connection. </ins>  <ins> Attackers are additionally categorized as either on-path attackers or off-path attackers; see Section 3.5 of SEC-CONS.  An on-path attacker can read, modify, or remove any packet it observes such that it no longer reaches its destination, while an off-path attacker observes the packets, but cannot prevent the original packet from reaching its intended destination.  Both types of attackers can also transmit arbitrary packets. </ins>  <ins> Properties of the handshake, protected packets, and connection migration are considered separately. </ins>  <ins> 21.1.1. </ins>  <ins> The QUIC handshake incorporates the TLS 1.3 handshake and inherits the cryptographic properties described in Appendix E.1 of TLS13. Many of the security properties of QUIC depend on the TLS handshake providing these properties.  Any attack on the TLS handshake could affect QUIC. </ins>  <ins> Any attack on the TLS handshake that compromises the secrecy or uniqueness of session keys affects other security guarantees provided by QUIC that depends on these keys.  For instance, migration (migration) depends on the efficacy of confidentiality protections, both for the negotiation of keys using the TLS handshake and for QUIC packet protection, to avoid linkability across network paths. </ins>  <ins> An attack on the integrity of the TLS handshake might allow an attacker to affect the selection of application protocol or QUIC version. </ins>  <ins> In addition to the properties provided by TLS, the QUIC handshake provides some defense against DoS attacks on the handshake. </ins>  <ins> 21.1.1.1. </ins>  <ins> Address validation (address-validation) is used to verify that an entity that claims a given address is able to receive packets at that address.  Address validation limits amplification attack targets to addresses for which an attacker can observe packets. </ins>  <ins> Prior to validation, endpoints are limited in what they are able to send.  During the handshake, a server cannot send more than three times the data it receives; clients that initiate new connections or migrate to a new network path are limited. </ins>  <ins> 21.1.1.2. </ins>  <ins> Computing the server's first flight for a full handshake is potentially expensive, requiring both a signature and a key exchange computation.  In order to prevent computational DoS attacks, the Retry packet provides a cheap token exchange mechanism that allows servers to validate a client's IP address prior to doing any expensive computations at the cost of a single round trip.  After a successful handshake, servers can issue new tokens to a client, which will allow new connection establishment without incurring this cost. </ins>  <ins> 21.1.1.3. </ins>  <ins> 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. </ins>  <ins> An on-path attacker can also replace the addresses of packets on either side and therefore cause the client or server to have an incorrect view of the remote addresses.  Such an attack is indistinguishable from the functions performed by a NAT. </ins>  <ins> 21.1.1.4. </ins>  <ins> The entire handshake is cryptographically protected, with the Initial packets being encrypted with per-version keys and the Handshake and later packets being encrypted with keys derived from the TLS key exchange.  Further, parameter negotiation is folded into the TLS transcript and thus provides the same integrity guarantees as ordinary TLS negotiation.  An attacker can observe the client's transport parameters (as long as it knows the version-specific salt) but cannot observe the server's transport parameters and cannot influence parameter negotiation. </ins>  <ins> Connection IDs are unencrypted but integrity protected in all packets. </ins>  <ins> This version of QUIC does not incorporate a version negotiation mechanism; implementations of incompatible versions will simply fail to establish a connection. </ins>  <ins> 21.1.2. </ins>  <ins> Packet protection (packet-protected) provides authentication and encryption of all packets except Version Negotiation packets, though Initial and Retry packets have limited encryption and authentication based on version-specific inputs; see QUIC-TLS for more details. This section considers passive and active attacks against protected packets. </ins>  <ins> Both on-path and off-path attackers can mount a passive attack in which they save observed packets for an offline attack against packet protection at a future time; this is true for any observer of any packet on any network. </ins>  <ins> A blind attacker, one who injects packets without being able to observe valid packets for a connection, is unlikely to be successful, since packet protection ensures that valid packets are only generated by endpoints that possess the key material established during the handshake; see handshake and handshake-properties.  Similarly, any active attacker that observes packets and attempts to insert new data or modify existing data in those packets should not be able to generate packets deemed valid by the receiving endpoint. </ins>  <ins> A spoofing attack, in which an active attacker rewrites unprotected parts of a packet that it forwards or injects, such as the source or destination address, is only effective if the attacker can forward packets to the original endpoint.  Packet protection ensures that the packet payloads can only be processed by the endpoints that completed the handshake, and invalid packets are ignored by those endpoints. </ins>  <ins> An attacker can also modify the boundaries between packets and UDP datagrams, causing multiple packets to be coalesced into a single datagram, or splitting coalesced packets into multiple datagrams. Aside from datagrams containing Initial packets, which require padding, modification of how packets are arranged in datagrams has no functional effect on a connection, although it might change some performance characteristics. </ins>  <ins> 21.1.3. </ins>  <ins> Connection Migration (migration) provides endpoints with the ability to transition between IP addresses and ports on multiple paths, using one path at a time for transmission and receipt of non-probing frames.  Path validation (migrate-validate) establishes that a peer is both willing and able to receive packets sent on a particular path.  This helps reduce the effects of address spoofing by limiting the number of packets sent to a spoofed address. </ins>  <ins> This section describes the intended security properties of connection migration when under various types of DoS attacks. </ins>  <ins> 21.1.3.1. </ins>  <ins> An attacker that can cause a packet it observes to no longer reach its intended destination is considered an on-path attacker.  When an attacker is present between a client and server, endpoints are required to send packets through the attacker to establish connectivity on a given path. </ins>  <ins> An on-path attacker can: </ins>  <ins> Inspect packets </ins>  <ins> Modify IP and UDP packet headers </ins>  <ins> Inject new packets </ins>  <ins> Delay packets </ins>  <ins> Reorder packets </ins>  <ins> Drop packets </ins>  <ins> Split and merge datagrams along packet boundaries </ins>  <ins> An on-path attacker cannot: </ins>  <ins> Modify an authenticated portion of a packet and cause the recipient to accept that packet </ins>  <ins> An on-path attacker has the opportunity to modify the packets that it observes, however any modifications to an authenticated portion of a packet will cause it to be dropped by the receiving endpoint as invalid, as packet payloads are both authenticated and encrypted. </ins>  <ins> In the presence of an on-path attacker, QUIC aims to provide the following properties: </ins>  <ins> An on-path attacker can prevent use of a path for a connection, causing it to fail if it cannot use a different path that does not contain the attacker.  This can be achieved by dropping all packets, modifying them so that they fail to decrypt, or other methods. </ins>  <ins> An on-path attacker can prevent migration to a new path for which the attacker is also on-path by causing path validation to fail on the new path. </ins>  <ins> An on-path attacker cannot prevent a client from migrating to a path for which the attacker is not on-path. </ins>  <ins> An on-path attacker can reduce the throughput of a connection by delaying packets or dropping them. </ins>  <ins> An on-path attacker cannot cause an endpoint to accept a packet for which it has modified an authenticated portion of that packet. </ins>  <ins> 21.1.3.2. </ins>  <ins> An off-path attacker is not directly on the path between a client and server, but could be able to obtain copies of some or all packets sent between the client and the server.  It is also able to send copies of those packets to either endpoint. </ins>  <ins> An off-path attacker can: </ins>  <ins> Inspect packets </ins>  <ins> Inject new packets </ins>  <ins> Reorder injected packets </ins>  <ins> An off-path attacker cannot: </ins>  <ins> Modify any part of a packet </ins>  <ins> Delay packets </ins>  <ins> Drop packets </ins>  <ins> Reorder original packets </ins>  <ins> An off-path attacker can modify packets that it has observed and inject them back into the network, potentially with spoofed source and destination addresses. </ins>  <ins> For the purposes of this discussion, it is assumed that an off-path attacker has the ability to observe, modify, and re-inject a packet into the network that will reach the destination endpoint prior to the arrival of the original packet observed by the attacker.  In other words, an attacker has the ability to consistently "win" a race with the legitimate packets between the endpoints, potentially causing the original packet to be ignored by the recipient. </ins>  <ins> It is also assumed that an attacker has the resources necessary to affect NAT state, potentially both causing an endpoint to lose its NAT binding, and an attacker to obtain the same port for use with its traffic. </ins>  <ins> In the presence of an off-path attacker, QUIC aims to provide the following properties: </ins>  <ins> An off-path attacker can race packets and attempt to become a "limited" on-path attacker. </ins>  <ins> An off-path attacker can cause path validation to succeed for forwarded packets with the source address listed as the off-path attacker as long as it can provide improved connectivity between the client and the server. </ins>  <ins> An off-path attacker cannot cause a connection to close once the handshake has completed. </ins>  <ins> An off-path attacker cannot cause migration to a new path to fail if it cannot observe the new path. </ins>  <ins> An off-path attacker can become a limited on-path attacker during migration to a new path for which it is also an off-path attacker. </ins>  <ins> An off-path attacker can become a limited on-path attacker by affecting shared NAT state such that it sends packets to the server from the same IP address and port that the client originally used. </ins>  <ins> 21.1.3.3. </ins>  <ins> A limited on-path attacker is an off-path attacker that has offered improved routing of packets by duplicating and forwarding original packets between the server and the client, causing those packets to arrive before the original copies such that the original packets are dropped by the destination endpoint. </ins>  <ins> A limited on-path attacker differs from an on-path attacker in that it is not on the original path between endpoints, and therefore the original packets sent by an endpoint are still reaching their destination.  This means that a future failure to route copied packets to the destination faster than their original path will not prevent the original packets from reaching the destination. </ins>  <ins> A limited on-path attacker can: </ins>  <ins> Inspect packets </ins>  <ins> Inject new packets </ins>  <ins> Modify unencrypted packet headers </ins>  <ins> Reorder packets </ins>  <ins> A limited on-path attacker cannot: </ins>  <ins> Delay packets so that they arrive later than packets sent on the original path </ins>  <ins> Drop packets </ins>  <ins> Modify the authenticated and encrypted portion of a packet and cause the recipient to accept that packet </ins>  <ins> A limited on-path attacker can only delay packets up to the point that the original packets arrive before the duplicate packets, meaning that it cannot offer routing with worse latency than the original path.  If a limited on-path attacker drops packets, the original copy will still arrive at the destination endpoint. </ins>  <ins> In the presence of a limited on-path attacker, QUIC aims to provide the following properties: </ins>  <ins> A limited on-path attacker cannot cause a connection to close once the handshake has completed. </ins>  <ins> A limited on-path attacker cannot cause an idle connection to close if the client is first to resume activity. </ins>  <ins> A limited on-path attacker can cause an idle connection to be deemed lost if the server is the first to resume activity. </ins>  <ins> Note that these guarantees are the same guarantees provided for any NAT, for the same reasons. </ins>  <ins> 21.2. </ins>  <ins> As an encrypted and authenticated transport QUIC provides a range of protections against denial of service.  Once the cryptographic handshake is complete, QUIC endpoints discard most packets that are not authenticated, greatly limiting the ability of an attacker to interfere with existing connections. </ins>  <ins> Once a connection is established QUIC endpoints might accept some unauthenticated ICMP packets (see pmtud), but the use of these packets is extremely limited.  The only other type of packet that an endpoint might accept is a stateless reset (stateless-reset), which relies on the token being kept secret until it is used. </ins>  <ins> During the creation of a connection, QUIC only provides protection against attack from off the network path.  All QUIC packets contain proof that the recipient saw a preceding packet from its peer. </ins>  <ins> Addresses cannot change during the handshake, so endpoints can discard packets that are received on a different network path. </ins>  <ins> The Source and Destination Connection ID fields are the primary means of protection against off-path attack during the handshake.  These are required to match those set by a peer.  Except for an 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. </ins>  <ins> The Destination Connection ID field in an Initial packet is selected by a client to be unpredictable, which serves an additional purpose. The packets that carry the cryptographic handshake are protected with a key that is derived from this connection ID and salt specific to the QUIC version.  This allows endpoints to use the same process for authenticating packets that they receive as they use after the cryptographic handshake completes.  Packets that cannot be authenticated are discarded.  Protecting packets in this fashion provides a strong assurance that the sender of the packet saw the Initial packet and understood it. </ins>  <ins> These protections are not intended to be effective against an attacker that is able to receive QUIC packets prior to the connection being established.  Such an attacker can potentially send packets that will be accepted by QUIC endpoints.  This version of QUIC attempts to detect this sort of attack, but it expects that endpoints will fail to establish a connection rather than recovering.  For the most part, the cryptographic handshake protocol QUIC-TLS is responsible for detecting tampering during the handshake. </ins>  <ins> Endpoints are permitted to use other methods to detect and attempt to recover from interference with the handshake.  Invalid packets may be identified and discarded using other methods, but no specific method is mandated in this document. </ins>  <ins> 21.3. </ins>  <ins> An attacker might be able to receive an address validation token (address-validation) from a server and then release the IP address it used to acquire that token.  At a later time, the attacker may initiate a 0-RTT connection with a server by spoofing this same address, which might now address a different (victim) endpoint.  The attacker can thus potentially cause the server to send an initial congestion window's worth of data towards the victim. Servers SHOULD provide mitigations for this attack by limiting the usage and lifetime of address validation tokens; see validate-future. </ins>  <ins> 21.4. </ins>  <ins> An endpoint that acknowledges packets it has not received might cause a congestion controller to permit sending at rates beyond what the network supports.  An endpoint MAY skip packet numbers when sending packets to detect this behavior.  An endpoint can then immediately close the connection with a connection error of type PROTOCOL_VIOLATION; see immediate-close. </ins>  <ins> 21.5. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> This section discusses ways in which QUIC might be used for request forgery attacks. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 21.5.1. </ins>  <ins> QUIC offers some opportunities for an attacker to influence or control where its peer sends UDP datagrams: </ins>  <ins> initial connection establishment (handshake), where a server is able to choose where a client sends datagrams, for example by populating DNS records; </ins>  <ins> preferred addresses (preferred-address), where a server is able to choose where a client sends datagrams; and </ins>  <ins> spoofed connection migrations (address-spoofing), where a client is able to use source address spoofing to select where a server sends subsequent datagrams. </ins>  <ins> In all three cases, the attacker can cause its peer to send datagrams to a victim that might not understand QUIC.  That is, these packets are sent by the peer prior to address validation; see address- validation. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 21.5.2. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 21.5.3. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 21.5.4. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 21.5.5. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 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. </ins>  <ins> 21.6. </ins>  <ins> The attacks commonly known as Slowloris (SLOWLORIS) try to keep many connections to the target endpoint open and hold them open as long as possible.  These attacks can be executed against a QUIC endpoint by generating the minimum amount of activity necessary to avoid being closed for inactivity.  This might involve sending small amounts of data, gradually opening flow control windows in order to control the sender rate, or manufacturing ACK frames that simulate a high loss rate. </ins>  <ins> QUIC deployments SHOULD provide mitigations for the Slowloris attacks, such as increasing the maximum number of clients the server will allow, limiting the number of connections a single IP address is allowed to make, imposing restrictions on the minimum transfer speed a connection is allowed to have, and restricting the length of time an endpoint is allowed to stay connected. </ins>  <ins> 21.7. </ins>  <ins> 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. </ins>  <ins> An adversarial receiver might intentionally not acknowledge packets containing stream data in an attempt to force the sender to store the unacknowledged stream data for retransmission. </ins>  <ins> The attack on receivers is mitigated if flow control windows correspond to available memory.  However, some receivers will over- commit memory and advertise flow control offsets in the aggregate that exceed actual available memory.  The over-commitment strategy can lead to better performance when endpoints are well behaved, but renders endpoints vulnerable to the stream fragmentation attack. </ins>  <ins> QUIC deployments SHOULD provide mitigations against stream fragmentation attacks.  Mitigations could consist of avoiding over- committing memory, limiting the size of tracking data structures, delaying reassembly of STREAM frames, implementing heuristics based on the age and duration of reassembly holes, or some combination. </ins>  <ins> 21.8. </ins>  <ins> An adversarial endpoint can open a large number of streams, exhausting state on an endpoint.  The adversarial endpoint could repeat the process on a large number of connections, in a manner similar to SYN flooding attacks in TCP. </ins>  <ins> Normally, clients will open streams sequentially, as explained in stream-id.  However, when several streams are initiated at short intervals, loss or reordering may cause STREAM frames that open streams to be received out of sequence.  On receiving a higher- numbered stream ID, a receiver is required to open all intervening streams of the same type; see stream-recv-states.  Thus, on a new connection, opening stream 4000000 opens 1 million and 1 client- initiated bidirectional streams. </ins>  <ins> The number of active streams is limited by the initial_max_streams_bidi and initial_max_streams_uni transport parameters, 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. </ins>  <ins> 21.9. </ins>  <ins> QUIC and TLS both contain frames or messages that have legitimate uses in some contexts, but that can be abused to cause a peer to expend processing resources without having any observable impact on the state of the connection. </ins>  <ins> Messages can also be used to change and revert state in small or inconsequential ways, such as by sending small increments to flow control limits. </ins>  <ins> If processing costs are disproportionately large in comparison to bandwidth consumption or effect on state, then this could allow a malicious peer to exhaust processing capacity. </ins>  <ins> While there are legitimate uses for all messages, implementations SHOULD track cost of processing relative to progress and treat excessive quantities of any non-productive packets as indicative of an attack.  Endpoints MAY respond to this condition with a connection error, or by dropping packets. </ins>  <ins> 21.10. </ins>  <ins> 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. </ins>  <ins> An on-the-side 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 off-path 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. </ins>  <ins> 21.11. </ins>  <ins> Stateless resets create a possible denial of service attack analogous to a TCP reset injection.  This attack is possible if an attacker is able to cause a stateless reset token to be generated for a connection with a selected connection ID.  An attacker that can cause this token to be generated can reset an active connection with the same connection ID. </ins>  <ins> If a packet can be routed to different instances that share a static key, for example by changing an IP address or port, then an attacker can cause the server to send a stateless reset.  To defend against this style of denial of service, endpoints that share a static key for stateless reset (see reset-token) MUST be arranged so that packets with a given connection ID always arrive at an instance that has connection state, unless that connection is no longer active. </ins>  <ins> More generally, servers MUST NOT generate a stateless reset if a connection with the corresponding connection ID could be active on any endpoint using the same static key. </ins>  <ins> In the case of a cluster that uses dynamic load balancing, it is possible that a change in load balancer configuration could occur while an active instance retains connection state.  Even if an instance retains connection state, the change in routing and resulting stateless reset will result in the connection being terminated.  If there is no chance of the packet being routed to the correct instance, it is better to send a stateless reset than wait for the connection to time out.  However, this is acceptable only if the routing cannot be influenced by an attacker. </ins>  <ins> 21.12. </ins>  <ins> This document defines QUIC Version Negotiation packets in version- negotiation that can be used to negotiate the QUIC version used between two endpoints.  However, this document does not specify how this negotiation will be performed between this version and subsequent future versions.  In particular, Version Negotiation packets do not contain any mechanism to prevent version downgrade attacks.  Future versions of QUIC that use Version Negotiation packets MUST define a mechanism that is robust against version downgrade attacks. </ins>  <ins> 21.13. </ins>  <ins> Deployments should limit the ability of an attacker to target a new connection to a particular server instance.  This means that client- controlled fields, such as the initial Destination Connection ID used on Initial and 0-RTT packets SHOULD NOT be used by themselves to make routing decisions.  Ideally, routing decisions are made independently of client-selected values; a Source Connection ID can be selected to route later packets to the same server. </ins>  <ins> 21.14. </ins>  <ins> The length of QUIC packets can reveal information about the length of the content of those packets.  The PADDING frame is provided so that endpoints have some ability to obscure the length of packet content; see frame-padding. Note however that defeating traffic analysis is challenging and the subject of active research.  Length is not the only way that information might leak.  Endpoints might also reveal sensitive information through other side channels, such as the timing of packets. </ins> 22.