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.

   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

   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

   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

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.

   [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