RFC 7336

Framework for Content Distribution Network Interconnection (CDNI)

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