Oblivious Proxy Feedback

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 24 November 2022.¶

Copyright Notice

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

Oblivious HTTP [OHTTP] requires three parties to exchange HTTP messages: the client, the proxy, and the target (formally, the Oblivious Request Resource and Oblivious Target Resource). Oblivious HTTP enables a client to send requests to a target in such a way that the target cannot tell whether two requests came from the same client, and the proxy cannot see the contents of the requests.¶

Since oblivious clients are located behind a proxy, a target cannot distinguish between well-behaving and malicious clients: an unexpected behavior from one or more clients can then impact on all the intermediated clients, as described in Section 8.2.1 of [OHTTP]. This can be problematic when the target implements rate limiting policies based on an information masked by the intermediary, such as the source IP address.¶

This document defines a mechanism that allows Oblivious request and target resource to provide rate-limit information to an Oblivious proxy via the RateLimit fields defined in [RATELIMIT]. This is useful when such servers identify traffic anomalies or unexpected request volumes. The Oblivious proxy can then use this information to apply rate-limit policies on oblivious clients.¶

While [RATELIMIT] provides enough information to generic clients to shape their request policy and avoid being throttled out, this specification allows an Oblivious request and target resource to indicate their RateLimit information is intended for the Oblivious proxy (rather than to the client).¶

How an Oblivious proxy can use this information to avoid being throttled out or shape its request policy is outside the scope of this specification.¶

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

The terms "content", "receiver", "request", and "response" are to be interpreted as described in [HTTP].¶

The terms "Encapsulated request", "Encapsulated response", "Oblivious proxy resource", "Oblivious request resource", "Oblivious target resource", and "Client" are to be interpreted as described in [OHTTP].¶

The collective term "Oblivious resource" indicates either an "Oblivious request resource" or an "Oblivious target resource".¶

The terms "quota policy", "service limit", "expiring limit", and "RateLimit fields" are to be interpreted as described in [RATELIMIT].¶

This document uses the Integer type from [STRUCTURED-FIELDS].¶

3. Providing RateLimit Information to an Oblivious Proxy

An Oblivious resource that uses RateLimit fields [RATELIMIT] to return service limit information MAY add the "ohttp-target" quota policy parameter defined in Section 4 to signal to the receiver that the associated quota policy is intended for an Oblivious proxy. For example, when an Oblivious target identifies a high frequency or high volume anomalies in the HTTP requests it would include the "ohttp-target" parameter.¶

The term "Oblivious Proxy Feedback" denotes both the mechanism described in this specification and the complete set of RateLimit fields together with the "ohttp-target" parameter.¶

To know whether the RateLimit fields provides Oblivious Proxy Feedback (see Section 3.1), an Oblivious proxy MUST:¶

1. Identify the quota policy associated to the expiring limit.¶
2. Check whether the "ohttp-target" parameter is present and its syntax is correct.¶

In the example shown in Figure 1, the expiring limit value is "100", so the associated quota policy is the second one. This quota policy includes the "ohttp-target" parameter: this indicates that the RateLimit fields are intended for an Oblivious proxy.¶

   RateLimit-Limit: 100, 10;w=1, 100;w=60;ohttp-target=1
   RateLimit-Remaining: 8
   RateLimit-Reset: 15

4. The ohttp-target Quota Policy Parameter

ohttp-target = sf-integer

5. The attack-severity Quota Policy Parameter

The following quota policy parameter is defined for the RateLimit-Limit field defined in [RATELIMIT]:¶

attack-severity:

Is used by the Oblivious resource to convey the likeliness that an Oblivious request is malicious. This parameter is OPTIONAL.¶

attack-severity = sf-string

Note that sf-string is defined in Section 3.3.3 of [STRUCTURED-FIELDS].¶

The value of the "attack-severity" parameter is a String (Section 3.3.3 of [RFC8941]) that takes one of the values defined in [SEVERITY]. This parameter MUST NOT appear more than once in a quota policy. If the parameter is malformed or its value is invalid, the parameter MUST be ignored, and the proxies MUST NOT attempt to fix neither the parameter nor the value.¶

6. Use of The ohttp-target Quota Policy Parameters: An Example

The example depicted in Figure 2 illustrates the use of the "ohttp-target" parameter. An oblivious target resource receives a malformed message and uses the source IP address to identify that it was an oblivious HTTP request decapsulated by an oblivious request resource. The Oblivious target resource generates a 400 response and adds the RateLimit fields along with the "ohttp-target" quota policy parameter. The oblivious request resource proceeds as follows:¶

1. Copy the RateLimit fields from the original response.¶
2. Remove them from the original response before encapsulating it.¶
3. Generate a single 200 response containing the encapsulated response for the oblivious proxy resource along with the copied RateLimit fields.¶

+----+            +----------+       +----------+    +----------+
| C  |            | Proxy    |       | Request  |    | Target   |
|    |            | Resource |       | Resource |    | Resource |
+-+--+            +----+-----+       +-----+----+    +-----+----+
  |                    |                   |               |
  | Encapsulated       |                   |               |
  +------------------->|                   |               |
  |  Request           |                   |               |
  |                    | Encapsulated      |               |
  |                    +------------------>|               |
  |                    |  Request          |               |
  |                    |                   | Request       | .---------.
  |                    |                   +-------------->| | Identify|
  |                    |                   |               +-+malformed|
  |                    |                   |               | | request |
  |                    |                   |  400 response | '---------'
  |                    |                   |<--------------+
  |                    |                   |               |
  |                    | 200 response with |               |
  |                    | RateLimit-Limit   |               |
  |                    | field and the     |               |
  |                    | ohttp-target      |               |
  |                    | parameter         |               |
                       |<------------------+               |
.--------------------. | Encapsulated 400  |               |
| Process            | |    response       |               |
| ohttp-target       +-+                   |               |
| and shadowban      |  |                  |               |
| requests from the  |  |                  |               |
| offending client   |  |                  |               |
'--------------------'  |                  |               |
                        |                  |               |
  |                     |                  |               |
  | Encapsulated 400    |                  |               |
  |<--------------------+                  |               |
  |     response        |                  |               |
  |                     |                  |               |

The response that is generated by the Oblivious request resource is depicted in Figure 3. This response includes an unregistered, informative "comment" quota policy parameter providing the rationale for the "attack- severity".¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

  HTTP/1.1 200 OK
  Date: Wed, 27 March 2022 04:45:07 GMT
  Cache-Control: private, no-store
  RateLimit-Limit: 10,10;ohttp-target=2;attack-severity="high";\
comment="abnormal header matching a WAF rule"
  Content-Type: message/ohttp-res
  Content-Length: 38 <content is the encapsulated 400 response>
  ...encrypted content...

7. Security Considerations

The security considerations for the Oblivious HTTP protocol (Section 8 of [OHTTP]) as well as the ones for RateLimit-Limit fields (Section 6 of [RATELIMIT]) apply. The following sub-sections discuss security considerations specific to this specification.¶

8. IANA Considerations

+=================+=================+================+===============+
| Field Name      |Parameter Name   |Description     |Specification  |
+=================+=================+================+===============+
| RateLimit-Limit |ohttp-target     |ohttp ratelimit |Section 3 of   |
|                 |                 |                |this document  |
| RateLimit-Limit |attack-severity  |ohttp ratelimit |Section 5 of   |
|                 |                 |                |this document  |
+-----------------+-----------------+----------------+---------------+

Authors' Addresses