]> Zscaler

yrosomakho@zscaler.com

Multiplexed Application Substrate over QUIC Encryption quic http proxy reverse This document specifies an extension to the HTTP CONNECT method, enabling a proxy client to accept inbound TCP and UDP sessions proxied through HTTP/1.1, HTTP/2, or HTTP/3. This mechanism allows the client to dynamically advertise available local or internal network services and expose them through a HTTP proxy without reliance on IP routing. 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 Multiplexed Application Substrate over QUIC Encryption mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Reverse HTTP CONNECT for TCP and UDP extends the traditional CONNECT method (see ) by enabling a proxy client to accept inbound TCP and UDP sessions proxied through HTTP/1.1 , HTTP/2 , or HTTP/3 . In contrast to the traditional CONNECT method, which establishes outbound sessions to remote servers, this extension facilitates inbound sessions to the proxy client, allowing access to local or internal services. Unlike Proxying IP in HTTP , this approach simplifies deployment in dynamic or constrained network environments by removing reliance on IP routing. By eliminating the need for routing configurations, this approach reduces operational complexity and allows for easier integration in scenarios where traditional IP routing is impractical. On top of that, Reverse HTTP CONNECT reduces overhead as it does not carry IP or transport layer headers. Since Reverse HTTP CONNECT is built on top of existing HTTP transport, it can be efficiently combined with outbound CONNECT and other HTTP communications. The primary use cases for this extension include:

• Access to Local Services: A proxy client can expose its own local services by accepting inbound TCP or UDP sessions from an HTTP server. For example, this can enable remote management or access to local application servers that can only be accessed through an outbound connection to the proxy.

Accessing local client services

• Gateway to Internal Networks: A proxy client acts as a gateway, facilitating access to internal network services provided over TCP or UDP sessions. In this scenario, the proxy client forwards incoming session originating from an HTTP server to specific internal services, enabling secure communication with private network resources.

Accessing internal services through client

As explained in the specification both use cases can be combined on the same proxy client.

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.

Client Configuration To use a Reverse Connect proxy HTTP clients are configured with two URI Templates :

• Listener Control Channel described in
• Accepting Connection Requests described in .

Listener Control Channel The Listener Control Channel enables the HTTP server to request the establishment of inbound TCP or UDP sessions on the proxy client. This is necessary because the HTTP protocol inherently expects the client to initiate connections. To address this, the Listener Control Channel uses the Capsule Protocol (see ) to carry connection requests from the server to the client. Additionally, the Listener Control Channel can carry optional Service Discovery Capsules, which allow the proxy client to advertise available local or internal services to the HTTP server. This feature facilitates dynamic service discovery and ensures that the server has up-to-date information about the services accessible through the proxy client.

Listener Control Channel URI Template The Listener Control Channel template is similar to the one defined in and it MAY contain two variables: "target" and "ipproto". These variables are used to define the scope of network services that the client accepts connectivity for. Examples are shown below:

Listener Control Channel URI Template Examples

All template requirements listed in apply here. If set, the variable "target" MUST contain one of the following values:

• A hostname according to
• IPv4 or IPv6 prefix according to
• "*" that does not limit scope
• A wildcard: a domain name prefixed by "*.". This implies that client MAY accept inbound sessions for any host in a given domain
• "." which means that the client will accept sessions to local services only and will not forward to other hosts

If set, the variable "ipproto" MUST contain one of the following values:

• "6" which means that the client will only accept TCP sessions.
• "17" which means that the client will only accept UDP sessions.
• "*" which means that the client will accept both TCP and UDP sessions.

As with , some client configurations for Reverse Connect proxies will only allow the user to configure the proxy host and proxy port. Clients with such limitations MAY attempt to access proxying capabilities using the default template, which is defined as: "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/listen/{target}/{ipproto}/", where $PROXY_HOST and $PROXY_PORT are the configured host and port of the proxy, respectively. Reverse Connect proxy deployments SHOULD offer service at this location if they need to interoperate with such clients.

Establishing Listener Control Channel over HTTP/1.1 When establishing the Listener Control Channel using HTTP/1.1 , the client follows the requirements from but uses "connect-listen" as the value for the Upgrade header. For example, the client configured with the default URI Template "https://example.org/.well-known/masque/listen/{target}/{ipproto}/" can establish the Listener Control Channel for local TCP and UDP services by sending the following request:

Example HTTP/1.1 Request

The server confirms successful registration of the client as described in , but with "connect-listen" for the value for Upgrade header. An example of the server confirming successful registration of the client is provided below:

Example HTTP/1.1 Response

Establishing Listener Control Channel over HTTP/2 and HTTP/3 When establishing Listener Control Channel using HTTP/2 or HTTP/3 , the client follows requirements from , but uses "connect-listen" as the value for :protocol pseudo-header. For example, the client configured with the default URI Template "https://example.org/.well-known/masque/listen/{target}/{ipproto}/" can establish the Listener Control Channel for local TCP and UDP services by sending the following request:

