The Remote Rate Limiting Protocol

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 17 February 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

Privacy proxy systems such as those built on MASQUE [CONNECT-UDP], Oblivious HTTP [OHTTP], and WireGuard [WIREGUARD]. provide one common feature: they mask a client's true IP address from the targets to which clients interact with through these proxies. While this offers meaningful privacy benefits to clients, it complicates common operational security practices, such as IP addresses to help identify and mitigate abusive traffic. Examples of abusive traffic include malicious or otherwise malformed application data sent to targets through the proxies, volumetric flooding attacks, and general (distributed) denial of service (DoS) attacks. Naturally, absent some mechanism to apply granular rate limits to individual client connections, targets are left with broad sweeping mitigations that target the proxy service, such as IP-based rate limits, and therefore affect all of its clients, including those which do not engage in abusive behavior.¶

Proactively preventing abuse through (privacy-preserving) client authentication is one alternative solution that can help mitigate such abuse in practice. In particular, proxies can only admit service to authentiated clients, or targets can use privacy-preserving authentication protocols such as Privacy Pass [PRIVACY-PASS] to admit client traffic. Another type of solution might be in form of some "humanity check" such as a CAPTCHA, with the intent of making sure that some human is responsible for client traffic rather than an automated bot. However, there are several important ways in which these proactive techniques can be inadequate in practice:¶

1. Authorization decisions based on client authentication do not attest to client behavior -- they only attest to the client identity. This means that authenticated clients can still engage in abusive behavior.¶
2. Authorization decisions based on humanity checks also do not attest to client behavior. Humans interacting with an application can intentionally initiate abusive traffic.¶

Reactive mitigation mechanisms complement proactive mechanisms. Reactive mechanisms allow targets and proxy systems to work together to take corrective action to minimize or remove abusive traffic.¶

This document describes a protocol that can implement one limited form of reactive mitigation, called the remote rate limiting (RRL) protocol. RRL builds on ACME to enable seamless registration and configuration between proxies and targets. Targets use authentication information from ACME to request rate limiting actions by the target.¶

2. Terminology

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

Client:

An entity that interacts with remote services, called targets.¶

Target:

A service or resource that clients interact with.¶

Proxy:

An entity that sits between client and target.¶

Application proxy:

A proxy that relays application messages between client and target, such as an OHTTP Oblivious Relay Resource.¶

Transport proxy:

A proxy that relays end-to-end transport connections between client and target, such as a MASQUE proxy or WireGuard VPN proxy.¶

3. Threat Model

The remote rate limiting (RRL) protocol is based on the following threat model. Clients are either honest or malicious. Honest clients do not engage in abusive behavior, whereas malicious clients are carry out whatever behavior they wish, including abusive behavior. Targets can also be honest or malicious. An honest target will faithfully use the protocol to protect itself against abuse, whereas a malicious target will try to use the protocol to carry out the following goals.¶

1. Learn information about clients. The attacker aims to use the rate limiting protocol to learn information about the clients behind a proxy. This information might include, for example, the total number of clients behind a proxy, or any other information that might be useful in partitioning client anonymity sets.¶
2. Disproportionately and negatively impact honest clients. The attacker aims to misuse the rate limiting protocol to single out honest clients and cause service disruption for them.¶

Malicious clients can engage in abusive behavior with the intent of disrupting service for honest targets, or for negatively impacting the proxy service for other honest clients.¶

The proxy is assumed to be honest, since a malicious proxy could easily violate client privacy by revealing the client's IP address to targets.¶

4. Overview

Given the threat model in Section 3, the remote rate limiting (RRL) protocol is based on the following assumptions:¶

1. The definition of abuse varies widely and depends on the target service. In other words, targets are authoritative for what is considered abusive traffic that negatively affects the target.¶
2. Rate limiting rules can only be expressed in terms of behavior that can be validated by both proxy and taget. Importantly, this means that targets can only express rules in terms of information that both parties know. In other words, targets cannot express rules in terms of information they do not know. As an example, it is not possible to express rules in terms of the number of requests per client if the target does not know how many clients are behind a particular proxy, nor if the proxy does not know the number of requests that a particular client is sending because the client's connection to the target is encrypted.¶
3. Proxies cannot trust targets which cannot authenticate themselves, as this can spoofed by attackers (malicious targets). Moreover, authenticating a target does not necessarily mean the target is honest; an authenticated target can still engage in malicious behavior. As such, the rate limiting protocol cannot leak information to the the privacy proxy that it does not already know. In particular, the protocol cannot depend on application data that is encrypted and unknown to the proxy. This ensures that the protocol cannot be misused by targets in an attempt to deanonymize clients.¶
4. IP addresses are not suitable for authentication and authorization decisions. In particular, this means that proxies cannot use target IP addresses to determine whether or not a particular target message is authenticated.¶

