]> Meta Platforms, Inc.

ietf@bemasc.net

wit httpbis TCP tunneling using HTTP CONNECT has long been part of the core HTTP specification. However, this tunneling functionality has several important deficiencies due to the lack of a well-defined HTTP origin or path. This specification remedies those deficiencies by defining CONNECT-TCP, an alternative protocol for tunneling TCP in HTTP. A proxy service for this protocol is described by a URI Template, similar to the CONNECT-UDP and CONNECT-IP protocols.

Introduction

History HTTP has used the CONNECT method for tunneling TCP connections since HTTP/1.1. When using CONNECT, the request target specifies a host and port number, and the proxy forwards TCP payloads between the client and the target destination (). Prior to this specification, this was the only mechanism defined for proxying TCP over HTTP. In this specification, this arrangement is referred to as a "classic HTTP CONNECT proxy". HTTP/3 uses a UDP transport, so it cannot be forwarded using the pre-existing CONNECT mechanism. To enable forward proxying of HTTP/3, the MASQUE effort has defined proxy mechanisms that are capable of tunneling UDP datagrams , and more generally IP datagrams . The destination host and port number (if applicable) are encoded into the HTTP resource path, and end-to-end datagrams are wrapped into HTTP Datagrams on the client-proxy path.

Problems HTTP clients can be configured to use proxies by selecting a proxy hostname, a port number, and whether to use a security protocol. However, classic HTTP CONNECT requests using the proxy do not carry this configuration information. Instead, they only indicate the hostname and port of the target. This prevents any HTTP server from hosting multiple distinct proxy services, as the server cannot distinguish them by path (as with distinct resources) or by origin (as in "virtual hosting"). The absence of an explicit origin for the proxy also rules out the usual defenses against server port misdirection attacks (see ) and creates ambiguity about the use of origin-scoped response header fields (e.g., Alt-Svc or Strict-Transport-Security ). Classic HTTP CONNECT requests are not extensible to carry in-stream metadata. For example, the WRAP_UP capsule cannot be used with classic HTTP CONNECT.

Overview This specification describes an alternative mechanism for tunneling TCP in HTTP. Like and , the proxy service is identified by a URI Template. Proxy interactions reuse standard HTTP components and semantics, avoiding changes to the core HTTP protocol.

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. In this document, the term "proxy" refers to the HTTP server that acts upon a client's TCP tunneling request. If there are HTTP intermediaries (as defined in Section 3.7 of [HTTP]) between the client and the proxy, those are referred to as "intermediaries" or "gateways" in this document. The term "endpoint" describes an implementation of this specification in either client or proxy role. The protocol defined in this specification is termed "CONNECT-TCP". The term "CONNECT-TCP proxy" refers to a proxy that is identified by a URI Template for CONNECT-TCP.

Specification A template-driven TCP transport proxy for HTTP is identified by a URI Template containing variables named "target_host" and "target_port". This URI Template and its variable values MUST meet all the same requirements as for UDP proxying (Sections and of ), and are subject to the same validation rules. Clients MUST substitute the destination host and port number into this template to produce a request URI. The derived URI serves as the destination of a Capsule Protocol connection using the Upgrade Token "connect-tcp" (see registration in ). If the request is well-formed and permissible, the proxy MUST attempt to establish the TCP connection before sending a final success or failure response.

Payload Transport When using CONNECT-TCP, TCP payload data is sent in the payload of new Capsule Types named DATA and FINAL_DATA (see and registrations in ). The ordered concatenation of these capsule payloads, which MAY be empty, represents the TCP payload data. A FINAL_DATA capsule additionally indicates that the sender has closed this stream, semantically equivalent to TCP FIN. After sending a FINAL_DATA capsule, an endpoint MUST NOT send any more DATA or FINAL_DATA capsules on this data stream. See for related requirements.

DATA and FINAL_DATA Capsule Formats, using notation from Section 1.3 of [QUIC]

The boundaries between DATA and FINAL_DATA capsules are not significant, and are not expected to match TCP segments, TLS records, HTTP DATA frames, QUIC STREAM frames, etc. Recipients SHOULD begin forwarding payload from a DATA or FINAL_DATA capsule without waiting to receive the entire capsule, especially if the capsule is large. An intermediary MAY merge and split successive DATA and FINAL_DATA capsules, subject to the following requirements:

• There are no intervening capsules of other types.
• The order of payload content is preserved.
• The final emitted capsule uses the same capsule type (DATA or FINAL_DATA) as the final input capsule, and all others use the DATA capsule type.

For example, an intermediary holding two successive DATA capsules in its transmission buffer could merge them, saving at least 2 bytes of encapsulation overhead when they are forwarded. This protocol supports backward-compatible extensions via additional Capsule Types, as described in .

In HTTP/1.1 In HTTP/1.1 , the client uses the proxy by issuing a request as follows:

• The method SHALL be GET.
• The request's target SHALL correspond to the URI derived from expansion of the proxy's URI Template.
• The request SHALL include a single Host header field whose value identifies the proxy.
• The request SHALL include a Connection header field with the value "Upgrade". (Note that this requirement is case-insensitive as per .)
• The request SHALL include an Upgrade header field with the value "connect-tcp".
• The request SHOULD include a "Capsule-Protocol: ?1" header field (as recommended in ).

If the TCP connection is successful, the response SHALL be as follows:

• The HTTP status code SHALL be 101 (Switching Protocols).
• The response SHALL include a Connection header field with the value "Upgrade".
• The response SHALL include a single Upgrade header field with the value "connect-tcp".
• The response SHOULD include a "Capsule-Protocol: ?1" header field (as above).

If a TCP connection was not established, the proxy MUST NOT switch protocols to CONNECT-TCP, and the client MAY reuse this connection for additional HTTP requests.

CONNECT-TCP in HTTP/1.1: Example request for a connection to 192.0.2.1:443 via https://example.com/proxy{?target_host,target_port}

CONNECT-TCP in HTTP/1.1: Initial response

CONNECT-TCP in HTTP/1.1: Final success response

In HTTP/2 and HTTP/3 In HTTP/2 and HTTP/3, the proxy MUST include SETTINGS_ENABLE_CONNECT_PROTOCOL in its SETTINGS frame . The client uses the proxy by issuing an "extended CONNECT" request as follows:

• The :method pseudo-header field SHALL be CONNECT.
• The :protocol pseudo-header field SHALL be "connect-tcp".
• The :authority pseudo-header field SHALL contain the authority of the proxy.
• The :path and :scheme pseudo-header fields SHALL contain the path and scheme of the request URI derived from the proxy's URI Template.

A CONNECT-TCP request that does not conform to all of these requirements represents a client error (see ) and may be malformed (see and ). Additionally, the Capsule-Protocol header field SHOULD be present with a value of "?1" (as recommended in ).

CONNECT-TCP in HTTP/2: Example request to [2001:db8::1]:443

Use of Other Relevant Headers

Origin-scoped Headers Ordinary HTTP headers apply only to the single resource identified in the request or response. An origin-scoped HTTP header is a special response header that is intended to change the client's behavior for subsequent requests to any resource on this origin. Unlike classic HTTP CONNECT proxies, a CONNECT-TCP proxy has an unambiguous origin of its own. Origin-scoped headers apply to this origin when they are associated with a CONNECT-TCP response. Here are some origin-scoped headers that could potentially be sent by a CONNECT-TCP proxy:

• Alt-Svc
• Strict-Transport-Security
• Accept-CH
• Set-Cookie , which has configurable scope.
• Clear-Site-Data

Authentication Headers Authentication to a CONNECT-TCP proxy normally uses ordinary HTTP authentication via the 401 (Unauthorized) response code, the WWW-Authenticate response header field, and the Authorization request header field (). A CONNECT-TCP proxy does not use the 407 (Proxy Authentication Required) status code and related header fields () because they do not traverse HTTP gateways (see ). Clients SHOULD assume that all proxy resources generated by a single template share a protection space (i.e., a realm) (). For many authentication schemes, this will allow the client to avoid waiting for a 401 (Unauthorized) response before each new connection through the proxy. TLS Client Certificate authentication can also be used (see ).