Example HTTP/2 or HTTP/3 Request

The server indicates a successful registration of the client as described in . Example of server confirming successful registration of the client is provided below:

Example HTTP/2 or HTTP/3 Response

Service Discovery The Reverse Connect client MAY advertise offered TCP and UDP services to the proxy server through the AVAILABLE_SERVICES Capsule over the established Listener Control Channel. This information serves as a hint for the proxy server and does not constrain the server from attempting to establish sessions with services that were not advertised. The presence of a service in the AVAILABLE_SERVICES list does not guarantee actual service availability, as the client may not be able to track the health of the service. Capsule format for AVAILABLE_SERVICES is the following:

AVAILABLE_SERVICES Capsule Format

The AVAILABLE_SERVICES capsule contains a sequence of zero or more Services.

Service Format

Each service record represents potential connection destination and contains the following fields:

Destination Type:

A single byte value defining type and format of Destination field. Valid destination types are:

• 0: Destination is local for the client.
• 1: Destination is specified by a hostname.
• 4: Destination is specified by an IPv4 address.
• 6: Destination is specified by an IPv6 address.

Destination:

Content of the Destination field is determined by the Destination Type. For local destination type destination is omitted. IPv4 destination carries 32 bits of IPv4 address. IPv6 destination carries 128 bits of IPv6 address. Hostname destination (destination type 1) is provided in the following format:

Hostname Destination Format

Length is encoded as a variable-length integer and Hostname contains the hostname string.

Protocol:

A single byte value of 6 for TCP and 17 for UDP.

Port:

Two bytes value of target TCP or UDP port.

AVAILABLE_SERVICES messages are not incremental. A new message completely overwrites the previous hint. If any of the capsule fields are malformed upon reception, the server MUST follow the error-handling procedure defined in .

Connection Lifecycle

Requesting Connection To request a new outbound connection from the client for an inbound TCP or UDP session, the server sends a CONNECTION_REQUEST Capsule. The CONNECTION_REQUEST Capsule is defined as follows:

CONNECTION_REQUEST Capsule Format

Request ID:

A unique request identifier, encoded as a variable-length integer. The Request ID MUST be unique for a given Listener Control Channel.

Service:

Session destination as described in .

If any of the capsule fields are malformed upon reception, or if the Request ID has been previously used on the same Listener Control Channel, the client MUST follow the error-handling procedure defined in . If the client declines the connection request it responds with a CONNECTION_REQUEST_DECLINED Capsule in the following format:

CONNECTION_REQUEST_DECLINED Capsule Format

If any of the capsule fields are malformed upon reception, or if the  Request ID does not correspond to an outstanding CONNECTION_REQUEST on the same Listener Control Channel, the server MUST follow the error-handling procedure defined in .

Accepting Connection To accept the inbound session, the client sends a new outbound request to the server. This request uses an Accepting Connection URI Template . The URI Template MUST contain "request_id" variable. Examples are shown below:

Accepting Connection URI Template Examples

The following requirements apply to the Accepting Connection URI Template:

