draft-ietf-cdni-problem-statement-04.txt   draft-ietf-cdni-problem-statement-05.txt 
Network Working Group B. Niven-Jenkins Network Working Group B. Niven-Jenkins
Internet-Draft Velocix (Alcatel-Lucent) Internet-Draft Velocix (Alcatel-Lucent)
Intended status: Informational F. Le Faucheur Intended status: Informational F. Le Faucheur
Expires: September 11, 2012 Cisco Expires: November 4, 2012 Cisco
N. Bitar N. Bitar
Verizon Verizon
March 10, 2012 May 3, 2012
Content Distribution Network Interconnection (CDNI) Problem Statement Content Distribution Network Interconnection (CDNI) Problem Statement
draft-ietf-cdni-problem-statement-04 draft-ietf-cdni-problem-statement-05
Abstract Abstract
Content Delivery Networks (CDNs) provide numerous benefits: reduced Content Delivery Networks (CDNs) provide numerous benefits: reduced
delivery cost for cacheable content, improved quality of experience delivery cost for cacheable content, improved quality of experience
for End Users and increased robustness of delivery. For these for End Users and increased robustness of delivery. For these
reasons they are frequently used for large-scale content delivery. reasons they are frequently used for large-scale content delivery.
As a result, existing CDN Providers are scaling up their As a result, existing CDN Providers are scaling up their
infrastructure and many Network Service Providers (NSPs) are infrastructure and many Network Service Providers (NSPs) are
deploying their own CDNs. It is generally desirable that a given deploying their own CDNs. It is generally desirable that a given
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2012. This Internet-Draft will expire on November 4, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. CDN Background . . . . . . . . . . . . . . . . . . . . . . 8 1.2. CDN Background . . . . . . . . . . . . . . . . . . . . . . 10
2. CDN Interconnection Use Cases . . . . . . . . . . . . . . . . 9 2. CDN Interconnection Use Cases . . . . . . . . . . . . . . . . 10
3. CDN Interconnection Model & Problem Area for IETF . . . . . . 10 3. CDN Interconnection Model & Problem Area for IETF . . . . . . 11
4. Scoping the CDNI Problem . . . . . . . . . . . . . . . . . . . 14 4. Scoping the CDNI Problem . . . . . . . . . . . . . . . . . . . 15
4.1. CDNI Request Routing Interface . . . . . . . . . . . . . . 14 4.1. CDNI Request Routing Interface . . . . . . . . . . . . . . 16
4.2. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 15 4.2. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 16
4.3. CDNI Logging Interface . . . . . . . . . . . . . . . . . . 16 4.3. CDNI Logging Interface . . . . . . . . . . . . . . . . . . 17
4.4. CDNI Control Interface . . . . . . . . . . . . . . . . . . 16 4.4. CDNI Control Interface . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Security of the CDNI Control interface . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Security of the CDNI Request Routing Interface . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 6.3. Security of the CDNI Metadata interface . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 6.4. Security of the CDNI Logging interface . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Design considerations for realizing the CDNI Appendix A. Design considerations for realizing the CDNI
Interfaces . . . . . . . . . . . . . . . . . . . . . 19 Interfaces . . . . . . . . . . . . . . . . . . . . . 22
A.1. CDNI Request Routing Interface . . . . . . . . . . . . . . 19 A.1. CDNI Request Routing Interface . . . . . . . . . . . . . . 22
A.2. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 21 A.2. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 24
A.3. CDNI Logging Interface . . . . . . . . . . . . . . . . . . 22 A.3. CDNI Logging Interface . . . . . . . . . . . . . . . . . . 25
A.4. CDNI Control Interface . . . . . . . . . . . . . . . . . . 23 A.4. CDNI Control Interface . . . . . . . . . . . . . . . . . . 26
Appendix B. Additional Material . . . . . . . . . . . . . . . . . 24 Appendix B. Additional Material . . . . . . . . . . . . . . . . . 26
B.1. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 24 B.1. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 26
B.2. Related standardization activites . . . . . . . . . . . . 25 B.2. Related standardization activites . . . . . . . . . . . . 28
B.2.1. IETF CDI Working Group (Concluded) . . . . . . . . . . 26 B.2.1. IETF CDI Working Group (Concluded) . . . . . . . . . . 29
B.2.2. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.2.2. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 29
B.2.3. ISO MPEG . . . . . . . . . . . . . . . . . . . . . . . 28 B.2.3. ISO MPEG . . . . . . . . . . . . . . . . . . . . . . . 30
B.2.4. ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 28 B.2.4. ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 31
B.2.5. CableLabs . . . . . . . . . . . . . . . . . . . . . . 29 B.2.5. CableLabs . . . . . . . . . . . . . . . . . . . . . . 31
B.2.6. ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 29 B.2.6. ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 31
B.2.7. ETSI TISPAN . . . . . . . . . . . . . . . . . . . . . 29 B.2.7. ETSI TISPAN . . . . . . . . . . . . . . . . . . . . . 31
B.2.8. ITU-T . . . . . . . . . . . . . . . . . . . . . . . . 29 B.2.8. ITU-T . . . . . . . . . . . . . . . . . . . . . . . . 32
B.2.9. Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 30 B.2.9. Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 32
B.2.10. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 30 B.2.10. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 32
B.2.11. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 30 B.2.11. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 33
B.2.12. Summary of existing stanardization work . . . . . . . 31 B.2.12. Summary of existing standardization work . . . . . . . 33
B.3. Related Research Projects . . . . . . . . . . . . . . . . 33 B.3. Related Research Projects . . . . . . . . . . . . . . . . 35
B.3.1. IRTF P2P Research Group . . . . . . . . . . . . . . . 33 B.3.1. IRTF P2P Research Group . . . . . . . . . . . . . . . 35
B.3.2. OCEAN . . . . . . . . . . . . . . . . . . . . . . . . 33 B.3.2. OCEAN . . . . . . . . . . . . . . . . . . . . . . . . 35
B.3.3. Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 33 B.3.3. Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 35
B.4. Relationship to relevant IETF Working Groups . . . . . . . 33 B.4. Relationship to relevant IETF Working Groups . . . . . . . 36
B.4.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . 33 B.4.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . 36
B.4.2. DECADE . . . . . . . . . . . . . . . . . . . . . . . . 34 B.4.2. DECADE . . . . . . . . . . . . . . . . . . . . . . . . 36
B.4.3. PPSP . . . . . . . . . . . . . . . . . . . . . . . . . 35 B.4.3. PPSP . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
The volume of video and multimedia content delivered over the The volume of video and multimedia content delivered over the
Internet is rapidly increasing and expected to continue doing so in Internet is rapidly increasing and expected to continue doing so in
the future. In the face of this growth, Content Delivery Networks the future. In the face of this growth, Content Delivery Networks
(CDNs) provide numerous benefits: reduced delivery cost for cacheable (CDNs) provide numerous benefits: reduced delivery cost for cacheable
content, improved quality of experience for End Users and increased content, improved quality of experience for End Users (EUs) and
robustness of delivery. For these reasons CDNs are frequently used increased robustness of delivery. For these reasons CDNs are
for large-scale content delivery. As a result, existing CDN frequently used for large-scale content delivery. As a result,
Providers are scaling up their infrastructure and many Network existing CDN Providers are scaling up their infrastructure and many
Service Providers (NSPs) are deploying their own CDNs. Network Service Providers (NSPs) are deploying their own CDNs.
It is generally desirable that a given content item can be delivered It is generally desirable that a given content item can be delivered
to an End User regardless of that End User's location or attachment to an EU regardless of that EU's location or the network they are
network. However, a given CDN in charge of delivering a given attached to. However, a given CDN in charge of delivering a given
content may not have a footprint that expands close enough to the End content may not have a footprint that expands close enough to the
User's current location or attachment network, or may not have the EU's current location or attachment network, or may not have the
necessary resources, to realize the user experience and cost benefit necessary resources, to realize the user experience and cost benefit
that a more distributed CDN infrastructure would allow. This is the that a more distributed CDN infrastructure would allow. This is the
motivation for interconnecting standalone CDNs so that their motivation for interconnecting standalone CDNs so that their
collective CDN footprint and resources can be leveraged for the end- collective CDN footprint and resources can be leveraged for the end-
to-end delivery of content from Content Service Providers (CSPs) to to-end delivery of content from CSPs to EUs. As an example, a CSP
End Users. As an example, a CSP could contract with an could contract with an "authoritative" CDN Provider for the delivery
"authoritative" CDN Provider for the delivery of content and that of content and that authoritative CDN Provider could contract with
authoritative CDN Provider could contract with one or more downstream one or more downstream CDN Provider(s) to distribute and deliver some
CDN Provider(s) to distribute and deliver some or all of the content or all of the content on behalf of the authoritative CDN Provider.
on behalf of the authoritative CDN Provider. The formation and
details of any business relationships between a CSP and a CDN A typical end to end content delivery scenario would then involve the
Provider and between one CDN Provider and another CDN Provider are following business arrangements:
out of scope of this document. However, no standards or open
specifications currently exist to facilitate such CDN o A business arrangement between the EU and his CSP, authorizing
interconnection. access by the EU to content items controlled by the CSP.
o A business arrangement between the CSP and an "authoritative" CDN
Provider where the CSP authorizes the CDN Provider to perform the
content delivery on behalf of the CSP.
o A business arrangement between the authoritative CDN Provider and
another (or other) CDN(s) where the authoritative CDN may delegate
the actual serving of some of the content delivery requests to the
other CDN(s). A particular case, is where this other CDN Provider
happens to also be the Network Service Provider providing network
access to the EU, in which case there is also a separate and
independent business relationship between the EU and the NSP for
the corresponding network access.
The formation and details of any business relationships between a CSP
and a CDN Provider as well as between one CDN Provider and another
CDN Provider are out of scope of this document. However, this
document concerns itself with the fact that no standards or open
specifications currently exist to facilitate such CDN interconnection
from a technical perspective.
The goal of this document is to outline the problem area of CDN The goal of this document is to outline the problem area of CDN
interconnection. Section 2 discusses the use cases for CDN interconnection. Section 2 discusses the use cases for CDN
interconnection. Section 3 presents the CDNI model and problem area interconnection. Section 3 presents the CDNI model and problem area
being considered by the IETF. Section 4 describes each CDNI being considered by the IETF. Section 4 describes each CDNI
interface individually and highlights example candidate protocols interface individually and highlights example candidate protocols
that could be considered for reuse or leveraging to implement the that could be considered for reuse or leveraging to implement the
CDNI interfaces. Appendix B.2 discusses the relevant work of other CDNI interfaces. Appendix B.2 discusses the relevant work of other
standards organizations. Appendix B.4 describes the relationships standards organizations. Appendix B.4 describes the relationships
between the CDNI problem space and other relevant IETF Working between the CDNI problem space and other relevant IETF Working
skipping to change at page 12, line 28 skipping to change at page 13, line 45
Note that the actual grouping of functionalities under these four Note that the actual grouping of functionalities under these four
interfaces is considered tentative at this stage and may be changed interfaces is considered tentative at this stage and may be changed
after further study (e.g. some subset of functionality be moved from after further study (e.g. some subset of functionality be moved from
one interface into another). one interface into another).
The above list covers a significant potential problem space, in part The above list covers a significant potential problem space, in part
because in order to interconnect two CDNs there are several 'touch because in order to interconnect two CDNs there are several 'touch
points' that require standardization. However, it is expected that points' that require standardization. However, it is expected that
the CDNI interfaces need not be defined from scratch and instead can the CDNI interfaces need not be defined from scratch and instead can
very significantly reuse or leverage existing protocols: this is very significantly reuse or leverage existing protocols; this is
discussed further in Section 4. discussed further in Section 4.
The interfaces that form the CDNI problem area are illustrated in The interfaces that form the CDNI problem area are illustrated in
Figure 1. Figure 1.
-------- --------
/ \ / \
| CSP | | CSP |
\ / \ /
-------- --------
skipping to change at page 14, line 16 skipping to change at page 15, line 16
the CDNI problem space described in this document is focussed on only the CDNI problem space described in this document is focussed on only
defining the control plane for CDNI; and the CDNI data plane (i.e. defining the control plane for CDNI; and the CDNI data plane (i.e.
the acquisition & distribution of the actual content objects) is out the acquisition & distribution of the actual content objects) is out
of scope. The rationale for such a decision is that CDNs today of scope. The rationale for such a decision is that CDNs today
typically already use standardized protocols such as HTTP, FTP, typically already use standardized protocols such as HTTP, FTP,
rsync, etc. to acquire content from their CSP customers and it is rsync, etc. to acquire content from their CSP customers and it is
expected that the same protocols could be used for acquisition expected that the same protocols could be used for acquisition
between interconnected CDNs. Therefore the problem of content between interconnected CDNs. Therefore the problem of content
acquisition is considered already solved and all that is required acquisition is considered already solved and all that is required
from specifications developed by the CDNI working group is to from specifications developed by the CDNI working group is to
describe within the CDNI Metadata where to go and which protocol to describe within the CDNI Metadata the parameters to use to retrieve
use to retrieve the content. the content for example the IP address/hostname to connect to, what
protocol to use to retrieve the content, etc.
4. Scoping the CDNI Problem 4. Scoping the CDNI Problem
This section outlines how the scope of work addressing the CDNI This section outlines how the scope of work addressing the CDNI
problem space can be constrained through reuse or leveraging of problem space can be constrained through reuse or leveraging of
existing protocols to implement the CDNI interfaces. This discussion existing protocols to implement the CDNI interfaces. This discussion
is not intended to pre-empt any working group decision as to the most is not intended to pre-empt any working group decision as to the most
appropriate protocols, technologies and solutions to select to appropriate protocols, technologies and solutions to select to
realize the CDNI interfaces but is intended as an illustration of the realize the CDNI interfaces but is intended as an illustration of the
fact that the CDNI interfaces need not be created in a vacuum and fact that the CDNI interfaces need not be created in a vacuum and
skipping to change at page 14, line 41 skipping to change at page 15, line 42
Routing interface, CDNI Metadata interface, CDNI Logging interface) Routing interface, CDNI Metadata interface, CDNI Logging interface)
described in Section 3 within the CDNI problem area are all control described in Section 3 within the CDNI problem area are all control
plane interfaces operating at the application layer (Layer 7 in the plane interfaces operating at the application layer (Layer 7 in the
OSI network model). Firstly, since it is not expected that these OSI network model). Firstly, since it is not expected that these
interfaces would exhibit unique session, transport or network interfaces would exhibit unique session, transport or network
requirements as compared to the many other existing applications in requirements as compared to the many other existing applications in
the Internet, it is expected that the CDNI interfaces will be defined the Internet, it is expected that the CDNI interfaces will be defined
on top of existing session, transport and network protocols. on top of existing session, transport and network protocols.
Secondly, although a new application protocol could be designed Secondly, although a new application protocol could be designed
specifically for CDNI we assume that this is unnecessary and it is specifically for CDNI our analysis below shows that this is
recommended that existing application protocols be reused or unnecessary and it is recommended that existing application protocols
leveraged (HTTP [RFC2616], Atom Publishing Protocol [RFC5023], XMPP be reused or leveraged (HTTP [RFC2616], Atom Publishing Protocol
[RFC6120], for example) to realize the CDNI interfaces. [RFC5023], XMPP [RFC6120], for example) to realize the CDNI
interfaces.
4.1. CDNI Request Routing Interface 4.1. CDNI Request Routing Interface
The CDNI Request Routing interface enables a Request Routing function The CDNI Request Routing interface enables a Request Routing function
in an upstream CDN to query a Request Routing function in a in an upstream CDN to query a Request Routing function in a
downstream CDN to determine if the downstream CDN is able (and downstream CDN to determine if the downstream CDN is able (and
willing) to accept the delegated content request and to allow the willing) to accept the delegated content request and to allow the
downstream CDN to control what the upstream Request Routing function downstream CDN to control what the upstream Request Routing function
should return to the User Agent in the redirection message. should return to the User Agent in the redirection message.
skipping to change at page 15, line 28 skipping to change at page 16, line 34
interface is also expected to enable a downstream CDN to provide to interface is also expected to enable a downstream CDN to provide to
the upstream CDN (static or dynamic) information (e.g. resources, the upstream CDN (static or dynamic) information (e.g. resources,
footprint, load) to facilitate selection of the downstream CDN by the footprint, load) to facilitate selection of the downstream CDN by the
upstream CDN request routing system when processing subsequent upstream CDN request routing system when processing subsequent
content requests from User Agents. It is expected that such content requests from User Agents. It is expected that such
functionality of the CDNI request Routing could be specified by the functionality of the CDNI request Routing could be specified by the
CDNI working group with significant leveraging of existing IETF CDNI working group with significant leveraging of existing IETF
protocols supporting the dynamic distribution of reachability protocols supporting the dynamic distribution of reachability
information (for example by leveraging existing routing protocols) or information (for example by leveraging existing routing protocols) or
supporting application level queries for topological information (for supporting application level queries for topological information (for
example by leveraging ALTO). example by leveraging ALTO [RFC5693]).
4.2. CDNI Metadata Interface 4.2. CDNI Metadata Interface
The CDNI Metadata interface enables the Distribution System in a The CDNI Metadata interface enables the Distribution System in a
downstream CDN to request CDNI Metadata from an upstream CDN so that downstream CDN to request CDNI Metadata from an upstream CDN so that
the downstream CDN can properly process and respond to redirection the downstream CDN can properly process and respond to redirection
requests received over the CDNI Request Routing interface and Content requests received over the CDNI Request Routing interface and Content
Requests received directly from User Agents. Requests received directly from User Agents.
The CDNI Metadata interface is therefore similar to the CDNI Request The CDNI Metadata interface is therefore similar to the CDNI Request
skipping to change at page 16, line 9 skipping to change at page 17, line 11
WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.) WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.)
or possibly using other existing protocols such as XMPP [RFC6120]. or possibly using other existing protocols such as XMPP [RFC6120].
This removes the need for the CDNI working group to define a new This removes the need for the CDNI working group to define a new
protocol for the request/response element of the CDNI Metadata protocol for the request/response element of the CDNI Metadata
interface. interface.
4.3. CDNI Logging Interface 4.3. CDNI Logging Interface
The CDNI Logging interface enables details of logs or events to be The CDNI Logging interface enables details of logs or events to be
exchanged between interconnected CDNs, where events could be for exchanged between interconnected CDNs, where events could be for
example log lines related to the delivery of content (similar to the example log records related to the delivery of content (similar to
log lines recorded in a web server's access log) as well as real-time the log records recorded in a web server's access log) as well as
or near-real time events before, during or after content delivery and real-time or near-real time events before, during or after content
operations and diagnostic messages. delivery and operations and diagnostic messages.
Several protocols already exist that could potentially be used to Several protocols already exist that could potentially be used to
exchange CDNI logs between interconnected CDNs including SNMP, exchange CDNI logs between interconnected CDNs including SNMP,
syslog, ftp, HTTP POST, etc. syslog, ftp (and secure variants), HTTP POST, etc.
4.4. CDNI Control Interface 4.4. CDNI Control Interface
The CDNI Control interface allows the Control System in The CDNI Control interface allows the Control System in
interconnected CDNs to communicate. The exact inter-CDN control interconnected CDNs to communicate. The exact inter-CDN control
functionality required to be supported by the CDNI Control interface functionality required to be supported by the CDNI Control interface
is less well defined than the other three CDNI interfaces at this is less well defined than the other three CDNI interfaces at this
time. time.
It is expected that for the Control interface, as for the other CDNI It is expected that for the Control interface, as for the other CDNI
skipping to change at page 16, line 40 skipping to change at page 17, line 42
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
6. Security Considerations 6. Security Considerations
Distribution of content by a CDN comes with a range of security Distribution of content by a CDN comes with a range of security
considerations such as how to enforce control of access to the considerations such as how to enforce control of access to the
content by users in line with the CSP policy. These security aspects content by end users in line with the CSP policy, or how to trust the
are already dealt with by CDN Providers and CSPs today in the context logging information generated by the CDN for the purposes of charging
of standalone CDNs. However, interconnection of CDNs introduces a the CSP. These security aspects are already dealt with by CDN
new set of security considerations by extending the trust model (i.e. Providers and CSPs today in the context of standalone CDNs. However,
the CSP "trusts" a CDN that "trusts" another CDN). interconnection of CDNs introduces a new set of security
considerations by extending the trust model to a chain of trust (i.e.
the CSP "trusts" a CDN that "trusts" another CDN). The mechanisms
used to mitigate these risks in multi-CDN environments may be similar
to those used in the single CDN case, but their suitability in this
more complex environment must be validated.
Maintaining the security of the content itself, its associated Maintaining the security of the content itself, its associated
metadata (including distribution and delivery policies) and the CDNs metadata (including delivery policies) and the CDNs distributing and
distributing and delivering it, are critical requirements for both delivering it, are critical requirements for both CDN Providers and
CDN Providers and CSPs and any work on CDN Interconnection must CSPs and the CDN Interconnection interfaces must provide sufficient
provide sufficient mechanisms to maintain the security of the overall mechanisms to maintain the security of the overall system of
system of interconnected CDNs as well as the information (content, interconnected CDNs as well as the information (content, metadata,
metadata, logs, etc) distributed and delivered through any CDN logs, etc) distributed and delivered through any set of
interconnections. interconnected CDNs.
6.1. Security of the CDNI Control interface
Information on this interface is of a very private nature between
interconnected CDNs. A pair of CDNs use this interface to allow
bootstrapping of all the other CDNI interfaces possibly including
establishment of the mechanisms for securing these interfaces.
Therefore, corruption of that interface may result in corruption of
all other interfaces. Using this interface, an upstream CDN may pre-
position or delete content or metadata in a downstream CDN and a
downstream CDN may provide administrative information to an upstream
CDN, etc. All of these operations require that the peer CDNs are
appropriately authenticated and that the confidentiality and
integrity of information flowing between them can be ensured.
6.2. Security of the CDNI Request Routing Interface
Appropriate levels of authentication and confidentiality must be used
in this interface because it allows an upstream CDN to query the
downstream CDN in order to redirect requests, and conversely, allows
the downstream CDN to influence the upstream CDN's Request Routing
function.
In the absence of appropriate security on this interface, a rogue
upstream CDN could inundate downstream CDNs with bogus requests, or
have the downstream CDN send the rogue upstream CDN private
information. Also, a rogue downstream CDN could influence the
upstream CDN so the upstream CDN redirects requests to the rogue dCDN
or another dCDN in order to, for example, attract additional delivery
revenue.
6.3. Security of the CDNI Metadata interface
This interface allows a downstream CDN to request CDNI metadata from
an upstream CDN, and therefore the upstream CDN must ensure that the
former is appropriately authenticated before sending the data.
Conversely, a downstream CDN must authenticate an upstream CDN before
requesting metadata to insulate itself from poisoning by rogue
upstream CDNs. The confidentiality and integrity of the information
exchanged between the peers must be protected.
6.4. Security of the CDNI Logging interface
Logging data consists of potentially sensitive information (which end
user accessed which media resource, IP addresses of end users,
potential names and subscriber account information, etc.).
Confidentiality of this information must be protected as log records
are moved between CDNs. This information may also be sensitive from
the viewpoint that it can be the basis for charging across CDNs.
Therefore, appropriate levels of protection are needed against
corruption, duplication and loss of this information.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Andre Beck, Gilles Bertrand, Mark The authors would like to thank Andre Beck, Gilles Bertrand, Mark
Carlson, Bruce Davie, David Ferguson, Yiu Lee, Kent Leung, Will Li, Carlson, Bruce Davie, David Ferguson, Yiu Lee, Kent Leung, Will Li,
Kevin Ma, Julien Maisonneuve, Guy Meador, Emile Stephan, Oskar van Kevin Ma, Julien Maisonneuve, Guy Meador, Larry Peterson, Emile
Deventer, Mahesh Viveganandhan and Richard Woundy for their review Stephan, Oskar van Deventer, Mahesh Viveganandhan and Richard Woundy
comments and contributions to the text. for their review comments and contributions to the text.
8. References 8. References
8.1. Normative References 8.1. Normative References
8.2. Informative References 8.2. Informative References
[3GP-DASH] [3GP-DASH]
"Transparent end-to-end Packet-switched Streaming Service "Transparent end-to-end Packet-switched Streaming Service
(PSS); Progressive Download and Dynamic Adaptive Streaming (PSS); Progressive Download and Dynamic Adaptive Streaming
skipping to change at page 18, line 16 skipping to change at page 20, line 27
"IETF DECADE WG Charter "IETF DECADE WG Charter
(http://datatracker.ietf.org/wg/decade/charter/)". (http://datatracker.ietf.org/wg/decade/charter/)".
[I-D.bertrand-cdni-experiments] [I-D.bertrand-cdni-experiments]
Faucheur, F. and L. Peterson, "Content Distribution Faucheur, F. and L. Peterson, "Content Distribution
Network Interconnection (CDNI) Experiments", Network Interconnection (CDNI) Experiments",
draft-bertrand-cdni-experiments-02 (work in progress), draft-bertrand-cdni-experiments-02 (work in progress),
February 2012. February 2012.
[I-D.ietf-cdni-use-cases] [I-D.ietf-cdni-use-cases]
Gilles, B., Watson, G., Ma, K., Eardley, P., Emile, S., Bertrand, G., Emile, S., Watson, G., Burbridge, T.,
and T. Burbridge, "Use Cases for Content Delivery Network Eardley, P., and K. Ma, "Use Cases for Content Delivery
Interconnection", draft-ietf-cdni-use-cases-03 (work in Network Interconnection", draft-ietf-cdni-use-cases-04
progress), January 2012. (work in progress), March 2012.
[I-D.jenkins-alto-cdn-use-cases] [I-D.jenkins-alto-cdn-use-cases]
Previdi, S., Watson, G., Medved, J., Bitar, N., and B. Previdi, S., Watson, G., Medved, J., Bitar, N., and B.
Niven-Jenkins, "Use Cases for ALTO within CDNs", Niven-Jenkins, "Use Cases for ALTO within CDNs",
draft-jenkins-alto-cdn-use-cases-02 (work in progress), draft-jenkins-alto-cdn-use-cases-02 (work in progress),
December 2011. December 2011.
[MPEG-DASH] [MPEG-DASH]
"Information technology - MPEG systems technologies - Part "Information technology - MPEG systems technologies - Part
6: Dynamic adaptive streaming over HTTP (DASH), (DIS 6: Dynamic adaptive streaming over HTTP (DASH), (DIS
skipping to change at page 19, line 20 skipping to change at page 21, line 31
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
Content Network (CN) Request-Routing Mechanisms", Content Network (CN) Request-Routing Mechanisms",
RFC 3568, July 2003. RFC 3568, July 2003.
[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content
Internetworking (CDI) Scenarios", RFC 3570, July 2003. Internetworking (CDI) Scenarios", RFC 3570, July 2003.
[RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing
Protocol", RFC 5023, October 2007. Protocol", RFC 5023, October 2007.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011. Protocol (XMPP): Core", RFC 6120, March 2011.
[SNIA-CDMI] [SNIA-CDMI]
"SNIA CDMI (http://www.snia.org/tech_activities/standards/ "SNIA CDMI (http://www.snia.org/tech_activities/standards/
curr_standards/cdmi)". curr_standards/cdmi)".
[TAXONOMY] [TAXONOMY]
Pathan, A., "A Taxonomy and Survey of Content Delivery Pathan, A., "A Taxonomy and Survey of Content Delivery
Networks Networks
skipping to change at page 23, line 5 skipping to change at page 25, line 20
o The semantics (i.e. meaning and expected contents) of the o The semantics (i.e. meaning and expected contents) of the
individual properties of a Metadata object. individual properties of a Metadata object.
o How the relationships between different CDNI Metadata objects are o How the relationships between different CDNI Metadata objects are
represented. represented.
A.3. CDNI Logging Interface A.3. CDNI Logging Interface
The CDNI Logging interface enables details of logs or events to be The CDNI Logging interface enables details of logs or events to be
exchanged between interconnected CDNs, where events could be: exchanged between interconnected CDNs, where events could be:
o Log lines related to the delivery of content (similar to the log o Log records related to the delivery of content (similar to the log
lines recorded in a web server's access log). records recorded in a web server's access log).
o Real-time or near-real time events before, during or after content o Real-time or near-real time events before, during or after content
delivery, e.g. content delivery interruption delivery, e.g. content delivery interruption
o Operations and diagnostic messages. o Operations and diagnostic messages.
Within CDNs today, logs and events are used for a variety of purposes Within CDNs today, logs and events are used for a variety of purposes
in addition to real-time and non real-time diagnostics and auditing in addition to real-time and non real-time diagnostics and auditing
by the CDN Provider and its customers. Specifically CDNs use logs to by the CDN Provider and its customers. Specifically CDNs use logs to
generate Call Data Records (CDRs) for passing to billing and payment generate Call Data Records (CDRs) for passing to billing and payment
systems and to real-time (and near real-time) analytics systems. systems and to real-time (and near real-time) analytics systems.
Such applications place requirements on the CDNI Logging interface to Such applications place requirements on the CDNI Logging interface to
skipping to change at page 31, line 13 skipping to change at page 33, line 26
standard ([SNIA-CDMI]). standard ([SNIA-CDMI]).
"The Cloud Data Management Interface defines the functional interface "The Cloud Data Management Interface defines the functional interface
that applications will use to create, retrieve, update and delete that applications will use to create, retrieve, update and delete
data elements from the Cloud. As part of this interface the client data elements from the Cloud. As part of this interface the client
will be able to discover the capabilities of the cloud storage will be able to discover the capabilities of the cloud storage
offering and use this interface to manage containers and the data offering and use this interface to manage containers and the data
that is placed in them. In addition, metadata can be set on that is placed in them. In addition, metadata can be set on
containers and their contained data elements through this interface." containers and their contained data elements through this interface."
B.2.12. Summary of existing stanardization work B.2.12. Summary of existing standardization work
The following sections will summarize the existing work of the The following sections will summarize the existing work of the
standard bodies listed earlier against the CDNI problem space. standard bodies listed earlier against the CDNI problem space.
Appendix B.2.12.1 summarizes existing interfaces that could be Appendix B.2.12.1 summarizes existing interfaces that could be
leveraged for content acquisition between CDNs and Appendix B.2.12.2 leveraged for content acquisition between CDNs and Appendix B.2.12.2
summarizes existing metadata specifications that may be applicable to summarizes existing metadata specifications that may be applicable to
CDNI. To date we are not aware of any standardization activities in CDNI. To date we are not aware of any standardization activities in
the areas of the remaining CDNI interfaces (CDNI Request Routing, the areas of the remaining CDNI interfaces (CDNI Request Routing,
CDNI Control and CDNI Logging). CDNI Control and CDNI Logging).
 End of changes. 22 change blocks. 
104 lines changed or deleted 188 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/