]> Fastly

kazuhooku@gmail.com

Zscaler

yrosomakho@zscaler.com

ptth internet-draft This document specifies the Protocol for Transposed Transactions over HTTP (PTTH), an HTTP extension that allows a backend server to establish an HTTP connection to a reverse proxy and transpose the flow of HTTP requests. The reverse proxy then sends requests to the backend server over the resulting transposed channel. This extension lets backend servers behind restrictive firewalls accept HTTP traffic through reverse proxies without changing firewall settings and with minimal overhead. Discussion Venues Discussion of this document takes place on the Protocol for Transposed Transactions over HTTP Working Group mailing list (ptth@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction In scalable HTTP deployments—such as those using CDNs and dynamic backend server pools—clients send requests to reverse proxies, which then forward them to backend servers. Backend servers frequently reside behind firewalls that block inbound TCP or QUIC connections, requiring special network or firewall configuration to permit proxy-initiated traffic. To overcome these restrictions, some organizations use VPNs, but VPNs introduce operational complexity, hamper scalability, and impose performance overhead. PTTH lets a backend server establish an HTTP connection to a reverse proxy and transpose the flow of HTTP requests, so that the reverse proxy can send HTTP requests to the backend server. PTTH has the following characteristics:

• URI-based: the setup request's target URI identifies the PTTH endpoint and scopes which requests the reverse proxy forwards to the backend server.
• Authorized like any HTTP request: the backend server asserts its identity — with a TLS client certificate, an HTTP authentication scheme, or otherwise — and the reverse proxy authenticates and authorizes the request just as it would any ordinary HTTP request.
• Unmodified HTTP on the transposed channel: PTTH merely sets up the transposed channel; HTTP runs over it unmodified, so HTTP extensions can be used without modification.
• Minimal overhead: the encapsulation that a transposed channel would otherwise incur can be avoided, letting the channel use the underlying transport directly.

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.

Establishing Transposed HTTP Channels To establish a transposed HTTP channel, the backend server connects to the reverse proxy and issues an extended CONNECT request ( and ) — or, in HTTP/1.1, the equivalent HTTP Upgrade () — that both authenticates the backend server and negotiates the transposition. Although the way extended CONNECT is expressed differs between HTTP versions, the accompanying header fields do not. The parameters for negotiating PTTH are therefore defined in a version-neutral manner. The target URI of the request identifies the PTTH endpoint and the scope of requests that the reverse proxy forwards to the backend server over the transposed channel. When that scope is an origin (), the well-known URI defined in is used. When the scope is expressed by other means, such as a configuration identifier, the target URI is left to the deployment. The authentication scheme is unspecified: deployments can use a TLS- or an HTTP-based scheme, or something else. Once a transposed channel is established, HTTP requests flow from the reverse proxy to the backend server: the reverse proxy acts as the HTTP client and the backend server as the HTTP server on the transposed channel. The HTTP version that carries the extended CONNECT request and the HTTP version of the transposed channel are independent. The backend server can send an extended CONNECT request on any version of HTTP and establish a transposed HTTP channel of any HTTP version.

Client Configuration When backend servers are configured to receive forwarded requests scoped by an origin, they use a target URI built from a URI Template () to establish a transposed channel. The URI Template identifies the reverse proxy and the origin for which the backend server is registering a transposed channel. The following examples show URI Templates for registering PTTH channels:

URI Template Examples

The following requirements apply to the URI Template:

• The URI Template MUST be a level 4 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 the variable "serialized_origin" 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.
• The URI Template MUST NOT use Reserved Expansion ("+" operator), Fragment Expansion ("#" operator), Label Expansion with Dot-Prefix, Path Segment Expansion with Slash-Prefix, or Path-Style Parameter Expansion with Semicolon-Prefix.

Backend servers SHOULD validate the requirements above. However, a backend server MAY use a general-purpose URI Template implementation that does not perform PTTH-specific validation. If a backend server detects that any of the requirements above are not met by a URI Template, it MUST reject its configuration and abort the request without sending it to the reverse proxy. The "serialized_origin" variable identifies the backend origin or origins being registered. The value of "serialized_origin" is a non-empty list. Each member of the list is a "serialized-origin" value as defined in and MUST be the ASCII serialization of an origin as defined in . The value "null" MUST NOT be used. If the port is omitted from a serialized origin, the default port for the corresponding scheme is implied. When represented in the resulting target URI, characters in each serialized origin that are not allowed in the target URI component are percent-encoded by URI Template expansion. For example, the serialized origin "https://backend.example.com:8443" is represented as "https%3A%2F%2Fbackend.example.com%3A8443" when expanded into a path segment. When sending a PTTH establishment request, the backend server MUST perform URI Template expansion using "serialized_origin" set to the list of backend origins it is registering. If more than one origin is registered, the list contains one serialized origin for each backend origin. For example, expanding with "serialized_origin" set to the list containing "https://backend.example.com" and "https://api.example.com:8443" produces: Backend server implementations that are constrained to configuring only the reverse proxy host and port MAY attempt to use the following default template: where $PROXY_HOST and $PROXY_PORT are the configured host and port of the reverse proxy, respectively. PTTH deployments SHOULD offer service at this location if they need to interoperate with such backend servers.

HTTP/1 and HTTP/2 To establish a transposed HTTP/1 or HTTP/2 channel, the backend server issues extended CONNECT accompanied by the "ptth" token: in HTTP/1.1 (), a "GET" request carrying an "Upgrade: ptth" header field; in HTTP/2 () and HTTP/3 (), a CONNECT request carrying "ptth" in the ":protocol" pseudo-header field. The request MUST also carry the ALPN header field () specifying the HTTP versions that the backend server is willing to use on the transposed channel. Valid ALPN identifiers include HTTP protocols that run directly over a byte stream, such as "h2" and "http/1.1", and HTTP/3 over QMux (), identified by the "h3qx" ALPN identifier. When the transposition succeeds, the reverse proxy returns a successful response — a 101 (Switching Protocols) response in HTTP/1.1, or a 2xx (Successful) response in HTTP/2 and HTTP/3 — carrying an ALPN response header field that specifies the chosen HTTP version. HTTP of that version is then carried directly over the resulting bidirectional byte stream, with neither TLS nor capsules: its confidentiality and integrity are provided by the setup channel's encryption, and the transposed HTTP protocol supplies its own framing and can exchange metadata such as the intent to shut down the connection. When HTTP/2 is selected, it is started by the reverse proxy sending a connection preface (). Because HTTP/2 offers cleaner framing and metadata exchange than HTTP/1.1, HTTP/2 is RECOMMENDED as the transposed protocol. shows an HTTP/1.1 exchange establishing a transposed channel. Here the Basic HTTP Authentication Scheme authenticates the backend server, which offers both HTTP/2 and HTTP/1.1; the reverse proxy selects HTTP/2.

Establishing a transposed channel over HTTP/1.1

HTTP/3 HTTP/3 () runs over QUIC (), whose underlying transport is UDP. A transposed HTTP/3 channel is therefore established as a new HTTP/3 connection whose UDP flow is proxied over the setup channel. To establish it, the backend server issues an extended CONNECT request with a "ptth-udp" upgrade token, together with an ALPN header field specifying HTTP/3. The new connection is initiated by the reverse proxy toward the backend server; the reverse proxy is thus the client-side of the transposed connection as well as being the HTTP client, and the backend server is the server-side of the transposed connection as well as being the HTTP server, so the transposed connection is an ordinary HTTP/3 connection in which no transport or stream roles are reversed. The UDP flow carrying the new connection is proxied over the setup channel as datagrams encapsulated using HTTP/3 Datagrams or capsules (), as in Proxying UDP in HTTP (). Therefore, while any version of HTTP can be used as the setup channel, using HTTP/3 as the setup channel provides the opportunity to use HTTP/3 Datagrams and avoid head-of-line blocking. To reduce the encapsulation overhead, extensions that optimize the proxying of UDP MAY also be used; see . For the QUIC handshake () of the new connection, an external PSK () is used, which both endpoints derive from the setup channel's TLS or QUIC connection using the exporter interface (), with the label "ptth-udp", an empty context, and an output length equal to the size of the hash of the cipher suite negotiated on the setup channel. That hash is also the PSK's associated hash function, and the key is offered under the PSK identity "ptth-udp". The purpose of this PSK is not to authenticate the backend server. Instead, it is used to let the QUIC connection, an always-encrypted transport, inherit the security context of the setup channel. When the reverse proxy returns a successful response to the extended CONNECT request, it has already validated the identity of the backend server as with ordinary HTTP requests, and has agreed to forward requests. Authentication of the backend server is unneeded after that point.

Avoiding Encapsulation Overhead The transposed channel established as described above is carried within the setup connection: over HTTP/2 it is confined to a single stream, and over HTTP/3 the new connection's packets are wrapped as HTTP Datagrams and thereby encrypted twice. This section describes, for each case, how that encapsulation can be avoided so that the transposed channel uses the underlying transport directly.

HTTP/1 and HTTP/2 Extended CONNECT over HTTP/2 or HTTP/3 establishes the transposed channel within a single bidirectional stream. A transposed HTTP/2 channel carried this way is multiplexed inside that one stream, adding a layer of framing and confining the transposed channel to that stream's flow-control window. Performing the setup over HTTP/1.1 avoids this. The HTTP/1.1 Upgrade hands over the entire connection rather than a single stream, so the transposed channel is the connection itself; a transposed HTTP/2 channel then runs natively, with its streams mapped directly onto the connection. Because the transposed channel reuses the setup connection, it also inherits that connection's TLS session: its authentication and encryption carry over unchanged, and neither a pre-shared key nor any additional authentication is required.

HTTP/3 Proxying the transposed connection's packets as HTTP/3 Datagrams or capsules encrypts each packet twice: once by the transposed connection and again by the setup channel. Forwarded mode of QUIC-Aware Proxying () removes the second encryption. In forwarded mode, short header packets of the transposed connection are sent over the same path as the setup channel but are not encapsulated within it; the reverse proxy and the backend server identify them by their QUIC connection IDs. Packet transforms () are unnecessary in PTTH, because the reverse proxy is itself an endpoint of the transposed connection; there is no additional link that passive attackers might observe to correlate. Endpoints can therefore send and receive the QUIC packets of the transposed connection directly on the network path of the setup connection, simply by swapping the Connection IDs to the Virtual Connection IDs assigned by the forwarded mode.

Security Considerations

Establishing Authority In HTTP, only the URI's authority may process or delegate the request (). This authority model of HTTP remains unchanged under PTTH:

• When the backend server connects to the reverse proxy and requests the transposition of the connection, the backend identifies the reverse proxy using a target URI whose authority component identifies the reverse proxy.
• When the reverse proxy forwards requests to the backend over a transposed connection, it is merely exercising its rights as the authoritative server. This behavior is identical to forwarding requests over connections the reverse proxy initiated, using whatever authentication scheme it chooses. PTTH differs only in how the backend connections are established.

Accepting a PTTH establishment request does more than authenticate the backend server. It authorizes that backend server to receive requests for each backend origin identified by the request target. A reverse proxy MUST therefore verify that the authenticated backend server is authorized to register every requested backend origin before accepting the request.

IANA Considerations

HTTP Upgrade Token Once approved, this document will request IANA to register the following entries to the "HTTP Upgrade Tokens" registry maintained at https://www.iana.org/assignments/http-upgrade-tokens:

Value:

ptth

Description:

Establishes a transposed HTTP channel that runs over a byte stream.

Expected Version Tokens:

None

Reference:

this document

Value:

ptth-udp

Description:

Establishes a transposed HTTP channel that runs over UDP.

Expected Version Tokens:

None

Reference:

this document

TLS Exporter Label Once approved, this document will request IANA to register the following entry in the "TLS Exporter Labels" registry maintained at https://www.iana.org/assignments/tls-parameters:

Value:

ptth-udp

DTLS-OK:

N

Recommended:

Y

Reference:

this document

Well-Known URI Once approved, this document will request IANA to register the following entry in the "Well-Known URIs" registry maintained at https://www.iana.org/assignments/well-known-uris:

URI Suffix:

ptth

Reference:

this document

Status:

permanent

Change Controller:

IETF

References 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. 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. 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. 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 defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK] 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 specification allows HTTP CONNECT requests to indicate what protocol is intended to be used within the tunnel once established, using the ALPN header field. 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 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 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. Independent 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 updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. Informative References Fastly Cloudflare Netflix This document specifies how to use HTTP/3 over QMux. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the HTTP Working Group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/. Source for this draft and an issue tracker can be found at https://github.com/kazuho/draft-kazuho-httpbis-http3-on-streams. This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64. This document describes how Transport Layer Security (TLS) is used to secure QUIC. Apple Inc. Apple Inc. Google LLC This document extends UDP Proxying over HTTP to add optimizations for proxied QUIC connections. Specifically, it allows a proxy to reuse UDP 4-tuples for multiple proxied connections, and adds a mode of proxying in which QUIC short header packets can be forwarded and transformed through a HTTP/3 proxy rather than being fully re- encapsulated and re-encrypted.

Acknowledgments TODO.