Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7336

Framework for Content Distribution Network Interconnection (CDNI)

Pages: 58
Informational
Obsoletes:  3466
Part 4 of 4 – Pages 53 to 58
First   Prev   None

Top   ToC   RFC7336 - Page 53   prevText

6. Trust Model

There are a number of trust issues that need to be addressed by a CDNI solution. Many of them are in fact similar or identical to those in a simple CDN without interconnection. In a standard CDN environment (without CDNI), the CSP places a degree of trust in a single CDN operator to perform many functions. The CDN is trusted to deliver content with appropriate quality of experience for the end user. The CSP trusts the CDN operator not to corrupt or modify the content. The CSP often relies on the CDN operator to provide reliable accounting information regarding the volume of delivered content. The CSP may also trust the CDN operator to perform actions such as timely invalidation of content and restriction of access to content based on certain criteria such as location of the user and time of day, and to enforce per-request authorization performed by the CSP using techniques such as URI signing. A CSP also places trust in the CDN not to distribute any information that is confidential to the CSP (e.g., how popular a given piece of content is) or confidential to the end user (e.g., which content has been watched by which user). A CSP does not necessarily have to place complete trust in a CDN. A CSP will in some cases take steps to protect its content from improper distribution by a CDN, e.g., by encrypting it and distributing keys in some out of band way. A CSP also depends on monitoring (possibly by third parties) and reporting to verify that the CDN has performed adequately. A CSP may use techniques such as client-based metering to verify that accounting information provided by the CDN is reliable. HTTP conditional requests may be used to provide the CSP with some checks on CDN operation. In other words, while a CSP may trust a CDN to perform some functions in the short term, the CSP is able, in most cases, to verify whether these actions have been performed correctly and to take action (such as moving the content to a different CDN) if the CDN does not live up to expectations. One of the trust issues raised by CDNI is transitive trust. A CDN that has a direct relationship with a CSP can now "outsource" the delivery of content to another (Downstream) CDN. That CDN may in term outsource delivery to yet another Downstream CDN, and so on.
Top   ToC   RFC7336 - Page 54
   The top-level CDN in such a chain of delegation is responsible for
   ensuring that the requirements of the CSP are met.  Failure to do so
   is presumably just as serious as in the traditional single CDN case.
   Hence, an Upstream CDN is essentially trusting a Downstream CDN to
   perform functions on its behalf in just the same way as a CSP trusts
   a single CDN.  Monitoring and reporting can similarly be used to
   verify that the Downstream CDN has performed appropriately.  However,
   the introduction of multiple CDNs in the path between CSP and end
   user complicates the picture.  For example, third-party monitoring of
   CDN performance (or other aspects of operation, such as timely
   invalidation) might be able to identify the fact that a problem
   occurred somewhere in the chain but not point to the particular CDN
   at fault.

   In summary, we assume that an Upstream CDN will invest a certain
   amount of trust in a Downstream CDN, but that it will verify that the
   Downstream CDN is performing correctly, and take corrective action
   (including potentially breaking off its relationship with that CDN)
   if behavior is not correct.  We do not expect that the trust
   relationship between a CSP and its "top level" CDN will differ
   significantly from that found today in single CDN situations.
   However, it does appear that more sophisticated tools and techniques
   for monitoring CDN performance and behavior will be required to
   enable the identification of the CDN at fault in a particular
   delivery chain.

   We expect that the detailed designs for the specific interfaces for
   CDNI will need to take the transitive trust issues into account.  For
   example, explicit confirmation that some action (such as content
   removal) has taken place in a Downstream CDN may help to mitigate
   some issues of transitive trust.

7. Privacy Considerations

In general, a CDN has the opportunity to collect detailed information about the behavior of end users, e.g., by logging which files are being downloaded. While the concept of interconnected CDNs as described in this document doesn't necessarily allow any given CDN to gather more information on any specific user, it potentially facilitates sharing of this data by a CDN with more parties. As an example, the purpose of the CDNI Logging interface is to allow a dCDN to share some of its log records with a uCDN, both for billing purposes as well as for sharing traffic statistics with the Content Provider on whose behalf the content was delivered. The fact that the CDNI interfaces provide mechanisms for sharing such potentially sensitive user data, shows that it is necessary to include in these
Top   ToC   RFC7336 - Page 55
   interface appropriate privacy and confidentiality mechanisms.  The
   definition of such mechanisms is dealt with in the respective CDN
   interface documents.

8. Security Considerations

