idnits 2.17.1 draft-rdb-ohai-feedback-to-proxy-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (23 May 2022) is 676 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) -- Possible downref: Normative reference to a draft: ref. 'HTTP' == Outdated reference: A later version (-10) exists of draft-ietf-ohai-ohttp-01 == Outdated reference: A later version (-07) exists of draft-ietf-httpapi-ratelimit-headers-03 -- Duplicate reference: RFC8941, mentioned in 'STRUCTURED-FIELDS', was also mentioned in 'RFC8941'. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). 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: 24 November 2022 Citrix 6 M. Boucadair 7 Orange 8 R. Polli 9 Team Digitale, Italian Government 10 23 May 2022 12 Oblivious Proxy Feedback 13 draft-rdb-ohai-feedback-to-proxy-02 15 Abstract 17 To provide equitable service to clients, servers often rate-limit 18 incoming requests, for example, based upon the source IP address. 19 However, oblivious HTTP removes the ability for the server to 20 distinguish amongst clients so the server can only rate-limit traffic 21 from the oblivious proxy. This harms all clients behind that 22 oblivious proxy. 24 This specification enables a server to convey rate-limit information 25 to an oblivious proxy, which can use it to apply rate-limit policies 26 on oblivious clients. Cooperating oblivious proxies can thus provide 27 more equitable service to their distinguishable clients without 28 impacting on all clients behind that oblivious proxy. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 24 November 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Providing RateLimit Information to an Oblivious Proxy . . . . 4 66 4. The ohttp-target Quota Policy Parameter . . . . . . . . . . . 4 67 4.1. ohttp-target Parameter . . . . . . . . . . . . . . . . . 4 68 4.2. Processing the ohttp-target Parameter . . . . . . . . . . 5 69 5. The attack-severity Quota Policy Parameter . . . . . . . . . 6 70 6. Use of The ohttp-target Quota Policy Parameters: An 71 Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 7.1. Client and Oblivous Proxy Collusion . . . . . . . . . . . 8 74 7.2. Attack Categories . . . . . . . . . . . . . . . . . . . . 8 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 8.1. RateLimit Parameter Value Registrations . . . . . . . . . 9 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 10.2. Informative References . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 Oblivious HTTP [OHTTP] requires three parties to exchange HTTP 86 messages: the client, the proxy, and the target (formally, the 87 Oblivious Request Resource and Oblivious Target Resource). Oblivious 88 HTTP enables a client to send requests to a target in such a way that 89 the target cannot tell whether two requests came from the same 90 client, and the proxy cannot see the contents of the requests. 92 Since oblivious clients are located behind a proxy, a target cannot 93 distinguish between well-behaving and malicious clients: an 94 unexpected behavior from one or more clients can then impact on all 95 the intermediated clients, as described in Section 8.2.1 of [OHTTP]. 96 This can be problematic when the target implements rate limiting 97 policies based on an information masked by the intermediary, such as 98 the source IP address. 100 This document defines a mechanism that allows Oblivious request and 101 target resource to provide rate-limit information to an Oblivious 102 proxy via the RateLimit fields defined in [RATELIMIT]. This is 103 useful when such servers identify traffic anomalies or unexpected 104 request volumes. The Oblivious proxy can then use this information 105 to apply rate-limit policies on oblivious clients. 107 While [RATELIMIT] provides enough information to generic clients to 108 shape their request policy and avoid being throttled out, this 109 specification allows an Oblivious request and target resource to 110 indicate their RateLimit information is intended for the Oblivious 111 proxy (rather than to the client). 113 How an Oblivious proxy can use this information to avoid being 114 throttled out or shape its request policy is outside the scope of 115 this specification. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119][RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 The terms "content", "receiver", "request", and "response" are to be 126 interpreted as described in [HTTP]. 128 The terms "Encapsulated request", "Encapsulated response", "Oblivious 129 proxy resource", "Oblivious request resource", "Oblivious target 130 resource", and "Client" are to be interpreted as described in 131 [OHTTP]. 133 The collective term "Oblivious resource" indicates either an 134 "Oblivious request resource" or an "Oblivious target resource". 136 The terms "quota policy", "service limit", "expiring limit", and 137 "RateLimit fields" are to be interpreted as described in [RATELIMIT]. 139 This document uses the Integer type from [STRUCTURED-FIELDS]. 141 3. Providing RateLimit Information to an Oblivious Proxy 143 An Oblivious resource that uses RateLimit fields [RATELIMIT] to 144 return service limit information MAY add the "ohttp-target" quota 145 policy parameter defined in Section 4 to signal to the receiver that 146 the associated quota policy is intended for an Oblivious proxy. For 147 example, when an Oblivious target identifies a high frequency or high 148 volume anomalies in the HTTP requests it would include the "ohttp- 149 target" parameter. 151 The term "Oblivious Proxy Feedback" denotes both the mechanism 152 described in this specification and the complete set of RateLimit 153 fields together with the "ohttp-target" parameter. 155 To know whether the RateLimit fields provides Oblivious Proxy 156 Feedback (see Section 3.1), an Oblivious proxy MUST: 158 1. Identify the quota policy associated to the expiring limit. 160 2. Check whether the "ohttp-target" parameter is present and its 161 syntax is correct. 163 In the example shown in Figure 1, the expiring limit value is "100", 164 so the associated quota policy is the second one. This quota policy 165 includes the "ohttp-target" parameter: this indicates that the 166 RateLimit fields are intended for an Oblivious proxy. 168 RateLimit-Limit: 100, 10;w=1, 100;w=60;ohttp-target=1 169 RateLimit-Remaining: 8 170 RateLimit-Reset: 15 172 Figure 1: An Example of Oblivious Proxy Feedback. 174 4. The ohttp-target Quota Policy Parameter 176 4.1. ohttp-target Parameter 178 The following quota policy parameter is defined for the RateLimit- 179 Limit field [RATELIMIT]: 181 ohttp-target: Indicates that the associated quota policy provides 182 Oblivious Proxy Feedback. This parameter is OPTIONAL. 184 The "ohttp-target" parameter has the following syntax: 186 ohttp-target = sf-integer 187 Its value MUST be an Integer (Section 3.3.1 of [STRUCTURED-FIELDS]) 188 and indicates whether the quota policy is applicable to all the 189 clients that are serviced by the Oblivious proxy or applicable only 190 to a specific client. The "ohttp-target" parameter MUST have one of 191 the following values: 193 1: Indicates that RateLimit fields are applicable to all the clients 194 that are serviced by the same Oblivious proxy. 196 2: Indicates that RateLimit fields are applicable only to the 197 offending client. For example, this value is used if the client 198 is attacking the server (e.g., the client is using an abnormal 199 header that matches an attack pattern). The Oblivious proxy can 200 shadowban requests from the offending client for a certain 201 duration instead of rate-limiting the requests when the client has 202 a high ratio of malicious requests to legitimate requests. 204 Other values MUST cause the parameter to be ignored. 206 The "ohttp-target" parameter MUST NOT appear more than once in a 207 quota policy. If the parameter is malformed or its value is invalid, 208 it MUST be ignored, and the receiving Oblivious proxy MUST NOT 209 attempt to fix neither the parameter nor its value. That is, the 210 RateLimit fields must not be considered as providing Oblivious Proxy 211 Feedback. 213 4.2. Processing the ohttp-target Parameter 215 An Oblivious proxy receiving RateLimit fields providing Oblivious 216 Proxy Feedback will do the following: 218 1. It MUST remove the RateLimit fields from the response, since they 219 are not intended to be forwarded to clients. 221 2. It MAY add a new set of RateLimit fields that are intended to be 222 forwarded to a client. 224 An Oblivious request resource receiving RateLimit fields providing 225 Oblivious Proxy Feedback will do the following: 227 1. It MUST remove the RateLimit fields from the HTTP response, since 228 they are not intended to be forwarded to the client. It, then, 229 encapsulates the HTTP response. 231 2. It MUST add the above RateLimit fields to the response containing 232 the encapsulated response sent to the Oblivious proxy, so that 233 the Oblivious proxy can access them. 235 If the RateLimit fields along with the "ohttp-target" parameter are 236 generated by the oblivious request resource before removing the 237 protection (including being unable to remove the encapsulation for 238 any reason)(Section 6.2 of [OHTTP]), it will result in the RateLimit 239 fields added in the response being sent without protection in 240 response to a POST request from a client. 242 While this specification does not mandate specific traffic shaping 243 actions for Oblivious proxies in addition to the ones indicated in 244 [RATELIMIT], an Oblivious proxy failing to reshape traffic from a 245 specific client or from all the clients according to the received 246 Oblivious Proxy Feedback can experience different levels of service 247 denial by the Oblivious request and target resources. There is no 248 explicit mechanism for an Oblivious proxy to indicate to the server 249 that the rate-limit information was processed or was ignored. 251 5. The attack-severity Quota Policy Parameter 253 The following quota policy parameter is defined for the RateLimit- 254 Limit field defined in [RATELIMIT]: 256 attack-severity: Is used by the Oblivious resource to convey the 257 likeliness that an Oblivious request is malicious. This parameter 258 is OPTIONAL. 260 attack-severity = sf-string 262 Note that sf-string is defined in Section 3.3.3 of 263 [STRUCTURED-FIELDS]. 265 The value of the "attack-severity" parameter is a String 266 (Section 3.3.3 of [RFC8941]) that takes one of the values defined in 267 [SEVERITY]. This parameter MUST NOT appear more than once in a quota 268 policy. If the parameter is malformed or its value is invalid, the 269 parameter MUST be ignored, and the proxies MUST NOT attempt to fix 270 neither the parameter nor the value. 272 6. Use of The ohttp-target Quota Policy Parameters: An Example 274 The example depicted in Figure 2 illustrates the use of the "ohttp- 275 target" parameter. An oblivious target resource receives a malformed 276 message and uses the source IP address to identify that it was an 277 oblivious HTTP request decapsulated by an oblivious request resource. 278 The Oblivious target resource generates a 400 response and adds the 279 RateLimit fields along with the "ohttp-target" quota policy 280 parameter. The oblivious request resource proceeds as follows: 282 1. Copy the RateLimit fields from the original response. 284 2. Remove them from the original response before encapsulating it. 286 3. Generate a single 200 response containing the encapsulated 287 response for the oblivious proxy resource along with the copied 288 RateLimit fields. 290 +----+ +----------+ +----------+ +----------+ 291 | C | | Proxy | | Request | | Target | 292 | | | Resource | | Resource | | Resource | 293 +-+--+ +----+-----+ +-----+----+ +-----+----+ 294 | | | | 295 | Encapsulated | | | 296 +------------------->| | | 297 | Request | | | 298 | | Encapsulated | | 299 | +------------------>| | 300 | | Request | | 301 | | | Request | .---------. 302 | | +-------------->| | Identify| 303 | | | +-+malformed| 304 | | | | | request | 305 | | | 400 response | '---------' 306 | | |<--------------+ 307 | | | | 308 | | 200 response with | | 309 | | RateLimit-Limit | | 310 | | field and the | | 311 | | ohttp-target | | 312 | | parameter | | 313 |<------------------+ | 314 .--------------------. | Encapsulated 400 | | 315 | Process | | response | | 316 | ohttp-target +-+ | | 317 | and shadowban | | | | 318 | requests from the | | | | 319 | offending client | | | | 320 '--------------------' | | | 321 | | | 322 | | | | 323 | Encapsulated 400 | | | 324 |<--------------------+ | | 325 | response | | | 326 | | | | 328 Figure 2: An Example of Ratelimit Feedback to Proxy 330 The response that is generated by the Oblivious request resource is 331 depicted in Figure 3. This response includes an unregistered, 332 informative "comment" quota policy parameter providing the rationale 333 for the "attack- severity". 335 =============== NOTE: '\' line wrapping per RFC 8792 ================ 337 HTTP/1.1 200 OK 338 Date: Wed, 27 March 2022 04:45:07 GMT 339 Cache-Control: private, no-store 340 RateLimit-Limit: 10,10;ohttp-target=2;attack-severity="high";\ 341 comment="abnormal header matching a WAF rule" 342 Content-Type: message/ohttp-res 343 Content-Length: 38 344 ...encrypted content... 346 Figure 3: Example of a Response 348 7. Security Considerations 350 The security considerations for the Oblivious HTTP protocol 351 (Section 8 of [OHTTP]) as well as the ones for RateLimit-Limit fields 352 (Section 6 of [RATELIMIT]) apply. The following sub-sections discuss 353 security considerations specific to this specification. 355 7.1. Client and Oblivous Proxy Collusion 357 While Oblivious HTTP relies upon an Oblivious proxy to prevent 358 leaking the client identity to the Oblivious resources, it might be 359 the case that the Oblivious proxy colludes with clients in attacking 360 Oblivious resources. RateLimit fields might disclose operational 361 capacity information useful to design denial of service attacks or to 362 circumvent defensive measures put in place by the Oblivious resources 363 (Section 6.2 of [RATELIMIT]). The Oblivious target and request 364 resources SHOULD convey Oblivious Proxy Feedback only to trusted 365 Oblivious proxies. 367 7.2. Attack Categories 369 Attacks against the Oblivious Request and Target Resources can be 370 classified into three primary categories: 372 1. A client deliberately sends a malformed encapsulated request 373 causing decryption failure or decryption overload failure on the 374 oblivious request resource. This causes the oblivious request 375 resource to send an error status code back to the oblivious 376 proxy. 378 2. A client deliberately sends an HTTP request that causes an HTTP 379 error on the oblivious target resource. This might be a 380 malformed HTTP request, or request for a missing resource. 382 3. A botnet performing an application layer denial of service attack 383 (e.g. HTTP flood) against an Oblivious resource. Because each 384 bot in a botnet makes seemingly legitimate network requests the 385 traffic may appear "normal" in origin, nonetheless as a whole it 386 not only can saturate the Oblivious resources, but also makes 387 appear the Oblivious proxy as an attacker. This might be too 388 many requests from a single client, too many requests from the 389 clients behind the same oblivious proxy or too many requests from 390 all clients on the Internet. 392 8. IANA Considerations 394 8.1. RateLimit Parameter Value Registrations 396 This specification requests IANA to add the following parameters to 397 the "Hypertext Transfer Protocol (HTTP) RateLimit Parameters" 398 registry defined in [RATELIMIT]. 400 +=================+=================+================+===============+ 401 | Field Name |Parameter Name |Description |Specification | 402 +=================+=================+================+===============+ 403 | RateLimit-Limit |ohttp-target |ohttp ratelimit |Section 3 of | 404 | | | |this document | 405 | RateLimit-Limit |attack-severity |ohttp ratelimit |Section 5 of | 406 | | | |this document | 407 +-----------------+-----------------+----------------+---------------+ 409 9. Acknowledgements 411 Thanks to Lucas Pardue, Rich Salz, and Brandon Williams for the 412 discussion and comments. 414 10. References 416 10.1. Normative References 418 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 419 Semantics", Work in Progress, Internet-Draft, draft-ietf- 420 httpbis-semantics-19, 12 September 2021, 421 . 424 [OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in 425 Progress, Internet-Draft, draft-ietf-ohai-ohttp-01, 15 426 February 2022, . 429 [RATELIMIT] 430 Polli, R. and A. M. Ruiz, "RateLimit Fields for HTTP", 431 Work in Progress, Internet-Draft, draft-ietf-httpapi- 432 ratelimit-headers-03, 7 March 2022, 433 . 436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, 438 DOI 10.17487/RFC2119, March 1997, 439 . 441 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 442 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 443 May 2017, . 445 [RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for 446 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 447 . 449 [STRUCTURED-FIELDS] 450 Nottingham, M. and P-H. Kamp, "Structured Field Values for 451 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 452 . 454 10.2. Informative References 456 [SEVERITY] IANA, "Incident Object Description Exchange Format v2 457 (IODEF)", . 460 Authors' Addresses 462 Tirumaleswar Reddy 463 Akamai 464 Embassy Golf Link Business Park 465 Bangalore 560071 466 Karnataka 467 India 468 Email: kondtir@gmail.com 469 Dan Wing 470 Citrix Systems, Inc. 471 4988 Great America Pkwy 472 Santa Clara, CA 95054 473 United States of America 474 Email: danwing@gmail.com 476 Mohamed Boucadair 477 Orange 478 35000 Rennes 479 France 480 Email: mohamed.boucadair@orange.com 482 Roberto Polli 483 Team Digitale, Italian Government 484 Email: robipolli@gmail.com