Caching Headers In HTTP/2 and HTTP/3, this specification uses the CONNECT method, which is not subject to caching (). However, in HTTP/1.1, the method is GET, which in other usages can be cacheable. To minimize discrepancies between HTTP versions, the following requirements apply when using HTTP/1.1:

• If the response has a heuristically cacheable status code (), it SHOULD also carry a "Cache-Control: no-store" header field ().
  • This can occur if the request is rejected or the connection fails.
• The proxy SHOULD NOT attach any other caching-related header fields to the response.

Closing Connections Connection termination is essentially symmetrical for proxies and their clients, which we refer to here as the "endpoints" of a request. When closing connections, endpoints are subject to the following requirements:

• When an endpoint receives a valid TCP FIN, it MUST send a FINAL_DATA capsule.
• When an endpoint receives a valid FINAL_DATA capsule, it MUST send a TCP FIN.
• When a TCP connection reaches the TIME-WAIT or CLOSED state, the associated endpoint MUST close its send stream.
  • If the connection closed gracefully, the endpoint MUST close the send stream gracefully.
  • Otherwise, the endpoint SHOULD close the send stream abruptly, using a mechanism appropriate to the HTTP version:
    • HTTP/3: reset the stream with H3_CONNECT_ERROR; see and .
    • HTTP/2: reset the stream with CONNECT_ERROR; see , Sections 6.4 and 7.
    • HTTP/1.1 over TLS: TCP shutdown without a TLS closure alert; see .
    • HTTP/1.1 without TLS: TCP RST.
• When the receive stream is closed abruptly or without a FINAL_DATA capsule received, the endpoint SHOULD send a TCP RST if the TCP subsystem permits it.

Any locally imposed timeout () MUST be treated as an abrupt closure of the affected stream or connection. The mandatory behaviors above enable endpoints to detect any truncation of incoming TCP data. The recommended behaviors propagate any TCP errors through the tunnel. In HTTP/3, endpoints MAY negotiate and use the RESET_STREAM_AT frame in order to reduce data loss during an abrupt closure . However, RESET_STREAM_AT may not be very effective in this case, as TCP implementations will typically discard pending data when a RST is received.

Simple graceful termination example (HTTP/3) +--------DATA{"abc"}------->+---"abc"--->| +----FIN---->+------FINAL_DATA{""}------>+----FIN---->| |<---FIN-----+<-----FINAL_DATA{""}-------+<---FIN-----+ | |<----QUIC.STREAM{FIN}------+ | +---FINACK-->+-----QUIC.STREAM{FIN}----->| | | | | | ]]>

Simple TCP RST termination example (HTTP/2) +----RST_STREAM{CON_ERR}--->+----RST---->| | | | | ]]>

Timeout example (HTTP/1.1) +--------DATA{"abc"}------->+---"abc"--->| | | (... timeout @ A ...) | | | +--FIN (no close_notify) -->+----RST---->| | | | | ]]>

RST after FIN example (HTTP/3) +-------FINAL_DATA{""}----->+-----FIN--->| | | | | | (FIN) | | (FIN) | |<---"abc"---+<----FINAL_DATA{"abc"}-----+<---"abc"---+ | |<----QUIC.STREAM{FIN}------+ | +-----RST--->+-----H3_CONNECT_ERROR----->+-----RST--->| | | | | ]]>

Handling Invalid Data An endpoint that receives invalid data from its peer is subject to the same requirements as when receiving an abrupt closure of the receive stream (see ). Some examples of invalid data include:

• A second FINAL_DATA capsule.
• A DATA capsule after FINAL_DATA.
• Data that results in a parsing error under the Capsule Protocol.
• A capsule that is truncated by the end of the stream.
• A capsule that would require unreasonable effort to process.

Note that very large DATA and FINAL_DATA capsules are still valid, as they can be forwarded incrementally using a bounded memory buffer.

Additional Connection Setup Behaviors This section discusses some behaviors that are permitted or recommended in order to enhance the performance or functionality of connection setup.

