idnits 2.17.1 draft-ietf-cdni-request-routing-extensions-06.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 (September 23, 2019) is 1670 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 7231 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Finkelman 3 Internet-Draft Qwilt 4 Intended status: Standards Track S. Mishra 5 Expires: March 26, 2020 Verizon 6 September 23, 2019 8 CDNI Request Routing Extensions 9 draft-ietf-cdni-request-routing-extensions-06 11 Abstract 13 Open Caching is a use case of Content Delivery Networks 14 Interconnetion (CDNI) in which the commercial Content Delivery 15 Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer 16 serves as the downstream CDN (dCDN). The extensions specified in 17 this document to the CDNI Metadata and FCI interfaces are derived 18 from requirements raised by Open Caching but are also applicable to 19 CDNI use cases in general. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 25 "OPTIONAL" in this document are to be interpreted as described in BCP 26 14 [RFC2119] [RFC8174] when, and only when, they appear in all 27 capitals, as shown here. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 26, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Redirect Target Capability . . . . . . . . . . . . . . . . . 3 66 2.1. Properties of Redirect Target Capability Object . . . . . 5 67 2.2. DnsTarget . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.3. HttpTarget . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.4. Usage Example . . . . . . . . . . . . . . . . . . . . . . 9 70 3. Fallback Target Address Metadata . . . . . . . . . . . . . . 10 71 3.1. Properties of Fallback Target Address Metadata Object . . 11 72 3.2. Usage Example . . . . . . . . . . . . . . . . . . . . . . 12 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 4.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 14 75 4.1.1. CDNI FCI RedirectTarget Payload Type . . . . . . . . 14 76 4.1.2. CDNI MI FallbackTarget Payload Type . . . . . . . . . 14 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 5.1. Confidentiality and Privacy . . . . . . . . . . . . . . . 15 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 82 7.2. Informative References . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 The Open Caching working group of the Streaming Video Alliance (SVA) 88 is focused on the delegation of video delivery requests from 89 commercial CDNs to a caching layer at the Internet Service Provider's 90 (ISP) network. Open Caching is a specific use case of CDNI where the 91 commercial CDN is the upstream CDN (uCDN) and the ISP caching layer 92 is the downstream CDN (dCDN). This document defines and registers 93 CDNI generic metadata object [RFC8006] and CDNI Footprint and 94 Capabilities object [RFC8008] that are required for Open Caching 95 request routing. For consistency with other CDNI documents this 96 document follows the CDNI convention of uCDN (upstream CDN) and dCDN 97 (downstream CDN) to represent the commerical CDN and ISP caching 98 layer respectively. 100 This document also registers CDNI Payload Types [RFC7736] for the 101 defined objects: 103 o Redirect Target Capability (for dCDN advertising redirect target 104 address) 106 o Fallback Target Metadata (for uCDN configuring fallback target 107 address) 109 1.1. Terminology 111 The following terms are used throughout this document: 113 o FQDN - Fully Qualified Domain Name 115 o CDN - Content Delivery Network 117 Additionaly, this document reuses the terminology defined in 118 [RFC6707], [RFC7336], [RFC8006], [RFC8007], and [RFC8008]. 119 Specifically, we use the following CDNI acronyms: 121 o FCI - Footprint and Capability Interface (see [RFC8008]) 123 o MI - Metadata Interface (see [RFC8006]) 125 o uCDN, dCDN - Upstream CDN and Downstream CDN respectively (see 126 [RFC7336]) 128 o RT - Redirection Target. Endpoint for redirection from uCDN to 129 dCDN. 131 o RR - Request Router. An element responsible for routing user 132 requests. 134 2. Redirect Target Capability 136 Iterative request redirection is defined in Section 1.1 of [RFC7336] 137 and elaborated by examples in Sections 3.2 and 3.4 of [RFC7336]. A 138 Redirection Target (RT) is defined in Section 2 of [RFC7975] for 139 Recursive Request Redirection as: 141 "The endpoint to which the User Agent is redirected. In CDNI, a 142 RT may point to a number of different components, some examples 143 include a surrogate in the same CDN as the request router, a 144 request router in a dCDN, or a surrogate in a dCDN". 146 In this document we adopt the same defintion of the RT for the 147 Iterative Request Redirect use case. This use case requires the 148 provisioning of the RT address to be used by the uCDN in order to 149 redirect to the dCDN. RT addresses can vary between different 150 footprints, for example, between different regions, and they may also 151 change over time, for example as a result of network problems. Given 152 this variable and dynamic nature of the redirect target address, it 153 may not be suitable to advertise it during bootstrap. A more dynamic 154 and footprint oriented interface is required. Section 4.3 of 155 [RFC7336] suggests that it could be one of the roles of the FCI 156 [RFC8008]. Following this suggestion we have, therefore, chosen to 157 use the CDNI Footprint and Capabilities interface for redirect target 158 address advertisement. 160 Use cases 162 o Footprint: The dCDN may want to have a different target per 163 footprint. Note that a dCDN may spread across multiple 164 geographies. This makes it easier to route client requests to a 165 nearby request router. Though this can be achieved using a single 166 canonical name and Geo DNS, that approach has limitations; for 167 example a client may be using a third party DNS resolver, making 168 it impossible for the redirector to detect where the client is 169 located, or Geo DNS granularity may be too rough for the 170 requirement of the application. 172 o Scaling: The dCDN may choose to scale its request routing service 173 by deploying more request routers in new locations and advertise 174 them via an updatable interface like the FCI. 176 The Redirect Target capability object is used to indicate the target 177 address the uCDN should use in order to redirect a client to the 178 dCDN. A target may be attached to a specific uCDN host, a list of 179 uCDN hosts, or used globally for all the hosts of the uCDN. 181 When a dCDN is attaching the redirect target to a specific uCDN host 182 or a list of uCDN hosts, the dCDN MUST advertise the hosts within the 183 Redirect Target capability object as "redirecting-hosts". In this 184 case, the uCDN can redirect to that dCDN address, only if the User 185 Agent request was to one of these uCDN hosts. 187 A redirect target for DNS redirection is an IPv4 address used as an A 188 record response, an IPv6 address used as an AAAA record response or a 189 FQDN used as an alias in a CNAME record response (see [RFC1034]) of 190 the uCDN DNS router. Note that DNS routers make routing decisions 191 based on either the DNS resolver's IP address or the client IP 192 address when EDNS0 client-subnet is used (see [RFC7871]). The dCDN 193 may choose to advertise redirect targets and footprints to cover both 194 cases. A uCDN DNS router implemenation SHOULD prefer routing based 195 on client IP address when it is available. 197 A redirect target for HTTP redirection is the URI to be used as the 198 value for the Location header of a HTTP redirect 3xx response, 199 typically a 302 (Found) (see Section 7.1.2 of [RFC7231] and section 200 6.4 of [RFC7231]). 202 If the redirect target capability object does not contain a target or 203 the target is empty, the uCDN MUST interpret it as "no target 204 available for these uCDN hosts for the specified footprint". In case 205 such a target was already advertised in a previous FCI object, the 206 uCDN MUST interperet it as an update that deletes the previous 207 redirect target. 209 2.1. Properties of Redirect Target Capability Object 211 The Redirect Target capability object consists of the following 212 properties: 214 Property: redirecting-hosts 216 Description: One or more uCDN hosts to which this redirect 217 target is attached. A redirecting host SHOULD be a host that 218 was published in a HostMatch object by the uCDN as defined in 219 Section 4.1.2 of [RFC8006]. 221 Type: A list of Endpoint objects (see Section 4.3.3 of 222 [RFC8006]) 224 Mandatory-to-Specify: No. If not present, or empty, the 225 redirect target applies to all hosts of the redirecting uCDN. 227 Property: dns-target 229 Description: Target address for a DNS A record, AAAA record or 230 CNAME record. 232 Type: DnsTarget object (see Section 2.2) 234 Mandatory-to-Specify: No. If the dns-target is not present or 235 empty the uCDN MUST interpret it as "no dns-target available". 237 Property: http-target 239 Description: Target URI for a HTTP redirect. 241 Type: HttpTarget object (see Section 2.3) 243 Mandatory-to-Specify: No. If the http-target is not present or 244 empty the uCDN MUST interpret it as "no http-target available". 246 The following is an example of a Redirect Target capability object 247 serialization that advertises a dCDN target address that is attached 248 to a specific list of uCDN "redirecting-hosts". A uCDN host that is 249 included in that list can redirect to the advertised dCDN redirect 250 target. The capabilities object is serialized as a JSON object as 251 defined in Section 5 of [RFC8008] 253 { 254 "capabilities": [ 255 { 256 "capability-type": "FCI.RedirectTarget", 257 "capability-value": { 258 "redirecting-hosts": [ 259 "a.service123.ucdn.example.com", 260 "b.service123.ucdn.example.com" 261 ], 262 "dns-target": { 263 "host": "service123.ucdn.dcdn.example.com" 264 }, 265 "http-target": { 266 "host": "us-east1.dcdn.example.com", 267 "path-prefix": "/cache/1/", 268 "include-redirecting-host": true 269 } 270 }, 271 "footprints": [ 272 273 ] 274 } 275 ] 276 } 278 2.2. DnsTarget 280 The DnsTarget object gives the target address for the DNS response to 281 delegate from the uCDN to the dCDN. 283 Property: host 284 Description: The host property is a hostname or an IP address, 285 without a port number. 287 Type: Endpoint object as defined in Section 4.3.3 of [RFC8006] 288 with the limitation that it SHOULD NOT include a port number 289 and, in case a port number is present, the uCDN MUST ignore it. 291 Mandatory-to-Specify: Yes. 293 The following is an example of DnsTarget object: 295 { 296 "host": "service123.ucdn.dcdn.example.com" 297 } 299 The following is an example of a DNS query for uCDN address 300 "a.service123.ucdn.example.com" and the corresponding CNAME 301 redirection response: 303 Query: 304 a.service123.ucdn.example.com: 305 type A, class IN 307 Response: 308 a.service123.ucdn.example.com: 309 type CNAME, class IN, cname service123.ucdn.dcdn.example.com 311 2.3. HttpTarget 313 The HttpTarget object gives the necessary information to construct 314 the target Location URI for HTTP redirection. 316 Property: host 318 Description: Hostname or IP address and an optional port, i.e., 319 the host and port of the authority component of the URI as 320 described in Section 3.2 of [RFC3986]. 322 Type: Endpoint object as defined in Section 4.3.3 of [RFC8006]. 324 Mandatory-to-Specify: Yes. 326 Property: path-prefix 328 Description: A path prefix for the HTTP redirect Location 329 header. The original path is appended after this prefix. 331 Type: A prefix of a path-absolute as defined in Section 3.3 of 332 [RFC3986]. The prefix MUST end with a trailing slash, to 333 indicate the end of the last path segment in the prefix. 335 Mandatory-to-Specify: No. If this property is absent or empty, 336 the uCDN MUST NOT prepend a path prefix to the original content 337 path, i.e., the original path MUST appear in the location URI 338 right after the authority component. 340 Property: include-redirecting-host 342 Description: A flag indicating whether or not to include the 343 redirecting host as the first path segment after the path- 344 prefix. If set to true and a "path-prefix" is used, the uCDN 345 redirecting host MUST be added as a separate path segment after 346 the path-prefix and before the original URL path. If set to 347 true and there is no path-prefix, the uCDN redirecting host 348 MUST be prepended as the first path segment in the redirect 349 URL. 351 Type: Boolean. 353 Mandatory-to-Specify: No. Default value is False. 355 Example of HttpTarget object with a path-prefix and include- 356 redirecting-host: 358 { 359 "host": "us-east1.dcdn.example.com", 360 "path-prefix": "/cache/1/", 361 "include-redirecting-host": true 362 } 364 Example of a HTTP request for content at uCDN host 365 "a.service123.ucdn.example.com" and the corresponding HTTP response 366 with Location header used for redirecting the client to the dCDN 367 using the the http-target in the above example: 369 Request: 370 GET /vod/1/movie.mp4 HTTP/1.1 371 Host: a.service123.ucdn.example.com 373 Response: 374 HTTP/1.1 302 Found 375 Location: http://us-east1.dcdn.example.com/cache/1/ 376 a.service123.ucdn.example.com/vod/1/movie.mp4 378 2.4. Usage Example 380 Before requests can be routed from the uCDN to the dCDN the CDNs must 381 exchange service configurations between them. Using the MI the uCDN 382 advertises out-of-band its hosts to the dCDN, each host is designated 383 by a host name and has its own specific metadata (see Section 4.1.2 384 of [RFC8006]. The dCDN, using the FCI, advertises, also out-of-band, 385 the redirect target address object defined in Section 2.1 for the 386 relevant uCDN hosts. The following is a generalized example of the 387 message flow between an upstream CDN and a downstream dCDN. For 388 simplicity, we focus on the sequence of messages between the uCDN and 389 dCDN and not on how they are passed. 391 dCDN uCDN 392 + + 393 | | 394 (1) | MI: host: s123.ucdn.example.com | 395 | host-metadata: < metadata > | 396 <-------------------------------------------------------+ 397 | | 398 (2) | FCI: capability-type: FCI.RedirectTarget | 399 | redirecting-hosts: us-east1.dcdn.example.com | 400 | target host: s123.ucdn.example.com | 401 +-------------------------------------------------------> 402 | | 403 | | 404 + + 406 Figure 1: Redirect target address advertisement 408 1. The uCDN advertises a host (s123.ucdn.example.com) with the host 409 metadata. 411 2. The dCDN adveritses its FCI objects to the uCDN including a 412 FCI.RedirectTarget object that contains the redirect target 413 address (us-east1.dcdn.example.com) specified for that uCDN host. 415 Once the redirect target has been set, the uCDN can start redirecting 416 user requests to the dCDN. The following is a generic sequence of 417 redirection using the host and redirect target that were advertised 418 in Figure 1 above. 420 End User dCDN uCDN RR 421 + + + 422 | | | 423 (1) | Request sent s123.ucdn.example.com | 424 +-----------------------+-----------------------> 425 | | | 426 (2) | Redirect to us-east1.dcdn.example.com | 427 <-----------------------+-----------------------+ 428 | | | 429 (3) | Request us-east1.dcdn.example.com | 430 +-----------------------> | 431 | | | 432 (4) | Response | | 433 <-----------------------+ | 434 | | | 435 + + + 437 Figure 2: Generic requests redirection sequence 439 1. The End User sends a request (DNS or HTTP) to the uCDN Request 440 Router (RR). 442 2. Using the previously advertised Redirect Target, the uCDN 443 redirects the request to the dCDN. 445 3. The End User sends a request to the dCDN. 447 4. The dCDN either sends a response or reroutes it, for example, to 448 a dCDN surrogate. 450 3. Fallback Target Address Metadata 452 Open Caching requires that the uCDN provides a fallback target server 453 to the dCDN, to be used in cases where the dCDN cannot properly 454 handle the request. To avoid redirect loops, the fallback target 455 server's address at the uCDN MUST be different from the original uCDN 456 address from which the client was redirected to the dCDN. The uCDN 457 MUST avoid further redirection when receiving the client request at 458 the fallback target. The fallback target is defined as a generic 459 metadata object (see Section 3.2 of [RFC8006]) 461 Use cases 463 o Failover: A dCDN request router receives a request but has no 464 caches to which it can route the request. This can happen in the 465 case of failures or temporary network overload. 467 o No coverage: A dCDN request router receives a request from a 468 client located in an area inside the footprint but not covered by 469 the dCDN caches or outside the dCDN footprint coverage. In such 470 cases, the router may choose to redirect the request back to the 471 uCDN fallback address. 473 o Error: A cache may receive a request that it cannot properly 474 serve, for example, some of the metadata objects for that service 475 were not properly acquired. In this case, the cache may resolve 476 to redirect back to uCDN. 478 The Fallback target metadata object is used to indicate the target 479 address the dCDN should use in order to redirect a client back to the 480 uCDN. Fallback target is represented as endpoint objects as defined 481 in section 4.3.3 of [RFC8006]. 483 The uCDN fallback target address may be used as a DNS A record, AAAA 484 record or CNAME record in case of DNS redirection or a hostname for 485 HTTP redirect. 487 When using HTTP redirect to route a client request back to the uCDN, 488 it is the dCDN's responsibility to use the original URL path as the 489 client would have used for the original uCDN request, stripping, if 490 needed, the dCDN path-prefix and/or the uCDN hostname from the 491 redirect URL that may have been used to request the content from the 492 dCDN. 494 3.1. Properties of Fallback Target Address Metadata Object 496 The MI.FallbackTarget Metadata object consists of the following 497 single property: 499 Property: host 501 Description: Target address to which the dCDN can redirect the 502 client. 504 Type: Endpoint object as defined in Section 4.3.3 of [RFC8006] 505 with the limitation that in case of DNS delegation it SHOULD 506 NOT include a port number and, in case a port number is 507 present, the dCDN MUST ignore it. 509 Mandatory-to-Specify: Yes. 511 Example of a MI.FallbackTarget Metadata object that designates the 512 host address the dCDN should use as fallback address to redirect back 513 to the uCDN. 515 { 516 "generic-metadata-type": "MI.FallbackTarget", 517 "generic-metadata-value": 518 { 519 "host": "fallback-a.service123.ucdn.example" 520 } 521 } 523 3.2. Usage Example 525 The uCDN advertises out-of-band the fallback target address to the 526 dCDN, so that the dCDN may redirect a request back to the uCDN in 527 case the dCDN cannot serve it. Using the MI the uCDN advertises its 528 hosts to the dCDN, along with their specific host metadata (see 529 Section 4.1.2 of [RFC8006]. The Fallback Target generic metadata 530 object is encapsulated within the "host-metadata" property of each 531 host. The following is an example of a message flow between an 532 upstream CDN and a downstream dCDN. For simplicity, we focus on the 533 sequence of messages between the uCDN and dCDN, not on how they are 534 passed. 536 dCDN uCDN 537 + + 538 | | 539 (1) | MI: host: s123.ucdn.example.com | 540 | host-metadata: | 541 | < metadata objects > | 542 | < MI.FallbackTarget | 543 | host: fallback-a.service123.ucdn.example > | 544 | < metadata objects > | 545 <-------------------------------------------------------+ 546 | | 547 (2) | FCI: capability-type: FCI.RedirectTarget | 548 | redirecting-hosts: us-east1.dcdn.example.com | 549 | target host: s123.ucdn.example.com | 550 +-------------------------------------------------------> 551 | | 552 | | 553 + + 555 Figure 3: Advertisement of host metadata with Fallback Target 557 1. The uCDN advertises a host (s123.ucdn.example.com) with the host 558 metadata. The host-metadata property contains a 559 MI.FallbackTarget object. 561 2. The dCDN adveritses its FCI objects to the uCDN including a 562 FCI.RedirectTarget object that contains the redirect target 563 address (us-east1.dcdn.example.com) specified for that uCDN host. 565 The following is a generic sequence of redirection using the 566 configurations that were advertised in Figure 3 above. In this case 567 the dCDN redirects back to the uCDN fallback target address. 569 End User dCDN uCDN fallback uCDN RR 570 + + + + 571 | | | | 572 (1) | Request sent s123.ucdn.example.com | | 573 +-------------------+-------------------+-------------------> 574 | | | | 575 (2) | Redirect to us-east1.dcdn.example.com | | 576 <-------------------+-------------------+-------------------+ 577 | | | | 578 (3) | Request us-east1.dcdn.example.com | | 579 +-------------------> | | 580 | | | | 581 (4) | Redirect back to fallback-a.service123.ucdn.example | 582 <-------------------+ | | 583 | | | | 584 (5) | Request fallback-a.service123.ucdn.example | 585 +---------------------------------------> | 586 | | | | 587 (6) | Response | | | 588 <-------------------+-------------------+ | 589 | | | | 590 + + + + 592 Figure 4: Redirection to Fallback Target 594 1. The End User sends a request (DNS or HTTP) to the uCDN Request 595 Router (RR). 597 2. Using the previously advertised Redirect Target, the uCDN 598 redirects the request to the dCDN. 600 3. The End User sends a request to the dCDN. 602 4. The dCDN cannot handled the request and, therefore, redirects it 603 back to the uCDN fallback target address. 605 5. The End User sends the request to the uCDN fallback target 606 address. 608 6. The uCDN either sends a response or reroutes it, for example, to 609 a uCDN surrogate. 611 4. IANA Considerations 613 4.1. CDNI Payload Types 615 This document requests the registration of the following CDNI Payload 616 Types under the IANA "CDNI Payload Types" registry defined in 617 [RFC7736]: 619 +--------------------+---------------+ 620 | Payload Type | Specification | 621 +--------------------+---------------+ 622 | FCI.RedirectTarget | RFCthis | 623 | MI.FallbackTarget | RFCthis | 624 +--------------------+---------------+ 626 [RFC Editor: Please replace RFCthis with the published RFC number for 627 this document.] 629 4.1.1. CDNI FCI RedirectTarget Payload Type 631 Purpose: The purpose of this payload type is to distinguish 632 RedirectTarget FCI objects 634 Interface: FCI 636 Encoding: see Section 2.1 638 4.1.2. CDNI MI FallbackTarget Payload Type 640 Purpose: The purpose of this payload type is to distinguish 641 FallbackTarget MI objects (and any associated capability 642 advertisement) 644 Interface: MI/FCI 646 Encoding: see Section 3.1 648 5. Security Considerations 650 This specification is in accordance with the CDNI Metadata Interface 651 and the CDNI Request Routing: Footprint and Capabilities Semantics. 652 As such, it is subject to the security and privacy considerations as 653 defined in Section 8 of [RFC8006] and in Section 7 of [RFC8008] 654 respectively. 656 5.1. Confidentiality and Privacy 658 The redirect Target FCI object potentially exposes information about 659 the internal strcture of the dCDN network. A third party could 660 intercept the FCI transactions and use the information to attack the 661 dCDN. An implemenation of the FCI MUST therefore use strong 662 authentication and encryption and strictly follow the directions for 663 securing the interface as defined for the Metadata Interface in 664 Section 8.3 of [RFC8006]. 666 6. Acknowledgements 668 The authors thank Nir B. Sopher for reality checks against production 669 use cases, his contribution is significant to this document. The 670 authors also thank Ben Niven-Jenkins for his review and feedback and 671 Kevin J. Ma for his guidance throughout the development of this 672 document including his regular reviews. 674 7. References 676 7.1. Normative References 678 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 679 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 680 . 682 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 683 Requirement Levels", BCP 14, RFC 2119, 684 DOI 10.17487/RFC2119, March 1997, 685 . 687 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 688 Resource Identifier (URI): Generic Syntax", STD 66, 689 RFC 3986, DOI 10.17487/RFC3986, January 2005, 690 . 692 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 693 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 694 DOI 10.17487/RFC7231, June 2014, 695 . 697 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 698 "Request Routing Redirection Interface for Content 699 Delivery Network (CDN) Interconnection", RFC 7975, 700 DOI 10.17487/RFC7975, October 2016, 701 . 703 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 704 "Content Delivery Network Interconnection (CDNI) 705 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 706 . 708 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 709 Interconnection (CDNI) Control Interface / Triggers", 710 RFC 8007, DOI 10.17487/RFC8007, December 2016, 711 . 713 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 714 R., and K. Ma, "Content Delivery Network Interconnection 715 (CDNI) Request Routing: Footprint and Capabilities 716 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 717 . 719 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 720 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 721 May 2017, . 723 7.2. Informative References 725 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 726 Distribution Network Interconnection (CDNI) Problem 727 Statement", RFC 6707, DOI 10.17487/RFC6707, September 728 2012, . 730 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 731 "Framework for Content Distribution Network 732 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 733 August 2014, . 735 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 736 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 737 December 2015, . 739 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 740 Kumari, "Client Subnet in DNS Queries", RFC 7871, 741 DOI 10.17487/RFC7871, May 2016, 742 . 744 Authors' Addresses 745 Ori Finkelman 746 Qwilt 747 6, Ha'harash 748 Hod HaSharon 4524079 749 Israel 751 Email: ori.finkelman.ietf@gmail.com 753 Sanjay Mishra 754 Verizon 755 13100 Columbia Pike 756 Silver Spring, MD 20904 757 USA 759 Email: sanjay.mishra@verizon.com