< draft-rdb-ohai-feedback-to-proxy-00.txt   draft-rdb-ohai-feedback-to-proxy-01.txt >
ohai T. Reddy ohai T. Reddy
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track D. Wing Intended status: Standards Track D. Wing
Expires: 7 September 2022 Citrix Expires: 21 September 2022 Citrix
M. Boucadair M. Boucadair
Orange Orange
6 March 2022 20 March 2022
Oblivious Proxy Feedback Oblivious Proxy Feedback
draft-rdb-ohai-feedback-to-proxy-00 draft-rdb-ohai-feedback-to-proxy-01
Abstract Abstract
To provide equitable service to clients, servers often rate-limit To provide equitable service to clients, servers often rate-limit
incoming requests, often based upon the source IP address. However, incoming requests, often based upon the source IP address. However,
oblivious HTTP removes the ability for the server to distinguish oblivious HTTP removes the ability for the server to distinguish
amongst clients so the server can only rate-limit traffic from the amongst clients so the server can only rate-limit traffic from the
oblivious proxy. This harms all clients behind that oblivious proxy. oblivious proxy. This harms all clients behind that oblivious proxy.
This specification provides feedback from a server to an oblivious This specification provides feedback from a server to an oblivious
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 September 2022. This Internet-Draft will expire on 21 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Feedback Header . . . . . . . . . . . . . . . . . . . . . . . 3 3. Ohai-Proxy-Feedback Header . . . . . . . . . . . . . . . . . 4
4. Feedback Header Parameters . . . . . . . . . . . . . . . . . 4 4. Ohai-Proxy-Feedback Header Parameters . . . . . . . . . . . . 5
5. Request or Target Resource Generating Feedback Header . . . . 7 5. Request or Target Resource Generating Ohai-Proxy-Feedback
6. Proxy Processing of Feedback Header . . . . . . . . . . . . . 7 Header . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Proxy Processing of Ohai-Proxy-Feedback Header . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8.1. Registration of new HTTP Header Field . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1.1. Feedback Header . . . . . . . . . . . . . . . . . . . 8 8.1. Registration of new HTTP Header Field . . . . . . . . . . 9
8.1.2. Feedback Parameter Name Registry . . . . . . . . . . 8 8.1.1. Ohai-Proxy-Feedback Header . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8.1.2. Ohai-Proxy-Feedback Parameter Name Registry . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Oblivious HTTP [I-D.ietf-ohai-ohttp] describes a method of Oblivious HTTP [I-D.ietf-ohai-ohttp] describes a method of
encapsulation for binary HTTP messages [BINARY] using Hybrid Public encapsulation for binary HTTP messages [BINARY] using Hybrid Public
Key Encryption (HPKE; [HPKE]). This protects the content of both Key Encryption (HPKE; [HPKE]). This protects the content of both
requests and responses and enables a deployment architecture that can requests and responses and enables a deployment architecture that can
separate the identity of a requester from the request. This scheme separate the identity of a requester from the request. This scheme
requires that servers and proxies explicitly support it. The server requires that servers and proxies explicitly support it. The server
is susceptible to attacks described below, but the server cannot take is susceptible to attacks described below, but the server cannot take
skipping to change at page 3, line 12 skipping to change at page 3, line 12
Attacks against the Request and Target Resources can be classified Attacks against the Request and Target Resources can be classified
into three primary categories: into three primary categories:
1. A client sends a malformed encapsulated request causing 1. A client sends a malformed encapsulated request causing
decryption failure or decryption overload failure on the decryption failure or decryption overload failure on the
oblivious request resource. This causes the oblivious request oblivious request resource. This causes the oblivious request
resource to send an error status code back to the oblivious resource to send an error status code back to the oblivious
proxy. proxy.
2. A client sends an HTTP transaction that causes an HTTP error on 2. A client sends an HTTP transaction that causes an HTTP error on
the oblivious target tesource. This might be a malformed HTTP the oblivious target resource. This might be a malformed HTTP
request, or request for a missing resource., request, or request for a missing resource.,
3. HTTP flood: A botnet performing an HTTP flood attack against a 3. HTTP flood: A botnet performing an HTTP flood attack against a
victim's server. Because each bot in a botnet makes seemingly victim's server. Because each bot in a botnet makes seemingly
legitimate network requests the traffic is not spoofed and may legitimate network requests the traffic is not spoofed and may
appear "normal" in origin. This might be too many requests from appear "normal" in origin. This might be too many requests from
a single client, too many requests from the clients behind the a single client, too many requests from the clients behind the
same oblivious proxy or too many requests from all clients on the same oblivious proxy or too many requests from all clients on the
Internet. Internet.
This document defines how an overload indication is communicated to This document defines how an overload indication is communicated to
an oblivious proxy so that this proxy can rate limit transactions by an oblivious proxy so that this proxy can rate limit transactions by
overzealous or misbehaving clients, allowing the oblivious proxy to overzealous or misbehaving clients, allowing the oblivious proxy to
continue servicing well-behaved clients to that same oblivious target continue servicing well-behaved clients to that same oblivious target
tesource. resource.
"RateLimit Fields for HTTP" specification
[I-D.ietf-httpapi-ratelimit-headers] 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.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document makes use of the terms defined in This document makes use of the terms defined in
[I-D.ietf-ohai-ohttp]. [I-D.ietf-ohai-ohttp].
3. Feedback Header 3. Ohai-Proxy-Feedback Header
The "Feedback" header field is defined in this specification. The The "Ohai-Proxy-Feedback" header field is defined in this
Feedback header provides feedback information from the request specification. The Ohai-Proxy-Feedback header provides feedback
resource or target resource to the proxy in the HTTP response. The information from the request resource or target resource to the proxy
proxy MUST remove the Feedback header before sending the HTTP in the HTTP response. The proxy MUST remove the Ohai-Proxy-Feedback
response containing the encapsulated response to the client. If the header before sending the HTTP response containing the encapsulated
feedback information is generated by the request resource before response to the client. If the feedback information is generated by
removing the protection (including being unable to remove the request resource before removing the protection (including being
encapsulation for any reason)(see Section 6.2 of unable to remove encapsulation for any reason)(see Section 6.2 of
[I-D.ietf-ohai-ohttp]), it will result in the Feedback Header added [I-D.ietf-ohai-ohttp]), it will result in the Ohai-Proxy-Feedback
in the status code being sent without protection in response to the Header added in the status code being sent without protection in
POST request from the client. response to the POST request from the client.
Figure 1 describes the syntax (Augmented Backus-Naur Form) of the Figure 1 describes the syntax (Augmented Backus-Naur Form) of the
header field, using the grammar defined in [RFC5234] and the rules header field, using the grammar defined in [RFC5234] and the rules
defined in Section 3.2 of [RFC7230]. The field values of the header defined in Section 3.2 of [RFC7230]. The field values of the header
field conform to the same rules. field conform to the same rules.
Feedback = feedback-parameter *( OWS ";" OWS feedback-parameter) Ohai-Proxy-Feedback = feedback-parameter *( OWS ";" OWS feedback-parameter)
feedback-parameter = feedback-parameter =
feedback-parameter-name [ "=" feedback-parameter-value ] feedback-parameter-name [ "=" feedback-parameter-value ]
feedback-parameter-name = registered-token feedback-parameter-name = registered-token
registered-token = token registered-token = token
feedback-parameter-value = 1*DIGIT feedback-parameter-value = 1*DIGIT
Figure 1: Feedback Header Syntax Figure 1: Ohai-Proxy-Feedback Header Syntax
[[NOTE: CHECK IF WE CAN REUSE THE STRUCTURED FIELDS IN RFC 8941]] [[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 Optional white space (OWS) is used as defined in Section 3.2.3 of
[RFC7230] and token is used as defined in Section 3.2.6 of [RFC7230]. [RFC7230] and token is used as defined in Section 3.2.6 of [RFC7230].
The overall processing of the parameters is discussed below: The overall processing of the parameters is discussed below:
1. The order of appearance of the parameters is not significant. 1. The order of appearance of the parameters is not significant.
2. A given parameter MUST NOT appear more than once in the Feedback 2. A given parameter MUST NOT appear more than once in the Ohai-
header. Proxy-Feedback header.
3. Parameters are either optional or required, as explicited in 3. Parameters are either optional or required, as explicited in
their definitions. their definitions.
4. Parameter names are case insensitive. 4. Parameter names are case insensitive.
5. Proxies MUST ignore any parameters or values, that do not conform 5. Proxies MUST ignore any parameters or values, that do not conform
to the syntax defined in this specification. In particular, to the syntax defined in this specification. In particular,
proxies must not attempt to fix malformed parameters or parameter proxies must not attempt to fix malformed parameters or parameter
values. values.
6. If the parameter is not recognized by the proxy, it MUST be 6. If the parameter is not recognized by the proxy, it MUST be
ignored by the proxy. ignored by the proxy.
4. Feedback Header Parameters 4. Ohai-Proxy-Feedback Header Parameters
The feedback information includes the following parameters: The feedback information includes the following parameters:
c-any-req: The maximum number of HTTP requests allowed per second RateLimit-p-Limit: It indicates the maximum number of requests that
from any client interacting with the oblivious proxy. This is a the server is willing to accept from the proxy. This is an
optional parameter. optional attribute.
c-any-outstanding: The maximum number of outstanding HTTP requests RateLimit-p-Reset: It indicates the number of seconds until the
allowed from any client interacting with the oblivious proxy. maximum number of requests quota resets for the proxy. This is an
This is an optional attribute. optional attribute.
p-req: The maximum number of HTTP requests allowed per second from RateLimit-p-outstanding-Limit: It indicates the maximum number of
outstanding requests that the server is willing to accept from the
proxy. This is an optional attribute.
RateLimit-p-outstanding-Reset: It indicates the number of seconds
until the maximum number of outstanding requests quota resets for
the proxy. This is an optional attribute. the proxy. This is an optional attribute.
p-outstanding: The maximum number of outstanding HTTP requests RateLimit-Limit: It indicates the maximum number of requests that
allowed from the proxy. This is an optional attribute. the server is willing to accept from the offending client. It is
defined in Section 5.1 of [I-D.ietf-httpapi-ratelimit-headers].
This is an optional attribute.
c-req: The maximum number of HTTP requests allowed per second from RateLimit-Reset: It indicates the number of seconds until the
the client which has sent a malformed request. This is an maximum number of requests quota resets for the offending client.
optional attribute. It is defined in Section 5.3 of
[I-D.ietf-httpapi-ratelimit-headers]. This is an optional
attribute.
c-outstanding: The maximum number of outstanding HTTP requests RateLimit-Outstanding-Limit: It indicates the maximum number of
allowed from the client which has sent a malformed request. This outstanding requests that the server is willing to accept from the
is an optional attribute. offending client. This is an optional attribute.
td: The time duration the OHAI target server wants this policy RateLimit-Outstanding-Reset: It indicates the number of seconds
applied. A value of -1 indicates infinity. A value of 0 until the maximum number of outstanding requests quota resets for
indicates all currently and previously-signaled feedback the offending client. This is an optional attribute.
thresholds no longer apply. Value in seconds. This is a
mandatory attribute.
TBD: Use of any other parameters like min-encap-request-size and max- TBD: Use of any other parameters like min-encap-request-size and max-
encap-request-size to defend from garbled encapsulated requests. encap-request-size to defend from garbled encapsulated requests.
TBD: Recommended lifetime of Feedback (3600 seconds) ? TBD: RateLimit-Outstanding-Limit parameter is not specific to OHAI
and it can be added to [I-D.ietf-httpapi-ratelimit-headers].
Note that we plan to use short parameter names in future versions of Note that we plan to use short parameter names in future versions of
the draft as recommended by [I-D.ietf-httpbis-bcp56bis]. the draft as recommended by [I-D.ietf-httpbis-bcp56bis].
The above parameters are in the form of a name=value pair. The The above parameters are in the form of a "name=value" pair.
feedback information header MUST include the td parameter and atleast
one of the parameters c-any-req, c-any-outstanding, p-req,
p-outstanding, c-req or c-outstanding.
Example: A target resource receives an malformed message and generate The feedback information header MUST include at least one of the
an HTTP response with a 400 status code, it adds the "Feedback" parameters RateLimit-p-Limit, RateLimit-p-outstanding-Limit,
header to the 400 response and sends the 400 response to the request RateLimit-Limit, or RateLimit-Outstanding-Limit.
resource. The request resource copies the "Feedback" header from the
400 response, removes the "Feedback" header from the 400 response and
encapsulates the 400 response. The request resource sends a single
200 response along with the copied "Feedback" header in the 200
response and encapsulated 400 response as the response content.
+---------+ +-----------+ +----------+ +-----------+ The RateLimit-Limit, RateLimit-Reset, RateLimit-Outstanding-Limit,
| Client | | Proxy | | Request | | Target | and RateLimit-Outstanding-Reset parameters are set if the client is
| | | Resource | | Resource | | Resource | attacking the server (e.g., the client using an abnormal header that
+---------+ +-----------+ +----------+ +-----------+ matches an attack rule).
| | | |
| Encapsulated Request | | | 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
| | Encapsulated Request | | 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
| | | Request | 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
| | | |-| Identify malformed request | the response content.
| | | | |----------------------------|
| | | | +----+ +----------+ +----------+ +-----------+
| | | 400 response | | C | | Proxy | | Request | | Target |
| | |<------------------| | | | Resource | | Resource | | Resource |
| | | | +-+--+ +----+-----+ +-----+----+ +------+----+
| | 200 response with Feedback Header | | | | | |
} | and Encapsulated 400 response | | | Encapsulated | | |
| | as the response content | | +--------------------->| | |
| |<----------------------------------------| | | Request | | |
| -----------------------------\ | | | | | Encapsulated | |
| | Process Feedback Header | | | | | +--------------------->| |
| } take mitigation action |---| | | | | Request | |
| |----------------------------| | | | | | | Request | .---------.
| | | | | | +--------------------->| | Identify|
| Encapsulated 400 response | | | | | | +-+malformed|
|<---------------------------------| | | | | | | | request |
| | | | | | | 400 response | '---------'
| | |<---------------------+
| | | |
| | 200 response with | |
| | Ohai-Proxy-Feedback | |
| | Header and | |
|<---------------------+ |
.---------------------. | Encapsulated 400 | |
| Process | | response | |
| Ohai-Proxy-Feedback +--+ | |
| and applies | | | |
| rate-limit for the | | | |
| offending client | | | |
'---------------------' | | |
| | |
| | | |
| Encapsulated 400 | | |
|<---------------------+ | |
| response | | |
| | | |
Figure 2: An Example of Feedback to Proxy Figure 2: An Example of Feedback to Proxy
The response constructed by the oblivious request resource is The response constructed by the oblivious request resource is
depicted below: depicted below:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Wed, 27 March 2022 04:45:07 GMT Date: Wed, 27 March 2022 04:45:07 GMT
Cache-Control: private, no-store Cache-Control: private, no-store
Feedback: c-any-req=1000; p-any-outstanding=20000; td=600 Ohai-Proxy-Feedback: RateLimit-p-Limit=10000; RateLimit-p-Reset=600
Content-Type: message/ohttp-res Content-Type: message/ohttp-res
Content-Length: 38 <content is the encapsulated 400 response> Content-Length: 38 <content is the encapsulated 400 response>
5. Request or Target Resource Generating Feedback Header 5. Request or Target Resource Generating Ohai-Proxy-Feedback Header
When an overlaod is experienced by the request or target resource it When an overload is experienced by the request or target resource it
adds the Feedback header and parameters to request load adjustement. adds the Ohai-Proxy-Feedback header and parameters to request load
For example, when a HTTP server itself identifies high frequency or adjustment. For example, when a HTTP server itself identifies high
high volume anomalies in the traffic directed to the server it would frequency or high volume anomalies in the traffic directed to the
include the Feedback header. Ideally the Feedback header provides server it would include the Ohai-Proxy-Feedback header. Ideally the
enough detail to the oblivious proxy to avoid the server rate Ohai-Proxy-Feedback header provides enough detail to the oblivious
limiting the oblivious proxy's IP address. proxy to avoid the server rate limiting the oblivious proxy's IP
address.
6. Proxy Processing of Feedback Header 6. Proxy Processing of Ohai-Proxy-Feedback Header
When presented with a response that contains a Feedback Header, the When presented with a response that contains the Ohai-Proxy-Feedback
proxy can process the parameters in the headers and take appropriate Header, the proxy can process the parameters in the header and take
action. There is no mechanism for proxy to indicate to server that appropriate actions. There is no mechanism for the proxy to indicate
feedback information was processed or was ignored. The proxy can to the server that feedback information was processed or was ignored.
honor the rate indicated by the request resource/resource target. To The proxy can honor the rate indicated by the request resource/
that aim, the proxy may take appropriate additional actions such as resource target. To that aim, the proxy may take appropriate
(1) rate-limiting the requests from a client not to exceed requests additional actions such as (1) rate-limiting the requests from a
per second (c-req) value (2) rate-limit the outstanding HTTP requests client not to exceed requests per second (RateLimit-Limit) value (2)
from a client not to exceed outstanding requests (c-outstanding) rate-limit the outstanding HTTP requests from a client not to exceed
value. outstanding requests (RateLimit-Outstanding-Limit) value.
If the proxy ignores the feedback information, there is a risk that If the proxy ignores the feedback information, there is a risk that
the overload may still be encountered by the request and target the overload may still be encountered by the request and target
resources. More severe actions may be then taken at the server, resources. More severe actions may be, then, taken at the server,
e.g., block all the requests from this proxy for a given time e.g., block all the requests from this proxy for a given time
duration. duration.
7. Security Considerations 7. Security Considerations
The security considerations for the Oblivious HTTP protocol are The security considerations for the Oblivious HTTP protocol are
discussed in Section 8 of [I-D.ietf-ohai-ohttp]. The target and discussed in Section 8 of [I-D.ietf-ohai-ohttp]. The client needs to
request resources SHOULD convey the Feedback header to trusted trust the proxy that it does not leak the client identity to the
oblivious proxy. However, if this oblivious proxy is not trusted, server. The target and request resources SHOULD convey the Ohai-
security risks discussed below may arise: 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 * If oblivious proxy and clients attacking the server are managed by
an attacker, the attacker can use the Feedback information to an attacker, the attacker can use the Feedback information to
identify the server has detected the attack and possibly change identify the server has detected the attack and possibly change
the attack strategy. the attack strategy.
* The oblivious proxy can colloude with the attacking clients and * The oblivious proxy can colloude with the attacking clients and
leak the Feedback information to the clients. leak the Feedback information to the clients.
8. IANA Considerations 8. IANA Considerations
8.1. Registration of new HTTP Header Field 8.1. Registration of new HTTP Header Field
8.1.1. Feedback Header 8.1.1. Ohai-Proxy-Feedback Header
This section describes a header field for registration in the This section describes a header field for registration in the
Permanent Message Header Field Registry [RFC3864]. Permanent Message Header Field Registry [RFC3864].
Header field name Header field name
Feedback Feedback
Applicable protocol Applicable protocol
http http
skipping to change at page 8, line 32 skipping to change at page 9, line 32
Author/Change controller Author/Change controller
IETF IETF
Specification document(s) Specification document(s)
RFC XXXX RFC XXXX
Related information Related information
This header field is only used for Oblivious HTTP. This header field is only used for Oblivious HTTP.
8.1.2. Feedback Parameter Name Registry 8.1.2. Ohai-Proxy-Feedback Parameter Name Registry
This specification requests the creation of a new IANA registry for This specification requests the creation of a new IANA registry for
Feedback Parameter Names to be sent in the Feedback Header in Feedback Parameter Names to be sent in the Feedback Header in
accordance with the principles set out in [RFC5226]. accordance with the principles set out in [RFC5226].
As part of this registry IANA will maintain the following As part of this registry IANA will maintain the following
information: information:
Parameter Name Parameter Name
The name of the parameter. The name of the parameter.
9. Acknowledgements 9. Acknowledgements
Thanks to Rich Salz and Brandon Williams for the discussion and Thanks to Lucas Pardue, Rich Salz and Brandon Williams for the
comments. discussion and comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[BINARY] Thomson, M. and C. A. Wood, "Binary Representation of HTTP [BINARY] Thomson, M. and C. A. Wood, "Binary Representation of HTTP
Messages", Work in Progress, Internet-Draft, draft-ietf- Messages", Work in Progress, Internet-Draft, draft-ietf-
httpbis-binary-message-01, 3 February 2022, httpbis-binary-message-01, 3 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
binary-message-01>. binary-message-01>.
[HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, [HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood,
"Hybrid Public Key Encryption", Work in Progress, "Hybrid Public Key Encryption", Work in Progress,
Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg- <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
hpke-12>. hpke-12>.
[I-D.ietf-httpapi-ratelimit-headers]
Polli, R. and A. M. Ruiz, "RateLimit Fields for HTTP",
Work in Progress, Internet-Draft, draft-ietf-httpapi-
ratelimit-headers-03, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-httpapi-
ratelimit-headers-03.txt>.
[I-D.ietf-ohai-ohttp] [I-D.ietf-ohai-ohttp]
Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
Progress, Internet-Draft, draft-ietf-ohai-ohttp-01, 15 Progress, Internet-Draft, draft-ietf-ohai-ohttp-01, 15
February 2022, <https://www.ietf.org/archive/id/draft- February 2022, <https://www.ietf.org/archive/id/draft-
ietf-ohai-ohttp-01.txt>. ietf-ohai-ohttp-01.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 35 change blocks. 
136 lines changed or deleted 174 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/