Latency Optimizations When using this specification in HTTP/2 or HTTP/3, clients MAY start sending TCP stream content optimistically, subject to flow control limits ( or ). Proxies MUST buffer this "optimistic" content until the TCP stream becomes writable, and discard it if the TCP connection fails. Clients MUST NOT use "optimistic" behavior in HTTP/1.1, as this would interfere with reuse of the connection after an error response such as 401 (Unauthorized). Servers that host a proxy under this specification MAY offer support for TLS early data in accordance with . Clients MAY send CONNECT-TCP requests in early data, and MAY include "optimistic" TCP content in early data (in HTTP/2 and HTTP/3). At the TLS layer, proxies MAY ignore, reject, or accept the early_data extension (). At the HTTP layer, proxies MAY process the request immediately, return a 425 (Too Early) response (), or delay some or all processing of the request until the handshake completes. For example, a proxy with limited anti-replay defenses might choose to perform DNS resolution of target_host when a request arrives in early data, but delay the TCP connection until the TLS handshake completes. When DNS resolution of target_host produces IP addresses from multiple address families, proxies SHOULD use a racing procedure such as Happy Eyeballs to accelerate connection establishment. Proxies that race multiple connection attempts MUST buffer any optimistic content until a connection is selected and MUST NOT transmit any payload data on the other connections.

Indicating Failure Failure to initiate a tunnel is indicated by the HTTP status code. A 4xx status code indicates that the request is malformed or impermissible. For example, if the proxy performs DNS resolution of target_host and receives an IP address that is disallowed by the proxy's policy, it might return 403 (Forbidden). A 5xx status code indicates a failure in the attempt, such as when a TCP connection was attempted but did not succeed. The 502 (Bad Gateway) and 504 (Gateway Timeout) status codes are commonly used. The 429 (Too Many Requests) and 503 (Service Unavailable) status codes indicate a temporary failure, and can carry a Retry-After response header field (). If included, this field applies to all requests using this URI Template.

Conveying Metadata This specification supports the 100 (Continue) status code () in any HTTP version. Proxies SHOULD send this status code whenever they accept a request, without waiting for the proxy-destination TCP handshake to succeed or fail. This allows for a few useful improvements:

• Clients can provide a clearer status indication while waiting for the destination host to respond. (TCP handshakes can hang for several minutes before failing.)
• Clients can apply separate timeouts to the tunneling request and connection establishment.
• In HTTP/2 and HTTP/3, clients have the option to delay some or all of the optimistic payload data until after confirming that the request is permissible. This strategy reduces wasted effort when the request is rejected.

Note that a client in this specification cannot send an "Expect: 100-continue" request header field, because the request does not include any "content" (). Proxies implementing this specification SHOULD include a Proxy-Status response header field in any success or failure response (i.e., status codes 101, 2xx, 4xx, or 5xx) to support advanced client behaviors and diagnostics. Clients and proxies MUST NOT send trailer fields on CONNECT-TCP streams.

Applicability

Servers For server operators, CONNECT-TCP proxies are particularly valuable in situations where virtual-hosting is needed, or where multiple proxies must share an origin. For example, the proxy might benefit from sharing an HTTP gateway that provides DDoS defense, performs request sanitization, or enforces user authorization (). CONNECT-TCP proxies can also be made invisible to probes from unauthorized clients:

• The URI template can include a high-entropy path, similar to Capability URLs .
• The proxy can require HTTP Concealed Authentication ().

Clients This specification does not require any specific type of configuration input. Suitable configuration input types include:

• A URI Template string, as described in .
• An IP address or hostname, with optional or required port and scheme (as often used to describe classic HTTP CONNECT proxies). A corresponding CONNECT-TCP proxy might be found in two ways:
  • At the default template for "connect-tcp" ().
  • In the "proxies" array of a provisioning domain resource retrieved from the corresponding ".well-known" URI (Sections and of ).
• A provisioning domain resource, configured directly or identified by a local or remote URI (e.g., using "file://" or "https://").

Registered default template

All of these input types MAY share a single input string, as they can be disambiguated reliably by parsing and probing. However, it may be preferable to indicate the configuration input type explicitly, to reduce probing delays while supporting clients with differing capabilities. Clients SHOULD treat certain errors during classic HTTP CONNECT as indications that the proxy might only support CONNECT-TCP:

