Oblivious Relay Feedback

Oblivious HTTP requires three parties to exchange HTTP messages: the client, the relay, and the target (formally, the Oblivious Gateway 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 relay cannot see the contents of the requests. Since clients are located behind a relay, 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 . 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 Gateway and Target Resource to provide rate-limit information to an Oblivious Relay Resource via the RateLimit fields defined in . This is useful when such servers identify traffic anomalies or unexpected request volumes. An Oblivious Relay Resource can then use this information to apply rate-limit policies on clients. While provides enough information to generic clients to shape their request policy and avoid being throttled out, this specification allows an Oblivious Gateway and Target Resource to indicate their RateLimit information is intended for the Oblivious Relay Resource (rather than to the client). How an Oblivious Relay Resource can use this information to avoid being throttled out or shape its request policy is outside the scope of this specification. The proposed mechanism does not address on purpose the attack of an offending client attacking the server (e.g., the client is using an abnormal header that matches an attack pattern) because the application of the rate-limit can potentially allow the target to take advantage of the differential treatment applied by the relay to de-anonymize the client.

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 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 . The terms "Encapsulated request", "Encapsulated response", "Oblivious Relay Resource", "Oblivious Gateway Resource", "Oblivious Target Resource", and "Client" are to be interpreted as described in Section 2.2 of . The collective term "Oblivious resource" indicates either an "Oblivious Gateway Resource" or an "Oblivious Target Resource". The terms "quota policy", "service limit", "expiring limit", and "RateLimit fields" are to be interpreted as described in . This document uses the Integer type from .

An Oblivious resource that uses RateLimit fields to return service limit information MAY add the "ohttp-target" quota policy parameter defined in to signal to the receiver that the associated quota policy is intended for an Oblivious Relay Resource. 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 Relay 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 Relay Feedback (see Section 3.1), an Oblivious Relay Resource MUST: Identify the quota policy associated with the expiring limit. Check whether the "ohttp-target" parameter is present and its syntax is correct. In the example shown in , 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 Relay Resource.

The following quota policy parameter is defined for the RateLimit-Policy field : Indicates that the associated quota policy provides Oblivious Relay Feedback and its value is empty. This parameter is OPTIONAL. It indicates that RateLimit fields are applicable to all the clients that are serviced by the same Oblivious Relay Resource. In order to offer better privacy, a relay SHOULD rate-limit all of the clients it is serving provided it will continue to forward a high volume of messages from a large number of clients even after applying the rate-limiting. A relay MUST NOT rate-limit a client or a subset of clients it is serving based on the RateLimit information from the server. The "ohttp-target" parameter MUST NOT appear more than once in a quota policy. If the parameter is malformed or has a value, it MUST be ignored, and the receiving Oblivious Relay Resource MUST NOT attempt to fix neither the parameter nor its value. That is, the RateLimit fields must not be considered as providing Oblivious Relay Feedback.

An Oblivious Relay Resource receiving RateLimit fields providing Oblivious Relay Feedback will do the following: It MUST remove all the RateLimit fields from the response, since they are not intended to be forwarded to clients. An Oblivious gateway resource receiving RateLimit fields providing Oblivious Relay Feedback MUST proceed as follows: Remove the RateLimit fields from the HTTP response, since they are not intended to be forwarded to the client. It, then, encapsulates the HTTP response. Add the above RateLimit fields to the response containing the Encapsulated Response sent to the Oblivious Relay Resource, so that the relay can access them. If the RateLimit fields along with the "ohttp-target" parameter are generated by the Oblivious gateway resource before removing the protection (including being unable to remove the encapsulation for any reason)(Section 6.2 of ), it will result in the RateLimit fields added in the response being sent without protection in response to a POST request from a client. While this specification does not mandate specific traffic shaping actions for Oblivious proxies in addition to the ones indicated in , an Oblivious Relay Resource failing to reshape traffic from all the clients according to the received Oblivious Relay Feedback can experience different levels of service denial by the Oblivious gateway and target resources. There is no explicit mechanism for an Oblivious Relay Resource to indicate to the server that the rate-limit information was processed or was ignored.

The following quota policy parameter is defined for the RateLimit-Policy field defined in : Is used by the Oblivious Gateway Resource or Target Resource to convey the severity of the attack. This parameter is OPTIONAL.

Note that sf-string is defined in Section 3.3.3 of . The value of the "attack-severity" parameter is a String (Section 3.3.3 of ) that takes one of the values defined in . 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 relays MUST NOT attempt to fix neither the parameter nor the value. The severity of the attack may be used as an operational alert to the Oblivious Relay Resource's security operation team and to automatically trigger the rate-limit mitigation action accordingly. Irrespective of the security level at which a rate-limit is triggered, the relay must follow the rules discussed in to offer privacy to the clients it is serving. The severity of the attack can also be used to identify a "ramp-up" attack versus a "blast" attack.

The example depicted in illustrates the use of the "ohttp-target" parameter. An oblivious target resource receives unexpected request volumes and uses the source IP address to identify that these were Encapsulated Requests decapsulated by an oblivious gateway resource. The Oblivious target resource adds the RateLimit fields along with the "ohttp-target" quota policy parameter to the HTTP response. The oblivious gateway resource proceeds as follows: Copy the RateLimit fields from the original response. Remove them from the original response before encapsulating it. Generate a single 200 response containing the encapsulated response for the Oblivious Relay Resource along with the copied RateLimit fields.

...encrypted content... ]]>

