]> Mozilla

mt@lowentropy.net

Web and Internet Transport Protocol for Transposed Transactions over HTTP next generation unicorn sparkling distributed ledger This document defines 🥔 (Potato), a suite of reversed versions of HTTP for origin servers. 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 Protocol for Transposed Transactions over HTTP Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Operating an HTTP server that is accessable on the public internet creates an unmanageable risk of denial of service for many organizations, especially smaller operators. Content delivery networks (CDNs) are able to provide a measure of protection. This helps, but only to a degree. A CDN typically operates as a gateway, which imposes requirements on origin servers for reachability, security, and scalability that can be operationally challenging. An alternative deployment model has emerged as a means of addressing this concern, where, rather than have the gateway initiate a connection to the origin, the origin connects to the gateway. | | | | messages | +-- request ------------------->| | exchanged | | | | | over | |<------------------ response --+ | existing |<-- response --+ | | | connection | | | | ]]> This arrangement has several advantages. It greatly simplifies the configuration of firewalls, which are better able to authorize outward-bound connections. It also changes the way that the origin scales up in the case where multiple server instances are needed. This document defines alternative, "reversed", versions of HTTP protocols. These protocols are all nearly identical to their "forward" counterparts, with the exception that the client and server roles are inverted after completing the transport and TLS layer establishment. This document defines reversed equivalents to HTTP/1.1 , HTTP/2 , and HTTP/3 .

Comparative Notes This is one of a set of different options in this space. Other designs include reverse tunnels and reverse HTTP transport . These alternatives are all broadly capable of achieving the goal. Key points of divergence exist around the use of tunnels (for reverse tunnels) and how different roles are authenticated and authorized. There are some minor differences in use of terminology, which need to be cleared up.

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. This document uses terminology from . Because having roles reversed can be especially confusing, this document tries to be consistent in its use of language. The terms client and server, when unqualified, refer to the HTTP client and HTTP server roles respectively. In this document, a gateway will generally be the HTTP client and an origin server will generally be the HTTP server. These terms will be used where it makes sense. Where it is necessary to identify a client or server role outside of the context of reversed HTTP, the term will be qualified. This typically will use the protocol where the role is used. For example, "TLS client role" or "acting as QUIC client".

Overview and Scope This document describes how to establish reversed HTTP connections. The overall approach is to allocate new Application-Layer Protocol Negotiation (ALPN) identifiers to each reversed HTTP version. The origin server acts in the client role for establishing the transport and security layers of a connection to the gateway, which provides a server for those layers. That is, for HTTP/1.1 and HTTP/2, the origin server is the TCP and TLS client and the gateway is the TCP and TLS server. For HTTP/3, the origin server is the QUIC client and the gateway is the QUIC server. If the gateway selects the reversed HTTP version in the protocol negotiation, the corresponding HTTP version is conducted with the usual roles reversed. The gateway becomes the HTTP client and the origin server becomes the HTTP server. No other changes are made to the protocol. The document explores some of the implications of this design, including authorization ( and ), and interactions with some protocol features. However, there are numerous factors that are relevant when choosing an appropriate server deployment architecture. This document will address only those that are relevant to the design of the protocol and essential to its secure and correct operation. This document does not define a protocol that allows both endpoints to make requests over the same connection. Separate connections can be used if requests need to be exchanged in both directions. Alternatively, tunnels (e.g., CONNECT or variants ) within a regular HTTP connection and a 🥔 variant can use that tunnel. Finally, a 🥔 connection could also be established and a tunnel with 🥔 variant inside, but the role inversions and the authentication and authorization that are involved could be more confusing than helpful.

Reversed HTTP This section defines the basic operation of 🥔 for each major HTTP version. All versions of 🥔 require special handling for questions of server authority. Authorizing the origin server is discussed in . Similarly the means by which a gateway authorizes an origin server are discussed in . Most HTTP features, including extensions to specific HTTP versions, are unaffected by the reversal of the protocol. Only those features that depend on lower protocols layers that also depend on assumptions about how the the TLS or transport-layer role relates to the HTTP client or server role. Such features cannot be used without additional profiling. The features that cannot be used with 🥔 include: the Client-Cert HTTP field . A small adjustment to the operation of the HTTP/3 Datagram extension is described in .

