idnits 2.17.1 draft-ietf-cdni-redirection-20.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 (August 15, 2016) is 2783 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) == Missing Reference: 'RFCthis' is mentioned on line 1216, but not defined == Missing Reference: 'RFCThis' is mentioned on line 1275, but not defined ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6707 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) -- Possible downref: Non-RFC (?) normative reference: ref. 'RTMP' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Niven-Jenkins, Ed. 3 Internet-Draft Nokia 4 Intended status: Standards Track R. van Brandenburg, Ed. 5 Expires: February 16, 2017 TNO 6 August 15, 2016 8 Request Routing Redirection interface for CDN Interconnection 9 draft-ietf-cdni-redirection-20 11 Abstract 13 The Request Routing Interface comprises (1) the asynchronous 14 advertisement of footprint and capabilities by a downstream Content 15 Delivery Network (CDN) that allows an upstream CDN to decide whether 16 to redirect particular user requests to that downstream CDN; and (2) 17 the synchronous operation of an upstream CDN requesting whether a 18 downstream CDN is prepared to accept a user request and of a 19 downstream CDN responding with how to actually redirect the user 20 request. This document describes an interface for the latter part, 21 i.e., the CDNI Request Routing Redirection interface. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 16, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Interface function and operation overview . . . . . . . . . . 4 60 4. HTTP based interface for the Redirection Interface . . . . . 5 61 4.1. Information passed in RI requests & responses . . . . . . 7 62 4.2. JSON encoding of RI requests & responses . . . . . . . . 8 63 4.3. MIME Media Types used by the RI interface . . . . . . . . 10 64 4.4. DNS redirection . . . . . . . . . . . . . . . . . . . . . 10 65 4.4.1. DNS Redirection requests . . . . . . . . . . . . . . 10 66 4.4.2. DNS Redirection responses . . . . . . . . . . . . . . 12 67 4.5. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 14 68 4.5.1. HTTP Redirection requests . . . . . . . . . . . . . . 14 69 4.5.2. HTTP Redirection responses . . . . . . . . . . . . . 16 70 4.6. Cacheability and scope of responses . . . . . . . . . . . 18 71 4.7. Error responses . . . . . . . . . . . . . . . . . . . . . 20 72 4.8. Loop detection & prevention . . . . . . . . . . . . . . . 24 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 74 5.1. Authentication, Authorization, Confidentiality, Integrity 75 Protection . . . . . . . . . . . . . . . . . . . . . . . 26 76 5.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 26 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 78 6.1. CDNI Payload Type Parameter registrations . . . . . . . . 27 79 6.1.1. CDNI RI Redirection Request Payload Type . . . . . . 27 80 6.1.2. CDNI RI Redirection Response Payload Type . . . . . . 28 81 6.2. RI Error response registry . . . . . . . . . . . . . . . 28 82 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 86 9.2. Informative References . . . . . . . . . . . . . . . . . 31 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 89 1. Introduction 91 A Content Delivery Network (CDN) is a system built on an existing IP 92 network which is used for large scale content delivery, via 93 prefetching or dynamically caching content on its distributed 94 surrogates (caching servers). [RFC6707] describes the problem area 95 of interconnecting CDNs. 97 The CDNI Request Routing interface outlined in [RFC7336] comprises 98 of: 100 1. The asynchronous advertisement of footprint and capabilities by a 101 downstream CDN (dCDN) that allows an upstream CDN (uCDN) to 102 decide whether to redirect particular user requests to that dCDN. 104 2. The synchronous operation of a uCDN requesting whether a dCDN is 105 prepared to accept a user request and of a dCDN responding with 106 how to actually redirect the user request. 108 This document describes an interface for the latter part, i.e., the 109 CDNI Request Routing Redirection interface (RI). 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 This document reuses the terminology defined in [RFC6707]. 119 The following additional terms are introduced by this document: 121 Application Level Redirection: The act of using an application 122 specific redirection mechanism for the request routing process of 123 a CDN. The Redirection Target (RT) is the result of the routing 124 decision of a CDN at the time it receives a content request via an 125 application specific protocol response. Examples of an 126 application level redirection are HTTP 302 Redirection and RTMP 127 302 Redirection [RTMP]. 129 DNS Redirection: The act of using DNS name resolution for the 130 request routing process of a CDN. In DNS Redirection, the DNS 131 name server of the CDN makes the routing decision based on a local 132 policy and selects one or more Redirection Targets (RTs) and 133 redirects the user agent to the RT(s) by returning the details of 134 the RT(s) in response to the DNS query request from the user 135 agent's DNS resolver. 137 HTTP Redirection: The act of using an HTTP redirection response for 138 the request routing process of a CDN. The Redirection Target (RT) 139 is the result of the routing decision of a CDN at the time it 140 receives a content request via HTTP. HTTP Redirection is a 141 particular case of Application Level Redirection. 143 Redirection Target (RT): A Redirection Target is the endpoint to 144 which the user agent is redirected. In CDNI, a RT may point to a 145 number of different components, some examples include a surrogate 146 in the same CDN as the request router, a request router in a dCDN 147 or a surrogate in a dCDN, etc. 149 3. Interface function and operation overview 151 The main function of the CDNI Redirection interface (RI) is to allow 152 the request routing systems in interconnected CDNs to communicate to 153 facilitate the redirection of User Agent requests between 154 interconnected CDNs. 156 The detailed requirements for the Redirection interface and their 157 relative priorities are described in section 5 of [RFC7337]. 159 The User Agent will make a request to a request router in the uCDN 160 using one of either DNS or HTTP. The RI is used between the uCDN and 161 one or more dCDNs. The dCDN's RI response may contain a Redirection 162 Target with a type that is compatible with the protocol used between 163 User Agent and uCDN request router. The dCDN has control over the 164 Redirection Target it provides. Depending on the returned 165 Redirection Target, the User Agent's request may be redirected to: 167 o The final Surrogate, which may be in the dCDN that returned the RI 168 response to the uCDN, or another CDN (if the dCDN delegates the 169 delivery to another CDN); or 171 o A request router (in the dCDN or another CDN), which may use a 172 different redirection protocol (DNS or HTTP) than the one included 173 in the RI request. 175 The Redirection interface operates between the request routing 176 systems of a pair of interconnected CDNs. To enable communication 177 over the Redirection interface, the uCDN needs to know the URI (end 178 point) in the dCDN to send CDNI request routing queries. 180 The Redirection interface URI may be statically pre-configured, 181 dynamically discovered via the CDNI Control interface, or discovered 182 via other means. However, such discovery mechanisms are not 183 specified in this document, as they are considered out of the scope 184 of the Redirection interface specification. 186 The Redirection interface is only relevant in the case of Recursive 187 Request Redirection, as Iterative Request Redirection does not invoke 188 any interaction over the Redirection interface between interconnected 189 CDNs. Therefore, the scope of this document is limited to Recursive 190 Request Redirection. 192 In the case of Recursive Request Redirection, in order to perform 193 redirection of a request received from a User Agent, the uCDN queries 194 the dCDN so that the dCDN can select and provide a Redirection 195 Target. In cases where a uCDN has a choice of dCDNs it is up to the 196 uCDN to decide (for example, via configured policies) which dCDN(s) 197 to query and in which order to query them. A number of strategies 198 are possible including selecting a preferred dCDN based on local 199 policy, possibly falling back to querying an alternative dCDN(s) if 200 the first dCDN does not return a Redirection Target or otherwise 201 rejects the uCDN's RI request. A more complex strategy could be to 202 query multiple dCDNs in parallel before selecting one and using the 203 Redirection Target provided by that dCDN. 205 The uCDN->User Agent redirection protocols addressed in this draft 206 are: DNS redirection and HTTP redirection. Other types of 207 application level redirection will not be discussed further in this 208 document. However, the Redirection interface is designed to be 209 extensible and could be extended to support additional application 210 level redirection protocols. 212 For both DNS & HTTP redirection, either HTTP or HTTPS could be used 213 to connect to the Redirection Target. When HTTPS is used to connect 214 to the uCDN, if the uCDN uses DNS redirection to identify the RT to 215 the User Agent, then the new target domain name may not match the 216 domain in the URL dereferenced to reach the uCDN; without operational 217 precautions, and in the absence of DNSSEC, this can make a legitimate 218 redirection look like a DNS-based attack to a User Agent and trigger 219 security warnings. When DNS-based redirection with HTTPS is used, 220 this specification assumes that any RT can complete the necessary TLS 221 handshake with the User Agent. Any operational mechanisms this 222 requires, e.g., private key distribution to surrogates and request 223 routers in dCDNs, are outside the scope of this document. 225 This document also defines an RI loop prevention and detection 226 mechanism as part of the Redirection interface. 228 4. HTTP based interface for the Redirection Interface 230 This document defines a simple interface for the Redirection 231 interface based on HTTP [RFC7230], where the attributes of a User 232 Agent's requests are encapsulated along with any other data that can 233 aid the dCDN in processing the requests. The RI response 234 encapsulates the attributes of the RT(s) that the uCDN should return 235 to the User Agent (if it decides to utilize the dCDN for delivery) 236 along with the policy for how the response can be reused. The 237 examples of RI requests and responses below do not contain a complete 238 set of HTTP headers for brevity; only the pertinent HTTP headers are 239 shown. 241 The RI between the uCDN and dCDN uses the same HTTP interface to 242 encapsulate the attributes of both DNS and HTTP requests received 243 from User Agents, although the contents of the RI requests/responses 244 contain data specific to either DNS or HTTP redirection. 246 This approach has been chosen because it enables CDN operators to 247 only have to deploy a single interface for the RI between their CDNs, 248 regardless of the User Agent redirection method. In this way, from 249 an operational point of view there is only one interface to monitor, 250 manage, develop troubleshooting tools for, etc. 252 In addition, having a single RI where the attributes of the User 253 Agent's DNS or HTTP request are encapsulated along with the other 254 data required for the dCDN to make a request routing decision, avoids 255 having to try to encapsulate or proxy DNS/HTTP/RTMP/etc requests and 256 find ways to somehow embed the additional CDNI Request Routing 257 Redirection interface properties/data within those End User 258 DNS/HTTP/RTMP/etc requests. 260 Finally, the RI is easily extendable to support other User Agent 261 request redirection methods (e.g., RTMP 302 redirection) by defining 262 additional protocol specific keys for RI requests and responses along 263 with a specification how to process them. 265 The generic Recursive Request Redirection message flow between 266 Request Routing systems in a pair of interconnected CDNs is as 267 follows: 269 User Agent CDN B RR CDN A RR 270 |UA Request (DNS or HTTP) | | 271 |-------------------------------------------------->| (1) 272 | | | 273 | |HTTP POST to CDN B's RI | 274 | |URI encapsulating UA | 275 | |request attributes | 276 | |<------------------------| (2) 277 | | | 278 | |HTTP Response with body | 279 | |containing RT attributes | 280 | |of the protocol specific | 281 | |response to return to UA | 282 | |------------------------>| (3) 283 | | | 284 | Protocol specific response (redirection)| 285 |<--------------------------------------------------| (4) 286 | | | 288 Figure 1: Generic Recursive Request Redirection message flow 290 1. The User Agent sends its (DNS or HTTP) request to CDN A. The 291 Request Routing System of CDN A processes the request and, 292 through local policy, recognizes that the request is best served 293 by another CDN, specifically CDN B (or that CDN B may be one of a 294 number of candidate dCDNs it could use). 296 2. The Request Routing System of CDN A sends an HTTP POST to CDN B's 297 RI URI containing the attributes of the User Agent's request. 299 3. The Request Routing System of CDN B processes the RI request and 300 assuming the request is well formed, responds with an HTTP "200" 301 response with a message body containing the RT(s) to return to 302 the User Agent as well as parameters that indicate the properties 303 of the response (cacheability and scope). 305 4. The Request Routing System of CDN A sends a protocol specific 306 response (containing the returned attributes) to the User Agent, 307 so that the User Agent's request will be redirected to the RT(s) 308 returned by CDN B. 310 4.1. Information passed in RI requests & responses 312 The information passed in RI requests splits into two basic 313 categories: 315 1. The attributes of the User Agent's request to the uCDN. 317 2. Properties/parameters that the uCDN can use to control the dCDN's 318 response or that can help the dCDN make its decision. 320 Generally, dCDNs can provide better routing decisions given 321 additional information about the content request, e.g., the URI of 322 the requested content or the User Agent's IP address or subnet. The 323 set of information required to base a routing decision on can be 324 highly dependent on the type of content delivered. A uCDN SHOULD 325 only include information that is absolutely necessary for delivering 326 that type of content. Cookies in particular are particularly 327 sensitive from a security/privacy point of view and in general SHOULD 328 NOT be conveyed in the RI Requests to the dCDN. The set of 329 information necessary to be conveyed for a particular type of request 330 is expected to be conveyed out of band between the uCDN and dCDN. 331 See Section 5.2 for more detail on the privacy aspects of using RI 332 Requests to convey information about UA requests. 334 In order for the dCDN to determine whether it is capable of 335 delivering any requested content, it requires CDNI metadata related 336 to the content the User Agent is requesting. That metadata will 337 describe the content and any policies associated with it. It is 338 expected that the RI request contains sufficient information for the 339 Request Router in the dCDN to be able to retrieve the required CDNI 340 Metadata via the CDNI Metadata interface. 342 The information passed in RI responses splits into two basic 343 categories: 345 1. The attributes of the RT to return to the User Agent in the DNS 346 response or HTTP response. 348 2. Parameters/policies that indicate the properties of the response, 349 such as, whether it is cacheable, the scope of the response, etc. 351 In addition to details of how to redirect the User Agent, the dCDN 352 may wish to return additional policy information to the uCDN to it 353 with future RI requests. For example, the dCDN may wish to return a 354 policy that expresses "this response can be reused without requiring 355 an RI request for 60 seconds provided the User Agent's IP address is 356 in the range 198.51.100.0 - 198.51.100.255". 358 These additional policies split into two basic categories: 360 o Cacheability information signaled via the HTTP response headers of 361 the RI response (to reduce the number of subsequent RI requests 362 the uCDN needs to make). 364 o The scope of a cacheable response signaled in the HTTP response 365 body of the RI response, for example, whether the response applies 366 to a wider range of IP addresses than what was included in the RI 367 request. 369 The cacheability of the response is indicated using the standard HTTP 370 Cache-Control mechanisms. 372 4.2. JSON encoding of RI requests & responses 374 The body of RI requests and responses is a JSON object [RFC7159] that 375 MUST conform to [RFC7493] containing a dictionary of key:value pairs. 376 Senders MUST encode all (top level object and sub-object) keys 377 specified in this document in lowercase. Receivers MUST ignore any 378 keys that are unknown or invalid. 380 The following top level keys are defined along with whether they are 381 applicable to RI requests, RI responses or both: 383 +----------+------------------+-------------------------------------+ 384 | Key | Request/Response | Description | 385 +----------+------------------+-------------------------------------+ 386 | dns | Both | The attributes of the UA's DNS | 387 | | | request or the attributes of the | 388 | | | RT(s) to return in a DNS response. | 389 | http | Both | The attributes of the UA's HTTP | 390 | | | request or the attributes of the RT | 391 | | | to return in a HTTP response. | 392 | scope | Response | The scope of the response (if it is | 393 | | | cacheable). For example, whether | 394 | | | the response applies to a wider | 395 | | | range of IP addresses than what was | 396 | | | included in the RI request. | 397 | error | Response | Additional details if the response | 398 | | | is an error response. | 399 | cdn-path | Both | A List of Strings. Contains a list | 400 | | | of the CDN Provider IDs of previous | 401 | | | CDNs that have participated in the | 402 | | | request routing for the associated | 403 | | | User Agent request. On RI requests | 404 | | | it contains the list of previous | 405 | | | CDNs that this RI request has | 406 | | | passed through. On RI responses it | 407 | | | contains the list of CDNs that were | 408 | | | involved in obtaining the final | 409 | | | redirection included in the RI | 410 | | | response. See Section 4.8 | 411 | max-hops | Request | Integer specifying the maximum | 412 | | | number of hops (CDN Provider IDs) | 413 | | | this request is allowed to be | 414 | | | propagated along. This allows the | 415 | | | uCDN to coarsely constrain the | 416 | | | latency of the request routing | 417 | | | chain. | 418 +----------+------------------+-------------------------------------+ 420 Top-Level keys in RI requests/responses 422 A single request or response MUST contain only one of the dns or http 423 keys. Requests MUST contain a cdn-path key and responses MAY contain 424 a cdn-path key. If the max-hops key is not present then there is no 425 limit on the number of CDN hops that the RI request can be propagated 426 along. If the first uCDN does not wish the RI request to be 427 propagated beyond the dCDN it is making the request to, then the uCDN 428 MUST set max-hops to 1. 430 The cdn-path MAY be reflected back in RI responses, although doing so 431 could expose information to the uCDN that a dCDN may not wish to 432 expose (for example, the existence of business relationships between 433 a dCDN and other CDNs). 435 If the cdn-path is reflected back in the RI response it MUST contain 436 the value of cdn-path received in the associated RI request with the 437 final dCDN's CDN Provider ID appended. Transit CDNs MAY remove the 438 cdn-path from RI responses but MUST NOT modify the cdn-path in other 439 ways. 441 The presence of an error key within a response that also contains 442 either a dns or http key does not automatically indicate that the RI 443 request was unsuccessful as the error key MAY be used for 444 communicating additional (e.g., debugging) information. When a 445 response contains an error key as well as either a dns or http key, 446 the error-code SHOULD be 1xx (e.g., 100). See Section 4.7 for more 447 details of encoding error information in RI responses. 449 All implementations that support IPv4 addresses MUST support the 450 encoding specified by the 'IPv4address' rule in Section 3.2.2 of 451 [RFC3986]. Likewise, implementations that support IPv6 addresses 452 MUST support all IPv6 address formats specified in [RFC4291]. Server 453 implementations SHOULD use IPv6 address formats specified in 454 [RFC5952]. 456 4.3. MIME Media Types used by the RI interface 458 RI requests MUST use a MIME Media Type of application/cdni as 459 specified in [RFC7736], with the Payload Type (ptype) parameter set 460 to 'redirection-request'. 462 RI responses MUST use a MIME Media Type of application/cdni as 463 specified in [RFC7736], with the Payload Type (ptype) parameter set 464 to 'redirection-response'. 466 4.4. DNS redirection 468 The following sections provide detailed descriptions of the 469 information that should be passed in RI requests and responses for 470 DNS redirection. 472 4.4.1. DNS Redirection requests 474 For DNS based redirection the uCDN needs to pass the following 475 information to the dCDN in the RI request: 477 o The IP address of the DNS resolver that made the DNS request to 478 the uCDN. 480 o The type of DNS query made (usually either A or AAAA). 482 o The class of DNS query made (usually IN). 484 o The fully qualified domain name for which DNS redirection is being 485 requested. 487 o The IP address or prefix of the User Agent (if known to the uCDN). 489 The information above is encoded as a set of key:value pairs within 490 the dns dictionary as follows: 492 +-------------+---------+-----------+-------------------------------+ 493 | Key | Value | Mandatory | Description | 494 +-------------+---------+-----------+-------------------------------+ 495 | resolver-ip | String | Yes | The IP address of the UA's | 496 | | | | DNS resolver. | 497 | qtype | String | Yes | The type of DNS query made by | 498 | | | | the UA's DNS resolvers in | 499 | | | | uppercase. The value of this | 500 | | | | field SHALL be set to either | 501 | | | | 'A' or 'AAAA'. | 502 | qclass | String | Yes | The class of DNS query made | 503 | | | | in uppercase (IN, etc.). | 504 | qname | String | Yes | The fully qualified domain | 505 | | | | name being queried. | 506 | c-subnet | String | No | The IP address (or prefix) of | 507 | | | | the UA in CIDR format. | 508 | dns-only | Boolean | No | If True then dCDN MUST only | 509 | | | | use DNS redirection and MUST | 510 | | | | include RTs to one or more | 511 | | | | surrogates in any successful | 512 | | | | RI response. CDNs MUST | 513 | | | | include the dns-only property | 514 | | | | set to True on any cascaded | 515 | | | | RI requests. Defaults to | 516 | | | | False. | 517 +-------------+---------+-----------+-------------------------------+ 519 An RI request for DNS-based redirection MUST include a dns 520 dictionary. This dns dictionary MUST contain the following keys: 521 resolver-ip, qtype, qclass, qname and the value of each MUST be the 522 value of the appropriate part of the User Agent's DNS query/request. 523 For internationalized domain names containing non-ASCII characters, 524 the value of the qname field MUST be the ASCII-compatible encoded 525 (ACE) representation (A-label) of the domain name [RFC5890]. 527 An example RI request (uCDN->dCDN) for DNS based redirection: 529 POST /dcdn/ri HTTP/1.1 530 Host: rr1.dcdn.example.net 531 Content-Type: application/cdni; ptype=redirection-request 532 Accept: application/cdni; ptype=redirection-response 534 { 535 "dns" : { 536 "resolver-ip" : "192.0.2.1", 537 "c-subnet" : "198.51.100.0/24", 538 "qtype" : "A", 539 "qclass" : "IN", 540 "qname" : "www.example.com" 541 }, 542 "cdn-path": ["AS64496:0"], 543 "max-hops": 3 544 } 546 4.4.2. DNS Redirection responses 548 For a successful DNS based redirection, the dCDN needs to return one 549 of the following to the uCDN in the RI response: 551 o The IP address(es) of (or the CNAME of) RTs that are dCDN 552 surrogates (if the dCDN is performing DNS based redirection 553 directly to a surrogate); or 555 o The IP address(es) of (or the CNAME of) RTs that are Request 556 Routers (if the dCDN will perform request redirection itself). A 557 dCDN MUST NOT return a RT which is a Request Router if the dns- 558 only key is set to True in the RI request. 560 The information above is encoded as a set of key:value pairs within 561 the dns dictionary as follows: 563 +-------+-----------+-----------+-----------------------------------+ 564 | Key | Value | Mandatory | Description | 565 +-------+-----------+-----------+-----------------------------------+ 566 | rcode | Integer | Yes | DNS response code (see | 567 | | | | [RFC6895]). | 568 | name | String | Yes | The fully qualified domain name | 569 | | | | the response relates to. | 570 | a | List of | No | Set of IPv4 Addresses of RT(s). | 571 | | String | | | 572 | aaaa | List of | No | Set of IPv6 Addresses of RT(s). | 573 | | String | | | 574 | cname | List of | No | Set of fully qualified domain | 575 | | String | | names of RT(s). | 576 | ttl | Integer | No | TTL in seconds of DNS response. | 577 | | | | Default is 0. | 578 +-------+-----------+-----------+-----------------------------------+ 580 A successful RI response for DNS-based redirection MUST include a dns 581 dictionary and MAY include an error dictionary (see Section 4.7). An 582 unsuccessful RI response for DNS-based redirection MUST include an 583 error dictionary. If a dns dictionary is included in the RI 584 response, it MUST include the rcode and name keys and it MUST include 585 at least one of the following keys: a, aaaa, cname. The dns 586 dictionary MAY include both 'a' and 'aaaa' keys. If the dns 587 dictionary contains a cname key it MUST NOT contain either an a or 588 aaaa key. For internationalized domain names containing non-ASCII 589 characters, the value of the cname field MUST be the ASCII-compatible 590 encoded (ACE) representation (A-label) of the domain name. 592 An example of a successful RI response (dCDN->uCDN) for DNS based 593 redirection with both a and aaaa keys is listed below : 595 HTTP/1.1 200 OK 596 Date: Mon, 06 Aug 2012 18:41:38 GMT 597 Content-Type: application/cdni; ptype=redirection-response 599 { 600 "dns" : { 601 "rcode" : 0, 602 "name" : "www.example.com", 603 "a" : ["203.0.113.200", "203.0.113.201", "203.0.113.202"], 604 "aaaa" : ["2001:DB8::C8", "2001:DB8::C9"], 605 "ttl" : 60 606 } 607 } 608 A further example of a successful RI response (dCDN->uCDN) for DNS 609 based redirection is listed below, in this case with a cname key 610 containing the FQDN of the RT. 612 HTTP/1.1 200 OK 613 Date: Mon, 06 Aug 2012 18:41:38 GMT 614 Content-Type: application/cdni; ptype=redirection-response 616 { 617 "dns" : { 618 "rcode" : 0, 619 "name" : "www.example.com", 620 "cname" : ["rr1.dcdn.example"], 621 "ttl" : 20 622 } 623 } 625 4.5. HTTP Redirection 627 The following sections provide detailed descriptions of the 628 information that should be passed in RI requests and responses for 629 HTTP redirection. 631 The dictionary keys used in HTTP Redirection requests and responses 632 use the following conventions for their prefixes: 634 o c- is prefixed to keys for information related to the Client (User 635 Agent). 637 o cs- is prefixed to keys for information passed by the Client (User 638 Agent) to the Server (uCDN). 640 o sc- is prefixed to keys for information to be passed by the Server 641 (uCDN) to the Client (User Agent). 643 4.5.1. HTTP Redirection requests 645 For HTTP-based redirection the uCDN needs to pass the following 646 information to the dCDN in the RI request: 648 o The IP address of the User Agent. 650 o The URI requested by the User Agent. 652 o The HTTP method requested by the User Agent 654 o The HTTP version number requested by the User Agent. 656 The uCDN may also decide to pass the presence and value of particular 657 HTTP headers included in the User Agent request to the dCDN. 659 The information above is encoded as a set of key:value pairs within 660 the http dictionary as follows: 662 +-------------------+--------+-----------+--------------------------+ 663 | Key | Value | Mandatory | Description | 664 +-------------------+--------+-----------+--------------------------+ 665 | c-ip | String | Yes | The IP address of the | 666 | | | | UA. | 667 | cs-uri | String | Yes | The Effective Request | 668 | | | | URI [RFC7230] requested | 669 | | | | by the UA. | 670 | cs-method | String | Yes | The method part of the | 671 | | | | request-line as defined | 672 | | | | in Section 3.1.1 of | 673 | | | | [RFC7230]. | 674 | cs-version | String | Yes | The HTTP-version part of | 675 | | | | the request-line as | 676 | | | | defined in Section 3.1.1 | 677 | | | | of [RFC7230]. | 678 | cs-() | String | No | The field-value of the | 679 | | | | HTTP header field named | 680 | | | | as a | 681 | | | | string, for example, | 682 | | | | cs-(cookie) would | 683 | | | | contain the value of the | 684 | | | | HTTP Cookie header from | 685 | | | | the UA request. | 686 +-------------------+--------+-----------+--------------------------+ 688 An RI request for HTTP-based redirection MUST include an http 689 dictionary. This http dictionary MUST contain the following keys: 690 c-ip, cs-method, cs-version and cs-uri and the value of each MUST be 691 the value of the appropriate part of the User Agent's HTTP request. 693 The http dictionary of an RI request MUST contain a maximum of one 694 cs-() key for each unique header field-name (HTTP header 695 field). MUST be identical to the equivalent HTTP header 696 field-name encoded in all lowercase. 698 In the case where the User Agent request includes multiple HTTP 699 header fields with the same field-name, it is RECOMMENDED that the 700 uCDN combines these different HTTP headers into a single value 701 according to Section 3.2.2 of [RFC7230]. However, because of the 702 plurality of already defined HTTP header fields, and inconsistency of 703 some of these header fields concerning the combination mechanism 704 defined in RFC 7230, the uCDN MAY have to deviate from using the 705 combination mechanism where appropriate. For example, it might only 706 send the contents of the first occurrence of the HTTP Headers 707 instead. 709 An example RI request (uCDN->dCDN) for HTTP based redirection: 711 POST /dcdn/rrri HTTP/1.1 712 Host: rr1.dcdn.example.net 713 Content-Type: application/cdni; ptype=redirection-request 714 Accept: application/cdni; ptype=redirection-response 716 { 717 "http": { 718 "c-ip": "198.51.100.1", 719 "cs-uri": "http://www.example.com", 720 "cs-version": "HTTP/1.1", 721 "cs-method": "GET" 722 }, 723 "cdn-path": ["AS64496:0"], 724 "max-hops": 3 725 } 727 4.5.2. HTTP Redirection responses 729 For a successful HTTP based redirection, the dCDN needs to return one 730 of the following to the uCDN in the RI response: 732 o A URI pointing to an RT that is the selected dCDN surrogate(s) (if 733 the dCDN is performing HTTP based redirection directly to a 734 surrogate); or 736 o A URI pointing to an RT that is a Request Router (if the dCDN will 737 perform request redirection itself). 739 The information above is encoded as a set of key:value pairs within 740 the http dictionary as follows: 742 +-------------------+---------+-----------+-------------------------+ 743 | Key | Value | Mandatory | Description | 744 +-------------------+---------+-----------+-------------------------+ 745 | sc-status | Integer | Yes | The status-code part of | 746 | | | | the status-line as | 747 | | | | defined in Section | 748 | | | | 3.1.2 of [RFC7230] to | 749 | | | | return to the UA | 750 | | | | (usually set to 302). | 751 | sc-version | String | Yes | The HTTP-version part | 752 | | | | of the status-line as | 753 | | | | defined in Section | 754 | | | | 3.1.2 of [RFC7230] to | 755 | | | | return to the UA. | 756 | sc-reason | String | Yes | The reason-phrase part | 757 | | | | of the status-line as | 758 | | | | defined in Section | 759 | | | | 3.1.2 of [RFC7230] to | 760 | | | | return to the UA. | 761 | cs-uri | String | Yes | The URI requested by | 762 | | | | the UA/client. | 763 | sc-(location) | String | Yes | The contents of the | 764 | | | | Location header to | 765 | | | | return to the UA (i.e., | 766 | | | | a URI pointing to the | 767 | | | | RT(s)). | 768 | sc-() | String | No | The field-value of the | 769 | | | | HTTP header field named | 770 | | | | to return | 771 | | | | to the UA. For example, | 772 | | | | sc-(expires) would | 773 | | | | contain the value of | 774 | | | | the HTTP Expires | 775 | | | | header. | 776 +-------------------+---------+-----------+-------------------------+ 778 Note: The sc-(location) key in the table above is an example of 779 sc-() that has been called out separately as its presence 780 is mandatory in RI responses. 782 A successful RI response for HTTP-based redirection MUST include an 783 http dictionary and MAY include an error dictionary (see 784 Section 4.7). An unsuccessful RI response for HTTP-based redirection 785 MUST include an error dictionary. If an http dictionary is included 786 in the RI response, it MUST include at least the following keys: sc- 787 status, sc-version, sc-reason, cs-uri and sc-(location). 789 The http dictionary of an RI response MUST contain a maximum of one 790 sc-() key for each unique header field-name (HTTP header 791 field). MUST be identical to the equivalent HTTP header 792 field-name encoded in all lowercase. 794 The uCDN MAY decide to not return, override or alter any or all of 795 the HTTP headers defined by sc-() keys before sending the 796 HTTP response to the UA. It should be noted that in some cases, 797 sending the HTTP Headers indicated by the dCDN transparently on to 798 the UA might result in, for the uCDN, undesired behaviour. As an 799 example, the dCDN might include sc-(cache-control), sc-(last- 800 modified) and sc-(expires) keys in the http dictionary, through which 801 the dCDN may try to influence the cacheability of the response by the 802 UA. If the uCDN would pass these HTTP headers on to the UA, this 803 could mean that further requests from the uCDN would go directly to 804 the dCDN, bypassing the uCDN and any logging it may perform on 805 incoming requests. The uCDN is therefore recommended to carefully 806 consider which HTTP headers to pass on, and which to either override 807 or not pass on at all. 809 An example of a successful RI response (dCDN->uCDN) for HTTP based 810 redirection: 812 HTTP/1.1 200 OK 813 Date: Mon, 06 Aug 2012 18:41:38 GMT 814 Content-Type: application/cdni; ptype=redirection-response 816 { 817 "http": { 818 "sc-status": 302, 819 "sc-version": "HTTP/1.1", 820 "sc-reason": "Found", 821 "cs-uri": "http://www.example.com" 822 "sc-(location)": 823 "http://sur1.dcdn.example/ucdn/example.com", 824 } 825 } 827 4.6. Cacheability and scope of responses 829 RI responses may be cacheable. As long as a cached RI response is 830 not stale according to standard HTTP Cache-Control or other 831 applicable mechanisms, it may be reused by the uCDN in response to 832 User Agent requests without sending another RI request to the dCDN. 834 An RI response MUST NOT be reused unless the request from the User 835 Agent would generate an identical RI request to the dCDN as the one 836 that resulted in the cached RI response (except for the c-ip field 837 provided that the User Agent's c-ip is covered by the scope in the 838 original RI response, as elaborated upon below). 840 Additionally, although RI requests only encode a single User Agent 841 request to be redirected there may be cases where a dCDN wishes to 842 indicate to the uCDN that the RI response can be reused for other 843 User Agent requests without the uCDN having to make another request 844 via the RI. For example, a dCDN may know that it will always select 845 the same Surrogates for a given set of User Agent IP addresses and in 846 order to reduce request volume across the RI or to remove the 847 additional latency associated with an RI request, the dCDN may wish 848 to indicate that set of User Agent IP addresses to the uCDN in the 849 initial RI response. This is achieved by including an optional scope 850 dictionary in the RI response. 852 Scope is encoded as a set of key:value pairs within the scope 853 dictionary as follows: 855 +---------+--------+-----------+------------------------------------+ 856 | Key | Value | Mandatory | Description | 857 +---------+--------+-----------+------------------------------------+ 858 | iprange | List | No | A List of IP subnets in CIDR | 859 | | of | | notation that this RI response can | 860 | | String | | be reused for, provided the RI | 861 | | | | response is still considered | 862 | | | | fresh. | 863 +---------+--------+-----------+------------------------------------+ 865 If a uCDN has multiple cached responses with overlapping scopes and a 866 UA request comes in for which the User Agent's IP matches with the IP 867 subnets in multiple of these cached responses, the uCDN SHOULD use 868 the most recent cached response when determining the approriate RI 869 response to use. 871 The following is an example of a DNS redirection response from 872 Section 4.4.2 that is cacheable by the uCDN for 30 seconds and can be 873 returned to any User Agent with an IPv4 address in 198.51.100.0/24. 875 HTTP/1.1 200 OK 876 Date: Mon, 06 Aug 2012 18:41:38 GMT 877 Content-Type: application/cdni; ptype=redirection-response 878 Cache-Control: public, max-age=30 880 { 881 "dns" : { 882 "rcode" : 0, 883 "name" : "www.example.com", 884 "a" : ["203.0.113.200", "203.0.113.201"], 885 "aaaa" : ["2001:DB8::C8", "2001:DB8::C9"], 886 "ttl" : 60 887 } 888 "scope" : { 889 "iprange" : ["198.51.100.0/24"] 890 } 891 } 893 Example of HTTP redirection response from Section 4.5.2 that is 894 cacheable by the uCDN for 60 seconds and can be returned to any User 895 Agent with an IPv4 address in 198.51.100.0/24. 897 Note: The response to the UA is only valid for 30 seconds, whereas 898 the uCDN can cache the RI response for 60 seconds. 900 HTTP/1.1 200 OK 901 Date: Mon, 06 Aug 2012 18:41:38 GMT 902 Content-Type: application/cdni; ptype=redirection-response 903 Cache-Control: public, max-age=60 905 { 906 "http": { 907 "sc-status": 302, 908 "cs-uri": "http://www.example.com" 909 "sc-(location)": 910 "http://sur1.dcdn.example/ucdn/example.com", 911 "sc-(cache-control)" : "public, max-age=30" 912 } 913 "scope" : { 914 "iprange" : ["198.51.100.0/24"] 915 } 916 } 918 4.7. Error responses 920 From a uCDN perspective, there are two types of errors that can be 921 the result of the transmission of an RI request to a dCDN: 923 1. An HTTP protocol error signaled via an HTTP status code, 924 indicating a problem with the reception or parsing of the RI 925 request or the generation of the RI response by the dCDN, and 927 2. An RI-level error specified in an RI response message 929 This section deals with the latter type. The former type is outside 930 the scope of this document. 932 There are numerous reasons for a dCDN to be unable to return an 933 affirmative RI response to a uCDN. Reasons may include both dCDN 934 internal issues such as capacity problems, as well as reasons outside 935 the influence of the dCDN, such as a malformed RI request. To aid 936 with diagnosing the cause of errors, RI responses SHOULD include an 937 error dictionary to provide additional information to the uCDN as to 938 the reason/cause of the error. The intention behind the error 939 dictionary is to aid with either manual or automatic diagnosis of 940 issues. The resolution of such issues is outside the scope of this 941 document; this document does not specify any consequent actions a 942 uCDN should take upon receiving a particular error code. 944 Error information (if present) is encoded as a set of key:value pairs 945 within a JSON-encoded error dictionary as follows: 947 +------------+---------+-----------+--------------------------------+ 948 | Key | Value | Mandatory | Description | 949 +------------+---------+-----------+--------------------------------+ 950 | error-code | Integer | Yes | A three-digit numeric code | 951 | | | | defined by the server to | 952 | | | | indicate the error(s) that | 953 | | | | occurred. | 954 | reason | String | No | A string providing further | 955 | | | | information related to the | 956 | | | | error. | 957 +------------+---------+-----------+--------------------------------+ 959 The first digit of the error-code defines the class of error. There 960 are 5 classes of error distinguished by the first digit of the error- 961 code: 963 1xx: Informational (no error): The response should not be 964 considered an error by the uCDN, which may proceed by redirecting 965 the UA according to the values in the RI response. The error code 966 and accompanying description may be used for informational 967 purposes, e.g., for logging. 969 2xx: Reserved. 971 3xx: Reserved. 973 4xx: uCDN error: The dCDN can not or will not process the request 974 due to something that is perceived to be a uCDN error, for 975 example, the RI request could not be parsed succesfully by the 976 dCDN. The last two-digits may be used to more specifically 977 indicate the source of the problem. 979 5xx: dCDN error: Indicates that the dCDN is aware that it has 980 erred or is incapable of satisfying the RI request for some 981 reason, for example, the dCDN was able to parse the RI request but 982 encountered an error for some reason. Examples include the dCDN 983 not being able to retrieve the associated metadata or the dCDN 984 being out of capacity. 986 The following error codes are defined and maintained by IANA (see 987 Section 6): 989 Error codes with a "Reason" of "" do not have a defined value 990 for their 'reason'-key. Depending on the error-code semantics, the 991 value of this field may be determined dynamically. 993 +------+--------------+---------------------------------------------+ 994 | Code | Reason | Description | 995 +------+--------------+---------------------------------------------+ 996 | 100 | | Generic informational error-code meant for | 997 | | (see | carrying a human-readable string | 998 | | Description) | | 999 | 400 | | Generic error-code for uCDN errors where | 1000 | | (see | the dCDN can not or will not process the | 1001 | | Description) | request due to something that is perceived | 1002 | | | to be a uCDN error. The reason field may be | 1003 | | | used to provide more details about the | 1004 | | | source of the error. | 1005 | 500 | | Generic error-code for dCDN errors where | 1006 | | (see | the dCDN is aware that it has erred or is | 1007 | | Description) | incapable of satisfying the RI request for | 1008 | | | some reason. The reason field may be used | 1009 | | | to provide more details about the source of | 1010 | | | the error. | 1011 | 501 | Unable to | The dCDN is unable to retrieve the metadata | 1012 | | retrieve | associated with the content requested by | 1013 | | metadata | the UA. This may indicate a configuration | 1014 | | | error or the content requested by the UA | 1015 | | | not existing. | 1016 | 502 | Loop | The dCDN detected a redirection loop (see | 1017 | | detected | Section 4.8). | 1018 | 503 | Maximum hops | The dCDN detected the maximum number of | 1019 | | exceeded | redirection hops exceeding max-hops (see | 1020 | | | Section 4.8). | 1021 | 504 | Out of | The dCDN does not currently have sufficient | 1022 | | capacity | capacity to handle the UA request. | 1023 | 505 | Delivery | The dCDN does not support the (set of) | 1024 | | protocol not | delivery protocols indicated in the CDNI | 1025 | | supported | Metadata of the content requested content | 1026 | | | by the UA. | 1027 | 506 | Redirection | The dCDN does not support the requested | 1028 | | protocol not | redirection protocol. This error-code is | 1029 | | supported | also used when the RI request has the dns- | 1030 | | | only flag set to True and the dCDN is not | 1031 | | | support or is not prepared to return a RT | 1032 | | | of a surrogate directly. | 1033 +------+--------------+---------------------------------------------+ 1035 Table 1 1037 The following is an example of an unsuccessful RI response 1038 (dCDN->uCDN) for a DNS based User Agent request: 1040 HTTP/1.1 500 Internal Server Error 1041 Date: Mon, 06 Aug 2012 18:41:38 GMT 1042 Content-Type: application/cdni; ptype=redirection-response 1043 Cache-Control: private, no-cache 1045 { 1046 "error" : { 1047 "error-code" : 504, 1048 "description" : "Out of capacity" 1049 } 1050 } 1052 The following is an example of a successful RI response (dCDN->uCDN) 1053 for a HTTP based User Agent request containing an error dictionary 1054 for informational purposes: 1056 HTTP/1.1 200 OK 1057 Date: Mon, 06 Aug 2012 18:41:38 GMT 1058 Content-Type: application/cdni; ptype=redirection-response 1059 Cache-Control: private, no-cache 1061 { 1062 "http": { 1063 "sc-status": 302, 1064 "sc-version": "HTTP/1.1", 1065 "sc-reason": "Found", 1066 "cs-uri": "http://www.example.com" 1067 "sc-(location)": 1068 "http://sur1.dcdn.example/ucdn/example.com", 1069 }, 1070 "error" : { 1071 "error-code" : 100, 1072 "description" : 1073 "This is a human-readable message meant for debugging purposes" 1074 } 1075 } 1077 4.8. Loop detection & prevention 1079 In order to prevent and detect RI request loops, each CDN MUST insert 1080 its CDN Provider ID into the cdn-path key of every RI request it 1081 originates or cascades. When receiving RI requests a dCDN MUST check 1082 the cdn-path and reject any RI requests which already contain the 1083 dCDN's Provider ID in the cdn-path. Transit CDNs MUST NOT propagate 1084 to any downstream CDNs if the number of CDN Provider IDs in cdn-path 1085 (before adding its own Provider ID) is equal to or greater than max- 1086 hops. 1088 The CDN Provider ID uniquely identifies each CDN provider during the 1089 course of request routing redirection. It consists of the characters 1090 AS followed by the CDN Provider's AS number, then a colon (':') and 1091 an additional qualifier that is used to guarantee uniqueness in case 1092 a particular AS has multiple independent CDNs deployed. For example, 1093 "AS64496:0". 1095 If a dCDN receives an RI request whose cdn-path already contains that 1096 dCDN's Provider ID the dCDN MUST send an RI error response which 1097 SHOULD include an error code of 502. 1099 If a dCDN receives an RI request where the number of CDN Provider IDs 1100 in cdn-path is greater than max-hops, the dCDN MUST send an RI error 1101 response which SHOULD include an error code of 503. 1103 It should be noted that the loop detection & prevention mechanisms 1104 described above only cover preventing and detecting loops within the 1105 RI itself. Besides loops within the RI itself, there is also the 1106 possibility of loops in the data plane, for example, if the IP 1107 address(es) or URI(s) returned in RI responses do not resolve 1108 directly to a surrogate in the final dCDN there is the possibility 1109 that a User Agent may be continuously redirected through a loop of 1110 CDNs. The specification of solutions to address data plane request 1111 redirection loops between CDNs is outside of the scope of this 1112 document. 1114 5. Security Considerations 1116 Information passed over the RI could be considered personal or 1117 sensitive, for example, RI requests contain parts of a User Agent's 1118 original request and RI responses reveal information about the dCDN's 1119 policy for which surrogates should serve which content/user 1120 locations. 1122 The RI interface also provides a mechanism whereby a uCDN could probe 1123 a dCDN and infer the dCDN's edge topology by making repeated RI 1124 requests for different content and/or UA IP addresses and correlating 1125 the responses from the dCDN. Additionally the ability for a dCDN to 1126 indicate that an RI response applies more widely than the original 1127 request (via the scope dictionary) may significantly reduce the 1128 number of RI requests required to probe and infer the dCDN's edge 1129 topology. 1131 The same information could be obtained in the absence of the RI 1132 interface, but it could be more difficult to gather as it would 1133 require a distributed set of machines with a range of different IP 1134 addresses each making requests directly to the dCDN. However, the RI 1135 facilitates easier collection of such information as it enables a 1136 single client to query the dCDN for a redirection/surrogate selection 1137 on behalf of any UA IP address. 1139 5.1. Authentication, Authorization, Confidentiality, Integrity 1140 Protection 1142 An implementation of the CDNI Redirection interface MUST support TLS 1143 transport as per [RFC2818] and [RFC7230]. The use of TLS for 1144 transport of the CDNI Redirection interface messages allows: 1146 o The dCDN and uCDN to authenticate each other 1148 and, once they have mutually authenticated each other, it allows: 1150 o The dCDN and uCDN to authorize each other (to ensure they are 1151 transmitting/receiving CDNI Redirection messages to/from an 1152 authorized CDN); 1154 o CDNI Redirection interface messages to be transmitted with 1155 confidentiality; and 1157 o The integrity of the CDNI Redirection interface messages to be 1158 protected during the exchange. 1160 In an environment where any such protection is required, mutually 1161 authenticated encrypted transport MUST be used to ensure 1162 confidentiality of the redirection information, and to do so, TLS 1163 MUST be used (including authentication of the remote end) by the 1164 server-side (dCDN) and the client-side (uCDN) of the CDNI Redirection 1165 interface. 1167 When TLS is used, the general TLS usage guidance in [RFC7525] MUST be 1168 followed. 1170 5.2. Privacy 1172 Information passed over the RI ought to be considered personal and 1173 sensitive. In particular, parts of a User Agent's original request, 1174 most notably the UA's IP address and requested URI, are transmitted 1175 over the RI to the dCDN. The use of mutually authenticated TLS, as 1176 described in the previous section, prevents any other party than the 1177 authorized dCDN from gaining access to this information. 1179 Regardless of whether the uCDN and dCDN use the RI, a successfull 1180 redirect from a uCDN to a dCDN will make that dCDN aware of the UA's 1181 IP address. As such, the fact that this information is transmitted 1182 across the RI does not allow the dCDN to learn new information. On 1183 the other hand, if a uCDN uses the RI to check with multiple 1184 candidate dCDNs, those candidates that do not end up getting 1185 redirected to, do obtain information regarding End User IP addresses 1186 and requested URIs that they would not have, had the RI not been 1187 used. 1189 While it is technically possible to mask some information in the RI 1190 Request, such as the last bits of the UA IP address, it is important 1191 to note that this will reduce the effectivess of the RI in certain 1192 cases. CDN deployments need to strike a balance between end-user 1193 privacy and the features impacted by such masking. This balance is 1194 likely to vary from one deployment to another. As an example, when 1195 the UA and its DNS resolver is behind a Carrier-grade NAT, and the RI 1196 is used to find an appropriate delivery node behind the same NAT, the 1197 full IP address might be necessary. Another potential issue when 1198 using IP anonymization is that it is no longer possible to correlate 1199 an RI Request with a subsequent UA request. 1201 6. IANA Considerations 1203 6.1. CDNI Payload Type Parameter registrations 1205 The IANA is requested to register the following two new Payload Types 1206 in the CDNI Payload Type Parameter registry for use with the 1207 application/cdni MIME media type. 1209 [RFC Editor Note: Please replace the references to [RFCthis] below 1210 with this document's RFC number before publication. 1212 +----------------------+---------------+ 1213 | Payload Type | Specification | 1214 +----------------------+---------------+ 1215 | redirection-request | [RFCthis] | 1216 | redirection-response | [RFCthis] | 1217 +----------------------+---------------+ 1219 6.1.1. CDNI RI Redirection Request Payload Type 1221 Purpose: The purpose of this payload type is to distinguish RI 1222 request messages. 1224 Interface: RI 1226 Encoding: see Section 4.4.1 and Section 4.5.1 1228 6.1.2. CDNI RI Redirection Response Payload Type 1230 Purpose: The purpose of this payload type is to distinguish RI 1231 response messages. 1233 Interface: RI 1235 Encoding: see Section 4.4.2 and Section 4.5.2 1237 6.2. RI Error response registry 1239 IANA is requested to create a new "CDNI RI Error response code" 1240 subregistry within the "Content Delivery Network Interconnection 1241 (CDNI) Parameters" registry. The "CDNI RI Error response code" 1242 namespace defines the valid values for the error-code key in RI error 1243 responses. The CDNI RI Error response code MUST be a three digit 1244 integer. 1246 Additions to the "RI Error response registry" will be made via 1247 "Specification Required" as defined in [RFC5226]. 1249 The Designated Expert will verify that new error code registrations 1250 do not duplicate existing error code definitions (in name or 1251 functionality), ensure that the new error code is in accordance with 1252 the error classes defined in section Section 4.7 of this document, 1253 prevent gratuitous additions to the namespace, and prevent any 1254 additions to the namespace that would impair the interoperability of 1255 CDNI implementations. 1257 New registrations are required to provide the following information: 1259 Code: A three-digit numeric error-code, in accordance with the 1260 error classes defined in section Section 4.7 of this document. 1262 Reason: A string that provides further information related to the 1263 error that will be included in the JSON error dictionary with the 1264 'reason'-key. Depending on the error-code semantics, the value of 1265 this field may be determined dynamically. In that case, the 1266 registration should set this value to '' and define its 1267 semantics in the description field. 1269 Description: A brief description of the error code semantics. 1271 Specification: Reference to the specification that defines the 1272 error code in more detail. 1274 The entries in Table 1 are registered by this document, with the 1275 value of the 'Specification' field set to [RFCThis]. 1277 7. Contributors 1279 [RFC Editor Note: Please move the contents of this section to the 1280 Authors' Addresses section prior to publication as an RFC.] 1282 The following persons have participated as co-authors to this 1283 document: 1285 Wang Danhua, Huawei, Email: wangdanhua@huawei.com 1287 He Xiaoyan, Huawi, Email: hexiaoyan@huawei.com 1289 Ge Chen, China Telecom, Email: cheng@gsta.com 1291 Ni Wei, China Mobile, Email: niwei@chinamobile.com 1293 Yunfei Zhang, Email:hishigh@gmail.com 1295 Spencer Dawkins, Huawei, Email: spencer@wonderhamster.org 1297 8. Acknowledgements 1299 The authors would like to thank Taesang Choi, Francois le Faucheur, 1300 Matt Miller, Scott Wainner and Kevin J Ma for their valuable comments 1301 and input to this document. 1303 9. References 1305 9.1. Normative References 1307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1308 Requirement Levels", BCP 14, RFC 2119, 1309 DOI 10.17487/RFC2119, March 1997, 1310 . 1312 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1313 Resource Identifier (URI): Generic Syntax", STD 66, 1314 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1315 . 1317 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1318 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1319 2006, . 1321 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1322 Address Text Representation", RFC 5952, 1323 DOI 10.17487/RFC5952, August 2010, 1324 . 1326 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1327 Protocol (HTTP/1.1): Message Syntax and Routing", 1328 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1329 . 1331 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1332 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1333 2014, . 1335 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1336 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1337 April 2013, . 1339 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 1340 DOI 10.17487/RFC7493, March 2015, 1341 . 1343 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1344 "Recommendations for Secure Use of Transport Layer 1345 Security (TLS) and Datagram Transport Layer Security 1346 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1347 2015, . 1349 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1350 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1351 DOI 10.17487/RFC5226, May 2008, 1352 . 1354 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1355 Distribution Network Interconnection (CDNI) Problem 1356 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1357 2012, . 1359 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1360 DOI 10.17487/RFC2818, May 2000, 1361 . 1363 [RFC5890] Klensin, J., "Internationalized Domain Names for 1364 Applications (IDNA): Definitions and Document Framework", 1365 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1366 . 1368 [RTMP] Adobe Systems Incorporated, "Real-Time Messaging Protocol 1369 (RTMP) specification", December 2012, 1370 . 1372 9.2. Informative References 1374 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 1375 Network Interconnection (CDNI) Requirements", RFC 7337, 1376 DOI 10.17487/RFC7337, August 2014, 1377 . 1379 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1380 "Framework for Content Distribution Network 1381 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1382 August 2014, . 1384 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 1385 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 1386 December 2015, . 1388 Authors' Addresses 1390 Ben Niven-Jenkins (editor) 1391 Nokia 1392 3 Ely Road 1393 Milton, Cambridge CB24 6DD 1394 UK 1396 Email: ben.niven-jenkins@nokia.com 1398 Ray van Brandenburg (editor) 1399 TNO 1400 Anna van Buerenplein 1 1401 The Hague 2595DA 1402 the Netherlands 1404 Phone: +31-88-866-7000 1405 Email: ray.vanbrandenburg@tno.nl