diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index eb67b9670c..c324939e9d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -6421,764 +6421,769 @@ the CONNECTION_CLOSE frame with a type of 0x1d ({{frame-connection-close}}). # Security Considerations -## Handshake Denial of Service {#handshake-dos} +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. -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. +## Overview of Security Properties {#security-properties} -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. +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. -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. +QUIC assumes the threat model described in {{?SEC-CONS=RFC3552}} and provides +protections against many of the attacks that arise from that model. -Addresses cannot change during the handshake, so endpoints can discard packets -that are received on a different network path. +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. -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. +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. -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. +Properties of the handshake, protected packets, and connection migration are +considered separately. -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. +### Handshake {#handshake-properties} +The QUIC handshake incorporates the TLS 1.3 handshake and inherits the +cryptographic properties described in Appendix E.1 of {{?TLS13=RFC8446}}. Many +of the security properties of QUIC depend on the TLS handshake providing these +properties. Any attack on the TLS handshake could affect QUIC. -## Amplification Attack +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. -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. +An attack on the integrity of the TLS handshake might allow an attacker to +affect the selection of application protocol or QUIC version. -Servers SHOULD provide mitigations for this attack by limiting the usage and -lifetime of address validation tokens; see {{validate-future}}. +In addition to the properties provided by TLS, the QUIC handshake provides some +defense against DoS attacks on the handshake. -## Optimistic ACK Attack +#### Anti-Amplification -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}}. +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. +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. -## Request Forgery Attacks -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. +#### Server-Side DoS -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. +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. -For example, cross-site request forgery {{?CSRF=DOI.10.1145/1455770.1455782}} -exploits on the Web cause a client to issue requests that include authorization -cookies {{?COOKIE=RFC6265}}, allowing one site access to information and -actions that are intended to be restricted to a different site. -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. +#### On-Path Handshake Termination -This section discusses ways in which QUIC might be used for request forgery -attacks. +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. -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. +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. -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. -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. +#### Parameter Negotiation +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. -### Control Options for Endpoints +Connection IDs are unencrypted but integrity protected in all packets. -QUIC offers some opportunities for an attacker to influence or control where -its peer sends UDP datagrams: +This version of QUIC does not incorporate a version negotiation mechanism; +implementations of incompatible versions will simply fail to establish a +connection. -* initial connection establishment ({{handshake}}), where a server is able to - choose where a client sends datagrams, for example by populating DNS records; -* preferred addresses ({{preferred-address}}), where a server is able to choose - where a client sends datagrams; and +### Protected Packets {#protected-packet-properties} -* spoofed connection migrations ({{address-spoofing}}), where a client is able - to use source address spoofing to select where a server sends subsequent - datagrams. +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. -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}}. +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. -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}}. +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. -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. +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. -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. +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. -### Request Forgery with Client Initial Packets +### Connection Migration {#migration-properties} -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. +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. -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. +This section describes the intended security properties of connection migration +when under various types of DoS attacks. -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. -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. +#### On-Path Active Attacks -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. +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. -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. +An on-path attacker can: +- Inspect packets +- Modify IP and UDP packet headers +- Inject new packets +- Delay packets +- Reorder packets +- Drop packets +- Split and merge datagrams along packet boundaries -### Request Forgery with Preferred Addresses {#forgery-spa} +An on-path attacker cannot: -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. +- Modify an authenticated portion of a packet and cause the recipient to accept + that packet -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. +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. -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. +In the presence of an on-path attacker, QUIC aims to provide the following +properties: +1. 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. -### Request Forgery with Spoofed Migration +2. 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. -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. +3. An on-path attacker cannot prevent a client from migrating to a path for + which the attacker is not on-path. -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. +4. An on-path attacker can reduce the throughput of a connection by delaying + packets or dropping them. -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. +5. An on-path attacker cannot cause an endpoint to accept a packet for which it + has modified an authenticated portion of that packet. -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=RFC2827}}, are especially effective -against attacks that use spoofing and originate from an external network. +#### Off-Path Active Attacks -### Generic Request Forgery Countermeasures {#forgery-generic} +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. -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. +An off-path attacker can: -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. +- Inspect packets +- Inject new packets +- Reorder injected packets -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. +An off-path attacker cannot: -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. +- Modify any part of a packet +- Delay packets +- Drop packets +- Reorder original packets -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. +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. -Note: +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. -: 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. +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. +In the presence of an off-path attacker, QUIC aims to provide the following +properties: -## Slowloris Attacks +1. An off-path attacker can race packets and attempt to become a "limited" + on-path attacker. -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. +2. 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. -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. +3. An off-path attacker cannot cause a connection to close once the handshake + has completed. +4. An off-path attacker cannot cause migration to a new path to fail if it + cannot observe the new path. -## Stream Fragmentation and Reassembly Attacks +5. 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. -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. +6. 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. -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. -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. +#### Limited On-Path Active Attacks -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. +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. +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. -## Stream Commitment Attack +A limited on-path attacker can: -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. +- Inspect packets +- Inject new packets +- Modify unencrypted packet headers +- Reorder packets -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. +A limited on-path attacker cannot: -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. +- Delay packets so that they arrive later than packets sent on the original path +- Drop packets +- Modify the authenticated and encrypted portion of a packet and cause the + recipient to accept that packet +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. -## Peer Denial of Service {#useless} +In the presence of a limited on-path attacker, QUIC aims to provide the +following properties: -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. +1. A limited on-path attacker cannot cause a connection to close once the + handshake has completed. -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. +2. A limited on-path attacker cannot cause an idle connection to close if the + client is first to resume activity. -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. +3. A limited on-path attacker can cause an idle connection to be deemed lost if + the server is the first to resume activity. -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. +Note that these guarantees are the same guarantees provided for any NAT, for the +same reasons. -## Explicit Congestion Notification Attacks {#security-ecn} +## Handshake Denial of Service {#handshake-dos} -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. +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. -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}}. +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. +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. -## Stateless Reset Oracle {#reset-oracle} +Addresses cannot change during the handshake, so endpoints can discard packets +that are received on a different network path. -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. +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. -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. +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. -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. +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. -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. +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. -## Version Downgrade {#version-downgrade} +## Amplification Attack -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. +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}}. -## Targeted Attacks by Routing -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. +## Optimistic ACK Attack +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}}. -## Traffic Analysis -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}}. +## Request Forgery Attacks -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. +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. +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. -## Overview of Security Properties {#security-properties} +For example, cross-site request forgery {{?CSRF=DOI.10.1145/1455770.1455782}} +exploits on the Web cause a client to issue requests that include authorization +cookies {{?COOKIE=RFC6265}}, allowing one site access to information and +actions that are intended to be restricted to a different site. -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. +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. -QUIC assumes the threat model described in {{?SEC-CONS=RFC3552}} and provides -protections against many of the attacks that arise from that model. +This section discusses ways in which QUIC might be used for request forgery +attacks. -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. +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. -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. +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. -Properties of the handshake, protected packets, and connection migration are -considered separately. +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. -### Handshake {#handshake-properties} +### Control Options for Endpoints -The QUIC handshake incorporates the TLS 1.3 handshake and inherits the -cryptographic properties described in Appendix E.1 of {{?TLS13=RFC8446}}. Many -of the security properties of QUIC depend on the TLS handshake providing these -properties. Any attack on the TLS handshake could affect QUIC. +QUIC offers some opportunities for an attacker to influence or control where +its peer sends UDP datagrams: -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. +* initial connection establishment ({{handshake}}), where a server is able to + choose where a client sends datagrams, for example by populating DNS records; -An attack on the integrity of the TLS handshake might allow an attacker to -affect the selection of application protocol or QUIC version. +* preferred addresses ({{preferred-address}}), where a server is able to choose + where a client sends datagrams; and -In addition to the properties provided by TLS, the QUIC handshake provides some -defense against DoS attacks on the handshake. +* spoofed connection migrations ({{address-spoofing}}), where a client is able + to use source address spoofing to select where a server sends subsequent + datagrams. +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}}. -#### Anti-Amplification +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}}. -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. +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. -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. +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. -#### Server-Side DoS +### Request Forgery with Client Initial Packets -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. +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. +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. -#### On-Path Handshake Termination +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. -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. +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. -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. +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. +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. -#### Parameter Negotiation -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. +### Request Forgery with Preferred Addresses {#forgery-spa} -Connection IDs are unencrypted but integrity protected in all packets. +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. -This version of QUIC does not incorporate a version negotiation mechanism; -implementations of incompatible versions will simply fail to establish a -connection. +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. +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. -### Protected Packets {#protected-packet-properties} -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. +### Request Forgery with Spoofed Migration -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. +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. -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. +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. -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. +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. -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. +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=RFC2827}}, are especially effective +against attacks that use spoofing and originate from an external network. -### Connection Migration {#migration-properties} +### Generic Request Forgery Countermeasures {#forgery-generic} -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. +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. -This section describes the intended security properties of connection migration -when under various types of DoS attacks. +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. +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. -#### On-Path Active Attacks +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. -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. +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. -An on-path attacker can: +Note: -- Inspect packets -- Modify IP and UDP packet headers -- Inject new packets -- Delay packets -- Reorder packets -- Drop packets -- Split and merge datagrams along packet boundaries +: 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. -An on-path attacker cannot: -- Modify an authenticated portion of a packet and cause the recipient to accept - that packet +## Slowloris Attacks -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. +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. -In the presence of an on-path attacker, QUIC aims to provide the following -properties: +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. -1. 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. -2. 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. +## Stream Fragmentation and Reassembly Attacks -3. An on-path attacker cannot prevent a client from migrating to a path for - which the attacker is not on-path. +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. -4. An on-path attacker can reduce the throughput of a connection by delaying - packets or dropping them. +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. -5. An on-path attacker cannot cause an endpoint to accept a packet for which it - has modified an authenticated portion of that packet. +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. +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. -#### Off-Path Active Attacks -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. +## Stream Commitment Attack -An off-path attacker can: +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. -- Inspect packets -- Inject new packets -- Reorder injected packets +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. -An off-path attacker cannot: +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. -- Modify any part of a packet -- Delay packets -- Drop packets -- Reorder original packets -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. +## Peer Denial of Service {#useless} -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. +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. -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. +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. -In the presence of an off-path attacker, QUIC aims to provide the following -properties: +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. -1. An off-path attacker can race packets and attempt to become a "limited" - on-path attacker. +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. -2. 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. -3. An off-path attacker cannot cause a connection to close once the handshake - has completed. +## Explicit Congestion Notification Attacks {#security-ecn} -4. An off-path attacker cannot cause migration to a new path to fail if it - cannot observe the new path. +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. -5. 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. +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}}. -6. 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. +## Stateless Reset Oracle {#reset-oracle} -#### Limited On-Path Active Attacks +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. -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. +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. -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. +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. -A limited on-path attacker can: +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. -- Inspect packets -- Inject new packets -- Modify unencrypted packet headers -- Reorder packets -A limited on-path attacker cannot: +## Version Downgrade {#version-downgrade} -- Delay packets so that they arrive later than packets sent on the original path -- Drop packets -- Modify the authenticated and encrypted portion of a packet and cause the - recipient to accept that packet +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. -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. -In the presence of a limited on-path attacker, QUIC aims to provide the -following properties: +## Targeted Attacks by Routing -1. A limited on-path attacker cannot cause a connection to close once the - handshake has completed. +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. -2. A limited on-path attacker cannot cause an idle connection to close if the - client is first to resume activity. -3. A limited on-path attacker can cause an idle connection to be deemed lost if - the server is the first to resume activity. +## Traffic Analysis -Note that these guarantees are the same guarantees provided for any NAT, for the -same reasons. +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. # IANA Considerations {#iana}