]> Mozilla

mt@lowentropy.net

Cloudflare

lucaspardue.24.7@gmail.com

Applications and Real-Time HTTP next generation unicorn sparkling distributed ledger A variant mechanism for managing stream limits is described for HTTP/2. This scheme is based on that used in QUIC and is more robust against certain patterns of abuse. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the HTTP Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction HTTP/2 allows endpoints to declare the concurrency limit for streams created by their peer (SETTINGS_MAX_CONCURRENT_STREAMS; see ). Initially, the stream concurrency limit is only bounded by the maximum number of streams that can be created, which is 2³⁰ for each endpoint, but the value can be changed at any time. Most endpoints set a smaller value in an attempt to protect the resources that are committed when processing a stream. This limit is not effective in the case that streams are quickly cancelled. The creator of a stream can cancel it using the RST_STREAM frame. The creator of a stream could also cause its peer to send RST_STREAM by purposefully sending frames that violate HTTP/2 rules, unless errors also cause the peer to close the connection. Either of these methods has deterministic and immediate effect, which means that the stream no longer counts against the concurrent stream limit. This means that a malicious endpoint can create or cancel an unbounded number of streams as long as its peer does not set a limit of zero. For clarity, we'll refer to either of these methods as "cancelling". If the creation of the stream results in the expenditure of resources, rapidly creating and cancelling streams can exhaust resources. For a server, clients that create and cancel many requests can effectively deny service; for a client, reserving and cancelling promised streams might have similar effect if a client does not disable server push using the SETTINGS_ENABLE_PUSH setting. This creates a denial of service exposure for which a remedy is not supported in the protocol. However, as noted in , many of the features in HTTP/2 that have some potential to create denial of service attacks also have constructive uses. Distinguishing constructive and destructive uses is often challenging. Some applications of HTTP might find that cancelling many requests is necessary; if cancellation is treated as abusive, it is possible that the treatment necessary to prevent attacks might unintentionally punish some clients. The QUIC protocol on which HTTP/3 is built contains an alternative mechanism for limiting concurrency. The scheme in QUIC, as described in , does not set a concurrent stream limit, but instead relies on a peer increasing the maximum allowed stream identifier. An endpoint cannot create new streams immediately after cancelling an open stream; their peer needs to send a message to make more streams available. In QUIC therefore, a malicious endpoint can only create and cancel a finite number of streams, after which their peer needs to provide consent to continue. This document ports the QUIC stream concurrency limit mechanisms to HTTP/2. As use of this system is voluntary and therefore not necessarily guaranteed, this does not prevent abusive use of stream cancellation. However, deployment of this mechanism in popular implementations might allow endpoints to deploy more aggressive strategies for managing abuse in its absence.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The HTTP/2 MAX_STREAMS Frame The MAX_STREAMS frame (type=0xTBD) is used to limit the streams that a recipient is permitted to create. The format of the MAX_STREAMS frame is illustrated in , using the notation defined in .

MAX_STREAMS Frame Format

In addition to the common HTTP/2 frame header (see ), the MAX_STREAMS contains a one-bit reserved field and a 31-bit Maxmimum Stream Identifier field. The Reserved field MUST be set to zero when sending and ignored on receipt. The Maximum Stream Identifier field contains the maximum value of stream identifier that a recipient of this frame can use when it creates or reserves a stream; see for how streams are created. A MAX_STREAMS frame MUST be sent on stream 0. Receipt of a MAX_STREAMS frame on any other stream MUST be treated as a connection error of type PROTOCOL_ERROR; see . An endpoint MUST treat receipt of a MAX_STREAMS frame with a length other than 4 as a connection error of type FRAME_SIZE_ERROR; see . A client MUST treat receipt of an even-numbered Maximum Stream Identifier as a connection error of type PROTOCOL_ERROR; see , with an exception of a value of 0, which can be used to indicate support for the feature without enabling the creation of streams (see ). Similarly, a server MUST treat receipt of an odd-numbered Maximum Stream Identifier as a connection error.

Applying Stream Limits An endpoint that receives a MAX_STREAMS frame MUST NOT create or reserve a stream with a number that exceeds the value of the Maximum Stream Identifier field from that frame, until it receives a MAX_STREAMS frame with a larger value. An endpoint MUST treat the creation or reservation of a stream with a higher valued stream identifier than it included in a MAX_STREAMS frame as a connection error of type FLOW_CONTROL_ERROR; see . Endpoints can only increase the value that they include in a MAX_STREAMS frame. An endpoint MUST treat receipt of a Maximum Stream Identifier that is equal to or smaller than a value that it has previously received as a connection error of type PROTOCOL_ERROR; see . Note that a value of 0 can be sent one time by either client or server to indicate support for this feature without permitting the creation of streams; see . An implementation can support a similar concurrency limit to that provided by SETTINGS_MAX_CONCURRENT_STREAMS. The initial value can be set to twice the value of SETTINGS_MAX_CONCURRENT_STREAMS, with a client adding 1 if the value is non-zero. The endpoint then increases the value of the Maximum Stream Identifier field as the streams its peer initiates are closed. An endpoint can avoid sending redundant MAX_STREAMS frames by processing all incoming data before increasing the maximum. This approach differs from SETTINGS_MAX_CONCURRENT_STREAMS in that a peer is not able to create and cancel streams arbitrarily, as new streams do not become available until after receiving a MAX_STREAMS frame.

Negotiating MAX_STREAMS Usage This extension is not negotiated using the SETTINGS frame. Instead, the receipt of a MAX_STREAMS frame indicates support for the feature. An endpoint that supports this extension MUST send a MAX_STREAMS frame after establishing a connection, after the HTTP/2 connection preface (). When a MAX_STREAMS frame is received, the endpoint MUST subsequently only create streams according to the rules in and ignore any value of the SETTINGS_MAX_CONCURRENT_STREAMS setting.

Security Considerations HTTP/2 considered the cancellation of a stream to reclaim the resources that might have been committed during its creation. The stream limits in HTTP/2 therefore did not provide a means to limit stream creation. Though cancellation is a potential source of abusive traffic, it was not explicitly mentioned (see ). However, experience has shown that the creation of a stream has costs that cannot always be recovered when that stream is cancelled. The use of the MAX_STREAMS frame provides endpoints with a means of limiting stream creation, using a method that has proven to be effective in QUIC. However, repeated use of the MAX_STREAMS frame is also a potential source of abuse, as described in . Though processing a MAX_STREAMS frame is likely to be trivial, receiving significantly more MAX_STREAMS frames than the number of streams that have been closed might indicate an attempt to waste effort.

IANA Considerations This document registers a new entry in the "HTTP/2 Frame Type" registry, as documented in . This entry has the following values.

Frame Type:

MAX_STREAMS

Code:

0xTBD

Specification:

References Normative References This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.

Acknowledgments This document is written in response to the problems discovered as part of , so maybe those behind the botnet responsible for that attack deserve some credit.