RRL assumes that proxies are public, i.e., that targets have some realiable means of discovering or learning about a proxy. RRL is therefore not applicable to deployment scenarios where the proxy is meant to be private or otherwise does not seek to make its presence known to targets.¶

The protocol is divided into two phases: an offline registration phase (Section 4.1), wherein targets obtain authentication material used for the online phase of the protocol, and an online phase (Section 4.2), wherein targets send rate limiting rules to the proxy for enactment. The relationship between these two phases is shown in Figure 1. Details about each phase are in the following sections.¶

5. Applications

This section contains example applications of RRL that may be used to mitigate attacks enabled or otherwise exacerbated by deployed proxy technologies.¶

{
   "RateLimit-Limit": 100,
   "RateLimit-Policy": "60; scope='total'; unit='requests'",
}

{
   "RateLimit-Limit": 1024,
   "RateLimit-Policy": "60; scope='single'; unit='bandwidth'",
}

{
   "RateLimit-Limit": 10,
   "RateLimit-Policy": "60; scope='total'; unit='connections'",
}

{
   "RateLimit-Limit": 65536,
   "RateLimit-Policy": "1; scope='total'; unit='bandwidth'; w=60",
}

6. Security Considerations

The RRL protocol was motivated by the need to ensure that operational security does not regress in the name of client privacy. As such, the design of RRL intentionally restricts what sort of security mitigations can be enacted in practice. A consequence of this is that certain classes of attack may not be mitigated entirely by RRL. For example, in the case of OHTTP, it is not possible to limit the number of requests per any single client, since enforcing such a policy might be abused by malicious targets to de-anonymize clients. As such, RRL is complementary to other approaches for dealing with attacks from individual clients, such as Privacy Pass.¶

The RRL protocol is designed to allow any target which can authenticate itself to send rate limit rules to the proxy. Each rate limit rule does require the proxy to store state for enacting the rule. As such, absent restrictions, malicious targets could abuse this mechanism to exhaust resources on the proxy. In settings where this is a problem, proxies SHOULD apply some form of allow list for targets to ensure that state does not grow unbounded.¶

7. IANA Considerations

This document has no IANA actions.¶

Appendix A. Comparison to DOTS

DDoS Open Threat Signaling (DOTS) is an architecture for establishing and maintaining Distributed DoS mitigations within and between domains on the Internet [DOTS]. The RRL protocol shares similarities with DOTS. For example, in some respects, targets act as DOTS client, which detect and request mitigation of attack, and proxies act as DOTS servers, which are responsible for implementing mitigations. There are also some notable syntactical differences, e.g., the DOTS signaling protocol uses CoAP instead of HTTP. Importantly, however, the RRL protocol differs from DOTS, and in particular the DOTS signal protocol in [DOTS-SIGNALS] in several semantically meaningful ways:¶

1. DOTS only signals information about targets under attack, e.g., the target domain name, IP address range, port range, etc., without conveying any information about specifying any sort of proxy mitigation behavior. This means that it would be possible for DOTS servers (proxies) to implement mitigations that could be abused to violate the privacy goals of the proxy system. In contrast, RRL is more explicit in terms of how mitigations are applied and, importantly, what mitigations cannot be applied.¶
2. DOTS requires an active session between client (target) and server (proxy) that is kept alive via heartbeat messages. Presumably this is done to ensure that the server (proxy) mitigation state is associated with the client session. In contrast, RRL does not use sessions to keep state and instead uses HTTP semantics for state management, i.e., the server maintains a resource that authenticated clients can update as needed without maintaining an active session.¶

Note that it may be the case that these differences are not actually meaningful in practice, or that these are differences are based on a misunderstanding of DOTS.¶

Appendix B. Acknowledgements

This document was inspired by [OHTTP-RateLimit], which was focused on a variant of the problem addressed by this document and tailored specifically to work within OHTTP, rather than alongside it.¶

This document was improved by contributions and feedback from Lucas Pardue and Tommy Pauly.¶

Author's Address