Internet DRAFT - draft-rdb-ohai-feedback-to-proxy
draft-rdb-ohai-feedback-to-proxy
ohai T. Reddy
Internet-Draft Nokia
Intended status: Standards Track D. Wing
Expires: 15 November 2023 Citrix
M. Boucadair
Orange
R. Polli
Team Digitale, Italian Government
14 May 2023
Oblivious Relay Feedback
draft-rdb-ohai-feedback-to-proxy-09
Abstract
Servers often rate-limit incoming requests, for example, rate-limit
based upon the source IP address to provide equitable service to
clients. However, oblivious HTTP removes the ability for the server
to distinguish amongst clients so the server can only rate-limit
traffic from an Oblivious Relay Resource. This harms all clients
behind that Oblivious Relay Resource.
This specification enables a server to convey rate-limit information
to an Oblivious Relay Resource, which can use it to apply rate-limit
policies on clients. Cooperating Oblivious Relay Resources can thus
provide more equitable service to their distinguishable clients
without impacting on all clients behind that Oblivious Relay
Resource.
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 15 November 2023.
Reddy, et al. Expires 15 November 2023 [Page 1]
Internet-Draft Oblivious Relay Feedback May 2023
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Providing RateLimit Information to an Oblivious Proxy . . . . 4
4. The ohttp-target Quota Policy Parameter . . . . . . . . . . . 4
4.1. ohttp-target Parameter . . . . . . . . . . . . . . . . . 5
4.2. Processing the ohttp-target Parameter . . . . . . . . . . 5
5. The 'attack-severity' Quota Policy Parameter . . . . . . . . 6
6. Use of The ohttp-target Quota Policy Parameters: An
Example . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Ohttp-Outside-Encap Header . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.1. Avoid Correlation . . . . . . . . . . . . . . . . . . . . 9
8.2. Client and Oblivous Proxy Collusion . . . . . . . . . . . 9
8.3. Attack Categories and Mitigation . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.1. RateLimit Parameter Value Registrations . . . . . . . . . 10
9.2. Registration of new HTTP Header Field . . . . . . . . . . 10
9.2.1. Ohttp-Outside-Encap Header . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Oblivious HTTP [OHTTP] 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.
Reddy, et al. Expires 15 November 2023 [Page 2]
Internet-Draft Oblivious Relay Feedback May 2023
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 [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 Gateway and
Target Resource to provide rate-limit information to an Oblivious
Relay Resource via the RateLimit fields defined in [RATELIMIT]. 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 [RATELIMIT] 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.
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
Relay Resource", "Oblivious Gateway Resource", "Oblivious Target
Resource", and "Client" are to be interpreted as described in
Section 2.2 of [OHTTP].
Reddy, et al. Expires 15 November 2023 [Page 3]
Internet-Draft Oblivious Relay Feedback May 2023
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 [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 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:
1. Identify the quota policy associated with 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 Relay Resource.
RateLimit-Limit: 100
RateLimit-Policy: 10;w=1, 100;w=60;ohttp-target
RateLimit-Remaining: 8
RateLimit-Reset: 15
Figure 1: An Example of Oblivious Proxy Feedback.
4. The ohttp-target Quota Policy Parameter
Reddy, et al. Expires 15 November 2023 [Page 4]
Internet-Draft Oblivious Relay Feedback May 2023
4.1. ohttp-target Parameter
The following quota policy parameter is defined for the RateLimit-
Policy field [RATELIMIT]:
ohttp-target: 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.
4.2. Processing the ohttp-target Parameter
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:
1. 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.
2. 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 [OHTTP]), it will result in the RateLimit
fields added in the response being sent without protection in
response to a POST request from a client.
Reddy, et al. Expires 15 November 2023 [Page 5]
Internet-Draft Oblivious Relay Feedback May 2023
While this specification does not mandate specific traffic shaping
actions for Oblivious proxies in addition to the ones indicated in
[RATELIMIT], 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.
5. The 'attack-severity' Quota Policy Parameter
The following quota policy parameter is defined for the RateLimit-
Policy field defined in [RATELIMIT]:
attack-severity: Is used by the Oblivious Gateway Resource or Target
Resource to convey the severity of the attack. 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 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 Section 4.1
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.
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 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:
Reddy, et al. Expires 15 November 2023 [Page 6]
Internet-Draft Oblivious Relay Feedback May 2023
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 Relay Resource along with the copied
RateLimit fields.
+----+ +----------+ +----------+ +----------+
| C | | Relay | | Gateway | | Target |
| | | Resource | | Resource | | Resource |
+-+--+ +----+-----+ +-----+----+ +-----+----+
| | | |
| Encapsulated | | |
+------------------->| | |
| Request | | |
| | Encapsulated | |
| +------------------>| |
| | Request | |
| | | Request | .----------------.
| | +-------------->| | Identify |
| | | +-+ unexpected |
| | | | | request volumes|
| | | 2xx response | '----------------'
| | |<--------------+
| | | |
| | 200 response with | |
| | RateLimit-Limit, | |
| | RateLimit-Policy | |
| | fields and the | |
| | ohttp-target | |
| | parameter | |
|<------------------+ |
.--------------------. | Encapsulated 2xx | |
| Process | | response | |
| ohttp-target +-+ | |
| and rate-limit | | | |
| requests from | | | |
| clients | | | |
'--------------------' | | |
| | | |
| | | |
| Encapsulated 2xx | | |
|<--------------------+ | |
| response | | |
| | | |
Figure 2: An Example of Ratelimit Feedback to Proxy
Reddy, et al. Expires 15 November 2023 [Page 7]
Internet-Draft Oblivious Relay Feedback May 2023
The response that is generated by the Oblivious gateway 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
RateLimit-Policy: 10;ohttp-target;attack-severity="high";\
comment="Bandwidth Limit Exceeded"
Content-Type: message/ohttp-res
Content-Length: 38 <content is the encapsulated 400 response>
...encrypted content...
Figure 3: Example of a Response
7. Ohttp-Outside-Encap Header
The "Ohttp-Outside-Encap" HTTP header field is defined in this
specification (Section 9.2.1). 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.
Figure 4 describes the syntax. The syntax of this header field
conforms to [RFC8941]. It is a List ([RFC8941], Section 3.1):
Ohai-Outside-Encap = sf-list
Figure 4: Ohttp-Outside-Encap Header Syntax
Reddy, et al. Expires 15 November 2023 [Page 8]
Internet-Draft Oblivious Relay Feedback May 2023
An example is illustrated below:
Ohttp-Outside-Encap: RateLimit-Limit,RateLimit-Remaining,RateLimit-Reset,RateLimit-Policy
8. Security Considerations
The security considerations for the Oblivious HTTP protocol
(Section 8 of [OHTTP]) as well as the ones for RateLimit fields
(Section 6 of [RATELIMIT]) apply. The following sub-sections discuss
security considerations specific to this specification.
8.1. Avoid Correlation
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 [OHTTP], 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.
8.2. Client and Oblivous Proxy Collusion
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 [RATELIMIT]). The Oblivious
target and gateway resources SHOULD convey Oblivious Relay Feedback
only to trusted Oblivious proxies.
8.3. Attack Categories and Mitigation
Attacks against the Oblivious Gateway and Target Resources can be
classified into three primary categories:
1. 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.
2. 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.
Reddy, et al. Expires 15 November 2023 [Page 9]
Internet-Draft Oblivious Relay Feedback May 2023
3. 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.
9. IANA Considerations
9.1. RateLimit Parameter Value Registrations
This specification requests IANA to add the following parameters to
the "Hypertext Transfer Protocol (HTTP) RateLimit Parameters"
registry defined in [RATELIMIT].
+=================+=================+================+===============+
| Field Name |Parameter Name |Description |Specification |
+=================+=================+================+===============+
| RateLimit-Policy|ohttp-target |ohttp ratelimit |Section 3 of |
| | | |this document |
| RateLimit-Policy|attack-severity |ohttp ratelimit |Section 5 of |
| | | |this document |
+-----------------+-----------------+----------------+---------------+
9.2. Registration of new HTTP Header Field
9.2.1. Ohttp-Outside-Encap Header
This section describes a header field for registration in the
Permanent Message Header Field Registry [RFC3864].
Reddy, et al. Expires 15 November 2023 [Page 10]
Internet-Draft Oblivious Relay Feedback May 2023
Header field name
Ohttp-Outside-Encap
Applicable protocol
http
Status
Standard
Author/Change controller
IETF
Specification document(s)
RFC XXXX
Related information
This header field is only used for Oblivious HTTP.
10. Acknowledgements
Thanks to Lucas Pardue, Rich Salz, Martin Thomson, Christopher A.
Wood, Ben Schwartz, Ted Hardie and Brandon Williams for the
discussion and comments.
11. References
11.1. Normative References
[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Semantics", Work in Progress, Internet-Draft, draft-ietf-
httpbis-semantics-19, 12 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
semantics-19>.
[OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
Progress, Internet-Draft, draft-ietf-ohai-ohttp-01, 15
February 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-ohai-ohttp-01>.
[RATELIMIT]
Polli, R. and A. M. Ruiz, "RateLimit Fields for HTTP",
Work in Progress, Internet-Draft, draft-ietf-httpapi-
ratelimit-headers-05, 6 July 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-
ratelimit-headers-05>.
Reddy, et al. Expires 15 November 2023 [Page 11]
Internet-Draft Oblivious Relay Feedback May 2023
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004,
<https://www.rfc-editor.org/info/rfc3864>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8941] Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
<https://www.rfc-editor.org/info/rfc8941>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[STRUCTURED-FIELDS]
Nottingham, M. and P-H. Kamp, "Structured Field Values for
HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
<https://www.rfc-editor.org/rfc/rfc8941>.
11.2. Informative References
[SEVERITY] IANA, "Incident Object Description Exchange Format v2
(IODEF)", <https://www.iana.org/assignments/iodef2/
iodef2.xhtml#businessimpact-severity>.
Authors' Addresses
Tirumaleswar Reddy
Nokia
India
Email: kondtir@gmail.com
Reddy, et al. Expires 15 November 2023 [Page 12]
Internet-Draft Oblivious Relay Feedback May 2023
Dan Wing
Citrix Systems, Inc.
4988 Great America Pkwy
Santa Clara, CA 95054
United States of America
Email: danwing@gmail.com
Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
Roberto Polli
Team Digitale, Italian Government
Email: robipolli@gmail.com
Reddy, et al. Expires 15 November 2023 [Page 13]