While there are a variety of security issues introduced by a single CDN, we are concerned here specifically with the additional issues that arise when CDNs are interconnected. For example, when a single CDN has the ability to distribute content on behalf of a CSP, there may be concerns that such content could be distributed to parties who are not authorized to receive it, and there are mechanisms to deal with such concerns. Our focus in this section is on how CDNI introduces new security issues not found in the single CDN case. For a more detailed analysis of the security requirements of CDNI, see Section 9 of [RFC7337]. Many of the security issues that arise in CDNI are related to the transitivity of trust (or lack thereof) described in Section 6. As noted above, the design of the various interfaces for CDNI must take account of the additional risks posed by the fact that a CDN with whom a CSP has no direct relationship is now potentially distributing content for that CSP. The mechanisms used to mitigate these risks may be similar to those used in the single CDN case, but their suitability in this more complex environment must be validated. CDNs today offer a variety of means to control access to content, such as time-of-day restrictions, geo-blocking, and URI signing. These mechanisms must continue to function in CDNI environments, and this consideration is likely to affect the design of certain CDNI interfaces (e.g., metadata, request routing). For more information on URI signing in CDNI, see [URI-SIGNING]. Just as with a single CDN, each peer CDN must ensure that it is not used as an "open proxy" to deliver content on behalf of a malicious CSP. Whereas a single CDN typically addresses this problem by having CSPs explicitly register content (or origin servers) that are to be served, simply propagating this information to peer Downstream CDNs may be problematic because it reveals more information than the Upstream CDN is willing to specify. (To this end, the content acquisition step in the earlier examples force the dCDN to retrieve content from the uCDN rather than go directly to the origin server.) There are several approaches to this problem. One is for the uCDN to encode a signed token generated from a shared secret in each URL routed to a dCDN, and for the dCDN to validate the request based on this token. Another one is to have each Upstream CDN advertise the set of CDN-Domains they serve, where the Downstream CDN checks each
Top   ToC   RFC7336 - Page 56
   request against this set before caching and delivering the associated
   object.  Although straightforward, this approach requires operators
   to reveal additional information, which may or may not be an issue.

8.1. Security of CDNI Interfaces

It is noted in [RFC7337] that all CDNI interfaces must be able to operate securely over insecure IP networks. Since it is expected that the CDNI interfaces will be implemented using existing application protocols such as HTTP or Extensible Messaging and Presence Protocol (XMPP), we also expect that the security mechanisms available to those protocols may be used by the CDNI interfaces. Details of how these interfaces are secured will be specified in the relevant interface documents.

8.2. Digital Rights Management

Digital Rights Management (DRM), also sometimes called digital restrictions management, is often employed for content distributed via CDNs. In general, DRM relies on the CDN to distribute encrypted content, with decryption keys distributed to users by some other means (e.g., directly from the CSP to the end user). For this reason, DRM is considered out of scope [RFC6707] and does not introduce additional security issues for CDNI.

9. Contributors

The following individuals contributed to this document: o Matt Caulfield o Francois Le Faucheur o Aaron Falk o David Ferguson o John Hartman o Ben Niven-Jenkins o Kent Leung
Top   ToC   RFC7336 - Page 57

10. Acknowledgements

The authors would like to thank Huw Jones and Jinmei Tatuya for their helpful input to this document. In addition, the authors would like to thank Stephen Farrell, Ted Lemon, and Alissa Cooper for their reviews, which have helped to improve this document.

11. Informative References

[CONTROL-TRIGGERS] Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / Triggers", Work in Progress, July 2014. [FOOTPRINT-CAPABILITY] Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., and K. Ma, "CDNI Request Routing: Footprint and Capabilities Semantics", Work in Progress, July 2014. [LOGGING] Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., and R. Peterkofsky, "CDNI Logging Interface", Work in Progress, July 2014. [METADATA] Niven-Jenkins, B., Murray, R., Caulfield, M., Leung, K., and K. Ma, "CDN Interconnection Metadata", Work in Progress, July 2014. [REDIRECTION] Niven-Jenkins, B., Ed. and R. Brandenburg, Ed., "Request Routing Redirection Interface for CDN Interconnection", Work in Progress, April 2014. [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003. [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012. [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, November 2012. [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)", RFC 6983, July 2013.
Top   ToC   RFC7336 - Page 58
   [RFC7337]  Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
              Network Interconnection (CDNI) Requirements", RFC 7337,
              August 2014.

   [URI-SIGNING]
              Leung, K., Faucheur, F., Downey, B., Brandenburg, R., and
              S. Leibrand, "URI Signing for CDN Interconnection (CDNI)",
              Work in Progress, March 2014.

Authors' Addresses

Larry Peterson Akamai Technologies, Inc. 8 Cambridge Center Cambridge, MA 02142 USA EMail: lapeters@akamai.com Bruce Davie VMware, Inc. 3401 Hillview Ave. Palo Alto, CA 94304 USA EMail: bdavie@vmware.com Ray van Brandenburg (editor) TNO Brassersplein 2 Delft 2612CT the Netherlands Phone: +31-88-866-7000 EMail: ray.vanbrandenburg@tno.nl