🥔 for HTTP/1.1 A reversed version of HTTP/1.1 is identified by the ALPN label "ph1". To negotiate the use of 🥔 for HTTP/1.1, an origin server advertises the "ph1" token in its TLS handshake using ALPN and a gateway selects that token. Once a TLS connection is established, the origin server (as a TLS client) becomes the HTTP server and the gateway (as TLS server) becomes the HTTP client. Messages sent by the gateway are HTTP requests and messages from the origin server are HTTP responses. HTTP/1.1 depends only on an undifferentiated stream of bytes. No special considerations apply to this version.

🥔 for HTTP/2 A reversed version of HTTP/2 is identified by the ALPN label "ph2". To negotiate the use of 🥔 for HTTP/2, an origin server advertises the "ph2" token in its TLS handshake using ALPN and a gateway selects that token. Once a TLS connection is established, the origin server (as a TLS client) becomes the HTTP/2 server and the gateway (as TLS server) becomes the HTTP/2 client. Each send a preface () and establishes an HTTP connection. HTTP/2 depends only on an undifferentiated stream of bytes. No changes are necessary to the base protocol. In operation, the gateway (as HTTP/2 client) initiates requests on odd-numbered streams, just like a regular HTTP/2 connection. Any push promises from the origin server (as HTTP server) are sent on even-numbered streams.

🥔 for HTTP/3 A reversed version of HTTP/3 is identified by the ALPN label "ph3". To negotiate the use of 🥔 for HTTP/3, an origin server advertises the "ph3" token in its QUIC handshake using ALPN and a gateway selects that token. Once a QUIC connection is established, the origin server (as a QUIC client) becomes the HTTP/3 server and the gateway (as QUIC server) becomes the HTTP/3 client. Unlike HTTP/2, the streaming layer that HTTP/3 uses is provided by QUIC. Therefore, the identifiers given to streams change. This should not be visible to the HTTP/3 layer; the HTTP/3 design generally does not depend on stream identifiers being in any particular form. One exception to this is the Quarter Stream ID concept introduced in . Because requests in reversed HTTP/3 are made on bi-directional, server-initiated streams, those identifiers end with two bits (0b01); see . To construct a Quarter Stream ID from a stream identifier, any remainder is discarded. To construct a stream identifier from a Quarter Stream ID in reversed HTTP/3, the value is multiplied by 4, then the stream type (0b01) is added. This adjustment only requires an understanding of the type of QUIC stream that the HTTP client uses to make requests, which works for regular HTTP/3 as well. Any extension that makes similar assumptions about the structure of stream identifiers can be adjusted in a similar manner.

Authenticating and Authorizing Origin Servers Arrangements between gateways and origin servers are often privately arranged. Therefore, how a gateway chooses to authorize an origin server does not necessarily benefit from having a single, standard mechanism. This section describes a few options for origin server authentication. None of these approaches is mandated, as it is expected that private arrangements will be used in most deployments.

TLS Client Certificates TLS client certificates can be used to authenticate TLS clients. That authentication could be used as the basis of authorization. The choice of how to authenticate a client certificate is complex. Multiple options are possible, each with different operational and deployment properties:

• The gateway could use the same public key infrastructure (PKI) as the certificate that the gateway itself offers (see ).
• A completely separate PKI could be used. This includes a PKI managed by the gateway.
• Self-signed certificates could be mapped to specific authorizations.

This option might introduce some challenges in implementation or deployment. Because the TLS connection that is established to the gateway uses the same endpoint as other clients, the TLS server software would need to make its protocol selection before deciding to request a client certificate.

HTTP Request Once a 🥔 connection is established, the gateway could make a request to a pre-arranged resource. This request could be used to retrieve a shared secret that authorizes the origin server. However, this is trivially vulnerable to impersonation attack if an adversary is able to capture the secret. A marginally more complex and more secure exchange might involve the origin server producing a signed object that covers a challenge produced by the gateway. TODO: Should this document define a protocol?

Authorization for Limited Path Scope A gateway does not need to authorize an origin server to serve all requests for an origin. A gateway might direct only a subset of URLs to a specific origin. Nor does a gateway need to limit its authorization to a single origin. A gateway could send requests for multiple origins, varying host or port as configured. The choice of which requests are forwarded to an origin server is a matter for gateway policy. That policy might be guided by the choice of credential presented by the origin server. If a HTTP request is used to authorize the origin server, the response might include information that guides the gateway in determining which requests are forwarded over the connection. This could be as simple as having the origin server list path prefixes that it can serve or it could be bound to the credentials that are offered. This might be used to enable different deployment architectures where the one logical origin server is distributed across multiple instances, with different paths being served by different hosts. This approach is also compatible with a gateway that makes regular HTTP connections to some origin server nodes. A gateway might forward requests for the one origin to origin servers that use both regular and reversed HTTP based on whatever policy it chooses.

