idnits 2.17.1 draft-cdn-loop-prevention-00.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 (June 27, 2018) is 2123 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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: Informational M. Nottingham 5 Expires: December 29, 2018 Fastly 6 N. Sullivan 7 Cloudflare 8 June 27, 2018 10 CDN Loop Prevention 11 draft-cdn-loop-prevention-00 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 December 29, 2018. 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 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 54 3. The CDN-Loop Request Header Field . . . . . . . . . . . . . . 3 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 59 6.2. Informative References . . . . . . . . . . . . . . . . . 5 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 In modern deployments of HTTP servers, it is common to interpose 65 Content Delivery Networks (CDNs) to improve end-user perceived 66 latency, reduce operational costs, and improve scalability and 67 reliability of services. 69 Often, more than one CDN is in use by any one server; this happens 70 for a variety of reasons, such as cost savings, arranging for 71 failover should one CDN have issues, or to directly compare their 72 services. 74 As a result, it is not unknown for CDNs to be configured in a "loop" 75 accidentally; because routing is achieved through a combination of 76 DNS and forwarding rules, and site configurations are sometimes 77 complex and managed by several parties. 79 When this happens, it is difficult to debug. Additionally, it 80 sometimes isn't accidental; loops between multiple CDNs be used as an 81 attack vector (e.g., see [loop-attack]), especially if one CDN 82 unintentionally strips the loop detection headers of another. 84 HTTP defines the Via header field in [RFC7230], Section 5.7.1 for 85 "tracking message forwards, avoiding request loops, and identifying 86 the protocol capabilities of senders along the request/response 87 chain." 89 In theory, Via could be used to identify these loops. However, in 90 practice it is not used in this fashion, because some HTTP servers 91 use Via for other purposes - in particular, some implementations 92 disable some HTTP/1.1 features when the Via header is present. 94 This specification defines the CDN-Loop request header field for 95 HTTP, to address this shortcoming. 97 2. Conventions and Definitions 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 This specification uses the Augmented Backus-Naur Form (ABNF) 106 notation of [RFC5234] with a list extension, defined in Section 7 of 107 [RFC7230], that allows for compact definition of comma-separated 108 lists using a '#' operator (similar to how the '*' operator indicates 109 repetition). Additionally, it uses the OWS rule from [RFC7230] and 110 the parameter rule from [RFC7231]. 112 3. The CDN-Loop Request Header Field 114 The CDN-Loop request header field is intended to help a Content 115 Delivery Network identify when an incoming request has already passed 116 through that CDN's servers, to prevent loops. 118 CDN-Loop = #cdn-id 119 cdn-id = token *( OWS ";" OWS parameter ) 121 Conforming Content Delivery Networks SHOULD add a value to this 122 header field to all requests they generate or forward (creating the 123 header if necessary). 125 The token identifies the CDN as a whole. Chosen token values SHOULD 126 be unique enough that a collision with other CDNs is unlikely. 127 Optionally, the token can have semicolon-separated key/value 128 parameters, to accommodate additional information for the CDN's use. 130 As with all HTTP headers defined using the "#" rule, the CDN-Loop 131 header can be added to by comma-separating values, or by creating a 132 new header field with the desired value. 134 For example: 136 CDN-Loop: FooCDN, barcdn; host="foo123.bar.cdn" 137 CDN-Loop: baz-cdn; abc="123"; def="456", anotherCDN 139 Note that the token syntax does not allow whitespace, DQUOTE or any 140 of the characters "(),/:;<=>?@[]{}". See [RFC7230], Section 3.2.6. 141 Likewise, note the rules for when parameter values need to be quoted 142 in [RFC7231], Section 3.1.1. 144 To be effective, intermediaries - including Content Delivery Networks 145 - MUST NOT remove this header field, or allow it to be removed (e.g., 146 through configuration) and servers (including intermediaries) SHOULD 147 NOT use it for other purposes. 149 4. Security Considerations 151 The CDN-Loop header field can be generated by any client, and 152 therefore its contents cannot be trusted. CDNs who modify their 153 behaviour based upon its contents should assure that this does not 154 become an attack vector (e.g., for Denial-of-Service). 156 It is possible to sign the contents of the header (either by putting 157 the signature directly into the field's content, or using another 158 header field), but such use is not defined (or required) by this 159 specification. 161 5. IANA Considerations 163 This document registers the "CDN-Loop" header field in the Permanent 164 Message Header Field Names registry. 166 o Header Field Name: CDN-Loop 168 o Protocol: http 170 o Status: standard 172 o Reference: (this document) 174 6. References 176 6.1. Normative References 178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels", BCP 14, RFC 2119, 180 DOI 10.17487/RFC2119, March 1997, 181 . 183 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 184 Specifications: ABNF", STD 68, RFC 5234, 185 DOI 10.17487/RFC5234, January 2008, 186 . 188 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 189 Protocol (HTTP/1.1): Message Syntax and Routing", 190 RFC 7230, DOI 10.17487/RFC7230, June 2014, 191 . 193 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 194 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 195 DOI 10.17487/RFC7231, June 2014, 196 . 198 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 199 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 200 May 2017, . 202 6.2. Informative References 204 [loop-attack] 205 Chen, J., Jiang, J., Zheng, X., Duan, H., Liang, J., Li, 206 K., Wan, T., and V. Paxson, "Forwarding-Loop Attacks in 207 Content Delivery Networks", ISBN 1-891562-41-X, 208 DOI 10.14722/ndss.2016.23442, February 2016, 209 . 211 Authors' Addresses 213 Stephen Ludin 214 Akamai Technologies 216 Email: sludin@akamai.com 218 Mark Nottingham 219 Fastly 221 Email: mnot@fastly.com 223 Nick Sullivan 224 Cloudflare 226 Email: nick@cloudflare.com