idnits 2.17.1 draft-ietf-cdni-metadata-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 2, 2016) is 2822 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'Object' is mentioned on line 337, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'POSIX' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6707 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-20) exists of draft-ietf-cdni-redirection-19 == Outdated reference: A later version (-26) exists of draft-ietf-cdni-uri-signing-09 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Niven-Jenkins 3 Internet-Draft R. Murray 4 Intended status: Standards Track Velocix (Alcatel-Lucent) 5 Expires: February 3, 2017 M. Caulfield 6 Cisco Systems 7 K. Ma 8 Ericsson 9 August 2, 2016 11 CDN Interconnection Metadata 12 draft-ietf-cdni-metadata-20 14 Abstract 16 The Content Delivery Networks Interconnection (CDNI) metadata 17 interface enables interconnected Content Delivery Networks (CDNs) to 18 exchange content distribution metadata in order to enable content 19 acquisition and delivery. The CDNI metadata associated with a piece 20 of content provides a downstream CDN with sufficient information for 21 the downstream CDN to service content requests on behalf of an 22 upstream CDN. This document describes both a base set of CDNI 23 metadata and the protocol for exchanging that metadata. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 3, 2017. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 67 1.2. Supported Metadata Capabilities . . . . . . . . . . . . . 5 68 2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 6 69 3. CDNI Metadata object model . . . . . . . . . . . . . . . . . 7 70 3.1. HostIndex, HostMatch, HostMetadata, PathMatch, 71 PatternMatch and PathMetadata objects . . . . . . . . . . 8 72 3.2. Generic CDNI Metadata Objects . . . . . . . . . . . . . . 10 73 3.3. Metadata Inheritance and Override . . . . . . . . . . . . 13 74 4. CDNI Metadata objects . . . . . . . . . . . . . . . . . . . . 14 75 4.1. Definitions of the CDNI structural metadata objects . . . 15 76 4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 15 77 4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 15 78 4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 17 79 4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 18 80 4.1.5. PatternMatch . . . . . . . . . . . . . . . . . . . . 19 81 4.1.6. PathMetadata . . . . . . . . . . . . . . . . . . . . 20 82 4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 21 83 4.2. Definitions of the initial set of CDNI Generic Metadata 84 objects . . . . . . . . . . . . . . . . . . . . . . . . . 23 85 4.2.1. SourceMetadata . . . . . . . . . . . . . . . . . . . 23 86 4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 24 87 4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 25 88 4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 27 89 4.2.2.2. Footprint . . . . . . . . . . . . . . . . . . . . 27 90 4.2.3. TimeWindowACL . . . . . . . . . . . . . . . . . . . . 29 91 4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 30 92 4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 31 93 4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 31 94 4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 32 95 4.2.5. DeliveryAuthorization Metadata . . . . . . . . . . . 33 96 4.2.6. Cache . . . . . . . . . . . . . . . . . . . . . . . . 34 97 4.2.7. Auth . . . . . . . . . . . . . . . . . . . . . . . . 36 98 4.2.8. Grouping . . . . . . . . . . . . . . . . . . . . . . 37 99 4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 37 100 4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 37 101 4.3.1.1. Link Loop Prevention . . . . . . . . . . . . . . 39 102 4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 39 103 4.3.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 39 104 4.3.4. Time . . . . . . . . . . . . . . . . . . . . . . . . 40 105 4.3.5. IPv4CIDR . . . . . . . . . . . . . . . . . . . . . . 40 106 4.3.6. IPv6CIDR . . . . . . . . . . . . . . . . . . . . . . 40 107 4.3.7. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 41 108 4.3.8. CountryCode . . . . . . . . . . . . . . . . . . . . . 41 109 5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 41 110 6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 42 111 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 42 112 6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 43 113 6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 44 114 6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 44 115 6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 45 116 6.6. Metadata Enforcement . . . . . . . . . . . . . . . . . . 46 117 6.7. Metadata Conflicts . . . . . . . . . . . . . . . . . . . 46 118 6.8. Versioning . . . . . . . . . . . . . . . . . . . . . . . 47 119 6.9. Media Types . . . . . . . . . . . . . . . . . . . . . . . 48 120 6.10. Complete CDNI Metadata Example . . . . . . . . . . . . . 48 121 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 122 7.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 52 123 7.1.1. CDNI MI HostIndex Payload Type . . . . . . . . . . . 53 124 7.1.2. CDNI MI HostMatch Payload Type . . . . . . . . . . . 53 125 7.1.3. CDNI MI HostMetadata Payload Type . . . . . . . . . . 54 126 7.1.4. CDNI MI PathMatch Payload Type . . . . . . . . . . . 54 127 7.1.5. CDNI MI PatternMatch Payload Type . . . . . . . . . . 54 128 7.1.6. CDNI MI PathMetadata Payload Type . . . . . . . . . . 54 129 7.1.7. CDNI MI SourceMetadata Payload Type . . . . . . . . . 54 130 7.1.8. CDNI MI Source Payload Type . . . . . . . . . . . . . 55 131 7.1.9. CDNI MI LocationACL Payload Type . . . . . . . . . . 55 132 7.1.10. CDNI MI LocationRule Payload Type . . . . . . . . . . 55 133 7.1.11. CDNI MI Footprint Payload Type . . . . . . . . . . . 55 134 7.1.12. CDNI MI TimeWindowACL Payload Type . . . . . . . . . 55 135 7.1.13. CDNI MI TimeWindowRule Payload Type . . . . . . . . . 56 136 7.1.14. CDNI MI TimeWindow Payload Type . . . . . . . . . . . 56 137 7.1.15. CDNI MI ProtocolACL Payload Type . . . . . . . . . . 56 138 7.1.16. CDNI MI ProtocolRule Payload Type . . . . . . . . . . 56 139 7.1.17. CDNI MI DeliveryAuthorization Payload Type . . . . . 56 140 7.1.18. CDNI MI Cache Payload Type . . . . . . . . . . . . . 57 141 7.1.19. CDNI MI Auth Payload Type . . . . . . . . . . . . . . 57 142 7.1.20. CDNI MI Grouping Payload Type . . . . . . . . . . . . 57 143 7.2. CDNI Metadata Footprint Types Registry . . . . . . . . . 57 144 7.3. CDNI Metadata Protocol Types Registry . . . . . . . . . . 58 145 8. Security Considerations . . . . . . . . . . . . . . . . . . . 58 146 8.1. Authentication and Integrity . . . . . . . . . . . . . . 59 147 8.2. Confidentiality and Privacy . . . . . . . . . . . . . . . 59 148 8.3. Securing the CDNI Metadata interface . . . . . . . . . . 60 149 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 60 150 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 60 151 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 61 152 11.1. Normative References . . . . . . . . . . . . . . . . . . 61 153 11.2. Informative References . . . . . . . . . . . . . . . . . 63 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 156 1. Introduction 158 Content Delivery Networks Interconnection (CDNI) [RFC6707] enables a 159 downstream Content Delivery Network (dCDN) to service content 160 requests on behalf of an upstream CDN (uCDN). 162 The CDNI metadata interface is discussed in [RFC7336] along with four 163 other interfaces that can be used to compose a CDNI solution (CDNI 164 Control interface, CDNI Request Routing Redirection interface, CDNI 165 Footprint & Capabilities Advertisement interface and CDNI Logging 166 interface). [RFC7336] describes each interface and the relationships 167 between them. The requirements for the CDNI metadata interface are 168 specified in [RFC7337]. 170 The CDNI metadata associated with a piece of content (or with a set 171 of content) provides a dCDN with sufficient information for servicing 172 content requests on behalf of an uCDN, in accordance with the 173 policies defined by the uCDN. 175 This document defines the CDNI metadata interface which enables a 176 dCDN to obtain CDNI metadata from an uCDN so that the dCDN can 177 properly process and respond to: 179 o Redirection requests received over the CDNI Request Routing 180 Redirection interface [I-D.ietf-cdni-redirection]. 182 o Content requests received directly from User Agents. 184 Specifically, this document specifies: 186 o A data structure for mapping content requests and redirection 187 requests to CDNI metadata objects (Section 3 and Section 4.1). 189 o An initial set of CDNI Generic metadata objects (Section 4.2). 191 o A HTTP web service for the transfer of CDNI metadata (Section 6). 193 1.1. Terminology 195 This document reuses the terminology defined in [RFC6707]. 197 Additionally, the following terms are used throughout this document 198 and are defined as follows: 200 o Object - a collection of properties. 202 o Property - a key and value pair where the key is a property name 203 and the value is the property value or another object. 205 This document uses the phrase "[Object] A contains [Object] B" for 206 simplicity when a strictly accurate phrase would be "[Object] A 207 contains or references (via a Link object) [Object] B". 209 1.2. Supported Metadata Capabilities 211 Only the metadata for a small set of initial capabilities is 212 specified in this document. This set provides the minimum amount of 213 metadata for basic CDN interoperability while still meeting the 214 requirements set forth by [RFC7337]. 216 The following high-level functionality can be configured via the CDNI 217 metadata objects specified in Section 4: 219 o Acquisition Source: Metadata for allowing a dCDN to fetch content 220 from a uCDN. 222 o Delivery Access Control: Metadata for restricting (or permitting) 223 access to content based on any of the following factors: 225 * Location 227 * Time Window 229 * Delivery Protocol 231 o Delivery Authorization: Metadata for authorizing dCDN user agent 232 requests. 234 o Cache Control: Metadata for controlling cache behavior of the 235 dCDN. 237 The metadata encoding described by this document is extensible in 238 order to allow for future additions to this list. 240 The set of metadata specified in this document covers the initial 241 capabilities above. It is only intended to support CDN 242 interconnection for the delivery of content by a dCDN using HTTP/1.1 243 [RFC7230] and for a dCDN to be able to acquire content from a uCDN 244 using either HTTP/1.1 or HTTP/1.1 over TLS [RFC2818]. 246 Supporting CDN interconnection for the delivery of content using 247 unencrypted HTTP/2 [RFC7540] (as well as for a dCDN to acquire 248 content using unencrypted HTTP/2 or HTTP/2 over TLS) requires the 249 registration of these protocol names in the CDNI Metadata Protocol 250 Types registry Section 7.3. 252 Delivery of content using HTTP/1.1 over TLS or HTTP/2 over TLS SHOULD 253 follow the guidelines set forth in [RFC7525]. Offline configuration 254 of TLS parameters between CDNs is beyond the scope of this document. 256 2. Design Principles 258 The CDNI metadata interface was designed to achieve the following 259 objectives: 261 1. Cacheability of CDNI metadata objects; 263 2. Deterministic mapping from redirection requests and content 264 requests to CDNI metadata properties; 266 3. Support for DNS redirection as well as application-specific 267 redirection (for example HTTP redirection); 269 4. Minimal duplication of CDNI metadata; and 271 5. Leveraging of existing protocols. 273 Cacheability can decrease the latency of acquiring metadata while 274 maintaining its freshness, and therefore decrease the latency of 275 serving content requests and redirection requests, without 276 sacrificing accuracy. The CDNI metadata interface uses HTTP and its 277 existing caching mechanisms to achieve CDNI metadata cacheability. 279 Deterministic mappings from content to metadata properties eliminates 280 ambiguity and ensures that policies are applied consistently by all 281 dCDNs. 283 Support for both HTTP and DNS redirection ensures that the CDNI 284 metadata meets the same design principles for both HTTP and DNS based 285 redirection schemes. 287 Minimal duplication of CDNI metadata improves storage efficiency in 288 the CDNs. 290 Leveraging existing protocols avoids reinventing common mechanisms 291 such as data structure encoding (by leveraging I-JSON [RFC7493]) and 292 data transport (by leveraging HTTP [RFC7230]). 294 3. CDNI Metadata object model 296 The CDNI metadata object model describes a data structure for mapping 297 redirection requests and content requests to metadata properties. 298 Metadata properties describe how to acquire content from an uCDN, 299 authorize access to content, and deliver content from a dCDN. The 300 object model relies on the assumption that these metadata properties 301 can be grouped based on the hostname of the content and subsequently 302 on the resource path (URI) of the content. The object model 303 associates a set of CDNI metadata properties with a Hostname to form 304 a default set of metadata properties for content delivered on behalf 305 of that Hostname. That default set of metadata properties can be 306 overridden by properties that apply to specific paths within a URI. 308 Different Hostnames and URI paths will be associated with different 309 sets of CDNI metadata properties in order to describe the required 310 behaviour when a dCDN surrogate or request router is processing User 311 Agent requests for content at that Hostname and URI path. As a 312 result of this structure, significant commonality could exist between 313 the CDNI metadata properties specified for different Hostnames, 314 different URI paths within a Hostname and different URI paths on 315 different Hostnames. For example the definition of which User Agent 316 IP addresses should be grouped together into a single network or 317 geographic location is likely to be common for a number of different 318 Hostnames; although a uCDN is likely to have several different 319 policies configured to express geo-blocking rules, it is likely that 320 a single geo-blocking policy could be applied to multiple Hostnames 321 delivered through the CDN. 323 In order to enable the CDNI metadata for a given Hostname and URI 324 Path to be decomposed into reusable sets of CDNI metadata properties, 325 the CDNI metadata interface splits the CDNI metadata into separate 326 objects. Efficiency is improved by enabling a single CDNI metadata 327 object (that is shared across Hostname and/or URI paths) to be 328 retrieved and stored by a dCDN once, even if it is referenced by the 329 CDNI metadata for multiple Hostnames and/or URI paths. 331 Important Note: Any CDNI metadata object A that contains another CDNI 332 metadata object B can include a Link object specifying a URI that can 333 be used to retrieve object B, instead of embedding object B within 334 object A. The remainder of this document uses the phrase "[Object] A 335 contains [Object] B" for simplicity when a strictly accurate phrase 336 would be "[Object] A contains or references (via a Link object) 337 [Object] B". It is generally a deployment choice for the uCDN 338 implementation to decide when to embed CDNI metadata objects and when 339 to reference separate resources via Link objects. 341 Section 3.1 introduces a high level description of the HostIndex, 342 HostMatch, HostMetadata, PathMatch, PatternMatch and PathMetadata 343 objects, and describes the relationships between them. 345 Section 3.2 introduces a high level description of the CDNI 346 GenericMetadata object which represents the level at which CDNI 347 metadata override occurs between HostMetadata and PathMetadata 348 objects. 350 Section 4 describes in detail the specific CDNI metadata objects and 351 properties specified by this document which can be contained within a 352 CDNI GenericMetadata object. 354 3.1. HostIndex, HostMatch, HostMetadata, PathMatch, PatternMatch and 355 PathMetadata objects 357 The relationships between the HostIndex, HostMatch, HostMetadata, 358 PathMatch, PatternMatch and PathMetadata objects are described in 359 Figure 1. 361 +---------+ +---------+ +------------+ 362 |HostIndex+-(*)->|HostMatch+-(1)->|HostMetadata+-------(*)------+ 363 +---------+ +---------+ +------+-----+ | 364 | | 365 (*) | 366 | V 367 --> Contains or References V ****************** 368 (1) One and only one +---------+ *Generic Metadata* 369 (*) Zero or more +--->|PathMatch| * Objects * 370 | +----+---++ ****************** 371 | | | ^ 372 (*) (1) (1) +------------+ | 373 | | +->|PatternMatch| | 374 | V +------------+ | 375 | +------------+ | 376 +--+PathMetadata+-------(*)------+ 377 +------------+ 379 Figure 1: Relationships between CDNI Metadata Objects (Diagram 380 Representation) 382 A HostIndex object (see Section 4.1.1) contains an array of HostMatch 383 objects (see Section 4.1.2) that contain Hostnames (and/or IP 384 addresses) for which content requests might be delegated to the dCDN. 385 The HostIndex is the starting point for accessing the uCDN CDNI 386 metadata data store. It enables the dCDN to deterministically 387 discover which CDNI metadata objects it requires in order to deliver 388 a given piece of content. 390 The HostIndex links Hostnames (and/or IP addresses) to HostMetadata 391 objects (see Section 4.1.3) via HostMatch objects. A HostMatch 392 object defines a Hostname (or IP address) to match against a 393 requested host and contains a HostMetadata object. 395 HostMetadata objects contain the default GenericMetadata objects (see 396 Section 4.1.7) required to serve content for that host. When looking 397 up CDNI metadata, the dCDN looks up the requested Hostname (or IP 398 address) against the HostMatch entries in the HostIndex, from there 399 it can find HostMetadata which describes the default metadata 400 properties for each host as well as PathMetadata objects (see 401 Section 4.1.6), via PathMatch objects (see Section 4.1.4). PathMatch 402 objects define patterns, contained inside PatternMatch objects (see 403 Section 4.1.5), to match against the requested URI path. 404 PatternMatch objects contain the pattern strings and flags that 405 describe the URI path that a PathMatch applies to. PathMetadata 406 objects contain the GenericMetadata objects that apply to content 407 requests matching the defined URI path pattern. PathMetadata 408 properties override properties previously defined in HostMetadata or 409 less specific PathMatch paths. PathMetadata objects can contain 410 additional PathMatch objects to recursively define more specific URI 411 paths to which GenericMetadata properties might be applied. 413 A GenericMetadata object contains individual CDNI metadata objects 414 which define the specific policies and attributes needed to properly 415 deliver the associated content. For example, a GenericMetadata 416 object could describe the source from which a CDN can acquire a piece 417 of content. The GenericMetadata object is an atomic unit that can be 418 referenced by HostMetadata or PathMetadata objects. 420 For example, if "example.com" is a content provider, a HostMatch 421 object could include an entry for "example.com" with the URI of the 422 associated HostMetadata object. The HostMetadata object for 423 "example.com" describes the metadata properties which apply to 424 "example.com" and could contain PathMatches for "example.com/ 425 movies/*" and "example.com/music/*", which in turn reference 426 corresponding PathMetadata objects that contain the properties for 427 those more specific URI paths. The PathMetadata object for 428 "example.com/movies/*" describes the properties which apply to that 429 URI path. It could also contain a PathMatch object for 430 "example.com/movies/hd/*" which would reference the corresponding 431 PathMetadata object for the "example.com/movies/hd/" path prefix. 433 The relationships in Figure 1 are also represented in tabular format 434 in Table 1 below. 436 +--------------+----------------------------------------------------+ 437 | Data Object | Objects it contains or references | 438 +--------------+----------------------------------------------------+ 439 | HostIndex | 0 or more HostMatch objects. | 440 | HostMatch | 1 HostMetadata object. | 441 | HostMetadata | 0 or more PathMatch objects. 0 or more | 442 | | GenericMetadata objects. | 443 | PathMatch | 1 PatternMatch object. 1 PathMetadata object. | 444 | PatternMatch | Does not contain or reference any other objects. | 445 | PathMetadata | 0 or more PathMatch objects. 0 or more | 446 | | GenericMetadata objects. | 447 +--------------+----------------------------------------------------+ 449 Table 1: Relationships between CDNI Metadata Objects 450 (Table Representation) 452 3.2. Generic CDNI Metadata Objects 454 The HostMetadata and PathMetadata objects contain other CDNI metadata 455 objects that contain properties which describe how User Agent 456 requests for content should be processed, for example where to 457 acquire the content from, authorization rules that should be applied, 458 geo-blocking restrictions, and so on. Each such CDNI metadata object 459 is a specialization of a CDNI GenericMetadata object. The 460 GenericMetadata object abstracts the basic information required for 461 metadata override and metadata distribution, from the specifics of 462 any given property (i.e., property semantics, enforcement options, 463 etc.). 465 The GenericMetadata object defines the properties contained within it 466 as well as whether or not the properties are "mandatory-to-enforce". 467 If the dCDN does not understand or support a "mandatory-to-enforce" 468 property, the dCDN MUST NOT serve the content. If the property is 469 not "mandatory-to-enforce", then that GenericMetadata object can be 470 safely ignored and the content request can be processed in accordance 471 with the rest of the CDNI metadata. 473 Although a CDN MUST NOT serve content to a User Agent if a 474 "mandatory-to-enforce" property cannot be enforced, it could still be 475 "safe-to-redistribute" that metadata to another CDN without 476 modification. For example, in the cascaded CDN case, a transit CDN 477 (tCDN) could pass through "mandatory-to-enforce" metadata to a dCDN. 479 For metadata which does not require customization or translation 480 (i.e., metadata that is "safe-to-redistribute"), the data 481 representation received off the wire MAY be stored and redistributed 482 without being understood or supported by the transit CDN. However, 483 for metadata which requires translation, transparent redistribution 484 of the uCDN metadata values might not be appropriate. Certain 485 metadata can be safely, though perhaps not optimally, redistributed 486 unmodified. For example, source acquisition address might not be 487 optimal if transparently redistributed, but it might still work. 489 Redistribution safety MUST be specified for each GenericMetadata 490 property. If a CDN does not understand or support a given 491 GenericMetadata property that is not "safe-to-redistribute", the CDN 492 MUST set the "incomprehensible" flag to true for that GenericMetadata 493 object before redistributing the metadata. The "incomprehensible" 494 flag signals to a dCDN that the metadata was not properly transformed 495 by the transit CDN. A CDN MUST NOT attempt to use metadata that has 496 been marked as "incomprehensible" by a uCDN. 498 Transit CDNs MUST NOT change the value of "mandatory-to-enforce" or 499 "safe-to-redistribute" when propagating metadata to a dCDN. Although 500 a transit CDN can set the value of "incomprehensible" to true, a 501 transit CDN MUST NOT change the value of "incomprehensible" from true 502 to false. 504 Table 2 describes the action to be taken by a transit CDN (tCDN) for 505 the different combinations of "mandatory-to-enforce" (MtE) and "safe- 506 to-redistribute" (StR) properties, when the tCDN either does or does 507 not understand the metadata in question: 509 +-------+-------+------------+--------------------------------------+ 510 | MtE | StR | Metadata | Action | 511 | | | Understood | | 512 | | | by tCDN | | 513 +-------+-------+------------+--------------------------------------+ 514 | False | True | True | Can serve and redistribute. | 515 | False | True | False | Can serve and redistribute. | 516 | False | False | False | Can serve. MUST set | 517 | | | | "incomprehensible" to True when | 518 | | | | redistributing. | 519 | False | False | True | Can serve. Can redistribute after | 520 | | | | transforming the metadata (if the | 521 | | | | CDN knows how to do so safely), | 522 | | | | otherwise MUST set | 523 | | | | "incomprehensible" to True when | 524 | | | | redistributing. | 525 | True | True | True | Can serve and redistribute. | 526 | True | True | False | MUST NOT serve but can redistribute. | 527 | True | False | True | Can serve. Can redistribute after | 528 | | | | transforming the metadata (if the | 529 | | | | CDN knows how to do so safely), | 530 | | | | otherwise MUST set | 531 | | | | "incomprehensible" to True when | 532 | | | | redistributing. | 533 | True | False | False | MUST NOT serve. MUST set | 534 | | | | "incomprehensible" to True when | 535 | | | | redistributing. | 536 +-------+-------+------------+--------------------------------------+ 538 Table 2: Action to be taken by a tCDN for the different combinations 539 of MtE and StR properties 541 Table 3 describes the action to be taken by a dCDN for the different 542 combinations of "mandatory-to-enforce" (MtE) and "incomprehensible" 543 (Incomp) properties, when the dCDN either does or does not understand 544 the metadata in question: 546 +-------+--------+--------------+-----------------------------------+ 547 | MtE | Incomp | Metadata | Action | 548 | | | Understood | | 549 | | | by dCDN | | 550 +-------+--------+--------------+-----------------------------------+ 551 | False | False | True | Can serve. | 552 | False | True | True | Can serve but MUST NOT | 553 | | | | interpret/apply any metadata | 554 | | | | marked incomprehensible. | 555 | False | False | False | Can serve. | 556 | False | True | False | Can serve but MUST NOT | 557 | | | | interpret/apply any metadata | 558 | | | | marked incomprehensible. | 559 | True | False | True | Can serve. | 560 | True | True | True | MUST NOT serve. | 561 | True | False | False | MUST NOT serve. | 562 | True | True | False | MUST NOT serve. | 563 +-------+--------+--------------+-----------------------------------+ 565 Table 3: Action to be taken by a dCDN for the different combinations 566 of MtE and Incomp properties 568 3.3. Metadata Inheritance and Override 570 In the metadata object model, a HostMetadata object can contain 571 multiple PathMetadata objects (via PathMatch objects). Each 572 PathMetadata object can in turn contain other PathMetadata objects. 573 HostMetadata and PathMetadata objects form an inheritance tree where 574 each node in the tree inherits or overrides the property values set 575 by its parent. 577 GenericMetadata objects of a given type override all GenericMetadata 578 objects of the same type previously defined by any parent object in 579 the tree. GenericMetadata objects of a given type previously defined 580 by a parent object in the tree are inherited when no object of the 581 same type is defined by the child object. For example, if 582 HostMetadata for the host "example.com" contains GenericMetadata 583 objects of type LocationACL and TimeWindowACL, while a PathMetadata 584 object which applies to "example.com/movies/*" defines an alternate 585 GenericMetadata object of type TimeWindowACL, then: 587 o the TimeWindowACL defined in the PathMetadata would override the 588 TimeWindowACL defined in the HostMetadata for all User Agent 589 requests for content under "example.com/movies/", and 591 o the LocationACL defined in the HostMetadata would be inherited for 592 all User Agent requests for content under "example.com/movies/". 594 A single HostMetadata or PathMetadata object MUST NOT contain 595 multiple GenericMetadata objects of the same type. If an array of 596 GenericMetadata contains objects of duplicate types, the receiver 597 MUST ignore all but the first object of each type. 599 4. CDNI Metadata objects 601 Section 4.1 provides the definitions of each metadata object type 602 introduced in Section 3. These metadata objects are described as 603 structural metadata objects as they provide the structure for host 604 and URI path-based inheritance and identify which GenericMetadata 605 objects apply to a given User Agent content request. 607 Section 4.2 provides the definitions for a base set of core metadata 608 objects which can be contained within a GenericMetadata object. 609 These metadata objects govern how User Agent requests for content are 610 handled. GenericMetadata objects can contain other GenericMetadata 611 as properties; these can be referred to as sub-objects). As with all 612 CDNI metadata objects, the value of the GenericMetadata sub-objects 613 can be either a complete serialized representation of the sub-object, 614 or a Link object that contains a URI that can be dereferenced to 615 retrieve the complete serialized representation of the property sub- 616 object. 618 Section 6.5 discusses the ability to extend the base set of 619 GenericMetadata objects specified in this document with additional 620 standards-based or vendor specific GenericMetadata objects that might 621 be defined in the future in separate documents. 623 dCDNs and tCDNs MUST support parsing of all CDNI metadata objects 624 specified in this document. A dCDN does not have to implement the 625 underlying functionality represented by non-structural 626 GenericMetadata objects (though that might restrict the content that 627 a given dCDN will be able to serve). uCDNs as generators of CDNI 628 metadata only need to support generating the CDNI metadata that they 629 need in order to express the policies required by the content they 630 are describing. See Section 6.4 for more details on the specific 631 encoding rules for CDNI metadata objects. 633 Note: In the following sections, the term "mandatory-to-specify" is 634 used to convey which properties MUST be included for a given 635 structural or GenericMetadata object. When mandatory-to-specify is 636 specified as "Yes" for an individual property, it means that if the 637 object containing that property is included in a metadata response, 638 then the mandatory-to-specify property MUST also be included 639 (directly or by reference) in the response, e.g., a HostMatch 640 property object without a host to match against does not make sense, 641 therefore, the host property is mandatory-to-specify inside a 642 HostMatch object. 644 4.1. Definitions of the CDNI structural metadata objects 646 Each of the sub-sections below describe the structural objects 647 introduced in Section 3.1. 649 4.1.1. HostIndex 651 The HostIndex object is the entry point into the CDNI metadata 652 hierarchy. It contains an array of HostMatch objects. An incoming 653 content request is checked against the Hostname (or IP address) 654 specified by each of the listed HostMatch objects to find the 655 HostMatch object which applies to the request. 657 Property: hosts 659 Description: Array of HostMatch objects. Hosts (HostMatch 660 objects) MUST be evaluated in the order they appear and the 661 first HostMatch object that matches the content request being 662 processed MUST be used. 664 Type: Array of HostMatch objects 666 Mandatory-to-Specify: Yes. 668 Example HostIndex object containing two HostMatch objects, where the 669 first HostMatch object is embedded and the second HostMatch object is 670 referenced: 672 { 673 "hosts": [ 674 { 675 676 }, 677 { 678 "type": "MI.HostMatch", 679 "href": "https://metadata.ucdn.example/hostmatch1234" 680 } 681 ] 682 } 684 4.1.2. HostMatch 686 The HostMatch object contains a Hostname or IP address to match 687 against content requests. The HostMatch object also contains a 688 HostMetadata object to apply if a match is found. 690 Property: host 692 Description: Hostname or IP address and optional port to match 693 against the requested host, i.e., the [RFC3986] host and port. 694 In order for a Hostname or IP address in a content request to 695 match the Hostname or IP address in the host property the value 696 from the content request when converted to lowercase MUST be 697 identical to the value of the host property when converted to 698 lowercase. All implementations MUST support IPv4 addresses 699 encoded as specified by the 'IPv4address' rule in Section 3.2.2 700 of [RFC3986]. IPv6 addresses MUST be encoded in one of the 701 IPv6 address formats specified in [RFC5952] although receivers 702 MUST support all IPv6 address formats specified in [RFC4291]. 703 Hostnames MUST conform to the Domain Name System (DNS) syntax 704 defined in [RFC1034] and [RFC1123]. Internationalized Domain 705 Names (IDN) must first be transformed to the IDNA encoding as 706 per [RFC5891]. 708 Type: Endpoint 710 Mandatory-to-Specify: Yes. 712 Property: host-metadata 714 Description: CDNI metadata to apply when delivering content 715 that matches this host. 717 Type: HostMetadata 719 Mandatory-to-Specify: Yes. 721 Example HostMatch object with an embedded HostMetadata object: 723 { 724 "host": "video.example.com", 725 "host-metadata" : { 726 727 } 728 } 730 Example HostMatch object referencing (via a Link object, see 731 Section 4.3.1) a HostMetadata object: 733 { 734 "host": "video.example.com", 735 "host-metadata" : { 736 "type": "MI.HostMetadata", 737 "href": "https://metadata.ucdn.example/host1234" 738 } 739 } 741 4.1.3. HostMetadata 743 A HostMetadata object contains the CDNI metadata properties for 744 content served for a particular host (defined in the HostMatch 745 object) and possibly child PathMatch objects. 747 Property: metadata 749 Description: Array of host related metadata. 751 Type: Array of GenericMetadata objects 753 Mandatory-to-Specify: Yes. 755 Property: paths 757 Description: Path specific rules. Path patterns (PathMatch 758 objects) MUST be evaluated in the order they appear and the 759 first (and only the first) PathMatch object that matches the 760 content request being processed MUST be used. 762 Type: Array of PathMatch objects 764 Mandatory-to-Specify: No. 766 Example HostMetadata object containing a number of embedded 767 GenericMetadata objects that will describe the default metadata for 768 the host and an embedded PathMatch object that contains a path for 769 which metadata exists that overrides the default metadata for the 770 host: 772 { 773 "metadata": [ 774 { 775 776 }, 777 { 778 779 }, 781 ... 783 { 784 785 } 786 ], 787 "paths": [ 788 { 789 790 } 791 ] 792 } 794 4.1.4. PathMatch 796 A PathMatch object contains PatternMatch object with a path to match 797 against a resource's URI path, as well as how to handle URI query 798 parameters. The PathMatch also contains a PathMetadata object with 799 GenericMetadata to apply if the resource's URI matches the pattern 800 within the PatternMatch object. 802 Property: path-pattern 804 Description: Pattern to match against the requested resource's 805 URI. 807 Type: PatternMatch 809 Mandatory-to-Specify: Yes. 811 Property: path-metadata 813 Description: CDNI metadata to apply when delivering content 814 that matches the associated PatternMatch. 816 Type: PathMetadata 818 Mandatory-to-Specify: Yes. 820 Example PathMatch object referencing the PathMetadata object to use 821 for URIs that match the case-sensitive URI path pattern "/movies/*" 822 (contained within an embedded PatternMatch object): 824 { 825 "path-pattern": { 826 "pattern": "/movies/*", 827 "case-sensitive": true 828 }, 829 "path-metadata": { 830 "type": "MI.PathMetadata", 831 "href": "https://metadata.ucdn.example/host1234/pathDCE" 832 } 833 } 835 4.1.5. PatternMatch 837 A PatternMatch object contains the pattern string and flags that 838 describe the pattern expression. 840 Property: pattern 842 Description: A pattern for matching against the URI path, i.e., 843 against the [RFC3986] path-absolute. The pattern can contain 844 the wildcards * and ?, where * matches any sequence of 845 [RFC3986] pchar or "/" characters (including the empty string) 846 and ? matches exactly one [RFC3986] pchar character. The three 847 literals $, * and ? MUST be escaped as $$, $* and $? (where $ 848 is the designated escape character). All other characters are 849 treated as literals. 851 Type: String 853 Mandatory-to-Specify: Yes. 855 Property: case-sensitive 857 Description: Flag indicating whether or not case-sensitive 858 matching should be used. Note: Case-insensitivity applies to 859 ALPHA characters in the URI path prior to percent-decoding 860 [RFC3986]. 862 Type: Boolean 864 Mandatory-to-Specify: No. Default is case-insensitive match. 866 Example PatternMatch object that matches the case-sensitive URI path 867 pattern "/movies/*". All query parameters will be ignored when 868 matching URIs requested from surrogates by content clients against 869 this path pattern: 871 { 872 "pattern": "/movies/*", 873 "case-sensitive": true 874 } 876 Example PatternMatch object that matches the case-sensitive URI path 877 pattern "/movies/*". Only the query parameter "sessionid" will be 878 evaluated when matching URIs requested from surrogates by content 879 clients against this path pattern: 881 { 882 "pattern": "/movies/*", 883 "case-sensitive": true 884 } 886 4.1.6. PathMetadata 888 A PathMetadata object contains the CDNI metadata properties for 889 content requests that match against the associated URI path (defined 890 in a PathMatch object). 892 Note that if DNS-based redirection is employed, then a dCDN will be 893 unable to evaluate any metadata at the PathMetadata level or below 894 because only the hostname of the content request is available at 895 request routing time. dCDNs SHOULD still process all PathMetadata for 896 the host before responding to the redirection request to detect if 897 any unsupported metadata is specified. If any metadata not supported 898 by the dCDN is marked as "mandatory-to-enforce", the dCDN SHOULD NOT 899 accept the content redirection request, in order to avoid receiving 900 content requests that it will not be able to satisfy/serve. 902 Property: metadata 904 Description: Array of path related metadata. 906 Type: Array of GenericMetadata objects 908 Mandatory-to-Specify: Yes. 910 Property: paths 912 Description: Path specific rules. Path patterns (PathMatch 913 objects) MUST be evaluated in the order they appear and the 914 first (and only the first) PathMatch object that matches the 915 content request being processed MUST be used. 917 Type: Array of PathMatch objects 919 Mandatory-to-Specify: No. 921 Example PathMetadata object containing a number of embedded 922 GenericMetadata objects that describe the metadata to apply for the 923 URI path defined in the parent PathMatch object, as well as a more 924 specific PathMatch object. 926 { 927 "metadata": [ 928 { 929 930 }, 931 { 932 933 }, 935 ... 937 { 938 939 } 940 ], 941 "paths": [ 942 { 943 944 } 945 ] 946 } 948 4.1.7. GenericMetadata 950 A GenericMetadata object is a wrapper for managing individual CDNI 951 metadata properties in an opaque manner. 953 Property: generic-metadata-type 955 Description: Case-insensitive CDNI metadata object type. 957 Type: String containing the CDNI Payload Type [RFC7736] of the 958 object contained in the generic-metadata-value property (see 959 Table 4). 961 Mandatory-to-Specify: Yes. 963 Property: generic-metadata-value 964 Description: CDNI metadata object. 966 Type: Format/Type is defined by the value of generic-metadata- 967 type property above. Note: generic-metadata-values MUST NOT 968 name any properties "href" (see Section 4.3.1). 970 Mandatory-to-Specify: Yes. 972 Property: mandatory-to-enforce 974 Description: Flag identifying whether or not the enforcement of 975 the property metadata is required. 977 Type: Boolean 979 Mandatory-to-Specify: No. Default is to treat metadata as 980 mandatory to enforce (i.e., a value of True). 982 Property: safe-to-redistribute 984 Description: Flag identifying whether or not the property 985 metadata can be safely redistributed without modification. 987 Type: Boolean 989 Mandatory-to-Specify: No. Default is allow transparent 990 redistribution (i.e., a value of True). 992 Property: incomprehensible 994 Description: Flag identifying whether or not any CDN in the 995 chain of delegation has failed to understand and/or failed to 996 properly transform this metadata object. Note: This flag only 997 applies to metadata objects whose safe-to-redistribute property 998 has a value of False. 1000 Type: Boolean 1002 Mandatory-to-Specify: No. Default is comprehensible (i.e., a 1003 value of False). 1005 Example GenericMetadata object containing a metadata object that 1006 applies to the applicable URI path and/or host (within a parent 1007 PathMetadata and/or HostMetadata object, respectively): 1009 { 1010 "mandatory-to-enforce": true, 1011 "safe-to-redistribute": true, 1012 "incomprehensible": false, 1013 "generic-metadata-type": , 1014 "generic-metadata-value": 1015 { 1016 1017 } 1018 } 1020 4.2. Definitions of the initial set of CDNI Generic Metadata objects 1022 The objects defined below are intended to be used in the 1023 GenericMetadata object generic-metadata-value field as defined in 1024 Section 4.1.7 and their generic-metadata-type property MUST be set to 1025 the appropriate CDNI Payload Type as defined in Table 4. 1027 4.2.1. SourceMetadata 1029 Source metadata provides the dCDN with information about content 1030 acquisition, i.e., how to contact an uCDN Surrogate or an Origin 1031 Server to obtain the content to be served. The sources are not 1032 necessarily the actual Origin Servers operated by the CSP but might 1033 be a set of Surrogates in the uCDN. 1035 Property: sources 1037 Description: Sources from which the dCDN can acquire content, 1038 listed in order of preference. 1040 Type: Array of Source objects (see Section 4.2.1.1) 1042 Mandatory-to-Specify: No. Default is to use static 1043 configuration, out-of-band from the metadata interface. 1045 Example SourceMetadata object (which contains two Source objects) 1046 that describes which servers the dCDN should use for acquiring 1047 content for the applicable URI path and/or host: 1049 { 1050 "generic-metadata-type": "MI.SourceMetadata", 1051 "generic-metadata-value": 1052 { 1053 "sources": [ 1054 { 1055 "endpoints": [ 1056 "a.service123.ucdn.example", 1057 "b.service123.ucdn.example" 1058 ], 1059 "protocol": "http/1.1" 1060 }, 1061 { 1062 "endpoints": ["origin.service123.example"], 1063 "protocol": "http/1.1" 1064 } 1065 ] 1066 } 1067 } 1069 4.2.1.1. Source 1071 A Source object describes the source to be used by the dCDN for 1072 content acquisition (e.g., a Surrogate within the uCDN or an 1073 alternate Origin Server), the protocol to be used, and any 1074 authentication method to be used when contacting that source. 1076 Endpoints within a Source object MUST be treated as equivalent/equal. 1077 A uCDN can specify an array of sources in preference order within a 1078 SourceMetadata object, and then for each preference ranked Source 1079 object, a uCDN can specify an array of endpoints that are equivalent 1080 (e.g., a pool of servers that are not behind a load balancer). 1082 Property: acquisition-auth 1084 Description: Authentication method to use when requesting 1085 content from this source. 1087 Type: Auth (see Section 4.2.7) 1089 Mandatory-to-Specify: No. Default is no authentication 1090 required. 1092 Property: endpoints 1094 Description: Origins from which the dCDN can acquire content. 1095 If multiple endpoints are specified they are all equal, i.e., 1096 the list is not in preference order (e.g., a pool of servers 1097 behind a load balancer). 1099 Type: Array of Endpoint objects (See Section 4.3.3) 1101 Mandatory-to-Specify: Yes. 1103 Property: protocol 1105 Description: Network retrieval protocol to use when requesting 1106 content from this source. 1108 Type: Protocol (see Section 4.3.2) 1110 Mandatory-to-Specify: Yes. 1112 Example Source object that describes a pair of endpoints (servers) 1113 the dCDN can use for acquiring content for the applicable host and/or 1114 URI path: 1116 { 1117 "endpoints": [ 1118 "a.service123.ucdn.example", 1119 "b.service123.ucdn.example" 1120 ], 1121 "protocol": "http/1.1" 1122 } 1124 4.2.2. LocationACL Metadata 1126 LocationACL metadata defines which locations a User Agent needs to be 1127 in, in order to be able to receive the associated content. 1129 A LocationACL which does not include a locations property results in 1130 an action of allow all, meaning that delivery can be performed 1131 regardless of the User Agent's location, otherwise a CDN MUST take 1132 the action from the first footprint to match against the User Agent's 1133 location. If two or more footprints overlap, the first footprint 1134 that matches against the User Agent's location determines the action 1135 a CDN MUST take. If the locations property is included but is empty, 1136 or if none of the listed footprints matches the User Agent's 1137 location, then the result is an action of deny. 1139 Although the LocationACL, TimeWindowACL (see Section 4.2.3), and 1140 ProtocolACL (see Section 4.2.4) are independent GenericMetadata 1141 objects, they can provide conflicting information to a dCDN, e.g., a 1142 content request which is simultaneously allowed based on the 1143 LocationACL and denied based on the TimeWindowACL. The dCDN MUST use 1144 the logical AND of all ACLs (where 'allow' is true and 'deny' is 1145 false) to determine whether or not a request should be allowed. 1147 Property: locations 1149 Description: Access control list which allows or denies 1150 (blocks) delivery based on the User Agent's location. 1152 Type: Array of LocationRule objects (see Section 4.2.2.1) 1154 Mandatory-to-Specify: No. Default is allow all locations. 1156 Example LocationACL object that allows the dCDN to deliver content to 1157 any location/IP address: 1159 { 1160 "generic-metadata-type": "MI.LocationACL", 1161 "generic-metadata-value": 1162 { 1163 } 1164 } 1166 Example LocationACL object (which contains a LocationRule object 1167 which itself contains a Footprint object) that only allows the dCDN 1168 to deliver content to User Agents in the USA: 1170 { 1171 "generic-metadata-type": "MI.LocationACL", 1172 "generic-metadata-value": 1173 { 1174 "locations": [ 1175 { 1176 "action": "allow", 1177 "footprints": [ 1178 { 1179 "footprint-type": "countrycode", 1180 "footprint-value": ["us"] 1181 } 1182 ] 1183 } 1184 ] 1185 } 1186 } 1188 4.2.2.1. LocationRule 1190 A LocationRule contains or references an array of Footprint objects 1191 and the corresponding action. 1193 Property: footprints 1195 Description: Array of footprints to which the rule applies. 1197 Type: Array of Footprint objects (see Section 4.2.2.2) 1199 Mandatory-to-Specify: Yes. 1201 Property: action 1203 Description: Defines whether the rule specifies locations to 1204 allow or deny. 1206 Type: Enumeration [allow|deny] encoded as a lowercase string 1208 Mandatory-to-Specify: No. Default is deny. 1210 Example LocationRule object (which contains a Footprint object) that 1211 allows the dCDN to deliver content to clients in the USA: 1213 { 1214 "action": "allow", 1215 "footprints": [ 1216 { 1217 "footprint-type": "countrycode", 1218 "footprint-value": ["us"] 1219 } 1220 ] 1221 } 1223 4.2.2.2. Footprint 1225 A Footprint object describes the footprint to which a LocationRule 1226 can be applied to, e.g., an IPv4 address range or a geographic 1227 location. 1229 Property: footprint-type 1231 Description: Registered footprint type (see Section 7.2). The 1232 footprint types specified by this document are: "ipv4cidr" 1233 (IPv4CIDR, see Section 4.3.5), "ipv6cidr" (IPv6CIDR, see 1234 Section 4.3.6), "asn" (Autonomous System Number, see 1235 Section 4.3.7) and "countrycode" (Country Code, see 1236 Section 4.3.8). 1238 Type: Lowercase String 1240 Mandatory-to-Specify: Yes. 1242 Property: footprint-value 1244 Description: Array of footprint values conforming to the 1245 specification associated with the registered footprint type. 1246 Footprint values can be simple strings (e.g., IPv4CIDR, 1247 IPv6CIDR, ASN, and CountryCode), however, other Footprint 1248 objects can be defined in the future, along with a more complex 1249 encoding (e.g., GPS coordinate tuples). 1251 Type: Array of footprints 1253 Mandatory-to-Specify: Yes. 1255 Example Footprint object describing a footprint covering the USA: 1257 { 1258 "footprint-type": "countrycode", 1259 "footprint-value": ["us"] 1260 } 1262 Example Footprint object describing a footprint covering the IP 1263 address ranges 192.0.2.0/24 and 198.51.100.0/24: 1265 { 1266 "footprint-type": "ipv4cidr", 1267 "footprint-value": ["192.0.2.0/24", "198.51.100.0/24"] 1268 } 1270 Example Footprint object describing a footprint covering the IP 1271 address ranges 2001:db8::/32: 1273 { 1274 "footprint-type": "ipv6cidr", 1275 "footprint-value": ["2001:db8::/32"] 1276 } 1278 Example Footprint object describing a footprint covering the 1279 autonomous system 64496: 1281 { 1282 "footprint-type": "asn", 1283 "footprint-value": ["as64496"] 1284 } 1286 4.2.3. TimeWindowACL 1288 TimeWindowACL metadata defines time-based restrictions. 1290 A TimeWindowACL which does not include a times property results in an 1291 action of allow all, meaning that delivery can be performed 1292 regardless of the time of the User Agent's request, otherwise a CDN 1293 MUST take the action from the first window to match against the 1294 current time. If two or more windows overlap, the first window that 1295 matches against the current time determines the action a CDN MUST 1296 take. If the times property is included but is empty, or if none of 1297 the listed windows matches the current time, then the result is an 1298 action of deny. 1300 Although the LocationACL (see Section 4.2.2), TimeWindowACL, and 1301 ProtocolACL (see Section 4.2.4) are independent GenericMetadata 1302 objects, they can provide conflicting information to a dCDN, e.g., a 1303 content request which is simultaneously allowed based on the 1304 LocationACL and denied based on the TimeWindowACL. The dCDN MUST use 1305 the logical AND of all ACLs (where 'allow' is true and 'deny' is 1306 false) to determine whether or not a request should be allowed. 1308 Property: times 1310 Description: Access control list which allows or denies 1311 (blocks) delivery based on the time of a User Agent's request. 1313 Type: Array of TimeWindowRule objects (see Section 4.2.3.1) 1315 Mandatory-to-Specify: No. Default is allow all time windows. 1317 Example TimeWIndowACL object (which contains a TimeWindowRule object 1318 which itself contains a TimeWIndow object) that only allows the dCDN 1319 to deliver content to clients between 09:00 01/01/2000 UTC and 17:00 1320 01/01/2000 UTC: 1322 { 1323 "generic-metadata-type": "MI.TimeWindowACL", 1324 "generic-metadata-value": 1325 { 1326 "times": [ 1327 { 1328 "action": "allow", 1329 "windows": [ 1330 { 1331 "start": 946717200, 1332 "end": 946746000 1333 } 1334 ] 1335 } 1336 ] 1337 } 1338 } 1340 4.2.3.1. TimeWindowRule 1342 A TimeWindowRule contains or references an array of TimeWindow 1343 objects and the corresponding action. 1345 Property: windows 1347 Description: Array of time windows to which the rule applies. 1349 Type: Array of TimeWindow objects (see Section 4.2.3.2) 1351 Mandatory-to-Specify: Yes. 1353 Property: action 1355 Description: Defines whether the rule specifies time windows to 1356 allow or deny. 1358 Type: Enumeration [allow|deny] encoded as a lowercase string 1360 Mandatory-to-Specify: No. Default is deny. 1362 Example TimeWIndowRule object (which contains a TimeWIndow object) 1363 that only allows the dCDN to deliver content to clients between 09:00 1364 01/01/2000 UTC and 17:00 01/01/2000 UTC: 1366 { 1367 "action": "allow", 1368 "windows": [ 1369 { 1370 "start": 946717200, 1371 "end": 946746000 1372 } 1373 ] 1374 } 1376 4.2.3.2. TimeWindow 1378 A TimeWindow object describes a time range which can be applied by an 1379 TimeWindowACL, e.g., start 946717200 (i.e., 09:00 01/01/2000 UTC), 1380 end: 946746000 (i.e., 17:00 01/01/2000 UTC). 1382 Property: start 1384 Description: The start time of the window. 1386 Type: Time (see Section 4.3.4) 1388 Mandatory-to-Specify: Yes. 1390 Property: end 1392 Description: The end time of the window. 1394 Type: Time (see Section 4.3.4) 1396 Mandatory-to-Specify: Yes. 1398 Example TimeWIndow object that describes a time window from 09:00 1399 01/01/2000 UTC to 17:00 01/01/2000 UTC: 1401 { 1402 "start": 946717200, 1403 "end": 946746000 1404 } 1406 4.2.4. ProtocolACL Metadata 1408 ProtocolACL metadata defines delivery protocol restrictions. 1410 A ProtocolACL which does not include a protocol-acl property results 1411 in an action of allow all, meaning that delivery can be performed 1412 regardless of the protocol in the User Agent's request, otherwise a 1413 CDN MUST take the action from the first protocol to match against the 1414 request protocol. If two or more request protocols overlap, the 1415 first protocol that matches the request protocol determines the 1416 action a CDN MUST take. If the protocol-acl property is included but 1417 is empty, or if none of the listed protocol matches the request 1418 protocol, then the result is an action of deny. 1420 Although the LocationACL, TimeWindowACL, and ProtocolACL are 1421 independent GenericMetadata objects, they can provide conflicting 1422 information to a dCDN, e.g., a content request which is 1423 simultaneously allowed based on the ProtocolACL and denied based on 1424 the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs 1425 (where 'allow' is true and 'deny' is false) to determine whether or 1426 not a request should be allowed. 1428 Property: protocol-acl 1430 Description: Description: Access control list which allows or 1431 denies (blocks) delivery based on delivery protocol. 1433 Type: Array of ProtocolRule objects (see Section 4.2.4.1) 1435 Mandatory-to-Specify: No. Default is allow all protocols. 1437 Example ProtocolACL object (which contains a ProtocolRule object) 1438 that only allows the dCDN to deliver content using HTTP/1.1: 1440 { 1441 "generic-metadata-type": "MI.ProtocolACL", 1442 "generic-metadata-value": 1443 { 1444 "protocol-acl": [ 1445 { 1446 "action": "allow", 1447 "protocols": ["http/1.1"] 1448 } 1449 ] 1450 } 1451 } 1453 4.2.4.1. ProtocolRule 1455 A ProtocolRule contains or references an array of Protocol objects 1456 and the corresponding action. 1458 Property: protocols 1460 Description: Array of protocols to which the rule applies. 1462 Type: Array of Protocols (see Section 4.3.2) 1464 Mandatory-to-Specify: Yes. 1466 Property: action 1468 Description: Defines whether the rule specifies protocols to 1469 allow or deny. 1471 Type: Enumeration [allow|deny] encoded as a lowercase string 1473 Mandatory-to-Specify: No. Default is deny. 1475 Example ProtocolRule object (which contains a ProtocolRule object) 1476 that allows the dCDN to deliver content using HTTP/1.1: 1478 { 1479 "action": "allow", 1480 "protocols": ["http/1.1"] 1481 } 1483 4.2.5. DeliveryAuthorization Metadata 1485 Delivery Authorization defines authorization methods for the delivery 1486 of content to User Agents. 1488 Property: delivery-auth-methods 1490 Description: Options for authorizing content requests. 1491 Delivery for a content request is authorized if any of the 1492 authorization methods in the list is satisfied for that 1493 request. 1495 Type: Array of Auth objects (see Section 4.2.7) 1497 Mandatory-to-Specify: No. Default is no authorization 1498 required. 1500 Example DeliveryAuthorization object (which contains an Auth object): 1502 { 1503 "generic-metadata-type": "MI.DeliveryAuthorization", 1504 "generic-metadata-value": 1505 { 1506 "delivery-auth-methods": [ 1507 { 1508 "auth-type": , 1509 "auth-value": 1510 { 1511 1512 } 1513 } 1514 ] 1515 } 1516 } 1518 4.2.6. Cache 1520 A Cache object describes the cache control parameters to be applied 1521 to the content by intermediate caches. 1523 Cache keys are generated from the URI of the content request 1524 [RFC7234]. In some cases, a CDN or content provider might want 1525 certain path segments or query parameters to be excluded from the 1526 cache key generation. The Cache object provides guidance on what 1527 parts of the path and query string to include. 1529 Property: exclude-path-pattern 1531 Description: A pattern for matching against the URI path, i.e., 1532 against the [RFC3986] path-absolute. The pattern can contain 1533 the wildcards * and ?, where * matches any sequence of 1534 [RFC3986] pchar or "/" characters (including the empty string) 1535 and ? matches exactly one [RFC3986] pchar character. The three 1536 literals $, * and ? MUST be escaped as $$, $* and $? (where $ 1537 is the designated escape character). All other characters are 1538 treated as literals. Cache key generation MUST only include 1539 the portion of the path-absolute that matches the wildcard 1540 portions of the pattern. Note: Inconsistency between the 1541 PatternMatch pattern Section 4.1.5 and the exclude-path-pattern 1542 can result in inefficient caching. 1544 Type: String 1546 Mandatory-to-Specify: No. Default is to use the full URI path- 1547 absolute to generate the cache key. 1549 Property: include-query-strings 1550 Description: Allows a Surrogate to specify the URI query string 1551 parameters [RFC3986] to include when comparing the requested 1552 URI against the URIs in its cache for equivalence. Matching 1553 query parameters MUST be case-insensitive. If all query 1554 parameters should be ignored, then the list MUST be specified 1555 and MUST be empty. If a query parameter appears multiple times 1556 in the query string, each instance value MUST be aggregated 1557 prior to comparison. For consistent cache key generation, 1558 query parameters SHOULD be evaluated in the order specified in 1559 this array. 1561 Type: Array of String 1563 Mandatory-to-Specify: No. Default is to consider all query 1564 string parameters when comparing URIs. 1566 Example Cache object that instructs the dCDN to use the full URI path 1567 and ignore all query parameters: 1569 { 1570 "generic-metadata-type": "MI.Cache", 1571 "generic-metadata-value": 1572 { 1573 "include-query-strings": [] 1574 } 1575 } 1577 Example Cache object that instructs the dCDN to exclude the "CDNX" 1578 path prefix and only include the (case-insensitive) query parameters 1579 named "mediaid" and "providerid": 1581 { 1582 "generic-metadata-type": "MI.Cache", 1583 "generic-metadata-value": 1584 { 1585 "exclude-path-pattern": "/CDNX/*", 1586 "include-query-strings": ["mediaid", "providerid"] 1587 } 1588 } 1590 Example Cache object that instructs the dCDN to exclude the "CDNX" 1591 path prefix, but includes all query parameters: 1593 { 1594 "generic-metadata-type": "MI.Cache", 1595 "generic-metadata-value": 1596 { 1597 "exclude-path-pattern": "/CDNX/*" 1598 } 1599 } 1601 4.2.7. Auth 1603 An Auth object defines authentication and authorization methods to be 1604 used during content acquisition and content delivery, respectively. 1606 Note: This document does not define any Auth methods. Individual 1607 Auth methods are being defined separately (e.g., URI Signing 1608 [I-D.ietf-cdni-uri-signing]). The GenericMetadata which contain Auth 1609 objects is defined herein for convenience and so as not to be 1610 specific to any particular Auth method. 1612 Property: auth-type 1614 Description: Auth type (The CDNI Payload Type [RFC7736] of the 1615 GenericMetadata object contained in the auth-value property). 1617 Type: String 1619 Mandatory-to-Specify: Yes. 1621 Property: auth-value 1623 Description: An object conforming to the specification 1624 associated with the Auth type. 1626 Type: GenericMetadata Object 1628 Mandatory-to-Specify: Yes. 1630 Example Auth object: 1632 { 1633 "generic-metadata-type": "MI.Auth", 1634 "generic-metadata-value": 1635 { 1636 "auth-type": , 1637 "auth-value": 1638 { 1639 1640 } 1641 } 1642 } 1644 4.2.8. Grouping 1646 A Grouping object identifies a group of content to which a given 1647 asset belongs. 1649 Property: ccid 1651 Description: Content Collection identifier for an application- 1652 specific purpose such as logging aggregation. 1654 Type: String 1656 Mandatory-to-Specify: No. Default is an empty string. 1658 Example Grouping object that specifies a Content Collection 1659 Identifier for the content associated with the Grouping object's 1660 parent HostMetadata and PathMetadata: 1662 { 1663 "generic-metadata-type": "MI.Grouping", 1664 "generic-metadata-value": 1665 { 1666 "ccid": "ABCD" 1667 } 1668 } 1670 4.3. CDNI Metadata Simple Data Type Descriptions 1672 This section describes the simple data types that are used for 1673 properties of CDNI metadata objects. 1675 4.3.1. Link 1677 A Link object can be used in place of any of the objects or 1678 properties described above. Link objects can be used to avoid 1679 duplication if the same metadata information is repeated within the 1680 metadata tree. When a Link object replaces another object, its href 1681 property is set to the URI of the resource and its type property is 1682 set to the CDNI Payload Type of the object it is replacing. 1684 dCDNs can detect the presence of a Link object by detecting the 1685 presence of a property named "href" within the object. This means 1686 that GenericMetadata types MUST NOT contain a property named "href" 1687 because doing so would conflict with the ability for dCDNs to detect 1688 Link objects being used to reference a GenericMetadata object. 1690 Property: href 1692 Description: The URI of the addressable object being 1693 referenced. 1695 Type: String 1697 Mandatory-to-Specify: Yes. 1699 Property: type 1701 Description: The CDNI Payload type of the object being 1702 referenced. 1704 Type: String 1706 Mandatory-to-Specify: No. If the container specifies the type 1707 (e.g., the HostIndex object contains an array of HostMatch 1708 objects, so a Link object in the list of HostMatch objects must 1709 reference a HostMatch), then it is not necessary to explicitly 1710 specify a type. 1712 Example Link object referencing a HostMatch object: 1714 { 1715 "type": "MI.HostMatch", 1716 "href": "https://metadata.ucdn.example/hostmatch1234" 1717 } 1719 Example Link object referencing a HostMatch object, without an 1720 explicit type, inside a HostIndex object: 1722 { 1723 "hosts": [ 1724 { 1725 1726 }, 1727 { 1728 "href": "https://metadata.ucdn.example/hostmatch1234" 1729 } 1730 ] 1731 } 1733 4.3.1.1. Link Loop Prevention 1735 When following a Link, CDNI metadata clients SHOULD verify that the 1736 CDNI Payload Type of the object retrieved matches the expected CDNI 1737 Payload Type, as indicated by the link object. For GenericMetadata 1738 objects, type checks will prevent self references; however, incorrect 1739 linking can result in circular references for structural metadtata 1740 objects, specifically, PathMatch and PathMetadata objects Figure 1. 1741 To prevent the circular references, CDNI metadata clients SHOULD 1742 verify that no duplicate Links occur for PathMatch or PathMetadata 1743 objects. 1745 4.3.2. Protocol 1747 Protocol objects are used to specify registered protocols for content 1748 acquisition or delivery (see Section 7.3). 1750 Type: String 1752 Example: 1754 "http/1.1" 1756 4.3.3. Endpoint 1758 A Hostname (with optional port) or an IP address (with optional 1759 port). 1761 All implementations MUST support IPv4 addresses encoded as specified 1762 by the 'IPv4address' rule in Section 3.2.2 of [RFC3986]. IPv6 1763 addresses MUST be encoded in one of the IPv6 address formats 1764 specified in [RFC5952] although receivers MUST support all IPv6 1765 address formats specified in [RFC4291]. Hostnames MUST conform to 1766 the Domain Name System (DNS) syntax defined in [RFC1034] and 1767 [RFC1123]. Internationalized Domain Names (IDN) must first be 1768 transformed to the IDNA encoding as per [RFC5891]. 1770 Type: String 1772 Example Hostname: 1774 "metadata.ucdn.example" 1776 Example IPv4 address: 1778 "192.0.2.1" 1780 Example IPv6 address (with port number): 1782 "[2001:db8::1]:81" 1784 4.3.4. Time 1786 A time value expressed in seconds since the Unix epoch (i.e., zero 1787 hours, zero minutes, zero seconds, on January 1, 1970) Coordinated 1788 Universal Time (UTC) [POSIX]. 1790 Type: Integer 1792 Example Time representing 09:00:00 01/01/2000 UTC: 1794 946717200 1796 4.3.5. IPv4CIDR 1798 An IPv4address CIDR block encoded as specified by the 'IPv4address' 1799 rule in Section 3.2.2 of [RFC3986] followed by a / followed by an 1800 unsigned integer representing the leading bits of the routing prefix 1801 (i.e., IPv4 CIDR notation). Single IP addresses can be expressed as 1802 /32. 1804 Type: String 1806 Example IPv4 CIDR: 1808 "192.0.2.0/24" 1810 4.3.6. IPv6CIDR 1812 An IPv6address CIDR block encoded in one of the IPv6 address formats 1813 specified in [RFC5952] followed by a / followed by an unsigned 1814 integer representing the leading bits of the routing prefix (i.e., 1815 IPv6 CIDR notation). Single IP addresses can be expressed as /128. 1817 Type: String 1818 Example IPv6 CIDR: 1820 "2001:db8::/32" 1822 4.3.7. ASN 1824 An Autonomous System Number encoded as a string consisting of the 1825 characters "as" (in lowercase) followed by the Autonomous System 1826 number [RFC6793]. 1828 Type: String 1830 Example ASN: 1832 "as64496" 1834 4.3.8. CountryCode 1836 An ISO 3166-1 alpha-2 code [ISO3166-1] in lowercase. 1838 Type: String 1840 Example Country Code representing the USA: 1842 "us" 1844 5. CDNI Metadata Capabilities 1846 CDNI metadata is used to convey information pertaining to content 1847 delivery from uCDN to dCDN. For optional metadata, it can be useful 1848 for the uCDN to know if the dCDN supports the underlying 1849 functionality described by the metadata, prior to delegating any 1850 content requests to the dCDN. If some metadata is "mandatory-to- 1851 enforce", and the dCDN does not support it, any delegated requests 1852 for content that requires that metadata will fail. The uCDN will 1853 likely want to avoid delegating those requests to that dCDN. 1854 Likewise, for any metadata which might be assigned optional values, 1855 it could be useful for the uCDN to know which values a dCDN supports, 1856 prior to delegating any content requests to that dCDN. If the 1857 optional value assigned to a given piece of content's metadata is not 1858 supported by the dCDN, any delegated requests for that content can 1859 fail, so again the uCDN is likely to want to avoid delegating those 1860 requests to that dCDN. 1862 The CDNI Footprint and Capabilities Interface (FCI) provides a means 1863 of advertising capabilities from dCDN to uCDN [RFC7336]. Support for 1864 optional metadata types and values can be advertised using the FCI. 1866 6. CDNI Metadata interface 1868 This section specifies an interface to enable a dCDN to retrieve CDNI 1869 metadata objects from a uCDN. 1871 The interface can be used by a dCDN to retrieve CDNI metadata objects 1872 either: 1874 o Dynamically as required by the dCDN to process received requests. 1875 For example in response to a query from an uCDN over the CDNI 1876 Request Routing Redirection interface (RI) 1877 [I-D.ietf-cdni-redirection] or in response to receiving a request 1878 for content from a User Agent. Or; 1880 o In advance of being required. For example in the case of pre- 1881 positioned CDNI metadata acquisition, initiated through the "CDNI 1882 Control interface / Triggers" (CI/T) interface 1883 [I-D.ietf-cdni-control-triggers]. 1885 The CDNI metadata interface is built on the principles of HTTP web 1886 services. In particular, this means that requests and responses over 1887 the interface are built around the transfer of representations of 1888 hyperlinked resources. A resource in the context of the CDNI 1889 metadata interface is any object in the object model (as described in 1890 Section 3 and Section 4). 1892 To retrieve CDNI metadata, a CDNI metadata client (i.e., a client in 1893 the dCDN) first makes a HTTP GET request for the URI of the HostIndex 1894 which provides the CDNI metadata client with an array of Hostnames 1895 for which the uCDN can delegate content delivery to the dCDN. The 1896 CDNI metadata client can then obtain any other CDNI metadata objects 1897 by making a HTTP GET requests for any linked metadata objects it 1898 requires. 1900 CDNI metadata servers (i.e., servers in the uCDN) are free to assign 1901 whatever structure they desire to the URIs for CDNI metadata objects 1902 and CDNI metadata clients MUST NOT make any assumptions regarding the 1903 structure of CDNI metadata URIs or the mapping between CDNI metadata 1904 objects and their associated URIs. Therefore any URIs present in the 1905 examples in this document are purely illustrative and are not 1906 intended to impose a definitive structure on CDNI metadata interface 1907 implementations. 1909 6.1. Transport 1911 The CDNI metadata interface uses HTTP as the underlying protocol 1912 transport [RFC7230]. 1914 The HTTP Method in the request defines the operation the request 1915 would like to perform. A server implementation of the CDNI metadata 1916 interface MUST support the HTTP GET and HEAD methods. 1918 The corresponding HTTP Response returns the status of the operation 1919 in the HTTP Status Code and returns the current representation of the 1920 resource (if appropriate) in the Response Body. HTTP Responses that 1921 contain a response body SHOULD include an ETag to enable validation 1922 of cached versions of returned resources. 1924 As the CDNI metadata interface builds on top of HTTP, CDNI metadata 1925 server implementations MAY make use of any HTTP feature when 1926 implementing the CDNI metadata interface, for example, a CDNI 1927 metadata server MAY make use of HTTP's caching mechanisms to indicate 1928 that the returned response/representation can be reused without re- 1929 contacting the CDNI metadata server. 1931 6.2. Retrieval of CDNI Metadata resources 1933 In the general case, a CDNI metadata server makes CDNI metadata 1934 objects available via a unique URIs and thus, in order to retrieve 1935 CDNI metadata, a CDNI metadata client first makes a HTTP GET request 1936 for the URI of the HostIndex which provides an array of Hostnames for 1937 which the uCDN can delegate content delivery to the dCDN. 1939 In order to retrieve the CDNI metadata for a particular request the 1940 CDNI metadata client processes the received HostIndex object and 1941 finds the corresponding HostMetadata entry (by matching the hostname 1942 in the request against the hostnames listed in the HostMatch 1943 objects). If the HostMetadata is linked (rather than embedded), the 1944 CDNI metadata client then makes a GET request for the URI specified 1945 in the href property of the Link object which points to the 1946 HostMetadata object itself. 1948 In order to retrieve the most specific metadata for a particular 1949 request, the CDNI metadata client inspects the HostMetadata for 1950 references to more specific PathMetadata objects (by matching the URI 1951 path in the request against the path-patterns in any PathMatch 1952 objects listed in the HostMetadata object). If any PathMetadata are 1953 found to match (and are linked rather than embedded), the CDNI 1954 metadata client makes another GET request for the PathMetadata. Each 1955 PathMetadata object can also include references to yet more specific 1956 metadata. If this is the case, the CDNI metadata client continues 1957 requesting PathMatch and PathMetadata objects recursively. The CDNI 1958 metadata client repeats this approach of processing metadata objects 1959 and retrieving (via HTTP GETs) any linked objects until it has all 1960 the metadata objects it requires in order to process the redirection 1961 request from an uCDN or the content request from a User Agent. 1963 In cases where a dCDN is not able to retrieve the entire set of CDNI 1964 metadata associated with a User Agent request, or it has retrieved 1965 that metadata but it is stale according to standard HTTP caching 1966 rules and cannot be revalidated, for example because the uCDN is 1967 unreachable or returns a HTTP 4xx or 5xx status in response to some 1968 or all of the dCDN's CDNI metadata requests, the dCDN MUST NOT serve 1969 the requested content. 1971 Where a dCDN is interconnected with multiple uCDNs, the dCDN needs to 1972 determine which uCDN's CDNI metadata should be used to handle a 1973 particular User Agent request. 1975 When application level redirection (e.g., HTTP 302 redirects) is 1976 being used between CDNs, it is expected that the dCDN will be able to 1977 determine the uCDN that redirected a particular request from 1978 information contained in the received request (e.g., via the URI). 1979 With knowledge of which uCDN routed the request, the dCDN can choose 1980 the correct uCDN from which to obtain the HostIndex. Note that the 1981 HostIndexes served by each uCDN can be unique. 1983 In the case of DNS redirection there is not always sufficient 1984 information carried in the DNS request from User Agents to determine 1985 the uCDN that redirected a particular request (e.g., when content 1986 from a given host is redirected to a given dCDN by more than one 1987 uCDN) and therefore dCDNs will have to apply local policy when 1988 deciding which uCDN's metadata to apply. 1990 6.3. Bootstrapping 1992 The URI for the HostIndex object of a given uCDN needs to be 1993 configured in the dCDN. All other objects/resources are then 1994 discoverable from the HostIndex object by following any links in the 1995 HostIndex object and through the referenced HostMetadata and 1996 PathMetadata objects and their GenericMetadata sub-objects. 1998 Manual configuration of the URI for the HostIndex object is outside 1999 the scope of this document. 2001 6.4. Encoding 2003 CDNI metadata objects MUST be encoded as I-JSON objects [RFC7493] 2004 containing a dictionary of (key,value) pairs where the keys are the 2005 property names and the values are the associated property values. 2007 The keys of the dictionary are the names of the properties associated 2008 with the object and are therefore dependent on the specific object 2009 being encoded (i.e., dependent on the CDNI Payload Type of the 2010 returned resource). Likewise, the values associated with each 2011 property (dictionary key) are dependent on the specific object being 2012 encoded (i.e., dependent on the CDNI Payload Type of the returned 2013 resource). 2015 Dictionary keys (properties) in I-JSON are case sensitive. By 2016 convention, any dictionary key (property) defined by this document 2017 (for example, the names of CDNI metadata object properties) MUST be 2018 lowercase. 2020 6.5. Extensibility 2022 The set of GenericMetadata objects can be extended with additional 2023 (standards based or vendor specific) metadata objects through the 2024 specification of new GenericMetadata objects. The GenericMetadata 2025 object defined in Section 4.1.7 specifies a type field and a type- 2026 specific value field that allows any metadata to be included in 2027 either the HostMetadata or PathMetadata arrays. 2029 As with the initial GenericMetadata types defined in Section 4.2, 2030 future GenericMetadata types MUST specify the information necessary 2031 for constructing and decoding the GenericMetadata object. 2033 Any document which defines a new GenericMetadata type MUST: 2035 1. Specify and register the CDNI Payload Type [RFC7736] used to 2036 identify the new GenericMetadata type being specified. 2038 2. Define the set of properties associated with the new 2039 GenericMetadata object. GenericMetadata MUST NOT contain a 2040 property named "href" because doing so would conflict with the 2041 ability to detect Link objects (see Section 4.3.1). 2043 3. Define a name, description, type, and whether or not the property 2044 is mandatory-to-specify. 2046 4. Describe the semantics of the new type including its purpose and 2047 example of a use case to which it applies including an example 2048 encoded in I-JSON. 2050 5. Describe the security and privacy consequences, for both the 2051 user-agent and the CDN, of the new GenericMetadata object. 2053 6. Describe any relation to, conflict with, or obsolescence of other 2054 existing CDNI metadata objects. 2056 Note: In the case of vendor specific extensions, vendor-identifying 2057 CDNI Payload Type names will decrease the possibility of 2058 GenericMetadata type collisions. 2060 6.6. Metadata Enforcement 2062 At any given time, the set of GenericMetadata types supported by the 2063 uCDN might not match the set of GenericMetadata types supported by 2064 the dCDN. 2066 In cases where a uCDN sends metadata containing a GenericMetadata 2067 type that a dCDN does not support, the dCDN MUST enforce the 2068 semantics of the "mandatory-to-enforce" property. If a dCDN does not 2069 understand or is unable to perform the functions associated with any 2070 "mandatory-to-enforce" metadata, the dCDN MUST NOT service any 2071 requests for the corresponding content. 2073 Note: Ideally, uCDNs would not delegate content requests to a dCDN 2074 that does not support the "mandatory-to-enforce" metadata associated 2075 with the content being requested. However, even if the uCDN has a 2076 priori knowledge of the metadata supported by the dCDN (e.g., via the 2077 FCI or through out-of-band negotiation between CDN operators), 2078 metadata support can fluctuate or be inconsistent (e.g., due to mis- 2079 communication, mis-configuration, or temporary outage). Thus, the 2080 dCDN MUST always evaluate all metadata associated with redirection 2081 and content requests and reject any requests where "mandatory-to- 2082 enforce" metadata associated with the content cannot be enforced. 2084 6.7. Metadata Conflicts 2086 It is possible that new metadata definitions will obsolete or 2087 conflict with existing GenericMetadata (e.g., a future revision of 2088 the CDNI metadata interface could redefine the Auth GenericMetadata 2089 object or a custom vendor extension could implement an alternate Auth 2090 metadata option). If multiple metadata (e.g., MI.Auth.v2, 2091 vendor1.Auth, and vendor2.Auth) all conflict with an existing 2092 GenericMetadata object (i.e., MI.Auth) and all are marked as 2093 "mandatory-to-enforce", it could be ambiguous which metadata should 2094 be applied, especially if the functionality of the metadata overlap. 2096 As described in Section 3.3, metadata override only applies to 2097 metadata objects of the same exact type found in HostMetadata and 2098 nested PathMetadata structures. The CDNI metadata interface does not 2099 support enforcement of dependencies between different metadata types. 2100 It is the responsibility of the CSP and the CDN operators to ensure 2101 that metadata assigned to a given piece of content do not conflict. 2103 Note: Because metadata is inherently ordered in HostMetadata and 2104 PathMetadata arrays, as well as in the PathMatch hierarchy, multiple 2105 conflicting metadata types MAY be used, however, metadata hierarchies 2106 SHOULD ensure that independent PathMatch root objects are used to 2107 prevent ambiguous or conflicting metadata definitions. 2109 6.8. Versioning 2111 The version of CDNI metadata objects is conveyed inside the CDNI 2112 Payload Type that is included in either the HTTP Content-Type header, 2113 for example: "Content-Type: application/cdni; ptype=MI.HostIndex", 2114 when retrieved via a link, or in the link type (Section 4.3.1), 2115 generic-metadata-type (Section 4.1.7), or auth-type (Section 4.2.7) 2116 properties in the JSON payload. The CDNI Payload Type uniquely 2117 identifies the specification defining that object, including any 2118 relation to, conflicts with, or obsolescence of other metadata. 2119 There is no explicit version mapping requirement, however, for ease 2120 of understanding, metadata creators SHOULD make new versions of 2121 metadata easily visible via the CDNI Payload Type, e.g., by appending 2122 a version string. Note: A version string is optional on the first 2123 version, e.g., MI.HostIndex, but could be added for subsequent 2124 versions, e.g., MI.HostIndex.v2, MI.HostIndex.v3, etc. 2126 Except when referenced by a Link object, nested metadata objects 2127 (i.e., structural metadata below the HostIndex; Source objects; 2128 Location, TimeWindow, and Protocol Rule objects; and Footprint and 2129 TimeWindow objects) can be serialized into a JSON payload without 2130 explicit CDNI Payload Type information. The type is inferred from 2131 the outer structural metadata, generic metadata, or auth object CDNI 2132 Payload Type. To avoid ambiguity when revising nestable metadata 2133 objects, any outer metadata object(s) MUST be reversioned and 2134 allocated new CDNI Payload Type(s) at the same time. For example, 2135 the MI.HostIndex object defined in this document contains an array of 2136 MI.HostMatch objects, which each in turn contains a MI.HostMetadata 2137 object. If a new MI.HostMetadata.v2 object were required, the outer 2138 MI.HostIndex and MI.HostMatch objects would need to be revised, e.g., 2139 to MI.HostIndex.v2 and MI.HostMatch.v2, respectively. Similarly, if 2140 a new MI.TimeWindowRule.v2 object was required, the outer 2141 MI.TimeWindowACL object would need to be revised, e.g., to 2142 MI.TimeWindowACL.v2; the MI.TimeWindowRule.v2 object, though, could 2143 still contain MI.TimeWindow objects, if so specified. 2145 HTTP requests sent to a metadata server SHOULD include an Accept 2146 header with the CDNI Payload Type of the expected object. Metadata 2147 clients can specify multiple CDNI Payload Types in the Accept header, 2148 for example, if a metadata client is capable of processing two 2149 different versions of the same type of object (defined by different 2150 CDNI Payload Types) it might decide to include both in the Accept 2151 header. 2153 6.9. Media Types 2155 All CDNI metadata objects use the Media Type "application/cdni". The 2156 CDNI Payload Type for each object then contains the object name of 2157 that object as defined by this document, prefixed with "MI.". 2158 Table 4 lists the CDNI Payload Type for the metadata objects 2159 (resources) specified in this document. 2161 +-----------------------+--------------------------+ 2162 | Data Object | CDNI Payload Type | 2163 +-----------------------+--------------------------+ 2164 | HostIndex | MI.HostIndex | 2165 | HostMatch | MI.HostMatch | 2166 | HostMetadata | MI.HostMetadata | 2167 | PathMatch | MI.PathMatch | 2168 | PatternMatch | MI.PatternMatch | 2169 | PathMetadata | MI.PathMetadata | 2170 | SourceMetadata | MI.SourceMetadata | 2171 | Source | MI.Source | 2172 | LocationACL | MI.LocationACL | 2173 | LocationRule | MI.LocationRule | 2174 | Footprint | MI.Footprint | 2175 | TimeWindowACL | MI.TimeWindowACL | 2176 | TimeWindowRule | MI.TimeWindowRule | 2177 | TimeWindow | MI.TimeWindow | 2178 | ProtocolACL | MI.ProtocolACL | 2179 | ProtocolRule | MI.ProtocolRule | 2180 | DeliveryAuthorization | MI.DeliveryAuthorization | 2181 | Cache | MI.Cache | 2182 | Auth | MI.Auth | 2183 | Grouping | MI.Grouping | 2184 +-----------------------+--------------------------+ 2186 Table 4: CDNI Payload Types for CDNI Metadata objects 2188 6.10. Complete CDNI Metadata Example 2190 A dCDN requests the HostIndex and receive the following object with a 2191 CDNI payload type of "MI.HostIndex": 2193 { 2194 "hosts": [ 2195 { 2196 "host": "video.example.com", 2197 "host-metadata" : { 2198 "type": "MI.HostMetadata", 2199 "href": "https://metadata.ucdn.example/host1234" 2200 } 2201 }, 2202 { 2203 "host": "images.example.com", 2204 "host-metadata" : { 2205 "type": "MI.HostMetadata", 2206 "href": "https://metadata.ucdn.example/host5678" 2207 } 2208 } 2209 ] 2210 } 2212 If the incoming request has a Host header with "video.example.com" 2213 then the dCDN would fetch the HostMetadata object from 2214 "https://metadata.ucdn.example/host1234" expecting a CDNI payload 2215 type of "MI.HostMetadata": 2217 { 2218 "metadata": [ 2219 { 2220 "generic-metadata-type": "MI.SourceMetadata", 2221 "generic-metadata-value": { 2222 "sources": [ 2223 { 2224 "endpoint": ["acq1.ucdn.example"], 2225 "protocol": "http/1.1" 2226 }, 2227 { 2228 "endpoint": ["acq2.ucdn.example"], 2229 "protocol": "http/1.1" 2230 } 2231 ] 2232 } 2233 }, 2234 { 2235 "generic-metadata-type": "MI.LocationACL", 2236 "generic-metadata-value": { 2237 "locations": [ 2238 { 2239 "footprints": [ 2240 { 2241 "footprint-type": "ipv4cidr", 2242 "footprint-value": ["192.0.2.0/24"] 2243 }, 2244 { 2245 "footprint-type": "ipv6cidr", 2246 "footprint-value": ["2001:db8::/32"] 2247 }, 2248 { 2249 "footprint-type": "countrycode", 2250 "footprint-value": ["us"] 2251 }, 2252 { 2253 "footprint-type": "asn", 2254 "footprint-value": ["as64496"] 2255 } 2256 ], 2257 "action": "deny" 2258 } 2259 ] 2260 } 2261 }, 2262 { 2263 "generic-metadata-type": "MI.ProtocolACL", 2264 "generic-metadata-value": { 2265 "protocol-acl": [ 2266 { 2267 "protocols": [ 2268 "http/1.1" 2269 ], 2270 "action": "allow" 2271 } 2272 ] 2273 } 2274 } 2275 ], 2276 "paths": [ 2277 { 2278 "path-pattern": { 2279 "pattern": "/video/trailers/*" 2280 }, 2281 "path-metadata": { 2282 "type": "MI.PathMetadata", 2283 "href": "https://metadata.ucdn.example/host1234/pathABC" 2284 } 2285 }, 2286 { 2287 "path-pattern": { 2288 "pattern": "/video/movies/*" 2290 }, 2291 "path-metadata": { 2292 "type": "MI.PathMetadata", 2293 "href": "https://metadata.ucdn.example/host1234/pathDEF" 2294 } 2295 } 2296 ] 2297 } 2299 Suppose the path of the requested resource matches the "/video/ 2300 movies/*" pattern, the next metadata requested would be for 2301 "https://metadata.ucdn.example/host1234/pathDCE" with an expected 2302 CDNI payload type of "MI.PathMetadata": 2304 { 2305 "metadata": [], 2306 "paths": [ 2307 { 2308 "path-pattern": { 2309 "pattern": "/videos/movies/hd/*" 2310 }, 2311 "path-metadata": { 2312 "type": "MI.PathMetadata", 2313 "href": 2314 "https://metadata.ucdn.example/host1234/pathDEF/path123" 2315 } 2316 } 2317 ] 2318 } 2320 Finally, if the path of the requested resource also matches the 2321 "/videos/movies/hd/*" pattern, the dCDN would also fetch the 2322 following object from 2323 "https://metadata.ucdn.example/host1234/pathDEF/path123" with CDNI 2324 payload type "MI.PathMetadata": 2326 { 2327 "metadata": [ 2328 { 2329 "generic-metadata-type": "MI.TimeWindowACL", 2330 "generic-metadata-value": { 2331 "times": [ 2332 "windows": [ 2333 { 2334 "start": "1213948800", 2335 "end": "1327393200" 2336 } 2337 ], 2338 "action": "allow" 2339 ] 2340 } 2341 } 2342 ] 2343 } 2345 The final set of metadata which applies to the requested resource 2346 includes a SourceMetadata, a LocationACL, a ProtocolACL, and a 2347 TimeWindowACL. 2349 7. IANA Considerations 2351 7.1. CDNI Payload Types 2353 This document requests the registration of the following CDNI Payload 2354 Types under the IANA CDNI Payload Type registry: 2356 +--------------------------+---------------+ 2357 | Payload Type | Specification | 2358 +--------------------------+---------------+ 2359 | MI.HostIndex | RFCthis | 2360 | MI.HostMatch | RFCthis | 2361 | MI.HostMetadata | RFCthis | 2362 | MI.PathMatch | RFCthis | 2363 | MI.PatternMatch | RFCthis | 2364 | MI.PathMetadata | RFCthis | 2365 | MI.SourceMetadata | RFCthis | 2366 | MI.Source | RFCthis | 2367 | MI.LocationACL | RFCthis | 2368 | MI.LocationRule | RFCthis | 2369 | MI.Footprint | RFCthis | 2370 | MI.TimeWindowACL | RFCthis | 2371 | MI.TimeWindowRule | RFCthis | 2372 | MI.TimeWindow | RFCthis | 2373 | MI.ProtocolACL | RFCthis | 2374 | MI.ProtocolRule | RFCthis | 2375 | MI.DeliveryAuthorization | RFCthis | 2376 | MI.Cache | RFCthis | 2377 | MI.Auth | RFCthis | 2378 | MI.Grouping | RFCthis | 2379 +--------------------------+---------------+ 2381 [RFC Editor: Please replace RFCthis with the published RFC number for 2382 this document.] 2384 7.1.1. CDNI MI HostIndex Payload Type 2386 Purpose: The purpose of this payload type is to distinguish HostIndex 2387 MI objects (and any associated capability advertisement) 2389 Interface: MI/FCI 2391 Encoding: see Section 4.1.1 2393 7.1.2. CDNI MI HostMatch Payload Type 2395 Purpose: The purpose of this payload type is to distinguish HostMatch 2396 MI objects (and any associated capability advertisement) 2398 Interface: MI/FCI 2400 Encoding: see Section 4.1.2 2402 7.1.3. CDNI MI HostMetadata Payload Type 2404 Purpose: The purpose of this payload type is to distinguish 2405 HostMetadata MI objects (and any associated capability advertisement) 2407 Interface: MI/FCI 2409 Encoding: see Section 4.1.3 2411 7.1.4. CDNI MI PathMatch Payload Type 2413 Purpose: The purpose of this payload type is to distinguish PathMatch 2414 MI objects (and any associated capability advertisement) 2416 Interface: MI/FCI 2418 Encoding: see Section 4.1.4 2420 7.1.5. CDNI MI PatternMatch Payload Type 2422 Purpose: The purpose of this payload type is to distinguish 2423 PatternMatch MI objects (and any associated capability advertisement) 2425 Interface: MI/FCI 2427 Encoding: see Section 4.1.5 2429 7.1.6. CDNI MI PathMetadata Payload Type 2431 Purpose: The purpose of this payload type is to distinguish 2432 PathMetadata MI objects (and any associated capability advertisement) 2434 Interface: MI/FCI 2436 Encoding: see Section 4.1.6 2438 7.1.7. CDNI MI SourceMetadata Payload Type 2440 Purpose: The purpose of this payload type is to distinguish 2441 SourceMetadata MI objects (and any associated capability 2442 advertisement) 2444 Interface: MI/FCI 2446 Encoding: see Section 4.2.1 2448 7.1.8. CDNI MI Source Payload Type 2450 Purpose: The purpose of this payload type is to distinguish Source MI 2451 objects (and any associated capability advertisement) 2453 Interface: MI/FCI 2455 Encoding: see Section 4.2.1.1 2457 7.1.9. CDNI MI LocationACL Payload Type 2459 Purpose: The purpose of this payload type is to distinguish 2460 LocationACL MI objects (and any associated capability advertisement) 2462 Interface: MI/FCI 2464 Encoding: see Section 4.2.2 2466 7.1.10. CDNI MI LocationRule Payload Type 2468 Purpose: The purpose of this payload type is to distinguish 2469 LocationRule MI objects (and any associated capability advertisement) 2471 Interface: MI/FCI 2473 Encoding: see Section 4.2.2.1 2475 7.1.11. CDNI MI Footprint Payload Type 2477 Purpose: The purpose of this payload type is to distinguish Footprint 2478 MI objects (and any associated capability advertisement) 2480 Interface: MI/FCI 2482 Encoding: see Section 4.2.2.2 2484 7.1.12. CDNI MI TimeWindowACL Payload Type 2486 Purpose: The purpose of this payload type is to distinguish 2487 TimeWindowACL MI objects (and any associated capability 2488 advertisement) 2490 Interface: MI/FCI 2492 Encoding: see Section 4.2.3 2494 7.1.13. CDNI MI TimeWindowRule Payload Type 2496 Purpose: The purpose of this payload type is to distinguish 2497 TimeWindowRule MI objects (and any associated capability 2498 advertisement) 2500 Interface: MI/FCI 2502 Encoding: see Section 4.2.3.1 2504 7.1.14. CDNI MI TimeWindow Payload Type 2506 Purpose: The purpose of this payload type is to distinguish 2507 TimeWindow MI objects (and any associated capability advertisement) 2509 Interface: MI/FCI 2511 Encoding: see Section 4.2.3.2 2513 7.1.15. CDNI MI ProtocolACL Payload Type 2515 Purpose: The purpose of this payload type is to distinguish 2516 ProtocolACL MI objects (and any associated capability advertisement) 2518 Interface: MI/FCI 2520 Encoding: see Section 4.2.4 2522 7.1.16. CDNI MI ProtocolRule Payload Type 2524 Purpose: The purpose of this payload type is to distinguish 2525 ProtocolRule MI objects (and any associated capability advertisement) 2527 Interface: MI/FCI 2529 Encoding: see Section 4.2.4.1 2531 7.1.17. CDNI MI DeliveryAuthorization Payload Type 2533 Purpose: The purpose of this payload type is to distinguish 2534 DeliveryAuthorization MI objects (and any associated capability 2535 advertisement) 2537 Interface: MI/FCI 2539 Encoding: see Section 4.2.5 2541 7.1.18. CDNI MI Cache Payload Type 2543 Purpose: The purpose of this payload type is to distinguish Cache MI 2544 objects (and any associated capability advertisement) 2546 Interface: MI/FCI 2548 Encoding: see Section 4.2.6 2550 7.1.19. CDNI MI Auth Payload Type 2552 Purpose: The purpose of this payload type is to distinguish Auth MI 2553 objects (and any associated capability advertisement) 2555 Interface: MI/FCI 2557 Encoding: see Section 4.2.7 2559 7.1.20. CDNI MI Grouping Payload Type 2561 Purpose: The purpose of this payload type is to distinguish Grouping 2562 MI objects (and any associated capability advertisement) 2564 Interface: MI/FCI 2566 Encoding: see Section 4.2.8 2568 7.2. CDNI Metadata Footprint Types Registry 2570 The IANA is requested to create a new "CDNI Metadata Footprint Types" 2571 subregistry in the "Content Delivery Networks Interconnection (CDNI) 2572 Parameters" registry. The "CDNI Metadata Footprint Types" namespace 2573 defines the valid Footprint object type values used by the Footprint 2574 object in Section 4.2.2.2. Additions to the Footprint type namespace 2575 conform to the "Specification Required" policy as defined in 2576 [RFC5226]. The designated expert will verify that new type 2577 definitions do not duplicate existing type definitions and prevent 2578 gratuitous additions to the namespace. New registrations are 2579 required to provide a clear description of how to interpret new 2580 footprint types. 2582 The following table defines the initial Footprint Registry values: 2584 +----------------+-------------------------------+---------------+ 2585 | Footprint Type | Description | Specification | 2586 +----------------+-------------------------------+---------------+ 2587 | ipv4cidr | IPv4 CIDR address block | RFCthis | 2588 | ipv6cidr | IPv6 CIDR address block | RFCthis | 2589 | asn | Autonomous System (AS) Number | RFCthis | 2590 | countrycode | ISO 3166-1 alpha-2 code | RFCthis | 2591 +----------------+-------------------------------+---------------+ 2593 [RFC Editor: Please replace RFCthis with the published RFC number for 2594 this document.] 2596 7.3. CDNI Metadata Protocol Types Registry 2598 The IANA is requested to create a new "CDNI Metadata Protocol Types" 2599 subregistry in the "Content Delivery Networks Interconnection (CDNI) 2600 Parameters" registry. The "CDNI Metadata Protocol Types" namespace 2601 defines the valid Protocol object values in Section 4.3.2, used by 2602 the SourceMetadata and ProtocolACL objects. Additions to the 2603 Protocol namespace conform to the "Specification Required" policy as 2604 defined in [RFC5226], where the specification defines the Protocol 2605 Type and the protocol to which it is associated. The designated 2606 expert will verify that new protocol definitions do not duplicate 2607 existing protocol definitions and prevent gratuitous additions to the 2608 namespace. 2610 The following table defines the initial Protocol values corresponding 2611 to the HTTP and HTTPS protocols: 2613 +-----------+----------------------+---------------+----------------+ 2614 | Protocol | Description | Type | Protocol | 2615 | Type | | Specification | Specifications | 2616 +-----------+----------------------+---------------+----------------+ 2617 | http/1.1 | Hypertext Transfer | RFCthis | RFC7230 | 2618 | | Protocol -- HTTP/1.1 | | | 2619 | https/1.1 | HTTP/1.1 Over TLS | RFCthis | RFC7230, | 2620 | | | | RFC2818 | 2621 +-----------+----------------------+---------------+----------------+ 2623 [RFC Editor: Please replace RFCthis with the published RFC number for 2624 this document.] 2626 8. Security Considerations 2627 8.1. Authentication and Integrity 2629 A malicious metadata server, proxy server, or attacker, impersonating 2630 an authentic uCDN metadata interface without being detected, could 2631 provide false metadata to a dCDN that either: 2633 o Denies service for one or more pieces of content to one or more 2634 User Agents; 2636 o Directs dCDNs to contact malicious origin servers instead of the 2637 actual origin servers, and substitute legitimate content with 2638 malware or slanderous alternate content; or 2640 o Removes delivery restrictions (e.g., LocationACL, TimeWindowACL, 2641 ProtocolACL, or Auth metadata), allowing access to content that 2642 would otherwise be denied, and thus possibly violating license 2643 restrictions and incurring unwarranted delivery costs. 2645 Unauthorized access to metadata could also enable a malicious 2646 metadata client to continuously issue metadata requests in order to 2647 overload a uCDN's metadata server(s). 2649 Unauthorized access to metadata could further result in leakage of 2650 private information. A malicious metadata client could request 2651 metadata in order to gain access to origin servers, as well as 2652 information pertaining to content restrictions. 2654 An implementation of the CDNI metadata interface MUST use mutual 2655 authentication and message authentication codes to prevent 2656 unauthorized access to and undetected modification of metadata (see 2657 Section 8.3). 2659 8.2. Confidentiality and Privacy 2661 Unauthorized viewing of metadata could result in leakage of private 2662 information. Content provider origin and policy information is 2663 conveyed through the CDNI metadata interface. A third party could 2664 intercept metadata transactions in order to gain access to origin 2665 servers, as well as information pertaining to content restrictions 2666 and usage patterns. 2668 Note: The distribution of metadata by a uCDN to dCDNs could introduce 2669 privacy concerns for some content providers, e.g., dCDNs accepting 2670 content requests for a content provider's content might be able to 2671 obtain additional information and usage patterns relating to the 2672 users of a content provider's services. Content providers with 2673 concerns about divulging information to dCDNs can instruct their uCDN 2674 partners not to use CDNI when delivering their content. 2676 An implementation of the CDNI metadata interface MUST use strong 2677 encryption to prevent unauthorized interception or monitoring of 2678 metadata (see Section 8.3). 2680 8.3. Securing the CDNI Metadata interface 2682 An implementation of the CDNI metadata interface MUST support TLS 2683 transport as per [RFC2818] and [RFC7230]. 2685 TLS MUST be used by the server-side (dCDN) and the client-side (uCDN) 2686 of the CDNI metadata interface, including authentication of the 2687 remote end, unless alternate methods are used for ensuring the 2688 security of the information in the CDNI metadata interface requests 2689 and responses (such as setting up an IPsec tunnel between the two 2690 CDNs or using a physically secured internal network between two CDNs 2691 that are owned by the same corporate entity). 2693 The use of TLS for transport of the CDNI metadata interface messages 2694 allows: 2696 o The dCDN and uCDN to authenticate each other. 2698 and, once they have mutually authenticated each other, it allows: 2700 o The dCDN and uCDN to authorize each other (to ensure they are 2701 transmitting/receiving CDNI metadata requests and responses from 2702 an authorized CDN); 2704 o CDNI metadata interface requests and responses to be transmitted 2705 with confidentiality; and 2707 o The integrity of the CDNI metadata interface requests and 2708 responses to be protected during the exchange. 2710 When TLS is used, the general TLS usage guidance in [RFC7525] MUST be 2711 followed. 2713 9. Acknowledgements 2715 The authors would like to thank David Ferguson, Francois Le Faucheur, 2716 Jan Seedorf and Matt Miller for their valuable comments and input to 2717 this document. 2719 10. Contributing Authors 2721 [RFC Editor Note: Please move the contents of this section to the 2722 Authors' Addresses section prior to publication as an RFC.] 2723 Grant Watson 2724 Velocix (Alcatel-Lucent) 2725 3 Ely Road 2726 Milton, Cambridge CB24 6AA 2727 UK 2729 Email: gwatson@velocix.com 2731 Kent Leung 2732 Cisco Systems 2733 3625 Cisco Way 2734 San Jose, 95134 2735 USA 2737 Email: kleung@cisco.com 2739 11. References 2741 11.1. Normative References 2743 [ISO3166-1] 2744 The International Organization for Standardization, "Codes 2745 for the representation of names of countries and their 2746 subdivisions -- Part 1: Country codes", ISO 3166-1:2013, 2747 2013. 2749 [POSIX] Institute of Electrical and Electronics Engineers, 2750 "Information Technology Portable Operating System 2751 Interface (POSIX) Part 1: System Application Program 2752 Interface (API) [C Language]", IEEE P1003.1, 1990. 2754 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2755 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2756 . 2758 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 2759 Application and Support", STD 3, RFC 1123, 2760 DOI 10.17487/RFC1123, October 1989, 2761 . 2763 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2764 Requirement Levels", BCP 14, RFC 2119, 2765 DOI 10.17487/RFC2119, March 1997, 2766 . 2768 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2769 Resource Identifier (URI): Generic Syntax", STD 66, 2770 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2771 . 2773 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2774 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2775 2006, . 2777 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2778 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2779 DOI 10.17487/RFC5226, May 2008, 2780 . 2782 [RFC5891] Klensin, J., "Internationalized Domain Names in 2783 Applications (IDNA): Protocol", RFC 5891, 2784 DOI 10.17487/RFC5891, August 2010, 2785 . 2787 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2788 Address Text Representation", RFC 5952, 2789 DOI 10.17487/RFC5952, August 2010, 2790 . 2792 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 2793 Distribution Network Interconnection (CDNI) Problem 2794 Statement", RFC 6707, DOI 10.17487/RFC6707, September 2795 2012, . 2797 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2798 Protocol (HTTP/1.1): Message Syntax and Routing", 2799 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2800 . 2802 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 2803 DOI 10.17487/RFC7493, March 2015, 2804 . 2806 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2807 "Recommendations for Secure Use of Transport Layer 2808 Security (TLS) and Datagram Transport Layer Security 2809 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2810 2015, . 2812 11.2. Informative References 2814 [I-D.ietf-cdni-control-triggers] 2815 Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / 2816 Triggers", draft-ietf-cdni-control-triggers-15 (work in 2817 progress), May 2016. 2819 [I-D.ietf-cdni-redirection] 2820 Niven-Jenkins, B. and R. Brandenburg, "Request Routing 2821 Redirection interface for CDN Interconnection", draft- 2822 ietf-cdni-redirection-19 (work in progress), July 2016. 2824 [I-D.ietf-cdni-uri-signing] 2825 Leung, K., Faucheur, F., Brandenburg, R., Downey, B., and 2826 M. Fisher, "URI Signing for CDN Interconnection (CDNI)", 2827 draft-ietf-cdni-uri-signing-09 (work in progress), June 2828 2016. 2830 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2831 DOI 10.17487/RFC2818, May 2000, 2832 . 2834 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 2835 Autonomous System (AS) Number Space", RFC 6793, 2836 DOI 10.17487/RFC6793, December 2012, 2837 . 2839 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 2840 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 2841 RFC 7234, DOI 10.17487/RFC7234, June 2014, 2842 . 2844 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 2845 "Framework for Content Distribution Network 2846 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 2847 August 2014, . 2849 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 2850 Network Interconnection (CDNI) Requirements", RFC 7337, 2851 DOI 10.17487/RFC7337, August 2014, 2852 . 2854 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2855 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2856 DOI 10.17487/RFC7540, May 2015, 2857 . 2859 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 2860 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 2861 December 2015, . 2863 Authors' Addresses 2865 Ben Niven-Jenkins 2866 Velocix (Alcatel-Lucent) 2867 3 Ely Road 2868 Milton, Cambridge CB24 6AA 2869 UK 2871 Email: ben@velocix.com 2873 Rob Murray 2874 Velocix (Alcatel-Lucent) 2875 3 Ely Road 2876 Milton, Cambridge CB24 6AA 2877 UK 2879 Email: rmurray@velocix.com 2881 Matt Caulfield 2882 Cisco Systems 2883 1414 Massachusetts Avenue 2884 Boxborough, MA 01719 2885 USA 2887 Phone: +1 978 936 9307 2888 Email: mcaulfie@cisco.com 2890 Kevin J. Ma 2891 Ericsson 2892 43 Nagog Park 2893 Acton, MA 01720 2894 USA 2896 Phone: +1 978-844-5100 2897 Email: kevin.j.ma@ericsson.com