The "Ohttp-Outside-Encap" HTTP header field is defined in this specification (). Its purpose is to signal which HTTP headers will be removed by the Oblivious gateway. It is intended only for use in requests to an Oblivious target. When an Oblivious gateway resource sends an HTTP request to an Oblivious target, it adds the "Ohttp-Outside-Encap" header to indicate which headers will be removed from the response. On receipt of an HTTP response from the Oblivious target resource, the Oblivious gateway resource copies those header fields and values, and it then removes them from the HTTP response. The Oblivious gateway then encapsulates the HTTP response. The Oblivious gateway resource adds the copied header fields and values to the response containing the Encapsulated Response, so that the Oblivious Relay Resource can access and act on them. The "Ohttp-Outside-Encap" header is useful in deployments where the Oblivious gateway resource and Oblivious target resource are managed by separate entities. describes the syntax. The syntax of this header field conforms to . It is a List (, Section 3.1):

An example is illustrated below:

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

If the Oblivious Relay Resource attempts to divide the rate limit fairly among the active clients, the timing pattern of requests can possibly be strongly correlated by the to gateway to de-anonymize clients. As discussed in Section 5 of , the relay can delay requests before forwarding them to migitate the attack as it will likely increase the anonymity set into which each request is attributed.

While Oblivious HTTP relies upon an Oblivious Relay Resource to prevent leaking the client identity to the Oblivious resources, it might be the case that the Oblivious Relay Resource colludes with clients in attacking Oblivious resources. RateLimit fields might disclose operational capacity information useful to design denial of service attacks or to circumvent defensive measures put in place by the Oblivious resources (Section 6.2 of ). The Oblivious target and gateway resources SHOULD convey Oblivious Relay Feedback only to trusted Oblivious proxies.

Attacks against the Oblivious Gateway and Target Resources can be classified into three primary categories: A client deliberately sends a malformed Encapsulated Request causing decryption failure or decryption overload failure on the oblivious gateway resource. This causes the oblivious gateway resource to send an error status code back to the oblivious relay. A client deliberately sends an HTTP request that causes an HTTP error on the oblivious target resource. This might be a malformed HTTP request, or request for a missing resource. A botnet performing an application layer denial of service attack (e.g., HTTP flood) against an Oblivious resource. Because each bot in a botnet makes seemingly legitimate network requests the traffic may appear "normal" in origin, nonetheless as a whole it not only can saturate the Oblivious resources, but also makes appear the Oblivious Relay Resource as an attacker. There might be too many requests from a single client, too many requests from the clients behind the same Oblivious Relay Resource, or too many requests from all clients on the Internet. Typicially, a DDoS attack mitigation service (DMS) would be used to analyze and filter application-level DDoS attacks. DMSes use rate-limiting as one of the techniques to mitigate the impact of DDoS attacks. A DMS could trigger the rate-limiting only when the capacity of the mitigation service is exceeded (or exceeding a threshold). However, some DMSes may use rate-limiting as a first line of defense against attacks, while other DMSes may use it as a secondary measure when other techniques (e.g., traffic filtering) are not sufficient. A DMS can leverage the mechanism defined in this document to avoid rate-limiting traffic from the Oblivious Relay Resource. If the relay fails to act, it can potentially experience different levels of service denial by the DMS.

This specification requests IANA to add the following parameters to the "Hypertext Transfer Protocol (HTTP) RateLimit Parameters" registry defined in .

This section describes a header field for registration in the Permanent Message Header Field Registry . Ohttp-Outside-Encap http Standard IETF RFC XXXX This header field is only used for Oblivious HTTP.

Thanks to Lucas Pardue, Rich Salz, Martin Thomson, Christopher A. Wood, Ben Schwartz, Ted Hardie and Brandon Williams for the discussion and comments.