idnits 2.17.1 draft-rdb-ohai-feedback-to-proxy-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (20 March 2022) is 765 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-ietf-httpbis-binary-message-01 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-hpke (ref. 'HPKE') == Outdated reference: A later version (-07) exists of draft-ietf-httpapi-ratelimit-headers-03 == Outdated reference: A later version (-10) exists of draft-ietf-ohai-ohttp-01 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ohai T. Reddy 3 Internet-Draft Akamai 4 Intended status: Standards Track D. Wing 5 Expires: 21 September 2022 Citrix 6 M. Boucadair 7 Orange 8 20 March 2022 10 Oblivious Proxy Feedback 11 draft-rdb-ohai-feedback-to-proxy-01 13 Abstract 15 To provide equitable service to clients, servers often rate-limit 16 incoming requests, often based upon the source IP address. However, 17 oblivious HTTP removes the ability for the server to distinguish 18 amongst clients so the server can only rate-limit traffic from the 19 oblivious proxy. This harms all clients behind that oblivious proxy. 21 This specification provides feedback from a server to an oblivious 22 proxy, enabling the oblivious proxy to rate-limit incoming requests 23 from clients. Cooperating oblivious proxies can thus provide more 24 equitable service to their distinguishable clients without triggering 25 rate-limiting on the request resource or the target resource that 26 would impact all clients behind that Oblivious proxy. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 21 September 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Ohai-Proxy-Feedback Header . . . . . . . . . . . . . . . . . 4 64 4. Ohai-Proxy-Feedback Header Parameters . . . . . . . . . . . . 5 65 5. Request or Target Resource Generating Ohai-Proxy-Feedback 66 Header . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6. Proxy Processing of Ohai-Proxy-Feedback Header . . . . . . . 8 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 8.1. Registration of new HTTP Header Field . . . . . . . . . . 9 71 8.1.1. Ohai-Proxy-Feedback Header . . . . . . . . . . . . . 9 72 8.1.2. Ohai-Proxy-Feedback Parameter Name Registry . . . . . 9 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 10.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 Oblivious HTTP [I-D.ietf-ohai-ohttp] describes a method of 82 encapsulation for binary HTTP messages [BINARY] using Hybrid Public 83 Key Encryption (HPKE; [HPKE]). This protects the content of both 84 requests and responses and enables a deployment architecture that can 85 separate the identity of a requester from the request. This scheme 86 requires that servers and proxies explicitly support it. The server 87 is susceptible to attacks described below, but the server cannot take 88 any mitigation action per client to protect itself from various 89 attacks -- the server can only take mitigation actions per oblivious 90 proxy. Rate-limiting traffic from an oblivious proxy impacts all 91 clients behind that proxy -- both misbehaving clients and well- 92 behaved clients. 94 Attacks against the Request and Target Resources can be classified 95 into three primary categories: 97 1. A client sends a malformed encapsulated request causing 98 decryption failure or decryption overload failure on the 99 oblivious request resource. This causes the oblivious request 100 resource to send an error status code back to the oblivious 101 proxy. 103 2. A client sends an HTTP transaction that causes an HTTP error on 104 the oblivious target resource. This might be a malformed HTTP 105 request, or request for a missing resource., 107 3. HTTP flood: A botnet performing an HTTP flood attack against a 108 victim's server. Because each bot in a botnet makes seemingly 109 legitimate network requests the traffic is not spoofed and may 110 appear "normal" in origin. This might be too many requests from 111 a single client, too many requests from the clients behind the 112 same oblivious proxy or too many requests from all clients on the 113 Internet. 115 This document defines how an overload indication is communicated to 116 an oblivious proxy so that this proxy can rate limit transactions by 117 overzealous or misbehaving clients, allowing the oblivious proxy to 118 continue servicing well-behaved clients to that same oblivious target 119 resource. 121 "RateLimit Fields for HTTP" specification 122 [I-D.ietf-httpapi-ratelimit-headers] allows servers to publish 123 current service limits to clients, whereas this draft allows servers 124 to publish current service limits to oblivious proxies. The former 125 specification allows clients to shape their request policy and avoid 126 being throttled out, whereas this specification allows oblivious 127 proxies to shape their request policy and avoid being throttled out. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119][RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 This document makes use of the terms defined in 138 [I-D.ietf-ohai-ohttp]. 140 3. Ohai-Proxy-Feedback Header 142 The "Ohai-Proxy-Feedback" header field is defined in this 143 specification. The Ohai-Proxy-Feedback header provides feedback 144 information from the request resource or target resource to the proxy 145 in the HTTP response. The proxy MUST remove the Ohai-Proxy-Feedback 146 header before sending the HTTP response containing the encapsulated 147 response to the client. If the feedback information is generated by 148 the request resource before removing the protection (including being 149 unable to remove encapsulation for any reason)(see Section 6.2 of 150 [I-D.ietf-ohai-ohttp]), it will result in the Ohai-Proxy-Feedback 151 Header added in the status code being sent without protection in 152 response to the POST request from the client. 154 Figure 1 describes the syntax (Augmented Backus-Naur Form) of the 155 header field, using the grammar defined in [RFC5234] and the rules 156 defined in Section 3.2 of [RFC7230]. The field values of the header 157 field conform to the same rules. 159 Ohai-Proxy-Feedback = feedback-parameter *( OWS ";" OWS feedback-parameter) 160 feedback-parameter = 161 feedback-parameter-name [ "=" feedback-parameter-value ] 162 feedback-parameter-name = registered-token 163 registered-token = token 164 feedback-parameter-value = 1*DIGIT 166 Figure 1: Ohai-Proxy-Feedback Header Syntax 168 [[NOTE: CHECK IF WE CAN REUSE THE STRUCTURED FIELDS IN RFC 8941]] 170 Optional white space (OWS) is used as defined in Section 3.2.3 of 171 [RFC7230] and token is used as defined in Section 3.2.6 of [RFC7230]. 173 The overall processing of the parameters is discussed below: 175 1. The order of appearance of the parameters is not significant. 177 2. A given parameter MUST NOT appear more than once in the Ohai- 178 Proxy-Feedback header. 180 3. Parameters are either optional or required, as explicited in 181 their definitions. 183 4. Parameter names are case insensitive. 185 5. Proxies MUST ignore any parameters or values, that do not conform 186 to the syntax defined in this specification. In particular, 187 proxies must not attempt to fix malformed parameters or parameter 188 values. 190 6. If the parameter is not recognized by the proxy, it MUST be 191 ignored by the proxy. 193 4. Ohai-Proxy-Feedback Header Parameters 195 The feedback information includes the following parameters: 197 RateLimit-p-Limit: It indicates the maximum number of requests that 198 the server is willing to accept from the proxy. This is an 199 optional attribute. 201 RateLimit-p-Reset: It indicates the number of seconds until the 202 maximum number of requests quota resets for the proxy. This is an 203 optional attribute. 205 RateLimit-p-outstanding-Limit: It indicates the maximum number of 206 outstanding requests that the server is willing to accept from the 207 proxy. This is an optional attribute. 209 RateLimit-p-outstanding-Reset: It indicates the number of seconds 210 until the maximum number of outstanding requests quota resets for 211 the proxy. This is an optional attribute. 213 RateLimit-Limit: It indicates the maximum number of requests that 214 the server is willing to accept from the offending client. It is 215 defined in Section 5.1 of [I-D.ietf-httpapi-ratelimit-headers]. 216 This is an optional attribute. 218 RateLimit-Reset: It indicates the number of seconds until the 219 maximum number of requests quota resets for the offending client. 220 It is defined in Section 5.3 of 221 [I-D.ietf-httpapi-ratelimit-headers]. This is an optional 222 attribute. 224 RateLimit-Outstanding-Limit: It indicates the maximum number of 225 outstanding requests that the server is willing to accept from the 226 offending client. This is an optional attribute. 228 RateLimit-Outstanding-Reset: It indicates the number of seconds 229 until the maximum number of outstanding requests quota resets for 230 the offending client. This is an optional attribute. 232 TBD: Use of any other parameters like min-encap-request-size and max- 233 encap-request-size to defend from garbled encapsulated requests. 235 TBD: RateLimit-Outstanding-Limit parameter is not specific to OHAI 236 and it can be added to [I-D.ietf-httpapi-ratelimit-headers]. 238 Note that we plan to use short parameter names in future versions of 239 the draft as recommended by [I-D.ietf-httpbis-bcp56bis]. 241 The above parameters are in the form of a "name=value" pair. 243 The feedback information header MUST include at least one of the 244 parameters RateLimit-p-Limit, RateLimit-p-outstanding-Limit, 245 RateLimit-Limit, or RateLimit-Outstanding-Limit. 247 The RateLimit-Limit, RateLimit-Reset, RateLimit-Outstanding-Limit, 248 and RateLimit-Outstanding-Reset parameters are set if the client is 249 attacking the server (e.g., the client using an abnormal header that 250 matches an attack rule). 252 Example: A target resource receives a malformed message and generates 253 an HTTP response with a 400 status code. It adds the "Ohai-Proxy- 254 Feedback" header with the appropriate rate limit values to the 400 255 response and then sends the 400 response to the request resource. 256 The request resource copies the "Ohai-Proxy-Feedback" header from the 257 400 response, removes the "Ohai-Proxy-Feedback" header from the 400 258 response, and encapsulates the 400 response. The request resource 259 sends a single 200 response along with the copied "Ohai-Proxy- 260 Feedback" header in the 200 response and encapsulated 400 response as 261 the response content. 263 +----+ +----------+ +----------+ +-----------+ 264 | C | | Proxy | | Request | | Target | 265 | | | Resource | | Resource | | Resource | 266 +-+--+ +----+-----+ +-----+----+ +------+----+ 267 | | | | 268 | Encapsulated | | | 269 +--------------------->| | | 270 | Request | | | 271 | | Encapsulated | | 272 | +--------------------->| | 273 | | Request | | 274 | | | Request | .---------. 275 | | +--------------------->| | Identify| 276 | | | +-+malformed| 277 | | | | | request | 278 | | | 400 response | '---------' 279 | | |<---------------------+ 280 | | | | 281 | | 200 response with | | 282 | | Ohai-Proxy-Feedback | | 283 | | Header and | | 284 |<---------------------+ | 285 .---------------------. | Encapsulated 400 | | 286 | Process | | response | | 287 | Ohai-Proxy-Feedback +--+ | | 288 | and applies | | | | 289 | rate-limit for the | | | | 290 | offending client | | | | 291 '---------------------' | | | 292 | | | 293 | | | | 294 | Encapsulated 400 | | | 295 |<---------------------+ | | 296 | response | | | 297 | | | | 299 Figure 2: An Example of Feedback to Proxy 301 The response constructed by the oblivious request resource is 302 depicted below: 304 HTTP/1.1 200 OK 305 Date: Wed, 27 March 2022 04:45:07 GMT 306 Cache-Control: private, no-store 307 Ohai-Proxy-Feedback: RateLimit-p-Limit=10000; RateLimit-p-Reset=600 308 Content-Type: message/ohttp-res 309 Content-Length: 38 311 5. Request or Target Resource Generating Ohai-Proxy-Feedback Header 313 When an overload is experienced by the request or target resource it 314 adds the Ohai-Proxy-Feedback header and parameters to request load 315 adjustment. For example, when a HTTP server itself identifies high 316 frequency or high volume anomalies in the traffic directed to the 317 server it would include the Ohai-Proxy-Feedback header. Ideally the 318 Ohai-Proxy-Feedback header provides enough detail to the oblivious 319 proxy to avoid the server rate limiting the oblivious proxy's IP 320 address. 322 6. Proxy Processing of Ohai-Proxy-Feedback Header 324 When presented with a response that contains the Ohai-Proxy-Feedback 325 Header, the proxy can process the parameters in the header and take 326 appropriate actions. There is no mechanism for the proxy to indicate 327 to the server that feedback information was processed or was ignored. 328 The proxy can honor the rate indicated by the request resource/ 329 resource target. To that aim, the proxy may take appropriate 330 additional actions such as (1) rate-limiting the requests from a 331 client not to exceed requests per second (RateLimit-Limit) value (2) 332 rate-limit the outstanding HTTP requests from a client not to exceed 333 outstanding requests (RateLimit-Outstanding-Limit) value. 335 If the proxy ignores the feedback information, there is a risk that 336 the overload may still be encountered by the request and target 337 resources. More severe actions may be, then, taken at the server, 338 e.g., block all the requests from this proxy for a given time 339 duration. 341 7. Security Considerations 343 The security considerations for the Oblivious HTTP protocol are 344 discussed in Section 8 of [I-D.ietf-ohai-ohttp]. The client needs to 345 trust the proxy that it does not leak the client identity to the 346 server. The target and request resources SHOULD convey the Ohai- 347 Proxy-Feedback header to trusted oblivious proxy. However, if this 348 oblivious proxy is not trusted, security risks discussed below may 349 arise: 351 * If oblivious proxy and clients attacking the server are managed by 352 an attacker, the attacker can use the Feedback information to 353 identify the server has detected the attack and possibly change 354 the attack strategy. 356 * The oblivious proxy can colloude with the attacking clients and 357 leak the Feedback information to the clients. 359 8. IANA Considerations 361 8.1. Registration of new HTTP Header Field 363 8.1.1. Ohai-Proxy-Feedback Header 365 This section describes a header field for registration in the 366 Permanent Message Header Field Registry [RFC3864]. 368 Header field name 369 Feedback 371 Applicable protocol 372 http 374 Status 375 standard 377 Author/Change controller 378 IETF 380 Specification document(s) 381 RFC XXXX 383 Related information 384 This header field is only used for Oblivious HTTP. 386 8.1.2. Ohai-Proxy-Feedback Parameter Name Registry 388 This specification requests the creation of a new IANA registry for 389 Feedback Parameter Names to be sent in the Feedback Header in 390 accordance with the principles set out in [RFC5226]. 392 As part of this registry IANA will maintain the following 393 information: 395 Parameter Name 396 The name of the parameter. 398 9. Acknowledgements 400 Thanks to Lucas Pardue, Rich Salz and Brandon Williams for the 401 discussion and comments. 403 10. References 405 10.1. Normative References 407 [BINARY] Thomson, M. and C. A. Wood, "Binary Representation of HTTP 408 Messages", Work in Progress, Internet-Draft, draft-ietf- 409 httpbis-binary-message-01, 3 February 2022, 410 . 413 [HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 414 "Hybrid Public Key Encryption", Work in Progress, 415 Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, 416 . 419 [I-D.ietf-httpapi-ratelimit-headers] 420 Polli, R. and A. M. Ruiz, "RateLimit Fields for HTTP", 421 Work in Progress, Internet-Draft, draft-ietf-httpapi- 422 ratelimit-headers-03, 7 March 2022, 423 . 426 [I-D.ietf-ohai-ohttp] 427 Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in 428 Progress, Internet-Draft, draft-ietf-ohai-ohttp-01, 15 429 February 2022, . 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, 434 DOI 10.17487/RFC2119, March 1997, 435 . 437 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 438 Procedures for Message Header Fields", BCP 90, RFC 3864, 439 DOI 10.17487/RFC3864, September 2004, 440 . 442 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 443 IANA Considerations Section in RFCs", RFC 5226, 444 DOI 10.17487/RFC5226, May 2008, 445 . 447 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 448 Specifications: ABNF", STD 68, RFC 5234, 449 DOI 10.17487/RFC5234, January 2008, 450 . 452 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 453 Protocol (HTTP/1.1): Message Syntax and Routing", 454 RFC 7230, DOI 10.17487/RFC7230, June 2014, 455 . 457 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 458 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 459 May 2017, . 461 10.2. Informative References 463 [I-D.ietf-httpbis-bcp56bis] 464 Nottingham, M., "Building Protocols with HTTP", Work in 465 Progress, Internet-Draft, draft-ietf-httpbis-bcp56bis-15, 466 27 August 2021, . 469 Authors' Addresses 471 Tirumaleswar Reddy 472 Akamai 473 Embassy Golf Link Business Park 474 Bangalore 560071 475 Karnataka 476 India 477 Email: kondtir@gmail.com 479 Dan Wing 480 Citrix Systems, Inc. 481 4988 Great America Pkwy 482 Santa Clara, CA 95054 483 United States of America 484 Email: danwing@gmail.com 486 Mohamed Boucadair 487 Orange 488 35000 Rennes 489 France 490 Email: mohamed.boucadair@orange.com