Reverse Tunnel over HTTP

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 23 August 2024.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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 ([HTTP-SEMANTICS] Section 7.8) and the "extended CONNECT" method in HTTP/2 [EXTENDED-CONNECT-H2] and HTTP/3 [EXTENDED-CONNECT-H3] 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.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. 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.¶

GET /reverse-endpoint HTTP/1.1
Host: example.com
Connection: upgrade
Upgrade: reverse
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: reverse

4. Authentication

When HTTPS is used for establishing the tunnel, clients (i.e., the nodes acting as TLS [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 ([HTTP-SEMANTICS] Section 11), or, when HTTPS is used, by using one of the TLS-based authentication schemes.¶

5. Application-Layer Protocol Negotiation

While TLS [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 [ALPN] 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.¶

Selected-ALPN = ALPN

GET /reverse-http-for-service/X HTTP/1.1
Host: example.com
Connection: upgrade
Upgrade: reverse
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
ALPN: h2, http%2F1.1

HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: reverse
Selected-ALPN: h2

6. 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 [FORWARDED] 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.¶

GET /.well-known/listen-tcp/0.0.0.0/25/ HTTP/1.1
Host: example.com
Connection: upgrade
Upgrade: reverse
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

HTTP/1.1 100 Continue

HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: reverse
Forwarded: for=192.0.2.43

https://example.com/.well-known/reverse/tcp/{listen_host}/{listen_port}/
https://example.org/listen/to/tcp?h={listen_host}&p={listen_port}

7. 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/".¶

Acknowledgments

This document is inspired by [I-D.bt-httpbis-reverse-http-01] and the discussion at IETF 118.¶

Thanks to Ben Schwartz for reviewing the initial version of the draft and providing valuable feedback.¶

Author's Address