Oblivious Proxy Feedback

Oblivious HTTP describes a method of encapsulation for binary HTTP messages using Hybrid Public Key Encryption (HPKE; ). This protects the content of both requests and responses and enables a deployment architecture that can separate the identity of a requester from the request. This scheme requires that servers and proxies explicitly support it. The server is susceptible to attacks described below, but the server cannot take any mitigation action per client to protect itself from various attacks -- the server can only take mitigation actions per oblivious proxy. Rate-limiting traffic from an oblivious proxy impacts all clients behind that proxy -- both misbehaving clients and well-behaved clients. Attacks against the Request and Target Resources can be classified into three primary categories: A client sends a malformed encapsulated request causing decryption failure or decryption overload failure on the oblivious request resource. This causes the oblivious request resource to send an error status code back to the oblivious proxy. A client sends an HTTP transaction that causes an HTTP error on the oblivious target resource. This might be a malformed HTTP request, or request for a missing resource., HTTP flood: A botnet performing an HTTP flood attack against a victim's server. Because each bot in a botnet makes seemingly legitimate network requests the traffic is not spoofed and may appear "normal" in origin. This might be too many requests from a single client, too many requests from the clients behind the same oblivious proxy or too many requests from all clients on the Internet. This document defines how an overload indication is communicated to an oblivious proxy so that this proxy can rate limit transactions by overzealous or misbehaving clients, allowing the oblivious proxy to continue servicing well-behaved clients to that same oblivious target resource. "RateLimit Fields for HTTP" specification allows servers to publish current service limits to clients, whereas this draft allows servers to publish current service limits to oblivious proxies. The former specification allows clients to shape their request policy and avoid being throttled out, whereas this specification allows oblivious proxies to shape their request policy and avoid being throttled out.

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. This document makes use of the terms defined in .

The "Ohai-Proxy-Feedback" header field is defined in this specification. The Ohai-Proxy-Feedback header provides feedback information from the request resource or target resource to the proxy in the HTTP response. The proxy MUST remove the Ohai-Proxy-Feedback header before sending the HTTP response containing the encapsulated response to the client. If the feedback information is generated by the request resource before removing the protection (including being unable to remove encapsulation for any reason)(see Section 6.2 of ), it will result in the Ohai-Proxy-Feedback Header added in the status code being sent without protection in response to the POST request from the client. describes the syntax (Augmented Backus-Naur Form) of the header field, using the grammar defined in and the rules defined in Section 3.2 of . The field values of the header field conform to the same rules.

[[NOTE: CHECK IF WE CAN REUSE THE STRUCTURED FIELDS IN RFC 8941]] Optional white space (OWS) is used as defined in Section 3.2.3 of and token is used as defined in Section 3.2.6 of . The overall processing of the parameters is discussed below: The order of appearance of the parameters is not significant. A given parameter MUST NOT appear more than once in the Ohai-Proxy-Feedback header. Parameters are either optional or required, as explicited in their definitions. Parameter names are case insensitive. Proxies MUST ignore any parameters or values, that do not conform to the syntax defined in this specification. In particular, proxies must not attempt to fix malformed parameters or parameter values. If the parameter is not recognized by the proxy, it MUST be ignored by the proxy.

The feedback information includes the following parameters: It indicates the maximum number of requests that the server is willing to accept from the proxy. This is an optional attribute. It indicates the number of seconds until the maximum number of requests quota resets for the proxy. This is an optional attribute. It indicates the maximum number of outstanding requests that the server is willing to accept from the proxy. This is an optional attribute. It indicates the number of seconds until the maximum number of outstanding requests quota resets for the proxy. This is an optional attribute. It indicates the maximum number of requests that the server is willing to accept from the offending client. It is defined in Section 5.1 of . This is an optional attribute. It indicates the number of seconds until the maximum number of requests quota resets for the offending client. It is defined in Section 5.3 of . This is an optional attribute. It indicates the maximum number of outstanding requests that the server is willing to accept from the offending client. This is an optional attribute. It indicates the number of seconds until the maximum number of outstanding requests quota resets for the offending client. This is an optional attribute. TBD: Use of any other parameters like min-encap-request-size and max-encap-request-size to defend from garbled encapsulated requests. TBD: RateLimit-Outstanding-Limit parameter is not specific to OHAI and it can be added to . Note that we plan to use short parameter names in future versions of the draft as recommended by . The above parameters are in the form of a "name=value" pair. The feedback information header MUST include at least one of the parameters RateLimit-p-Limit, RateLimit-p-outstanding-Limit, RateLimit-Limit, or RateLimit-Outstanding-Limit. The RateLimit-Limit, RateLimit-Reset, RateLimit-Outstanding-Limit, and RateLimit-Outstanding-Reset parameters are set if the client is attacking the server (e.g., the client using an abnormal header that matches an attack rule). Example: A target resource receives a malformed message and generates an HTTP response with a 400 status code. It adds the "Ohai-Proxy-Feedback" header with the appropriate rate limit values to the 400 response and then sends the 400 response to the request resource. The request resource copies the "Ohai-Proxy-Feedback" header from the 400 response, removes the "Ohai-Proxy-Feedback" header from the 400 response, and encapsulates the 400 response. The request resource sends a single 200 response along with the copied "Ohai-Proxy-Feedback" header in the 200 response and encapsulated 400 response as the response content.

]]>

When an overload is experienced by the request or target resource it adds the Ohai-Proxy-Feedback header and parameters to request load adjustment. For example, when a HTTP server itself identifies high frequency or high volume anomalies in the traffic directed to the server it would include the Ohai-Proxy-Feedback header. Ideally the Ohai-Proxy-Feedback header provides enough detail to the oblivious proxy to avoid the server rate limiting the oblivious proxy's IP address.

When presented with a response that contains the Ohai-Proxy-Feedback Header, the proxy can process the parameters in the header and take appropriate actions. There is no mechanism for the proxy to indicate to the server that feedback information was processed or was ignored. The proxy can honor the rate indicated by the request resource/resource target. To that aim, the proxy may take appropriate additional actions such as (1) rate-limiting the requests from a client not to exceed requests per second (RateLimit-Limit) value (2) rate-limit the outstanding HTTP requests from a client not to exceed outstanding requests (RateLimit-Outstanding-Limit) value. If the proxy ignores the feedback information, there is a risk that the overload may still be encountered by the request and target resources. More severe actions may be, then, taken at the server, e.g., block all the requests from this proxy for a given time duration.

The security considerations for the Oblivious HTTP protocol are discussed in Section 8 of . The client needs to trust the proxy that it does not leak the client identity to the server. The target and request resources SHOULD convey the Ohai-Proxy-Feedback header to trusted oblivious proxy. However, if this oblivious proxy is not trusted, security risks discussed below may arise: If oblivious proxy and clients attacking the server are managed by an attacker, the attacker can use the Feedback information to identify the server has detected the attack and possibly change the attack strategy. The oblivious proxy can colloude with the attacking clients and leak the Feedback information to the clients.

This section describes a header field for registration in the Permanent Message Header Field Registry . Feedback http standard IETF RFC XXXX This header field is only used for Oblivious HTTP.

This specification requests the creation of a new IANA registry for Feedback Parameter Names to be sent in the Feedback Header in accordance with the principles set out in . As part of this registry IANA will maintain the following information: The name of the parameter.

Thanks to Lucas Pardue, Rich Salz and Brandon Williams for the discussion and comments.