Reverse HTTP Transport

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 11 January 2024.¶

Copyright Notice

Copyright (c) 2023 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

The HTTP protocol has long supported the ability of clients to access origins via an intermediary. There are now a variety of well-defined intermediary types:¶

• Client-selected¶

  • HTTP request proxies (a.k.a. forward proxies)¶
  • Transport proxies (e.g., CONNECT (see Section 9.3.6 of [RFC9110]), CONNECT-UDP [RFC9298])¶
  • IP relays (e.g., CONNECT-IP [I-D.draft-ietf-masque-connect-ip])¶
  • Oblivious HTTP Relays [I-D.draft-ietf-ohai-ohttp]¶

• Origin-selected¶

  • HTTP gateways (a.k.a. reverse proxies)¶
  • Transport load balancers¶

Although these intermediaries differ widely in their functionality, they all generally act as a client when connecting to the origin. Client-selected intermediaries reach the origin based on its hostname or IP address specified in the HTTP request, while origin-selected intermediaries first translate this destination into a "backend address".¶

One of the main advantages of origin-selected intermediaries is their ability to defend the origin from attacks, especially Denial of Service (DoS) and Distributed Denial-of-Service (DDoS) attacks in which the attacker floods the origin server with requests or packets. To prevent attackers from simply bypassing the intermediary, common practices include keeping the backend address secret and/or instituting firewall rules that only allow packets from the intermediary. These practices are reasonably effective with origin-selected intermediaries, but they cannot be used with client-selected intermediaries, as those intermediaries do not know the secret backend address, and the origin does not know their "exit" IP addresses.¶

This specification defines a protocol for HTTP connections between origins and arbitrary intermediaries that can limit the impact of Layer 3 and Layer 4 DDoS attacks. When this protocol is in use, origins have the ability to partition the infrastructure that serves each intermediary. This ensures that attacks targeting the origin's public IP address or attacks via one intermediary will not affect any other intermediaries. By partitioning the infrastructure, the impact of the attacks is contained within the affected intermediary or the origin's public IP address.¶

This protocol works by reversing the TLS or QUIC transport that supports the HTTP connection: the origin acts as the transport client, and the intermediary acts as the server. Inside the secure transport, HTTP operates normally, but with the client and server roles reversed.¶

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. Protocol

The new protocol is termed "Reverse HTTP". The "Reverse HTTP/2" version is identified by the ALPN ID "h2-reverse", and "Reverse HTTP/3" by "h3-reverse" (see Section 7.1 for registrations). These protocols represent HTTP/2 and HTTP/3, operating with the roles reversed but otherwise unmodified, except as follows:¶

• The intermediary MUST send a TLS CertificateRequest message to indicate that certificate-based client authentication is required.¶
• The origin MUST respond with a valid certificate chain.¶
• Each party MUST send a SETTINGS frame as soon as the transport becomes writable to them. This means that the intermediary will typically send its SETTINGS frame first.¶

• The origin MUST immediately send an ORIGIN frame identifying the origins it claims. This frame is used as originally defined, except that wildcard names are permitted (contrary to Section 2.2 of [RFC8336]).¶

  • Otherwise, use of Reverse HTTP with wildcard certificates would be impossible.¶
• The intermediary MUST check the ORIGIN frame contents against the provided TLS client certificate.¶

Reverse HTTP/1.1 is not defined, as the lack of multiplexing renders it unsuitable for this use.¶

Once this process has completed, the origin has proved ownership of the Origin Set and is ready to receive requests. The intermediary SHOULD direct subsequent HTTP requests for this origin over this Reverse HTTP channel unless it appears to be overloaded.¶

4. Service Binding mapping

Intermediaries that support Reverse HTTP SHOULD indicate this by publishing a SVCB record with port-prefix naming, using the scheme "http-reverse" with a default port of 443. Applicable SvcParamKeys include "alpn", "ipv4hint"/"ipv6hint", "port", and "ech". There is no default ALPN value, so the "alpn" key is REQUIRED.¶

proxy.example.net.               IN HTTPS 1 . alpn=h2,h3 ech=ABC..123
_http-reverse.proxy.example.net. IN SVCB  1 proxy.example.net. \
      alpn=h2-reverse,h3-reverse ech=ABC..123

5. Operational Considerations

6. Security Considerations

7. IANA Considerations

Authors' Addresses