• In HTTP/1.1: the response's status code is 426 (Upgrade Required), with an "Upgrade: connect-tcp" response header.
• In any HTTP version: the response's status code is 501 (Not Implemented).
  • Requires SETTINGS_ENABLE_CONNECT_PROTOCOL to have been negotiated in HTTP/2 or HTTP/3.

If the client infers that classic HTTP CONNECT is not supported, it SHOULD retry the request using the registered default template for "connect-tcp" (). If this request succeeds, the client SHOULD record a preference for CONNECT-TCP to avoid further retry delays.

Gateways CONNECT-TCP requests can traverse standard HTTP gateways to ease implementation and allow use of shared infrastructure. However, current gateways might need modifications to support TCP proxy services. To be compatible, a gateway MUST:

• support Extended CONNECT (if acting as an HTTP/2 or HTTP/3 server).
• support HTTP/1.1 Upgrade to "connect-tcp" (if acting as an HTTP/1.1 server).
  • only after forwarding the upgrade request to the origin and observing a success response.
• forward the "connect-tcp" protocol to the origin.
• convert CONNECT-TCP requests between all supported HTTP server and client versions.
• allow any Proxy-Status headers to traverse the gateway.

If the proxy relies on TLS Client Certificates for client authentication, the gateway MUST perform this authentication itself or pass the relevant information to the origin (e.g., using a Client-Cert request header field ).

Security Considerations CONNECT-TCP is largely subject to the same security risks as classic HTTP CONNECT. For example, any restrictions on authorized use of the proxy (see ) apply equally to both. The "destination_ip_prohibited" Proxy Error Type from can be useful when rejecting unauthorized requests. A small additional risk is posed by the use of a URI Template parser on the client side. The template input string could be crafted to exploit any vulnerabilities in the parser implementation. Client implementers should apply their usual precautions for code that processes untrusted inputs. See for a comparison of the risks of operating a TCP or UDP proxy.

Resource Exhaustion attacks A malicious client can cause highly asymmetric resource usage at the proxy by colluding with a destination server and violating the ordinary rules of TCP or HTTP. Some example attacks, and mitigations that proxies can apply:

• Connection Pileup: A malicious client can attempt to open a large number of connections to exhaust the proxy's memory, port, or file descriptor limits. When using HTTP/2 or HTTP/3, each incremental TCP connection imposes a much higher cost on the proxy than on the attacker.
  • Mitigation: Limit the number of concurrent connections per client.
• Window Bloat: An attacker can grow the receive window size by simulating a "long, fat network" (), then fill the window (from the sender) and stop acknowledging it (at the receiver). This leaves the proxy buffering up to 1 GiB of TCP data until some timeout, while the attacker does not have to retain a large buffer.
  • Mitigation: Limit the maximum receive window for TCP and HTTP connections, and the size of userspace buffers used for forwarding data. Alternatively, monitor the connections' send queues and limit the total buffered data per client.
