| < 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/ | ||||