idnits 2.17.1 draft-ietf-httpbis-cdn-loop-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 : ---------------------------------------------------------------------------- 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 (October 24, 2018) is 2009 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) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group S. Ludin 3 Internet-Draft Akamai Technologies 4 Intended status: Standards Track M. Nottingham 5 Expires: April 27, 2019 Fastly 6 N. Sullivan 7 Cloudflare 8 October 24, 2018 10 CDN Loop Prevention 11 draft-ietf-httpbis-cdn-loop-01 13 Abstract 15 This specification defines the CDN-Loop request header field for 16 HTTP. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 27, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Relationship to Via . . . . . . . . . . . . . . . . . . . 2 54 1.2. Conventions and Definitions . . . . . . . . . . . . . . . 3 55 2. The CDN-Loop Request Header Field . . . . . . . . . . . . . . 3 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 60 5.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 In modern deployments of HTTP servers, it is common to interpose 66 Content Delivery Networks (CDNs) in front of origin servers to 67 improve end-user perceived latency, reduce operational costs, and 68 improve scalability and reliability of services. 70 Often, more than one CDN is in use by a given origin. This happens 71 for a variety of reasons, such as cost savings, arranging for 72 failover should one CDN have issues, or to directly compare their 73 services. 75 As a result, it is not unknown for forwarding CDNs to be configured 76 in a "loop" accidentally; because routing is achieved through a 77 combination of DNS and forwarding rules, and site configurations are 78 sometimes complex and managed by several parties. 80 When this happens, it is difficult to debug. Additionally, it 81 sometimes isn't accidental; loops between multiple CDNs be used as an 82 attack vector (e.g., see [loop-attack]), especially if one CDN 83 unintentionally strips the loop detection headers of another. 85 This specification defines the CDN-Loop request header field for HTTP 86 to enable secure interoperability of forwarding CDNs. Having a 87 header that is guaranteed not to be modified by other CDNs that are 88 used by a shared customer helps give each CDN additional confidence 89 that any purpose (debugging, data gathering, enforcement) that they 90 use this header for is free from tampering due to how that customer 91 configured the other CDNs. 93 1.1. Relationship to Via 95 HTTP defines the Via header field in [RFC7230], Section 5.7.1 for 96 "tracking message forwards, avoiding request loops, and identifying 97 the protocol capabilities of senders along the request/response 98 chain." 100 In theory, Via could be used to identify these loops. However, in 101 practice it is not used in this fashion, because some HTTP servers 102 use Via for other purposes - in particular, some implementations 103 disable some HTTP/1.1 features when the Via header is present. 105 1.2. Conventions and Definitions 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 This specification uses the Augmented Backus-Naur Form (ABNF) 114 notation of [RFC5234] with a list extension, defined in Section 7 of 115 [RFC7230], that allows for compact definition of comma-separated 116 lists using a '#' operator (similar to how the '*' operator indicates 117 repetition). Additionally, it uses the OWS rule from [RFC7230] and 118 the parameter rule from [RFC7231]. 120 2. The CDN-Loop Request Header Field 122 The CDN-Loop request header field is intended to help a Content 123 Delivery Network identify when an incoming request has already passed 124 through that CDN's servers, to prevent loops. 126 CDN-Loop = #cdn-id 127 cdn-id = token *( OWS ";" OWS parameter ) 129 Conforming Content Delivery Networks SHOULD add a value to this 130 header field to all requests they generate or forward (creating the 131 header if necessary). 133 The token identifies the CDN as a whole. Chosen token values SHOULD 134 be unique enough that a collision with other CDNs is unlikely. 135 Optionally, the token can have semicolon-separated key/value 136 parameters, to accommodate additional information for the CDN's use. 138 As with all HTTP headers defined using the "#" rule, the CDN-Loop 139 header can be added to by comma-separating values, or by creating a 140 new header field with the desired value. 142 For example: 144 CDN-Loop: FooCDN, barcdn; host="foo123.bar.cdn" 145 CDN-Loop: baz-cdn; abc="123"; def="456", anotherCDN 147 Note that the token syntax does not allow whitespace, DQUOTE or any 148 of the characters "(),/:;<=>?@[]{}". See [RFC7230], Section 3.2.6. 149 Likewise, note the rules for when parameter values need to be quoted 150 in [RFC7231], Section 3.1.1. 152 To be effective, intermediaries - including Content Delivery Networks 153 - MUST NOT remove this header field, or allow it to be removed (e.g., 154 through configuration) and servers (including intermediaries) SHOULD 155 NOT use it for other purposes. 157 3. Security Considerations 159 The threat model that the CDN-Loop header field addresses is a 160 customer who is attempting to attack a service provider by 161 configuring a forwarding loop by accident or malice. For it to 162 function, CDNs cannot allow it to be modified by customers (see 163 Section 2). 165 The CDN-Loop header field can be generated by any client, and 166 therefore its contents cannot be trusted. CDNs who modify their 167 behaviour based upon its contents should assure that this does not 168 become an attack vector (e.g., for Denial-of-Service). 170 It is possible to sign the contents of the header (either by putting 171 the signature directly into the field's content, or using another 172 header field), but such use is not defined (or required) by this 173 specification. 175 4. IANA Considerations 177 This document registers the "CDN-Loop" header field in the Permanent 178 Message Header Field Names registry. 180 o Header Field Name: CDN-Loop 182 o Protocol: http 184 o Status: standard 186 o Reference: (this document) 188 5. References 190 5.1. Normative References 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, 194 DOI 10.17487/RFC2119, March 1997, 195 . 197 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 198 Specifications: ABNF", STD 68, RFC 5234, 199 DOI 10.17487/RFC5234, January 2008, 200 . 202 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 203 Protocol (HTTP/1.1): Message Syntax and Routing", 204 RFC 7230, DOI 10.17487/RFC7230, June 2014, 205 . 207 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 208 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 209 DOI 10.17487/RFC7231, June 2014, 210 . 212 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 213 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 214 May 2017, . 216 5.2. Informative References 218 [loop-attack] 219 Chen, J., Jiang, J., Zheng, X., Duan, H., Liang, J., Li, 220 K., Wan, T., and V. Paxson, "Forwarding-Loop Attacks in 221 Content Delivery Networks", ISBN 1-891562-41-X, 222 DOI 10.14722/ndss.2016.23442, February 2016, 223 . 225 Authors' Addresses 227 Stephen Ludin 228 Akamai Technologies 230 Email: sludin@akamai.com 231 Mark Nottingham 232 Fastly 234 Email: mnot@fastly.com 236 Nick Sullivan 237 Cloudflare 239 Email: nick@cloudflare.com