• WAIT Abuse: An attacker can force the proxy into a TIME-WAIT, CLOSE-WAIT, or FIN-WAIT state until the timer expires, tying up a proxy-to-destination 4-tuple for up to four minutes after the client's connection is closed.
  • Mitigations:
    • Enable the PAWS optimization () across successive connections (e.g., Linux's tcp_tw_reuse=1 ). This makes TIME-WAIT 4-tuples rapidly reusable if the destination enables TCP Timestamps, which most do.
    • Allocate a large range of IP addresses for TCP connections (especially in IPv6).
    • Limit the number of connections for each client to each destination, even if those connections are in a waiting state and the corresponding CONNECT stream is closed.
    • If necessary, perform an abrupt TCP closure that destroys the Transmission Control Block. Note that reusing a 4-tuple in this way can increase the risk of interference between successive connections.

Client Authentication A proxy server operating without access controls on the open internet (an "open proxy") is likely to be discovered and misused quickly by attackers. HTTP client authentication is the most common way to avoid this misuse. describes how to use HTTP client authentication with this specification. Each HTTP client authentication scheme offers distinct security properties, so care should be taken to select an appropriate scheme for each deployment. See for additional guidance related to HTTP authentication.

TLS Early Data This specification supports sending both proxying requests and optimistic payload data in TLS early data (). TLS 1.3 recommends, but does not require, replay protection for this data (), so a replay attack could cause the proxy service to establish multiple connections to the target, and to deliver any optimistic payload data on each of these connections. When such a replay attack would cause harm (e.g., when the optimistic data represents a non-idempotent application command), clients MUST NOT use TLS early data. See for additional relevant security considerations.

Operational Considerations

Avoiding HTTP/1.1 While this specification is fully functional under HTTP/1.1, performance-sensitive deployments SHOULD use HTTP/2 or HTTP/3 instead. When using HTTP/1.1:

• Each CONNECT request requires a new TCP and TLS connection, imposing a higher cost in setup latency, congestion control convergence, CPU time, and data transfer.
• The graceful and abrupt closure signals () are more likely to be missing or corrupted:
  • Some implementations may be unable to emit the recommended abrupt closure signals, due to limitations in their TCP and TLS subsystems.
  • Faulty implementations may fail to send a TLS closure alert during graceful shutdown, or fail to report an error when the expected closure alert is not received. These misbehaviors are not compliant with , but they are common nonetheless among HTTP/1.1 implementations today.
• The number of active connections through each client may be limited by the number of available TCP client ports, especially if:
  • The client only has one IP address that can be used to reach the proxy.
  • The client is shared between many parties, such as when acting as a gateway or concentrator.
  • The tunneled connections are often closed by the destination. This causes the client to initiate closure of the client-to-proxy connection, leaving the client in a TIME-WAIT state for up to four minutes.

Timeouts Except when actively sending or receiving data, an endpoint is always waiting for an event from its peer or its TCP connection. HTTP and TCP are designed to ensure that such an event always arrives, so the connection is never permanently stuck in any state until it is fully closed. However, for efficient operation, it may be necessary to adjust the settings for TCP keep-alives (), QUIC idle timeouts (), HTTP/2 PING frames (), and other transport options. Endpoints MAY impose additional timeouts, especially as a defense against certain resource exhaustion attacks (). However, operators should apply timeouts cautiously to minimize the impact on connections that are functioning but slow. See for related requirements. For example, enabling PING frames on idle HTTP/2 connections allows the operator to prevent some kinds of failures and detect failed connections faster, but it uses more bandwidth, CPU time, and radio power, and increases the risk of false-positive connection failures. Optimal transport settings will depend on the network environment (e.g., mobile vs. fixed), characteristics of the tunneled application, and many other considerations.

Scope of Packet-Level Metadata This specification does not provide a way to pass packet-level metadata such as IPv6 Extension Headers , DiffServ Codepoints (DSCP) , or Explicit Congestion Notification (ECN) marks through the tunnel. TCP options and non-fatal ICMP messages (e.g., Packet Too Big) are similarly not relayed. Instead, these signals are processed by the relevant endpoint of this specification, which is also the TCP endpoint and only relays payload data through the tunnel. Consumption and generation of these signals on each connection is controlled by the endpoint, and is independent from any behaviors of the other endpoint and any similar signals on the tunnel's HTTP connection. If the operator has requirements related to these behaviors, it must configure the relevant endpoint (typically the proxy) accordingly.

IP address sharing A TCP proxy typically uses the same IP address to establish connections on behalf of multiple clients, especially in IPv4. provides guidance regarding difficulties that can arise from IP address sharing, including in this arrangement.

Diagnostics and Monitoring A proxy in this protocol reports success or failure in each response via the HTTP status code and the Proxy-Status response header field. Monitoring those error codes is a sensible way to assess the functioning of a proxy server. Other relevant performance indicators may include:

• Abrupt closure rates
• Number of active tunnels per user
• Total throughput in each direction
• Number of bytes buffered
• Connection duration
• Time spent establishing or closing connections
• Number of half-closed or WAIT-state connections
• DNS resolution delay

An increase in any of these measures could indicate an operational problem or a resource exhaustion attack (). See for guidance on relevant defenses and limits.

IANA Considerations

New Upgrade Token IANA is requested to add the following entry to the "HTTP Upgrade Tokens" registry under "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" registry group:

Value	Description	Expected Version Tokens	Reference
"connect-tcp"	Proxying of TCP payloads	(None)	(This document)

Interop testing For interoperability testing of this draft version, implementations SHALL use the value "connect-tcp-12".

New MASQUE Default Template IANA is requested to add the following entry to the "MASQUE URI Suffixes" registry under "Multiplexed Application Substrate over QUIC Encryption (MASQUE)" registry group:

Path Segment	Description	Reference
tcp	TCP Proxying	(This document)

New Capsule Type IANA is requested to add the following entry to the "HTTP Capsule Types" registry under "Multiplexed Application Substrate over QUIC Encryption (MASQUE)" registry group:

Value	Capsule Type	Status	Reference	Change Controller	Contact
0x08	DATA	permanent	(This document),	IETF	HTTPBIS
0x09	FINAL_DATA	permanent	(This document),	IETF	HTTPBIS

References Normative References The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. 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. 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. This document describes how to proxy UDP in HTTP, similar to how the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy. 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. A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK] This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections. HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection. The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP-version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3. 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. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay. This document defines the Proxy-Status HTTP response field to convey the details of an intermediary's response handling, including generated errors. This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. Informative References This document describes how to proxy IP packets in HTTP. This protocol is similar to UDP proxying in HTTP but allows transmitting arbitrary IP packets. More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an HTTP server that acts as an IP proxy. This document updates RFC 9298. This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK] Google LLC Cloudflare HTTP intermediaries sometimes need to terminate long-lived request streams in order to facilitate load balancing or impose data limits. However, Web browsers commonly cannot retry failed proxied requests when they cannot ascertain whether an in-progress request was acted on. To avoid user-visible failures, it is best for the intermediary to inform the client of upcoming request stream terminations in advance of the actual termination so that the client can wrap up existing operations related to that stream and start sending new work to a different stream or connection. This document specifies a new "WRAP_UP" capsule that allows a proxy to instruct a client that it should not start new requests on a tunneled connection, while still allowing it to finish existing requests. HTTP defines proactive content negotiation to allow servers to select the appropriate response for a given request, based upon the user agent's characteristics, as expressed in request headers. In practice, user agents are often unwilling to send those request headers, because it is not clear whether they will be used, and sending them impacts both performance and privacy. This document defines an Accept-CH response header that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK] The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. Fastly QUIC defines a RESET_STREAM frame to abort sending on a stream. When a sender resets a stream, it also stops retransmitting STREAM frames for this stream in the event of packet loss. On the receiving side, there is no guarantee that any data sent on that stream is delivered. This document defines a new QUIC frame, the RESET_STREAM_AT frame, that allows resetting a stream, while guaranteeing delivery of stream data up to a certain byte offset. Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555. Most HTTP authentication schemes are probeable in the sense that it is possible for an unauthenticated client to probe whether an origin serves resources that require authentication. It is possible for an origin to hide the fact that it requires authentication by not generating Unauthorized status codes; however, that only works with non-cryptographic authentication schemes: cryptographic signatures require a fresh nonce to be signed. Prior to this document, there was no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication. This document defines a new non-probeable cryptographic authentication scheme. Apple, Inc. Microsoft Zscaler This document defines a mechanism for accessing provisioning domain information associated with a proxy, such as other proxy URIs that support different protocols and information about which destinations are accessible using a proxy. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tfpauly/privacy-proxy. This document describes HTTP extension header fields that allow a TLS terminating reverse proxy (TTRP) to convey the client certificate information of a mutually authenticated TLS connection to the origin server in a common and predictable manner. This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein. This document obsoletes RFC 1323 and describes changes from it. This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK] This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK] This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK] The completion of IPv4 address allocations from IANA and the Regional Internet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope. Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. This document is not an Internet Standards Track specification; it is published for informational purposes.

Acknowledgments This document benefited from close review and suggested changes by:

• Mohamed Boucadair
• Deb Cooley
• Gorry Fairhurst
• Thomas Fossati
• Amos Jeffries
• Mahesh Jethanandani
• Antun Jurkovic
• Eric Kinnear
• Kyle Nekritz
• Kazuho Oku
• Tommy Pauly
• Yaroslav Romakho
• David Schinazi
• Ketan Talaulikar
• Willy Tarreau