HTTPBIS B. M. Schwartz
Internet-Draft Meta Platforms, Inc.
Intended status: Standards Track T. Reddy
Expires: 11 January 2024 Nokia
10 July 2023
Reverse HTTP Transport
draft-bt-httpbis-reverse-http-00
Abstract
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 DDoS attacks when an
intermediary is in use. It allows origin server's to be hosted
without being publicly accessible but allows the clients to access
these servers via an intermediary.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-bt-reverse-http/.
Discussion of this document takes place on the HTTPBIS Working Group
mailing list (mailto:ietf-http-wg@w3.org), which is archived at
http://lists.w3.org/Archives/Public/ietf-http-wg/.
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.
Schwartz & Reddy Expires 11 January 2024 [Page 1]
Internet-Draft Reverse HTTP July 2023
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Use with transport proxies . . . . . . . . . . . . . . . 6
3.2. Discovery of client-selected intermediaries . . . . . . . 6
4. Service Binding mapping . . . . . . . . . . . . . . . . . . . 6
5. Operational Considerations . . . . . . . . . . . . . . . . . 6
5.1. Efficiency . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Connection management . . . . . . . . . . . . . . . . . . 7
5.3. Non-public origins . . . . . . . . . . . . . . . . . . . 7
5.4. Other applications . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Stolen key attacks . . . . . . . . . . . . . . . . . . . 8
6.2. IP leaks . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Key consistency with Oblivious HTTP . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1. ALPN IDs . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. New Scheme . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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)
Schwartz & Reddy Expires 11 January 2024 [Page 2]
Internet-Draft Reverse HTTP July 2023
- 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.
Schwartz & Reddy Expires 11 January 2024 [Page 3]
Internet-Draft Reverse HTTP July 2023
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.
Schwartz & Reddy Expires 11 January 2024 [Page 4]
Internet-Draft Reverse HTTP July 2023
.------------------------------.
+---------+ +----------+ | +----------+ +----------+ |
| Client | | Relay | | | Gateway | | Target | |
| | | Resource | | | Resource | | Resource | |
+----+----+ +----+-----+ | +-----+----+ +----+-----+ |
| | `-------|--------------|-------'
| | Initiate TCP | |
| | handshake | |
| |<-------------------+ |
| | Initiate TLS with | |
| | ALPN="h2-reverse" | |
| |<-------------------+ |
| | CertificateRequest,| |
| | HTTP SETTINGS | |
| +------------------->| |
| | CertificateVerify, | |
| | SETTINGS, ORIGIN | |
| |<-------------------+ |
| .-------------. | | |
| | Validate | | | |
| | certificate & |+-+| | |
| | role reversal | | | |
| `-------------' | | |
| | | |
| Relay | | |
| Request | | |
| [+ Encapsulated | | |
| Request ] | | |
+-------------------->| Gateway | |
| | Request | |
| | [+ Encapsulated | |
| | Request ] | |
| +------------------->| Request |
| | +------------->|
| | | |
| | | Response |
| | Gateway |<-------------+
| | Response | |
| | [+ Encapsulated | |
| | Response ] | |
| Relay |<-------------------+ |
| Response | | |
| [+ Encapsulated | | |
| Response ] | | |
|<--------------------+ | |
| | | |
Figure 1: Example: Reverse HTTP/2 for Oblivious HTTP
Schwartz & Reddy Expires 11 January 2024 [Page 5]
Internet-Draft Reverse HTTP July 2023
3.1. Use with transport proxies
Transport proxies do not normally act as HTTP clients, so they cannot
use Reverse HTTP directly. Instead, if a transport proxy receives a
request whose destination host and port appears in the Origin Set,
the proxy establishes a transport proxy connection to this origin
over the Reverse HTTP connection. For TCP, this corresponds to an
HTTP CONNECT request, and for UDP it corresponds to an extended-
CONNECT request with the "connect-udp" protocol, using the registered
.well-known URI template.
Note that transport destinations identified by an IP address can only
use this mechanism if the origin's certificate includes that IP
address explicitly.
For IP relays, the destination does not include a port number. The
intermediary MUST add a port number of 443 before attempting to
forward packets using this procedure.
3.2. Discovery of client-selected intermediaries
The HTTP "Via" header can indicate the presence of a client-selected
intermediary. If a "Via" header arrives with an unrecognized host,
the origin MAY attempt a Reverse HTTP connection for use by future
requests from this intermediary. If the intermediary does not
confirm the protocol via ALPN, the origin MUST close the connection.
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
Figure 2: Example records for a forward proxy that supports
Reverse HTTP
5. Operational Considerations
Schwartz & Reddy Expires 11 January 2024 [Page 6]
Internet-Draft Reverse HTTP July 2023
5.1. Efficiency
Reverse HTTP does not use appreciably more bandwidth or CPU time than
ordinary HTTP on active connections. However, it is much less
efficient for idle connections, which use memory and other
connection-related resources on the intermediary even when no
requests are being processed.
5.2. Connection management
To accommodate loss of state in firewalls or translators, especially
in the absence of application traffic, the origin SHOULD use
appropriate transport-level keepalives and MUST re-establish a new
connection when application-level communication has failed.
Origins backed by multiple servers MAY attempt to establish a
separate Reverse HTTP connection from each one in order to tolerate
equipment failures and support optimized path selection. However,
intermediaries SHOULD limit the number of idle Reverse HTTP
connections operated on behalf of each registrable domain, in order
to avoid resource exhaustion attacks.
For very high-traffic origins and multi-instance intermediaries, a
disruption could occur if the intermediary immediately directs all
user traffic onto the first Reverse HTTP connection. Very large
intermediaries SHOULD ensure that transitions to Reverse HTTP are
gradual, so that large origins have time to establish multiple
connections.
5.3. Non-public origins
In some cases, an HTTP origin may be intended exclusively for use via
one or more client-selected intermediaries that are known to the
origin. In this situation, the publication of DNS records for the
origin is OPTIONAL.
5.4. Other applications
Reverse HTTP is principally intended for use between intermediaries
and origins. It is not applicable to general HTTP clients, as it
requires the origin to know that the client will issue a request
before the request occurs. However, in cases where the HTTP client
is publicly reachable and produces frequent requests to one origin
over a long period of time, Reverse HTTP may be applicable.
Schwartz & Reddy Expires 11 January 2024 [Page 7]
Internet-Draft Reverse HTTP July 2023
6. Security Considerations
6.1. Stolen key attacks
As noted in Section 4 of [RFC8336], accepting ORIGIN frames without
DNS confirmation facilitates the use of stolen keys, and thus
increases the incentive to steal these keys. The mitigations listed
in that section also apply here, and are RECOMMENDED. Intermediaries
also MAY impose a DNS confirmation requirement, although this weakens
the DoS/DDoS defense provided by Reverse HTTP (Section 6.2).
QUESTION: Should we do more about this? For example, we could
define an OID to mark these certificates as Reverse HTTP-only, or
we could commit to an IP range by placing a MAC in a DNS record
and revealing the message via a SETTINGS value.
6.2. IP leaks
One goal of Reverse HTTP is to prevent DoS/DDoS attackers from
learning the IP addresses used by the origin to communicate with this
intermediary. This IP address can be leaked in various ways,
requiring certain mitigations:
* In the ordinary DNS address records for the origin.
- Origins SHOULD use different IPs for Reverse HTTP (unless the
intermediary imposes a DNS confirmation requirement as
described in Section 6.1).
* In the Proxy-Status HTTP header field's "next-hop" attribute.
- Intermediaries MUST NOT populate the "next-hop" attribute when
using Reverse HTTP to the origin.
* From the probes sent to intermediaries discovered from the "Via"
header field.
- Origins SHOULD use distinct, unrelated IP addresses to contact
each intermediary.
* From connection monitoring of the ALPN values in ClientHellos.
- Intermediaries MAY use a single Encrypted ClientHello
configuration for HTTP and Reverse HTTP.
* From statistical analysis of traffic patterns.
- Origins SHOULD regularly change the IP address that is used.
Schwartz & Reddy Expires 11 January 2024 [Page 8]
Internet-Draft Reverse HTTP July 2023
Even if the origin's Reverse HTTP IP addresses do leak, Reverse HTTP
still provides significant protection by simplifying the firewall
rules required to block unsolicited connections.
6.3. Key consistency with Oblivious HTTP
The security considerations for the Oblivious HTTP protocol
(Section 8 of [OHTTP]) as well as the security considerations for
Discovery of Oblivious Services via Service Binding Records
(Section 6 of [OHAI-SVCB]) apply. [CONSISTENCY] provides an analysis
of the options for ensuring the key configurations are consistent
between different clients. Clients MUST employ some technique to
mitigate key targeting attacks. Note that the option of confirming
the key with a shared proxy as described in [CONSISTENCY] will work
if the Oblivious HTTP relay and the forward proxy operate from a
single origin.
7. IANA Considerations
7.1. ALPN IDs
This document creates two new registrations in the "TLS Application-
Layer Protocol Negotiation (ALPN) Protocol IDs" registry [RFC7301]:
+==========+====================================+===============+
| Protocol | Identification Sequence | Specification |
+==========+====================================+===============+
| Reverse | 0x68 0x32 0x2d 0x72 0x65 0x76 0x65 | (This |
| HTTP/2 | 0x72 0x73 0x65 ("h2-reverse") | document) |
+----------+------------------------------------+---------------+
| Reverse | 0x68 0x33 0x2d 0x72 0x65 0x76 0x65 | (This |
| HTTP/3 | 0x72 0x73 0x65 ("h3-reverse") | document) |
+----------+------------------------------------+---------------+
Table 1
7.2. New Scheme
Per [Attrleaf], IANA is directed to add the following entry to the
DNS Underscore Global Scoped Entry Registry:
+=========+===============+============================+
| RR TYPE | _NODE NAME | Reference |
+=========+===============+============================+
| SVCB | _http-reverse | (This document, Section 4) |
+---------+---------------+----------------------------+
Table 2
Schwartz & Reddy Expires 11 January 2024 [Page 9]
Internet-Draft Reverse HTTP July 2023
TODO: Register the URI scheme as well.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
RFC 8336, DOI 10.17487/RFC8336, March 2018,
<https://www.rfc-editor.org/rfc/rfc8336>.
8.2. Informative References
[Attrleaf] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/rfc/rfc8552>.
[CONSISTENCY]
Davidson, A., Finkel, M., Thomson, M., and C. A. Wood,
"Key Consistency and Discovery", Work in Progress,
Internet-Draft, draft-ietf-privacypass-key-consistency-00,
24 October 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-privacypass-key-consistency-00>.
[I-D.draft-ietf-masque-connect-ip]
Pauly, T., Schinazi, D., Chernyakhovsky, A., Kühlewind,
M., and M. Westerlund, "Proxying IP in HTTP", Work in
Progress, Internet-Draft, draft-ietf-masque-connect-ip-13,
28 April 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-masque-connect-ip-13>.
Schwartz & Reddy Expires 11 January 2024 [Page 10]
Internet-Draft Reverse HTTP July 2023
[I-D.draft-ietf-ohai-ohttp]
Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
Progress, Internet-Draft, draft-ietf-ohai-ohttp-08, 15
March 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-ohai-ohttp-08>.
[OHAI-SVCB]
Pauly, T. and T. Reddy.K, "Discovery of Oblivious Services
via Service Binding Records", Work in Progress, Internet-
Draft, draft-ietf-ohai-svcb-config-04, 19 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ohai-
svcb-config-04>.
[OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
Progress, Internet-Draft, draft-ietf-ohai-ohttp-08, 15
March 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-ohai-ohttp-08>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9298] Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
DOI 10.17487/RFC9298, August 2022,
<https://www.rfc-editor.org/rfc/rfc9298>.
Authors' Addresses
Benjamin M. Schwartz
Meta Platforms, Inc.
Email: ietf@bemasc.net
Tirumaleswar Reddy
Nokia
Email: kondtir@gmail.com
Schwartz & Reddy Expires 11 January 2024 [Page 11]