]> Fastly

kazuhooku@gmail.com

httpbis internet-draft This document specifies an HTTP extension to establish bi-directional byte streams in the direction from servers to their clients, utilizing HTTP as a tunneling mechanism. This approach not only facilitates communication between servers located behind firewalls and their known clients but also introduces the potential for these known clients to serve as relays. In such configurations, clients can forward application protocol messages or relay TCP connections, allowing servers to interact with any client on the Internet without direct exposure. Discussion Venues Discussion of this document takes place on the HTTP Working Group mailing list (ietf-http-wg@w3.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction In typical application protocols operating on top of TCP, clients initiate TCP connections by specifying the server's IP address and the port number. However, not all servers can accept incoming TCP connections directly. Presently, servers situated behind firewalls that block incoming TCP connections often rely on virtual private networks (VPNs). These VPNs enable the passage of packets initiating TCP connections to servers through encapsulation, effectively bypassing firewall restrictions. This approach, however, compromises network manageability and incurs performance penalties due to the additional routing and encapsulation involved. This document proposes an alternative to utilizing VPNs by defining a method for servers to establish connections to clients over HTTP, thereby creating bi-directional byte streams for application protocols. Specifically, this extension employs HTTP upgrades in HTTP/1.1 ( Section 7.8) and the "extended CONNECT" method in HTTP/2 and HTTP/3 for the establishment of these byte streams. Beyond better manageability and reduced performance overhead in comparison to VPNs, this method of employing HTTP for tunnel establishment provides additional advantages. It enables endpoints to utilize a variety of authentication schemes that are native to HTTP, such as HTTP authentication and cookies. Furthermore, it shifts client identification from relying on IP addresses and port numbers to using URIs, thereby enhancing flexibility and integration with web technologies. As servers specify their clients using URIs, only clients known to a server can communicate directly with it. Nevertheless, clients have the capability to forward application protocol-level messages (e.g., HTTP requests) or relay TCP connections they receive or accept from the Internet. Through such relay mechanisms, servers hidden behind firewalls can effectively receive requests from any client on the Internet, bridging the gap between restricted access and global connectivity.

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

The Protocol To setup a reverse tunnel, a server connects to the client as specified by the URI and issues an HTTP request. To signal the intent to establish a reverse tunnel, an upgrade token named "reverse" is used. The method and the conveyor of the upgrade token are different between the HTTP versions.

HTTP/1.1 In HTTP/1.1, the HTTP upgrade mechanism ( Section 7.8) is used. The method of the issued request SHALL be "GET". The upgrade token is conveyed by the "Upgrade" header field, and once the reverse tunnel is established successfully, the client responds with a 101 (Swithing Protocols) response. shows an exchange of HTTP/1.1 request and response establishing a reverse tunnel. In this example, the Basic HTTP Authentication Scheme is used to authenticate the server.

Establishing Reverse Tunnel over HTTP/1.1

HTTP/2 and HTTP/3 In HTTP/2 and HTTP/3, extended CONNECT is used; see and . In both HTTP versions, the method being used is "CONNECT" and the upgrade token is conveyed by the ":protocol" pseudo header. Once the reverse tunnel is established successfully, the client responds with a 200 (OK) response.

Authentication When HTTPS is used for establishing the tunnel, clients (i.e., the nodes acting as TLS servers) SHOULD use one of the TLS-based authentication schemes to identify themselves. Servers SHOULD authenticate themselves either by using one of the HTTP-based authentication schemes; e.g., HTTP Authentication ( Section 11), or, when HTTPS is used, by using one of the TLS-based authentication schemes.

Application-Layer Protocol Negotiation While TLS can be used on top of an established tunnel, doing so might not be necessary for ensuring the security of communication if the tunnel is established via HTTPS, and the client side of the reverse tunnel also functions as the client side of the application protocol in use. A typical scenario involves an HTTPS reverse proxy serving as the client of a reverse tunnel. This proxy terminates incoming TLS connections and decrypts the HTTP requests before forwarding them through the reverse tunnel, which is secured by a separate TLS connection. In these deployments, foregoing the use of TLS above the established tunnel can yield performance benefits without compromising security. However, this approach requires that endpoints negotiate the application protocol without relying on the Application-Layer Protocol Negotiation performed during the TLS handshake. To address this need, this document introduces an HTTP header-based mechanism for negotiating the application protocol. It employs ALPN identifiers for naming the application protocols, allowing for the selection of existing application protocols without depending on TLS-based negotiation.

Indicating Protocols Available for Use To indicate the application protocols that the server is willing to utilize, a server MAY include an "ALPN" header field in the HTTP request that it issues. The "ALPN" header field carries a list of application-protocol identifies that the server is willing to use.

Indicating the Chosen Protocol When a client receives an HTTP request with an "ALPN" header field, and if the client decides to select one of the application protocols being offered, the client includes a "Selected-ALPN" header field in the HTTP response. If the HTTP request does not include an "ALPN" header field, the client MUST NOT send a "Selected-ALPN" header field. Syntax of the "Selected-ALPN" header field is as follows. The syntax reuses the encoding of the "ALPN" header field, but always includes exactly one application-protocol identifier that is being chosen. shows an exchange of HTTP/1.1 response and response that sets up a tunnel for forwarding HTTP requests using HTTP/2, where tunnel server is the origin and the tunnel client is the reverse proxy.

Setting up a HTTP/2 Tunnel for forwarding HTTP Requests

When a server sends an HTTP request with an "ALPN" header field but receives a successful response without a "Selected-ALPN" header field, it could either be an indication that the client chose an application protocol that the server did not offer, or that the server could not determine which application protocol has been chosen. Therefore, the client SHOULD NOT assume that an application protocol other than the ones being offered has been selected.

Relaying Connections When a client is forwarding at the application protocol layer, it can utilize mechanisms provided by the application protocol in use to convey the identity of the actual client from which messages were received. For example, HTTP intermediaries acting as reverse tunnel clients can add the "Forwarded" header field to each request they relay. However, when the client acts as a transport-layer protocol relay (i.e., relaying TCP connections), it becomes the responsibility of the reverse tunnel protocol to convey the 4 tuple of the TCP connection being relayed.

Signalling Client Address Upon receiving a request to establish a reverse tunnel, a client acting as a relay SHOULD match a connection to be relayed before sending a successful response (i.e., 101 Switching Protocols or 200 OK, depending on the HTTP protocol version in use). Once a connection has been matched, the client SHOULD send a successful response with a "Forwarded" header field carrying the identity of the TCP connection being relayed. After that, the client begins relaying the bytes being sent and received between the tunnel and the matched connection. The "Forwarded" header field SHOULD include the "by" parameter and the "for" parameter to convey the 4 tuple of the TCP connection being relayed. If the client cannot immediately match a connection to be relayed, the client MAY send an informational response of 100 (Continue) to acknowledge that it has received the request but it is not yet ready to send a final response. This informational response MAY be sent more than once. When the client gives up waiting for a matching connection to become available, the client SHOULD send a 204 (No Content) response to indicate that it successfully processed the request, but a matching connection was not available. illustrates an exchange of HTTP/1.1 messages to establish a reverse TCP relay.

Establishing a TCP relay for SMTP

Specifying the Listening Address and Port Clients acting as relays that allow servers specify the listening address or port SHOULD use the following URI Template to define the target URI on which they provide the service. Adopting this template simplifies operations by ensuring a uniform method for configuring endpoints. Examples are shown below: Furthermore, the use of the default template is RECOMMENDED, which is defined as "https://$CLIENT_HOST:$CLIENT_PORT/.well-known/reverse/tcp/{listen_host}/{listen_port}/", where $CLIENT_HOST and $CLIENT_PORT are the host and port of the client. The "listen_host" variable specifies the listening address. This variable MAY contain an wildcard address. The "listen_port" variable specifies the listening port. The following requirements apply to the 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 the two variables "listen_host" and "listen_port", 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 Section 2.1).
• 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.