Authenticating Gateways An origin server MUST authenticate a gateway unless an alternative means of authentication is privately arranged. In all 🥔 variants, when the the origin server establishes a TLS connection to the gateway, it confirms the identity of the gateway according to the rules of the respective, non-🥔, HTTP version. The rules in regarding how clients determine whether a server can answer a request are applied in reverse. That is, an origin server that cannot successfully determine that a gateway is authoritative for resources MUST NOT answer requests from that gateway. Because the server and client roles are reversed, some methods for expanding the scope that a server can claim authority for are invalidated. Mechanisms like the ORIGIN frame remain valid as a means of limiting scope. These requirements do not exist to provide protection against impersonation, which is generally the reason to require that a server establish authority. They exist to protect things like the confidentiality of responses. TODO: For discovery, should this use generic SVCB records, HTTPS records, or a new RR type? It seems like HTTPS will work just fine for this.

TLS Early Data A gateway can use TLS session resumption to make establishing connections more efficient. This includes the possibility of enabling TLS early data. Unlike in regular HTTP where a client can use TLS early data to make a request, reversed HTTP gives the server an opportunity to speak first. This has little value, as an HTTP server generally has to wait for requests. This provides similar properties to the first flight of server application data in a TLS 1.3 connection without early data. There, the server is able to send first. Though that data has no replay risk, the data that a server might send in any HTTP version without a request is unlikely to produce side effects that might be a problem if replayed. An origin can use early data to reduce the latency of settings or pre-populate header compression state. These both only apply to HTTP/2 and HTTP/3. These uses can avoid any replay attack risk, as these do not cause side effects beyond the connection state. For a gateway, the first flight of application data can be used to make requests. However, this data is sent prior to receiving client certificates if those are used to authorize the origin server; see . This flight might be used to initiate a request to authorize the origin server, such as the option described in .

Scalability, Availability, and Connection Management A gateway that is configured to make connections to an origin server is able to make connections as needed. The origin server might deploy a load balancer to manage inbound connections. When roles are reversed, having the origin server be responsible for connection establishment can mean that the gateway cannot assume that it is able to make new connections as demand increases. This can mean that origin servers have a greater control over their availability and service scaling. Where an origin server that might need to scale up to handle increased demand might otherwise need to arrange for load balancing infrastructure, that becomes something that the gateway assumes more responsibilty for. As a passive participant, a gateway is not able to act if an origin server goes offline. The origin server is responsible for establishing connections when it becomes available. This can present scaling challenges as a gateway cannot make additional connections on the assumption that origin servers will scale to meet increased demand. Gateways can attempt to make additional requests over existing connections, but origin servers can use protocol features designed to limit resource commitment -- such as stream limits and flow control -- to manage load. This document does not define any mechanism that might allow the gateway to communicate changes in demand for capacity to origin server instances. Defining mechanisms to help with adding or removing capacity on demand is a matter for future work. The use of reversed HTTP/1.1 presents particular difficulty for connection management, which is borne by the origin server. The lack of any concurrency features in that protocol means that origin servers that use 🥔 for HTTP/1.1 will need to manage a pool of connections if the gateway needs to handle requests with any amount of concurrency or volume. Consequently, a choice to use it is inadvisable except for very specific conditions.

Security Considerations Using 🥔 changes the denial of service profile for origin servers that rely on it. Such servers are able to use different tools to manage their reachability. A gateway becomes a more central part of managing load, but the gateway no longer has direct control over connection establishment. This alters how gateways and origin servers need to be configured to handle scaling, availability, and connections; see for details. Other than these changes, the security considerations of HTTP and the specific HTTP version in use apply in full.

IANA Considerations TODO: Register ALPN labels.

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. 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 describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. 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 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. Informative References Fastly 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 HTTP request flow. The reverse proxy then forwards incoming requests to the backend server over the transposed connection. This extension lets backend servers behind restrictive firewalls accept HTTP traffic through reverse proxies without changing firewall settings and with virtually zero overhead. Meta Platforms, Inc. Nokia Orange SAP SE This document defines a secure transport for HTTP in which the client and server roles are reversed. This arrangement improves the origin server's protection from Layer 3 and Layer 4 denial-of-service attacks when an intermediary is in use. It allows origin server's to be hosted without being publicly (and directly) accessible but allows clients to access these servers via an intermediary. 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. 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 the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection.

Acknowledgments This draft is based on discussions with many people. Both and both made helpful contributions.