Oblivious Relay FeedbackAkamaiEmbassy Golf Link Business ParkBangaloreKarnataka560071Indiakondtir@gmail.comCitrix Systems, Inc.4988 Great America PkwySanta ClaraCA95054USAdanwing@gmail.comOrangeRennes35000Francemohamed.boucadair@orange.comTeam Digitale, Italian Governmentrobipolli@gmail.comohaiTo provide equitable service to clients, servers often rate-limit
incoming requests, for example, based upon the source IP address.
However, oblivious HTTP removes the ability for the server to
distinguish amongst clients so the server can only rate-limit traffic
from the oblivious relay. This harms all clients behind that oblivious
relay.This specification enables a server to convey rate-limit information
to an oblivious relay, which can use it to apply rate-limit policies on
clients. Cooperating oblivious relays can thus provide more equitable
service to their distinguishable clients without impacting on all
clients behind that oblivious relay.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
via the RateLimit fields defined in .
This is useful when such servers identify traffic anomalies or
unexpected request volumes. The Oblivious relay 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 (rather than to the client).How an Oblivious relay can use this information to avoid being
throttled out or shape its request policy is outside the scope of this
specification.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 .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. 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 MUST: Identify the quota policy associated to 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.The following quota policy parameter is defined for the
RateLimit-Policy field :Indicates that the associated quota
policy provides Oblivious Relay Feedback. This parameter is
OPTIONAL.The "ohttp-target" parameter has the following syntax:Its value MUST be an Integer (Section 3.3.1 of ) and indicates whether the quota
policy is applicable to all the clients that are serviced by the
Oblivious relay or applicable only to a specific client. The
"ohttp-target" parameter MUST have one of the following values:Indicates that RateLimit fields are applicable to
all the clients that are serviced by the same Oblivious relay.Indicates that RateLimit fields are applicable
only to the offending client. For example, this value is used if
the client is attacking the server (e.g., the client is using an
abnormal header that matches an attack pattern). The Oblivious relay does not immediately act to
rate-limit the traffic from the client but starts maintaining a
count of responses to the client with "ohttp-target" parameter
value set to "2" marked as "potential malicious requests" and
responses without the parameter marked as "legitimate requests".
The Oblivious relay can rate-limit
requests from the offending client for a certain duration only
when the client has a high ratio of "potential malicious requests"
to "legitimate requests". In other words, the Oblivious relay will
rate-limit requests from a client if the target has seen an attack
pattern in multiple requests from that same client. A malicious
client sends malformed HTTP requests, whereas a benign client
sends valid HTTP requests. The malformed HTTP requests are
linkable whereas the valid HTTP requests are not linkable. Most
importantly, the target will not be able to partition the
anonymity set of legitimate clients.Other values MUST cause the parameter to be ignored.The "ohttp-target" parameter MUST NOT appear more than once in a
quota policy. If the parameter is malformed or its value is invalid,
it MUST be ignored, and the receiving Oblivious relay 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 receiving RateLimit fields providing Oblivious
Relay Feedback will do the following:It MUST remove the RateLimit fields from the response, since
they are not intended to be forwarded to clients.It MAY add a new set of RateLimit fields that are intended to
be forwarded to a client.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, so that the
Oblivious 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 failing to
reshape traffic from a specific client or 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 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 resource to
convey the likeliness that an HTTP request is malicious. 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 example depicted in illustrates the
use of the "ohttp-target" parameter. An oblivious target resource
receives a malformed request and uses the source IP address to identify
that it was an encapsulated request decapsulated by an oblivious gateway
resource. The Oblivious target resource generates a 400 response and
adds the RateLimit fields along with the "ohttp-target" quota policy
parameter. 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.The response that is generated by the Oblivious gateway resource is
depicted in . This response includes an
unregistered, informative "comment" quota policy parameter providing the
rationale for the "attack- severity".The "Ohttp-Outside-Encap" header is defined in this specification
(). Its purpose is to signal which HTTP
headers will be removed by the Oblivious gateway.When an Oblivious gateway resource sends an HTTP request to an
Oblivious taget, 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 the header fields signaled in the
associated request and removes those headers 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 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 using Augmented
Backus-Naur Form (ABNF) of the header field, using the grammar defined
in and the rules defined in Section 5 of
. The field values of the header field
conform to the same rules.Optional white space (OWS) is used as defined in Section 5.6.3 of
.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.While Oblivious HTTP relies upon an Oblivious relay to prevent
leaking the client identity to the Oblivious resources, it might be
the case that the Oblivious relay 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 as an attacker. This might be too many
requests from a single client, too many requests from the clients
behind the same oblivious relay or too many requests from all
clients on the Internet.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-EncaphttpStandardIETFRFC XXXXThis
header field is only used for Oblivious HTTP.Thanks to Lucas Pardue, Rich Salz, Martin Thomson, Christopher A.
Wood and Brandon Williams for the discussion and comments.HTTP SemanticsAdobeFastlygreenbytes GmbHThe Hypertext Transfer Protocol (HTTP) is a stateless
application- level protocol for distributed, collaborative,
hypertext information systems. This document describes the overall
architecture of HTTP, establishes common terminology, and defines
aspects of the protocol that are shared by all versions. In this
definition are core protocol elements, extensibility mechanisms,
and the "http" and "https" Uniform Resource Identifier (URI)
schemes. This document updates RFC 3864 and obsoletes RFC 2818,
RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC
7694, and portions of RFC 7230.RateLimit Fields for HTTPTeam Digitale, Italian GovernmentRed HatThis document defines the RateLimit-Limit, RateLimit-Remaining,
RateLimit-Reset and RateLimit-Policy fields for HTTP, thus
allowing servers to publish current service limits and clients to
shape their request policy and avoid being throttled out.Structured Field Values for HTTPThis document describes a set of data types and associated
algorithms that are intended to make it easier and safer to define
and handle HTTP header and trailer fields, known as "Structured
Fields", "Structured Headers", or "Structured Trailers". It is
intended for use by specifications of new HTTP fields that wish to
use a common syntax that is more restrictive than traditional HTTP
field values.Oblivious HTTPMozillaCloudflareThis document describes a system for the forwarding of
encrypted HTTP messages. This allows a client to make multiple
requests of a server without the server being able to link those
requests to the client or to identify the requests as having come
from the same client.Incident Object Description Exchange Format v2
(IODEF)IANA