Servers SHOULD validate the requirements above; however, servers MAY use a general-purpose URI Template implementation that lacks this specific validation. If a server detects that any of the requirements above are not met by a URI Template, the server MUST reject its configuration and abort the request without sending it to the relaying client.

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

Value:

reverse

Description:

Reverse Tunnel

Expected Version Tokens:

None

Reference:

this document

To the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at https://www.iana.org/assignments/http-fields:

Field Name:

Selected-ALPN

Template:

None

Status:

permanent

Reference:

this document

Comments:

None

To the "Well-Known URIs" registry maintained at https://www.iana.org/assignments/well-known-uris:

URI Suffix:

listen-tcp

Change Controller:

IETF

Reference:

this document

Status:

permanent

Related Information:

Includes all resources identified with the path prefix "./well-known/listen-tcp/".

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. 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. 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 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 an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. 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] Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period. This memo defines a MIME content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format for Delivery Status Notifications". It is to be issued upon a request as described in "Message Tracking Query Protocol". This memo defines only the format of the status information. An extension to SMTP to label messages for further tracking and request tracking status is defined in a separate memo. [STANDARDS-TRACK] Informative References This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64. 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 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. 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.

Acknowledgments This document is inspired by and the discussion at IETF 118. Thanks to Ben Schwartz for reviewing the initial version of the draft and providing valuable feedback.