• The URI Template MUST be a level 3 template or lower.
• The URI Template MUST be in absolute form and MUST include non-empty scheme, authority, and path components.
• The path component of the URI Template MUST start with a slash "/".
• All template variables MUST be within the path or query components of the URI.
• The URI Template MUST contain variable "request_id" and MAY contain other variables.
• The URI Template MUST NOT contain any non-ASCII Unicode characters and MUST only contain ASCII characters in the range 0x21-0x7E inclusive (note that percent-encoding is allowed; see .
• The URI Template MUST NOT use Reserved Expansion ("+" operator), Fragment Expansion ("#" operator), Label Expansion with Dot-Prefix, Path Segment Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with Semicolon-Prefix.

Clients SHOULD validate the requirements above; however, clients MAY use a general-purpose URI Template implementation that lacks this specific validation. If a client detects that any of the requirements above are not met by a URI Template, the client MUST reject its configuration and abort the request without sending it to the IP proxy. As with , some client configurations for Reverse Connect proxies will only allow the user to configure the proxy host and proxy port. Clients with such limitations MAY attempt to access proxying capabilities using the default template, which is defined as: "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/accept/{request_id}/", where $PROXY_HOST and $PROXY_PORT are the configured host and port of the proxy, respectively. Reverse Connect proxy deployments SHOULD offer service at this location if they need to interoperate with such clients.

Accepting Connection over HTTP/1.1 When accepting an inbound session over HTTP/1.1 , the client sends to the proxy a new request as follows:

• The method SHALL be "GET"
• The request SHALL include a single "Host" header field containing the origin of 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 value "connect-accept".

A request that does not match the above restrictions is considered malformed. A proxy server receiving a malformed request MUST respond with an error and SHOULD use the 400 (Bad Request) status code. If request_id template variable is not matching an outstanding connection request for given client, proxy server MUST respond with an error and SHOULD use the 404 (Not Found) status code. The proxy SHALL indicate a successful response by replying with the following requirements:

• The HTTP status code on the response SHALL be 101 (Switching Protocols).
• The response SHALL include a Connection header field with value "Upgrade" (note that this requirement is case-insensitive as per ).
• The response SHALL include a single Upgrade header with value "connect-accept".
• The response SHALL meet the requirements of HTTP responses that start the Capsule Protocol according to .

A response that does not match these requirements MUST be treated as failed and corresponding connection MUST be aborted by the client. For example, the client configured with the URI Template "https://example.org/.well-known/masque/accept/{request_id}/" can accept the inbound Connection as a response to a connection request with Request ID 1:

Example HTTP/1.1 Request Accepting Connection

The proxy server could respond with the following:

Example HTTP/1.1 Response Accepting Connection

Accepting Connection over HTTP/2 and HTTP/3 When accepting an inbound sessions over HTTP/2 or HTTP/3 , the client sends to the proxy a request on a new Stream of the connection that carries the Listener Control Channel as follows:

• The :method pseudo-header field SHALL be "CONNECT".
• The :protocol pseudo-header field SHALL be "connect-accept".
• 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 Accepting Connection URI template for the proxy.

A request that does not match the above restrictions is considered malformed. A proxy server receiving a malformed request MUST respond with an error and SHOULD use the 400 (Bad Request) status code. If "request_id" template variable is not matching an outstanding connection request for given client, proxy server MUST respond with an error and SHOULD use the 404 (Not Found) status code. The proxy SHALL indicate a successful response by replying with the following requirements:

• The HTTP status code on the response SHALL be in 2xx (Successful) range.
• The response SHALL meet the requirements of HTTP responses that start the Capsule Protocol according to .

A response that does not match these requirements MUST be treated as failed and corresponding connection MUST be aborted by the client. For example, the client configured with the URI Template "https://example.org/.well-known/masque/accept/{request_id}/" can accept the inbound session as a response to a connection request with Request ID 1:

Example HTTP/2 or HTTP/3 Request Accepting Connection

The proxy server could respond with the following:

Example HTTP/2 or HTTP/3 Response Accepting Connection

Establishing Connection Once the client receives a successful response from the proxy for the request accepting the connection it establishes the requested TCP or UDP socket to a local or internal destination. If the socket failed to establish, the client MUST immediately close the request stream. For TCP flows, communicating parties carry TCP payload data in the payload of DATA Capsules over the established stream according to . Either party MAY close the stream if TCP connection is terminated. UDP data is carried in DATAGRAM capsules or encoded in QUIC DATAGRAM frames as explained in . The lifetime of the UDP socket is tied to the request stream as described in .

Security Considerations Proxy servers providing Reverse HTTP Connect services MUST restrict their services to authenticated users. An unauthorized user accepting an inbound session from the proxy server may cause availability risks and compromise the wider systems by misrouting communications. Clients that advertise services through the AVAILABLE_SERVICES Capsule may inadvertently expose sensitive or private services. Proxy servers MUST verify that advertised services comply with organizational security policies. To avoid exposing local or internal services to unauthorized parties, clients MUST confirm identity of the proxy service that they connect to and allow inbound sessions only to services that should be accessible from the proxy. Proxies providing Reverse HTTP Connect service over HTTP/1.1 MUST consistently authenticate clients on both Listener Control Channel and individual Connection Acceptance Requests. To minimize the risks of misrouting connection request to a rogue client, HTTP/1.1 Reverse Connect proxies SHOULD generate Request ID randomly instead of using a predictable sequence.

IANA Considerations

 HTTP Upgrade Tokens IF APPROVED, IANA is requested to add the following entries to the HTTP Upgrade Token Registry:

Value	Description	Reference
"connect-listen"	Listening for inbound connection requests	(This document)
"connect-accept"	Accepting an inbound connection request	(This document)

 New MASQUE Default Templates IF APPROVED, IANA is requested to add the following entries to the MASQUE URI Suffixes Registry:

Value	Description	Reference
"listen"	Listening for inbound connection requests	(This document)
"accept"	Accepting an inbound connection request	(This document)

 New HTTP Capsule Types IF APPROVED, IANA is requested to add the following entries to the HTTP Capsule Types Registry:

Value	Capsule Type
(TBD)	AVAILABLE_SERVICES
(TBD)	CONNECTION_REQUEST
(TBD)	CONNECTION_REQUEST_DECLINED

All of these new entries use the following values for these fields: Status: permanent Reference: (this document) Change Controller: IETF Contact: MASQUE Notes: None

Normative References 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. 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. 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. 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. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Meta Platforms, Inc. TCP proxying using HTTP CONNECT has long been part of the core HTTP specification. However, this proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative HTTP proxy service configuration for TCP connections. This configuration is described by a URI Template, similar to the CONNECT-UDP and CONNECT-IP protocols. 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.

Acknowledgments TODO acknowledge.