--- 1/draft-ietf-cdni-control-triggers-06.txt 2015-06-30 13:14:58.412886281 -0700 +++ 2/draft-ietf-cdni-control-triggers-07.txt 2015-06-30 13:14:58.484888064 -0700 @@ -1,18 +1,18 @@ Network Working Group R. Murray Internet-Draft B. Niven-Jenkins Intended status: Standards Track Velocix (Alcatel-Lucent) -Expires: August 27, 2015 February 23, 2015 +Expires: January 1, 2016 June 30, 2015 CDNI Control Interface / Triggers - draft-ietf-cdni-control-triggers-06 + draft-ietf-cdni-control-triggers-07 Abstract This document describes the part of the CDN Interconnection Control Interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-positions metadata or content, or that it invalidates or purges metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN. @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 27, 2015. + This Internet-Draft will expire on January 1, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -55,70 +55,74 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Model for CDNI Triggers . . . . . . . . . . . . . . . . . . . 4 2.1. Timing of Triggered Activity . . . . . . . . . . . . . . 6 2.2. Scope of Triggered Activity . . . . . . . . . . . . . . . 6 - 2.3. Trigger Results . . . . . . . . . . . . . . . . . . . . . 6 + 2.3. Trigger Results . . . . . . . . . . . . . . . . . . . . . 7 3. Collections of Trigger Status Resources . . . . . . . . . . . 7 4. CDNI Trigger Interface . . . . . . . . . . . . . . . . . . . 8 4.1. Creating Triggers . . . . . . . . . . . . . . . . . . . . 9 4.2. Checking Status . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Polling Trigger Status Resource collections . . . . . 10 4.2.2. Polling Trigger Status Resources . . . . . . . . . . 11 4.3. Cancelling Triggers . . . . . . . . . . . . . . . . . . . 11 4.4. Deleting Triggers . . . . . . . . . . . . . . . . . . . . 12 4.5. Expiry of Trigger Status Resources . . . . . . . . . . . 12 4.6. Loop Detection and Prevention . . . . . . . . . . . . . . 13 4.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 13 4.8. Content URLs . . . . . . . . . . . . . . . . . . . . . . 14 5. CI/T Object Properties and Encoding . . . . . . . . . . . . . 15 5.1. CI/T Objects . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1. CI/T Commands . . . . . . . . . . . . . . . . . . . . 15 5.1.2. Trigger Status Resource . . . . . . . . . . . . . . . 16 5.1.3. Trigger Collection . . . . . . . . . . . . . . . . . 17 - 5.2. Properties of CI/T Objects . . . . . . . . . . . . . . . 18 + 5.2. Properties of CI/T Objects . . . . . . . . . . . . . . . 19 5.2.1. Trigger Specification . . . . . . . . . . . . . . . . 19 5.2.2. Trigger Type . . . . . . . . . . . . . . . . . . . . 20 5.2.3. Trigger Status . . . . . . . . . . . . . . . . . . . 21 5.2.4. PatternMatch . . . . . . . . . . . . . . . . . . . . 21 5.2.5. Absolute Time . . . . . . . . . . . . . . . . . . . . 22 5.2.6. Error Description . . . . . . . . . . . . . . . . . . 22 5.2.7. Error Code . . . . . . . . . . . . . . . . . . . . . 23 - 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 6.1. Creating Triggers . . . . . . . . . . . . . . . . . . . . 24 - 6.1.1. Preposition . . . . . . . . . . . . . . . . . . . . . 24 - 6.1.2. Invalidate . . . . . . . . . . . . . . . . . . . . . 25 - 6.2. Examining Trigger Status . . . . . . . . . . . . . . . . 27 - 6.2.1. Collection of All Triggers . . . . . . . . . . . . . 27 - 6.2.2. Filtered Collections of Trigger Status Resources . . 28 - 6.2.3. Individual Trigger Status Resources . . . . . . . . . 29 - 6.2.4. Polling for Change . . . . . . . . . . . . . . . . . 31 - 6.2.5. Deleting Trigger Status Resources . . . . . . . . . . 34 - 6.2.6. Error Reporting . . . . . . . . . . . . . . . . . . . 35 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 - 7.1. Media type registrations . . . . . . . . . . . . . . . . 37 - 7.1.1. CI/T Commands . . . . . . . . . . . . . . . . . . . . 37 - 7.1.2. CI/T Trigger Status Resource . . . . . . . . . . . . 38 - 7.1.3. CI/T Trigger Collection . . . . . . . . . . . . . . . 39 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 - 8.1. Authentication, Confidentiality, Integrity Protection . . 40 - 8.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 41 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 41 - 10.2. Informative References . . . . . . . . . . . . . . . . . 42 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 + 5.3. Formalization of the JSON Data . . . . . . . . . . . . . 24 + 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 6.1. Creating Triggers . . . . . . . . . . . . . . . . . . . . 26 + 6.1.1. Preposition . . . . . . . . . . . . . . . . . . . . . 26 + 6.1.2. Invalidate . . . . . . . . . . . . . . . . . . . . . 27 + + 6.2. Examining Trigger Status . . . . . . . . . . . . . . . . 29 + 6.2.1. Collection of All Triggers . . . . . . . . . . . . . 29 + 6.2.2. Filtered Collections of Trigger Status Resources . . 30 + 6.2.3. Individual Trigger Status Resources . . . . . . . . . 31 + 6.2.4. Polling for Change . . . . . . . . . . . . . . . . . 33 + 6.2.5. Deleting Trigger Status Resources . . . . . . . . . . 36 + 6.2.6. Error Reporting . . . . . . . . . . . . . . . . . . . 38 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 + 7.1. Media type registrations . . . . . . . . . . . . . . . . 39 + 7.1.1. CI/T Commands . . . . . . . . . . . . . . . . . . . . 39 + 7.1.2. CI/T Trigger Status Resource . . . . . . . . . . . . 40 + 7.1.3. CI/T Trigger Collection . . . . . . . . . . . . . . . 41 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 + 8.1. Authentication, Authorization, Confidentiality, Integrity + Protection . . . . . . . . . . . . . . . . . . . . . . . 42 + 8.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 43 + 8.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 43 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 44 + 10.2. Informative References . . . . . . . . . . . . . . . . . 44 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 1. Introduction [RFC6707] introduces the problem scope for CDN Interconnection (CDNI) and lists the four categories of interfaces that may be used to compose a CDNI solution (Control, Metadata, Request Routing, Logging). [RFC7336] expands on the information provided in [RFC6707] and describes each of the interfaces and the relationships between them @@ -384,25 +388,25 @@ are purely illustrative and are not intended to impose a definitive structure on CI/T interface implementations. 4.1. Creating Triggers To issue a CI/T Command, the uCDN makes an HTTP POST to the dCDN's collection of all of the uCDN's Trigger Status Resources. The request body of that POST is a CI/T Command, as described in Section 5.1.1. - The dCDN validates and authenticates that CI/T Command, if it is - malformed or the uCDN does not have sufficient access rights it MUST - either respond with an appropriate 4xx HTTP error code and a Trigger - Status Resource MUST NOT be created on the dCDN, or create a 'failed' - Trigger Status Resource containing an appropriate error description. + The dCDN validates the CI/T Command, if it is malformed or the uCDN + does not have sufficient access rights it MUST either respond with an + appropriate 4xx HTTP error code and a Trigger Status Resource MUST + NOT be created on the dCDN, or create a 'failed' Trigger Status + Resource containing an appropriate error description. When a CI/T Trigger Command is accepted, the uCDN MUST create a new Trigger Status Resource which will convey a specification of the CI/T Command and its current status. The HTTP response to the dCDN MUST have status code 201 and MUST convey the URI of the Trigger Status Resource in the Location header field. The HTTP response SHOULD include the content of the newly created Trigger Status Resource, this is recommended particularly in cases where the CI/T Trigger Command has completed immediately. @@ -433,21 +437,22 @@ example, it is an invalidate or purge request for data the dCDN has not yet acquired, or a prepopulate request for data it has already acquired and which is still valid. In this case, the "status" of the Trigger Status Resource MUST be "processed" or "complete", and the Trigger Status Resource MUST be added to the dCDN's collection of Complete Trigger Status Resources. Once created, Trigger Status Resources can be cancelled or deleted by the uCDN, but not modified. The dCDN MUST reject PUT and POST requests from the uCDN to Trigger Status Resources by responding with - an appropriate HTTP status code. + an appropriate HTTP status code, for example 405 "Method Not + Allowed". 4.2. Checking Status The uCDN has two ways to check progress of CI/T Commands it has issued to the dCDN, described in sections Section 4.2.1 and Section 4.2.2. To check for change in status of a Trigger Status Resource or collection of Trigger Status Resources without re-fetching the whole Resource or Collection, Entity Tags SHOULD be included by the dCDN @@ -462,21 +467,21 @@ The uCDN can fetch the collection of its Trigger Status Resources, or filtered views of that collection. This makes it possible to poll status of all CI/T Trigger Commands in a single request. If the dCDN moves a Trigger Status Resource from the Active to the Completed collection, the uCDN can fetch the result of that activity. When polling in this way, the uCDN SHOULD use HTTP Entity Tags to monitor for change, rather than repeatedly fetching the whole - collection. + collection. An example of this is given in section Section 6.2.4. 4.2.2. Polling Trigger Status Resources The uCDN has a URI provided by the dCDN for each Trigger Status Resource it has created, it may fetch that Trigger Status Resource at any time. This can be used to retrieve progress information, and to fetch the result of the CI/T Command. @@ -489,22 +494,22 @@ The uCDN can request cancellation of a CI/T Trigger Command by POSTing a CI/T Cancel Command to the collection of all Trigger Status Resources. Cancellation of a CI/T Trigger Command is optional-to-implement in the dCDN. The dCDN MUST respond to the CI/T Cancel Command appropriately, for example with HTTP status code 200 "OK" if the cancellation has been processed and the CI/T Command is inactive, 202 "Accepted" if the - command has been accepted but the CI/T Command remains active, or 403 - "Forbidden" if cancellation is not supported by the dCDN. + command has been accepted but the CI/T Command remains active, or 501 + "Not Implemented" if cancellation is not supported by the dCDN. If cancellation of a "pending" Trigger Status Resource is accepted by the dCDN, the dCDN SHOULD NOT start processing of that activity. Issuing a CT/T cancel command for a "pending" Trigger Status Resource does not however guarantee that the corresponding activity will not be started, because the uCDN cannot control the timing of that activity. Processing could, for example, start after the POST is sent by the uCDN but before that request is processed by the dCDN. If cancellation of an "active" or "processed" Trigger Status Resource @@ -573,48 +578,49 @@ records for completed activity will be deleted. 4.6. Loop Detection and Prevention Given three CDNs, A, B and C. If CDNs B and C delegate delivery of CDN A's content to each other, CDN A's CI/T Commands could be passed between CDNs B and C in a loop. More complex networks of CDNs could contain similar loops involving more hops. In order to prevent and detect such CI/T loops, each CDN uses a CDN - Provider ID to uniquely identify itself. Each CDN MUST insert its - CDN Provider ID into the cdn-path key of every CI/T Command it - originates or cascades. When receiving CI/T Commands a dCDN MUST - check the cdn-path and reject any CI/T Command which already contains - its own CDN Provider ID in the cdn-path. Transit CDNs MUST check the - cdn-path and not cascade the CI/T Command to dCDNs that are already - listed in cdn-path. + Provider ID to uniquely identify itself. In every CI/T Command it + originates or cascades, each CDN MUST append an array element + containing its CDN Provider ID to a JSON array under an entry named + "cdn-path". When receiving CI/T Commands a dCDN MUST check the cdn- + path and reject any CI/T Command which already contains its own CDN + Provider ID in the cdn-path. Transit CDNs MUST check the cdn-path + and not cascade the CI/T Command to dCDNs that are already listed in + cdn-path. The CDN Provider Id consists of the two characters "AS" followed by the CDN Provider's Autonomous System number, then a colon (':') and an additional qualifier that is used to guarantee uniqueness in case a particular AS has multiple independent CDNs deployed. For example "AS64496:0". If the CDN provider has multiple Autonomous Systems, the same AS number SHOULD be used in all messages from that CDN provider, unless there are multiple distinct CDNs. If the RI interface described in [I-D.ietf-cdni-redirection] is implemented by the dCDN, the CI/T and RI interfaces SHOULD use the same CDN Provider Id. 4.7. Error Handling A dCDN can signal rejection of a CI/T Command using HTTP status - codes. For example, 400 if the request is malformed, or 401 if the - uCDN does not have permission to issue CI/T Commands or it is trying - to act on another CDN's data. + codes. For example, 400 if the request is malformed, or 403 or 404 + if the uCDN does not have permission to issue CI/T Commands or it is + trying to act on another CDN's data. If any part of the CI/T Trigger Command fails, the trigger SHOULD be reported as "failed" once its activity is complete or if no further errors will be reported. The "errors" property in the Trigger Status Resource will be used to enumerate which actions failed and the reasons for failure, and can be present while the Trigger Status Resource is still "pending" or "active", if the CI/T Trigger Command is still running for some URLs or Patterns in the Trigger Specification. @@ -698,32 +704,33 @@ Value: A Trigger Specification, as defined in Section 5.2.1. Mandatory: No, but exactly one of "trigger" or "cancel" MUST be present in a CI/T Command. Name: cancel Description: The URLs of Trigger Status Resources for CI/T Trigger Commands that the uCDN wants to cancel. - Value: A JSON array of URLs represented as JSON strings. + Value: A non-empty JSON array of URLs represented as JSON + strings. Mandatory: No, but exactly one of "trigger" or "cancel" MUST be present in a CI/T Command. Name: cdn-path Description: The CDN Provider Identifiers of CDNs that have already accepted the CI/T Command. - Value: A JSON array of JSON strings, where each string is a CDN - Provider Identifier as defined in Section 4.6. + Value: A non-empty JSON array of JSON strings, where each + string is a CDN Provider Identifier as defined in Section 4.6. Mandatory: Yes. 5.1.2. Trigger Status Resource Trigger Status Resources SHOULD use a MIME Media Type of application/ cdni.ci.TriggerStatus+json. A Trigger Status Resource is encoded as a JSON object containing the following name/value pairs. @@ -776,22 +782,23 @@ Value: Trigger Status, as defined in Section 5.2.3. Mandatory: Yes Name: errors Description: Descriptions of errors that have occurred while processing a Trigger Command. - Value: A list of Error Descriptions, as defined in - Section 5.2.6. + Value: An array of Error Description, as defined in + Section 5.2.6. An empty array is allowed, and equivalent to + omitting "errors" from the object. Mandatory: No. 5.1.3. Trigger Collection Trigger Collections SHOULD use a MIME Media Type of application/ cdni.ci.TriggerCollection+json. A Trigger Collection is encoded as a JSON object containing the following name/value pairs. @@ -790,36 +797,37 @@ 5.1.3. Trigger Collection Trigger Collections SHOULD use a MIME Media Type of application/ cdni.ci.TriggerCollection+json. A Trigger Collection is encoded as a JSON object containing the following name/value pairs. Name: triggers - Description: Links to Trigger Status Resources in the collection. - Value: A JSON array of URLs represented as JSON strings. + Value: A JSON array of zero or more URLs, represented as JSON + strings. Mandatory: Yes Name: staleresourcetime Description: The length of time for which the dCDN guarantees to keep a completed Trigger Status Resource. After this time, the dCDN SHOULD delete the Trigger Status Resource and all references to it from collections. - Value: A JSON number, integer time in seconds. + Value: A JSON number, which must be a positive integer, + representing time in seconds. Mandatory: Yes, in the collection of all Trigger Status Resources if the dCDN deletes stale entries. If the property is present in the filtered collections, it MUST have the same value as in the collection of all Trigger Status Resources. Names: coll-all, coll-pending, coll-active, coll-complete, coll- failed Description: Link to a Trigger Collection. @@ -1015,21 +1023,22 @@ "case-sensitive": true } 5.2.5. Absolute Time A JSON number, seconds since the UNIX epoch. 5.2.6. Error Description An Error Description is used to report failure of a CI/T Command, or - in the activity it triggered. + in the activity it triggered. It is encoded as a JSON object with + the following name/value pairs: Name: error Value: Error Code, as defined in Section 5.2.7. Mandatory: Yes. Names: metadata.urls, content.urls, metadata.patterns, content.patterns @@ -1075,20 +1084,96 @@ | | CDN). | | ereject | The dCDN is not willing to fulfil the CI/T Command | | | (for example, a preposition request for content at a | | | time when the dCDN would not accept Request Routing | | | requests from the uCDN). | | ecdn | An internal error in the dCDN or one of its | | | downstream CDNs. | | ecancelled | The uCDN cancelled the request. | +------------+------------------------------------------------------+ +5.3. Formalization of the JSON Data + + The JSON data described in this document has been formalised using + CDDL [I-D.greevenbosch-appsawg-cbor-cddl] as follows: + + CIT-object = CIT-command / Trigger-Status-Resource / Trigger-Collection + + CIT-command ; use media type application/cdni.ci.TriggerCommand+json + = { + ? trigger: Triggerspec + ? cancel: [* URI] + cdn-path: [* Cdn-PID] + } + + Trigger-Status-Resource ; application/cdni.ci.TriggerStatus+json. + = { + trigger: Triggerspec + ctime: Absolute-Time + mtime: Absolute-Time + ? etime: Absolute-Time + status: Trigger-Status + ? errors: [* Error-Description] + } + + Trigger-Collection ; application/cdni.ci.TriggerCollection+json + = { + triggers: [* URI] + ? staleresourcetime: int ; time in seconds + ? coll-all: URI + ? coll-pending: URI + ? coll-active: URI + ? coll-complete: URI + ? coll-failed: URI + ? cdn-id: Cdn-PID + } + + Triggerspec = { ; 5.2.1 + type: Trigger-Type + ? metadata.urls: [* URI] + ? content.urls: [* URI] + ? content.ccid: [* Ccid] + ? metadata.patterns: [* Pattern-Match] + ? content.patterns: [* Pattern-Match] + } + + Trigger-Type = "preposition" / "invalidate" / "purge" ; 5.2.2 + + Trigger-Status = "pending" / "active" / "complete" / "processed" + / "failed" / "cancelling" / "cancelled" ; 5.2.3 + + Pattern-Match = { ; 5.2.4 + pattern: tstr + ? case-sensitive: bool + ? match-query-string: bool + } + + Absolute-Time = number ; seconds since UNIX epoch, 5.2.5 + + Error-Description = { ; 5.2.6 + error: Error-Code + ? metadata.urls: [* URI] + ? content.urls: [* URI] + ? metadata.patterns: [* Pattern-Match] + ? content.patterns: [* Pattern-Match] + ? description: tstr + } + + Error-Code = "emeta" / "econtent" / "eperm" / "ereject" + / "ecdn" / "ecancelled" ; 5.2.7 + + Ccid = tstr ; see I-D.ietf-cdni-metadata + + Cdn-PID = tstr .regexp "AS[0-9]+:[0-9]+" + + URI = tstr + 6. Examples The following sections provide examples of different CI/T objects encoded as JSON. Discovery of the triggers interface is out of scope of this document. In an implementation, all CI/T URLs are under the control of the dCDN. The uCDN MUST NOT attempt to ascribe any meaning to individual elements of the path. @@ -1464,20 +1551,21 @@ For example, when the two example CI/T Trigger Commands are complete, the collections of pending and complete Trigger Status Resources might look like: REQUEST: GET /triggers/pending HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* + If-None-Match: "5012053611544832286" RESPONSE: HTTP/1.1 200 OK Content-Length: 56 Expires: Sun, 31 Aug 2014 09:54:29 GMT Server: example-server/0.1 Etag: "-4471185573414616962" Cache-Control: max-age=60 Date: Sun, 31 Aug 2014 09:53:29 GMT @@ -1487,20 +1575,21 @@ "staleresourcetime": 86400, "triggers": [] } REQUEST: GET /triggers/complete HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* + If-None-Match: "2986340333785000363" RESPONSE: HTTP/1.1 200 OK Content-Length: 153 Expires: Sun, 31 Aug 2014 09:54:30 GMT Server: example-server/0.1 Etag: "-1508172875796647067" Cache-Control: max-age=60 Date: Sun, 31 Aug 2014 09:53:30 GMT @@ -1775,41 +1865,43 @@ And so would a man in the middle attacker modifying valid CI/T commands generated by the uCDN. In both cases, that would decrease the dCDN caching efficiency by causing it to unnecessarily acquire or re-acquire content metadata and/or content. A dCDN implementation of CI/T MUST restrict the actions of a uCDN to the data corresponding to that uCDN. Failure to do so would allow uCDNs to detrimentally affect each other's efficiency by generating unnecessary acquisition or re-acquisition load. -8.1. Authentication, Confidentiality, Integrity Protection +8.1. Authentication, Authorization, Confidentiality, Integrity + Protection A CI/T implementation MUST support TLS transport for HTTP (https) as - per [RFC2818]. The use of TLS for transport of the CI/T interface - allows the dCDN and the uCDN to authenticate each other (to ensure - they are receiving CI/T Commands from, or reporting status to, an - authenticated CDN). + per [RFC2818]. - In an environment where any such protection is required, TLS SHOULD - be used for transport of the CI/T requests and responses, unless - alternate methods are used for ensuring that only authorised clients - are able to access their own data (such as setting up an IPsec tunnel - between the two CDNs, or using a physically secured internal network - between two CDNs that are owned by the same corporate entity). Both - parties of the transaction (the uCDN and the dCDN) SHOULD use mutual - authentication. + The use of TLS for transport of the CI/T interface allows: - A TLS implementation of CI/T MUST support the - TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite ([RFC5288]). An - implementation of the CI/T Interface SHOULD prefer cipher suites - which support perfect forward secrecy over cipher suites that don't. + o The dCDN and the uCDN to authenticate each other. + + and, once they have mutually authenticated each other, it allows: + + o The dCDN and the uCDN to authorize each other (to ensure they are + receiving CI/T Commands from, or reporting status to, an + authorized CDN). + + o CDNI commands and responses to transmitted with confidentiality, + In an environment where any such protection is required, the use of a + mutually authenticated encrypted transport MUST be used to ensure + confidentiality of the CI/T information. TLS MUST be used by CI/T, + including authentication of the remote end. + + The general TLS usage guidance in [RFC7525] SHOULD be followed. HTTP requests that attempt to access or operate on CI/T data belonging to another CDN MUST be rejected using, for example, HTTP "403 Forbidden" or "404 Not Found". This is intended to prevent unauthorised users from generating unnecessary load in dCDN or uCDN due to revalidation, reacquisition, or unnecessary acquisition. Note that in a "diamond" configuration, where one uCDN's content can be acquired via more than one directly-connected uCDN, it may not be possible for the dCDN to determine from which uCDN it acquired @@ -1825,77 +1917,100 @@ and/or via mechanisms outside the scope of the CI/T interface, such as firewalling or use of Virtual Private Networks (VPNs). Depending on the implementation, triggered activity may consume significant processing and bandwidth in the dCDN. A malicious or faulty uCDN could use this to generate unnecessary load in the dCDN. The dCDN should consider mechanisms to avoid overload, for example by rate-limiting acceptance or processing of CI/T Commands, or batching up its processing. +8.3. Privacy + + The CI/T protocol does not carry any information about individual End + Users of a CDN, there are no privacy concerns for End Users. + + The CI/T protocol does carry information which could be considered + commercially sensitive by CDN operators and content owners. The use + of mutually authenticated TLS to establish a secure session for the + transport of CI/T data, as discussed in Section 8.1, provides + confidentiality while the CI/T data is in transit, and prevents + parties other party than the authorised dCDN from gaining access to + that data. The dCDN MUST ensure that it only exposes CI/T data + related to a uCDN to clients it has authenticated as belonging to + that uCDN. + 9. Acknowledgements - The authors thank Kevin Ma for his input. + The authors thank Kevin Ma for his input, and Carsten Bormann for his + review and formalization of the JSON data. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014. [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 10.2. Informative References + [I-D.greevenbosch-appsawg-cbor-cddl] + Vigano, C., Birkholz, H., and R. Sun, "CBOR data + definition language: a notational convention to express + CBOR data structures.", draft-greevenbosch-appsawg-cbor- + cddl-05 (work in progress), March 2015. + [I-D.ietf-cdni-metadata] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "CDN Interconnection Metadata", draft-ietf-cdni- - metadata-08 (work in progress), October 2014. + metadata-09 (work in progress), March 2015. [I-D.ietf-cdni-redirection] Niven-Jenkins, B. and R. Brandenburg, "Request Routing Redirection Interface for CDN Interconnection", draft- - ietf-cdni-redirection-08 (work in progress), February - 2015. + ietf-cdni-redirection-09 (work in progress), April 2015. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. - [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois - Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, - August 2008. - [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012. [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, August 2014. [RFC7337] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, August 2014. + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, May 2015. + Authors' Addresses Rob Murray Velocix (Alcatel-Lucent) 3 Ely Road Milton, Cambridge CB24 6DD UK Email: rob.murray@alcatel-lucent.com + Ben Niven-Jenkins Velocix (Alcatel-Lucent) 3 Ely Road Milton, Cambridge CB24 6DD UK Email: ben.niven-jenkins@alcatel-lucent.com