draft-ietf-cdni-framework-10.txt   draft-ietf-cdni-framework-11.txt 
Network Working Group L. Peterson Network Working Group L. Peterson
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Obsoletes: 3466 (if approved) B. Davie Obsoletes: 3466 (if approved) B. Davie
Intended status: Informational VMware, Inc. Intended status: Informational VMware, Inc.
Expires: September 4, 2014 R. van Brandenburg, Ed. Expires: November 6, 2014 R. van Brandenburg, Ed.
TNO TNO
March 3, 2014 May 5, 2014
Framework for CDN Interconnection Framework for CDN Interconnection
draft-ietf-cdni-framework-10 draft-ietf-cdni-framework-11
Abstract Abstract
This document presents a framework for Content Distribution Network This document presents a framework for Content Distribution Network
Interconnection (CDNI). The purpose of the framework is to provide Interconnection (CDNI). The purpose of the framework is to provide
an overall picture of the problem space of CDNI and to describe the an overall picture of the problem space of CDNI and to describe the
relationships among the various components necessary to interconnect relationships among the various components necessary to interconnect
CDNs. CDN Interconnection requires the specification of interfaces CDNs. CDN Interconnection requires the specification of interfaces
and mechanisms to address issues such as request routing, and mechanisms to address issues such as request routing,
distribution metadata exchange, and logging information exchange distribution metadata exchange, and logging information exchange
across CDNs. The intent of this document is to outline what each across CDNs. The intent of this document is to outline what each
interface needs to accomplish, and to describe how these interfaces interface needs to accomplish, and to describe how these interfaces
and mechanisms fit together, while leaving their detailed and mechanisms fit together, while leaving their detailed
specification to other documents. It obsoletes RFC 3466. specification to other documents. This document, in combination with
RFC 6707, obsoletes RFC 3466.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 4, 2014. This Internet-Draft will expire on November 6, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 4 1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 5
1.3. Structure Of This Document . . . . . . . . . . . . . . . 8 1.3. Structure Of This Document . . . . . . . . . . . . . . . 9
2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 8 2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 8 2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 9
2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 8 2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 9
2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . 9 2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . 11
3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . 10 3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . 11
3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Iterative HTTP Redirect Example . . . . . . . . . . . . . 13 3.2. Iterative HTTP Redirect Example . . . . . . . . . . . . . 14
3.3. Recursive HTTP Redirection Example . . . . . . . . . . . 18 3.3. Recursive HTTP Redirection Example . . . . . . . . . . . 19
3.4. Iterative DNS-based Redirection Example . . . . . . 22 3.4. Iterative DNS-based Redirection Example . . . . . . . . . 23
3.5. Dynamic Footprint Discovery Example . . . . . . . . . . . 25 3.4.1. Notes on using DNSSEC . . . . . . . . . . . . . . . . 27
3.6. Content Removal Example . . . . . . . . . . . . . . . . . 27 3.5. Dynamic Footprint Discovery Example . . . . . . . . . . . 28
3.7. Pre-Positioned Content Acquisition Example . . . . . . . 28 3.6. Content Removal Example . . . . . . . . . . . . . . . . . 30
3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . 29 3.7. Pre-Positioned Content Acquisition Example . . . . . . . 31
3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 31 3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . 32
3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 34
3.10. Content and Metadata Acquisition with Multiple Upstream 3.10. Content and Metadata Acquisition with Multiple Upstream
CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 34 4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 37
4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 35 4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 38
4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 35 4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 38
4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 36 4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 39
4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 37 4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 40
4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 39 4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 42
4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 39 4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 42
4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 40 4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 43
4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 42 4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 44
5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 43 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 45
5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 43 5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 46
5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 44 5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 47
5.3. CSP using CDNI Request Routing Interface . . . . . . . . 45 5.3. CSP using CDNI Request Routing Interface . . . . . . . . 47
5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 46 5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 48
6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 49 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 51
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
8. Security Considerations . . . . . . . . . . . . . . . . . . . 50 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 52
8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 51 9. Security Considerations . . . . . . . . . . . . . . . . . . . 53
8.2. Digital Rights Management . . . . . . . . . . . . . . . . 52 9.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 54
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 9.2. Digital Rights Management . . . . . . . . . . . . . . . . 54
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54
11. Informative References . . . . . . . . . . . . . . . . . . . 52 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 12. Informative References . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
This document provides an overview of the various components This document provides an overview of the various components
necessary to interconnect CDNs, expanding on the problem statement necessary to interconnect CDNs, expanding on the problem statement
and use cases introduced in [RFC6770] and [RFC6707]. It describes and use cases introduced in [RFC6770] and [RFC6707]. It describes
the necessary interfaces and mechanisms in general terms and outlines the necessary interfaces and mechanisms in general terms and outlines
how they fit together to form a complete system for CDN how they fit together to form a complete system for CDN
Interconnection. Detailed specifications are left to other Interconnection. Detailed specifications are left to other
documents. This document makes extensive use of message flow documents. This document makes extensive use of message flow
skipping to change at page 3, line 34 skipping to change at page 3, line 41
[RFC3466] uses different terminology and models for "Content [RFC3466] uses different terminology and models for "Content
Internetworking (CDI)". It is also less prescriptive in terms of Internetworking (CDI)". It is also less prescriptive in terms of
interfaces. To avoid confusion, this document obsoletes [RFC3466]. interfaces. To avoid confusion, this document obsoletes [RFC3466].
1.1. Terminology 1.1. Terminology
This document uses the core terminology defined in [RFC6707]. It This document uses the core terminology defined in [RFC6707]. It
also introduces the following terms: also introduces the following terms:
CDN-Domain: a host name (FQDN) at the beginning of a URL, CDN-Domain: a host name (FQDN) at the beginning of a URL (excluding
representing a set of content that is served by a given CDN. For port and scheme), representing a set of content that is served by a
example, in the URL http://cdn.csp.example/...rest of url..., the CDN given CDN. For example, in the URL http://cdn.csp.example/...rest of
domain is cdn.csp.example. A major role of CDN-Domain is to identify url..., the CDN domain is cdn.csp.example. A major role of CDN-
a region (subset) of the URI space relative to which various CDN Domain is to identify a region (subset) of the URI space relative to
Interconnection rules and policies are to apply. For example, a which various CDN Interconnection rules and policies are to apply.
record of CDN Metadata might be defined for the set of resources For example, a record of CDN Metadata might be defined for the set of
corresponding to some CDN-Domain. resources corresponding to some CDN-Domain.
Distinguished CDN-Domain: a CDN-Domain that is allocated by a CDN for Distinguished CDN-Domain: a CDN-Domain that is allocated by a CDN for
the purposes of communication with a peer CDN, but which is not found the purposes of communication with a peer CDN, but which is not found
in client requests. Such CDN-Domains may be used for inter-CDN in client requests. Such CDN-Domains may be used for inter-CDN
acquisition, or as redirection targets, and enable a CDN to acquisition, or as redirection targets, and enable a CDN to
distinguish a request from a peer CDN from an end-user request. distinguish a request from a peer CDN from an end-user request.
Delivering CDN: the CDN that ultimately delivers a piece of content Delivering CDN: the CDN that ultimately delivers a piece of content
to the end-user. The last in a potential sequence of downstream to the end-user. The last in a potential sequence of downstream
CDNs. CDNs.
skipping to change at page 4, line 45 skipping to change at page 5, line 5
delivery. delivery.
Trigger Interface: a subset of the CDNI Control interface that Trigger Interface: a subset of the CDNI Control interface that
includes operations to pre-position, revalidate, and purge both includes operations to pre-position, revalidate, and purge both
metadata and content. These operations are typically called in metadata and content. These operations are typically called in
response to some action (Trigger) by the CSP on the upstream CDN. response to some action (Trigger) by the CSP on the upstream CDN.
We also sometimes use uCDN and dCDN as shorthand for upstream CDN and We also sometimes use uCDN and dCDN as shorthand for upstream CDN and
downstream CDN, respectively. downstream CDN, respectively.
At various points in this document, the concept of a CDN footprint is
used. For a discussion on what constitutes a CDN footprint, the
reader is referred to
[I-D.ietf-cdni-footprint-capabilities-semantics].
1.2. Reference Model 1.2. Reference Model
This document uses the reference model in Figure 1, which expands the This document uses the reference model in Figure 1, which expands the
reference model originally defined in [RFC6707]. (The difference is reference model originally defined in [RFC6707]. (The difference is
that the expanded model splits the Request Routing Interface into its that the expanded model splits the Request Routing Interface into its
two distinct parts: the Request Routing Redirection interface and the two distinct parts: the Request Routing Redirection interface and the
Footprint and Capabilities Advertisement interface, as described Footprint and Capabilities Advertisement interface, as described
below.) below.)
-------- --------
/ \ / \
skipping to change at page 7, line 22 skipping to change at page 8, line 22
* Offline exchanges, suitable for analytics and billing. * Offline exchanges, suitable for analytics and billing.
The division between the sets of Trigger-based operations in the CDNI The division between the sets of Trigger-based operations in the CDNI
Control interface and the CDNI Metadata interface is somewhat Control interface and the CDNI Metadata interface is somewhat
arbitrary. For both cases, the information passed from the upstream arbitrary. For both cases, the information passed from the upstream
CDN to the downstream CDN can broadly be viewed as metadata that CDN to the downstream CDN can broadly be viewed as metadata that
describes how content is to be managed by the downstream CDN. For describes how content is to be managed by the downstream CDN. For
example, the information conveyed by CI to pre-position, revalidate example, the information conveyed by CI to pre-position, revalidate
or purge metadata is similar to the information conveyed by posting or purge metadata is similar to the information conveyed by posting
updated metadata via the MI. Even the CI operation to purge content updated metadata via the MI. Even the CI operation to purge content
could be viewed as an metadata update for that content: purge simply could be viewed as a metadata update for that content: purge simply
says that the availability window for the named content ends now. says that the availability window for the named content ends now.
The two interfaces share much in common, so minimally, there will The two interfaces share much in common, so minimally, there will
need to be a consistent data model that spans both. need to be a consistent data model that spans both.
The distinction we draw has to do with what the uCDN knows about the The distinction we draw has to do with what the uCDN knows about the
successful application of the metadata by the dCDN. In the case of successful application of the metadata by the dCDN. In the case of
the CI, the downstream CDN returning a successful status message the CI, the downstream CDN returning a successful status message
guarantees that the operation has been successfully completed; e.g., guarantees that the operation has been successfully completed; e.g.,
the content has been purged or pre-positioned. This implies that the the content has been purged or pre-positioned. This implies that the
downstream CDN accepts responsibility for having successfully downstream CDN accepts responsibility for having successfully
skipping to change at page 8, line 34 skipping to change at page 9, line 34
2. Building Blocks 2. Building Blocks
2.1. Request Redirection 2.1. Request Redirection
At its core, CDN Interconnection requires the redirection of requests At its core, CDN Interconnection requires the redirection of requests
from one CDN to another. For any given request that is received by from one CDN to another. For any given request that is received by
an upstream CDN, it will either respond to the request directly, or an upstream CDN, it will either respond to the request directly, or
somehow redirect the request to a downstream CDN. Two main somehow redirect the request to a downstream CDN. Two main
mechanisms are available for redirecting a request to a downstream mechanisms are available for redirecting a request to a downstream
CDN. The first leverages the DNS name resolution process and the CDN. The first leverages the DNS name resolution process and the
second uses in-protocol redirection mechanisms such as the HTTP 302 second uses application-layer redirection mechanisms such as the HTTP
or 307 redirection response. We discuss these below as background 302 or RTSP 302 redirection responses. While there exists a large
before discussing some examples of their use in Section 3. variety of application-layer protocols that include some form of
redirection mechanism, this document will use HTTP (and HTTPS) in its
examples. Similar mechanisms can be applied to other application-
layer protocols. What follows is a short discussion of both DNS- and
HTTP-based redirection, before presenting some examples of their use
in Section 3.
2.1.1. DNS Redirection 2.1.1. DNS Redirection
DNS redirection is based on returning different IP addresses for the DNS redirection is based on returning different IP addresses for the
same DNS name, for example, to balance server load or to account for same DNS name, for example, to balance server load or to account for
the client's location in the network. A DNS server, sometimes called the client's location in the network. A DNS server, sometimes called
the Local DNS (LDNS), resolves DNS names on behalf of an end-user. the Local DNS (LDNS), resolves DNS names on behalf of an end-user.
The LDNS server in turn queries other DNS servers until it reaches The LDNS server in turn queries other DNS servers until it reaches
the authoritative DNS server for the CDN-Domain. The network the authoritative DNS server for the CDN-Domain. The network
operator typically provides the LDNS server, although the user is operator typically provides the LDNS server, although the user is
skipping to change at page 9, line 36 skipping to change at page 10, line 40
In CNAME-based DNS redirection, the authoritative server returns a In CNAME-based DNS redirection, the authoritative server returns a
CNAME response to the DNS request, telling the LDNS server to restart CNAME response to the DNS request, telling the LDNS server to restart
the name lookup using a new name. A CNAME is essentially a symbolic the name lookup using a new name. A CNAME is essentially a symbolic
link in the DNS namespace, and like a symbolic link, redirection is link in the DNS namespace, and like a symbolic link, redirection is
transparent to the client; the LDNS server gets the CNAME response transparent to the client; the LDNS server gets the CNAME response
and re-executes the lookup. Only when the name has been resolved to and re-executes the lookup. Only when the name has been resolved to
an IP address does it return the result to the user. Note that DNAME an IP address does it return the result to the user. Note that DNAME
would be preferable to CNAME if it becomes widely supported. would be preferable to CNAME if it becomes widely supported.
One of the advantages of DNS redirection compared to HTTP redirection
is that it can be cached, reducing load on the redirecting CDN's DNS
server. However, this advantage can also be a drawback, especially
when a given DNS resolver doesn't strictly adhere to the TTL, which
is a known problem in some real world environments. In such cases,
an end-user might end up at a dCDN without first having passed
through the uCDN, which might be an undesirable scenario from a uCDN
point of view.
2.1.2. HTTP Redirection 2.1.2. HTTP Redirection
HTTP redirection makes use of the redirection response of the HTTP HTTP redirection makes use of the redirection response of the HTTP
protocol (e.g.,"302" or "307"). This response contains a new URL protocol (e.g.,"302" or "307"). This response contains a new URL
that the application should fetch instead of the original URL. By that the application should fetch instead of the original URL. By
changing the URL appropriately, the server can cause the user to changing the URL appropriately, the server can cause the user to
redirect to a different server. The advantages of HTTP redirection redirect to a different server. The advantages of HTTP redirection
are that (1) the server can change the URL fetched by the client to are that (1) the server can change the URL fetched by the client to
include, for example, both the DNS name of the particular server to include, for example, both the DNS name of the particular server to
use, as well as the original HTTP server that was being accessed; (2) use, as well as the original HTTP server that was being accessed; (2)
the client sends the HTTP request to the server, so that its IP the client sends the HTTP request to the server, so that its IP
address is known and can be used in selecting the server; and (3) address is known and can be used in selecting the server; and (3)
other attributes (e.g., content type, user agent type) are visible to other attributes (e.g., content type, user agent type) are visible to
the redirection mechanism. the redirection mechanism.
The disadvantages of HTTP redirection are (1) it is visible to the Just as is the case for DNS redirection, there are some potential
application, so it requires application support and may affect the disadvantages of using HTTP redirection. For example, it may affect
application behavior (e.g., web browsers will not send cookies if the application behavior, e.g. web browsers will not send cookies if the
URL changes to a different domain); (2) HTTP is a heavyweight URL changes to a different domain. In addition, although this might
protocol layered on TCP so it has relatively high overhead; and (3) also be an advantage, results of HTTP redirection are not cached so
the results of HTTP redirection are not cached so that all that all redirections must go through to the uCDN.
redirections must go through to the server.
3. Overview of CDNI Operation 3. Overview of CDNI Operation
To provide a big picture overview of the various components of CDN To provide a big picture overview of the various components of CDN
Interconnection, we walk through a "day in the life" of a content Interconnection, we walk through a "day in the life" of a content
item that is made available via a pair of interconnected CDNs. This item that is made available via a pair of interconnected CDNs. This
will serve to illustrate many of the functions that need to be will serve to illustrate many of the functions that need to be
supported in a complete CDNI solution. We give examples using both supported in a complete CDNI solution. We give examples using both
DNS-based and HTTP-based redirection. We begin with very simple DNS-based and HTTP-based redirection. We begin with very simple
examples and then how additional capabilities, such as recursive examples and then show how additional capabilities, such as recursive
request redirection and content removal, might be added. request redirection and content removal, might be added.
Before walking through some specific examples, we present a high- Before walking through the specific examples, we present a high-level
level view of the operations that may take place. This high-level view of the operations that may take place. This high-level overview
overview is illustrated in Figure 2. Note that most operations will is illustrated in Figure 2. Note that most operations will involve
involve only a subset of all the messages shown below, and that the only a subset of all the messages shown below, and that the order and
order and number of operations may vary considerably, as more number of operations may vary considerably, as the more detailed
detailed examples illustrate below. examples illustrate.
The following shows Operator A as the upstream CDN (uCDN) and The following shows Operator A as the upstream CDN (uCDN) and
Operator B as the downstream CDN (dCDN), where the former has a Operator B as the downstream CDN (dCDN), where the former has a
relationship with a content provider and the latter being the CDN relationship with a content provider and the latter being the CDN
selected by Operator A to deliver content to the end-user. The selected by Operator A to deliver content to the end-user. The
interconnection relationship may be symmetric between these two CDN interconnection relationship may be symmetric between these two CDN
operators, but each direction can be considered as operating operators, but each direction can be considered as operating
independently of the other so for simplicity we show the interaction independently of the other so for simplicity we show the interaction
in one direction only. in one direction only.
skipping to change at page 17, line 35 skipping to change at page 18, line 35
it is DNS or HTTP based). it is DNS or HTTP based).
One disadvantage is that the end-user's browser is redirected to a One disadvantage is that the end-user's browser is redirected to a
new URL that is not in the same domain of the original URL. This has new URL that is not in the same domain of the original URL. This has
implications on a number of security or validation mechanisms implications on a number of security or validation mechanisms
sometimes used on endpoints. For example, it is important that any sometimes used on endpoints. For example, it is important that any
redirected URL be in the same domain (e.g., csp.example) if the redirected URL be in the same domain (e.g., csp.example) if the
browser is expected to send any cookies associated with that domain. browser is expected to send any cookies associated with that domain.
As another example, some video players enforce validation of a cross As another example, some video players enforce validation of a cross
domain policy that needs to accommodate the domains involved in the domain policy that needs to accommodate the domains involved in the
CDN redirection. These problems are generally soluble, but the CDN redirection. These problems are generally solvable, but the
solutions complicate the example, so we do not discuss them further solutions complicate the example, so we do not discuss them further
in this version of the draft. in this document.
We note that this example begins to illustrate some of the interfaces We note that this example begins to illustrate some of the interfaces
that may be required for CDNI, but does not require all of them. For that may be required for CDNI, but does not require all of them. For
example, obtaining information from dCDN regarding the set of client example, obtaining information from dCDN regarding the set of client
IP addresses or geographic regions it might be able to serve is an IP addresses or geographic regions it might be able to serve is an
aspect of request routing (specifically of the CDNI Footprint & aspect of request routing (specifically of the CDNI Footprint &
Capabilities Advertisement interface). Important configuration Capabilities Advertisement interface). Important configuration
information such as the distinguished names used for redirection and information such as the distinguished names used for redirection and
inter-CDN acquisition could also be conveyed via a CDNI interface inter-CDN acquisition could also be conveyed via a CDNI interface
(e.g., perhaps the CDNI Control interface). The example also shows (e.g., perhaps the CDNI Control interface). The example also shows
skipping to change at page 18, line 31 skipping to change at page 19, line 31
performs the rest of the redirection function by redirecting to a performs the rest of the redirection function by redirecting to a
suitable surrogate. If request routing is performed in the dCDN suitable surrogate. If request routing is performed in the dCDN
using HTTP redirection, this translates in the end-user experiencing using HTTP redirection, this translates in the end-user experiencing
two successive HTTP redirections. By contrast, the alternative two successive HTTP redirections. By contrast, the alternative
approach of "recursive" CDNI request redirection effectively approach of "recursive" CDNI request redirection effectively
coalesces these two successive HTTP redirections into a single one, coalesces these two successive HTTP redirections into a single one,
sending the end-user directly to the right delivery node in the dCDN. sending the end-user directly to the right delivery node in the dCDN.
This "recursive" CDNI request routing approach is discussed in the This "recursive" CDNI request routing approach is discussed in the
next section. next section.
While the example above uses HTTP, the iterative HTTP redirection
mechanism would work over HTTPS in a similar fashion. In order to
make sure an end-user's HTTPS request is not downgraded to HTTP along
the redirection path, it is necessary for every request router along
the path from the initial uCDN Request Router to the final surrogate
in the dCDN to respond to an incoming HTTPS request with an HTTP
Redirect containing an HTTPS URL. It should be noted that using
HTTPS will have the effect of increasing the total redirection
process time and increasing the load on the request routers,
especially when the redirection path includes many redirects and thus
many TLS/SSL sessions. In such cases, a recursive HTTP redirection
mechanism, as described in an example in the next section, might help
to reduce some of these issues.
3.3. Recursive HTTP Redirection Example 3.3. Recursive HTTP Redirection Example
The following example builds on the previous one to illustrate the The following example builds on the previous one to illustrate the
use of the request routing interface (specifically the CDNI Request use of the request routing interface (specifically the CDNI Request
Routing Redirection interface) to enable "recursive" CDNI request Routing Redirection interface) to enable "recursive" CDNI request
routing. We build on the HTTP-based redirection approach because it routing. We build on the HTTP-based redirection approach because it
illustrates the principles and benefits clearly, but it is equally illustrates the principles and benefits clearly, but it is equally
possible to perform recursive redirection when DNS-based redirection possible to perform recursive redirection when DNS-based redirection
is employed. is employed.
skipping to change at page 23, line 25 skipping to change at page 25, line 10
Figure 5 depicts the exchange of DNS and HTTP requests. The main Figure 5 depicts the exchange of DNS and HTTP requests. The main
differences from Figure 3 are the lack of HTTP redirection and differences from Figure 3 are the lack of HTTP redirection and
transparency to the end-user. transparency to the end-user.
End-User Operator B Operator A End-User Operator B Operator A
|DNS cdn.csp.example | | |DNS cdn.csp.example | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(1) | | |(1)
|CNAME b.cdn.csp.example | | |CNAME b.cdn.csp.example | |
|NS records for b.cdn.csp.example |
|<--------------------------------------------------| |<--------------------------------------------------|
| | |
|DNS b.cdn.csp.example | |
|-------------------------------------------------->|
| | |(2)
|NS records for b.cdn.csp.example + |
|Glue AAAA/A records for b.cdn.csp.example |
|<--------------------------------------------------|
| | |
|DNS b.cdn.csp.example | | |DNS b.cdn.csp.example | |
|------------------------>| | |------------------------>| |
| |(2) | | |(3) |
|IPaddr of B's Delivery Node | |IPaddr of B's Delivery Node |
|<------------------------| | |<------------------------| |
|HTTP cdn.csp.example | | |HTTP cdn.csp.example | |
|------------------------>| | |------------------------>| |
| |(3) | | |(4) |
| |DNS op-b-acq.op-a.example| | |DNS op-b-acq.op-a.example|
| |------------------------>| | |------------------------>|
| | |(4) | | |(5)
| |IPaddr of A's Delivery Node | |IPaddr of A's Delivery Node
| |<------------------------| | |<------------------------|
| |HTTP op-b-acq.op-a.example | |HTTP op-b-acq.op-a.example
| |------------------------>| | |------------------------>|
| | |(5) | | |(6)
| |Data | | |Data |
| |<------------------------| | |<------------------------|
|Data | | |Data | |
|<------------------------| | |<------------------------| |
Figure 5: Message Flow for DNS-based Redirection Figure 5: Message Flow for DNS-based Redirection
The steps illustrated in the figure are as follows: The steps illustrated in the figure are as follows:
1. Request Router for Operator A processes the DNS request for CDN- 1. Request Router for Operator A processes the DNS request for CDN-
Domain cdn.csp.example and recognizes that the end-user is best Domain cdn.csp.example and recognizes that the end-user is best
served by another CDN. (This may depend on the IP address of the served by another CDN. (This may depend on the IP address of the
user's local DNS resolver, or other information discussed below.) user's local DNS resolver, or other information discussed below.)
The Request Router returns a DNS CNAME response by "stacking" the The Request Router returns a DNS CNAME response by "stacking" the
distinguished identifier for Operator B onto the original CDN- distinguished identifier for Operator B onto the original CDN-
Domain (e.g., b.cdn.csp.example), plus an NS record that maps Domain (e.g., b.cdn.csp.example).
b.cdn.csp.example to B's Request Router.
2. The end-user does a DNS lookup using the modified CDN-Domain 2. The end-user sends a DNS query for the modified CDN-Domain (i.e.
(i.e., b.cdn.csp.example). This causes B's Request Router to b.cdn.csp.example) to Operator A's DNS server. The Request
respond with a suitable delivery node. Router for Operator A processes the DNS request and return a
delegation to b.cdn.csp.example by sending an NS record plus glue
AAAA/A records pointing to Operator B's DNS server. (This extra
step is necessary since typical DNS implementation won't follow
an NS record when it is sent together with a CNAME record,
thereby necessitating a two-step approach).
3. The end-user requests the content from B's delivery node. The 3. The end-user sends a DNS query for the modified CDN-Domain (i.e.,
b.cdn.csp.example) to Operator B's DNS server, using the NS and
AAAA/A records received in step 2. This causes B's Request
Router to respond with a suitable delivery node.
4. The end-user requests the content from B's delivery node. The
requested URL contains the name cdn.csp.example. (Note that the requested URL contains the name cdn.csp.example. (Note that the
returned CNAME does not affect the URL.) At this point the returned CNAME does not affect the URL.) At this point the
delivery node has the correct IP address of the end-user and can delivery node has the correct IP address of the end-user and can
do an HTTP 302 redirect if the redirections in steps 2 and 3 were do an HTTP 302 redirect if the redirections in steps 2 and 3 were
incorrect. Otherwise B verifies that this CDN-Domain belongs to incorrect. Otherwise B verifies that this CDN-Domain belongs to
a known peer (so as to avoid being tricked into serving as an a known peer (so as to avoid being tricked into serving as an
open proxy). It then does a DNS request for an "internal" CDN- open proxy). It then does a DNS request for an "internal" CDN-
Domain as agreed above (op-b-acq.op-a.example). Domain as agreed above (op-b-acq.op-a.example).
4. Operator A recognizes that the DNS request is from a peer CDN 5. Operator A recognizes that the DNS request is from a peer CDN
rather than an end-user (due to the internal CDN-Domain) and so rather than an end-user (due to the internal CDN-Domain) and so
returns the address of a delivery node in uCDN. returns the address of a delivery node in uCDN.
5. Operator A serves content to dCDN. Although not shown, it is at 6. Operator A serves content to dCDN. Although not shown, it is at
this point that Operator A processes the rest of the URL: it this point that Operator A processes the rest of the URL: it
extracts information identifying the origin server, validates extracts information identifying the origin server, validates
that this server has been registered, and determines the content that this server has been registered, and determines the content
provider that owns the origin server. provider that owns the origin server.
The advantages of this approach are that it is more transparent to The advantages of this approach are that it is more transparent to
the end-user and requires fewer round trips than HTTP-based the end-user and requires fewer round trips than HTTP-based
redirection (in its worst case, i.e., when none of the needed DNS redirection (in its worst case, i.e., when none of the needed DNS
information is cached). A potential problem is that the upstream CDN information is cached). A potential problem is that the upstream CDN
depends on being able to learn the correct downstream CDN that serves depends on being able to learn the correct downstream CDN that serves
skipping to change at page 25, line 8 skipping to change at page 27, line 9
user uses a global DNS service--then the upstream CDN cannot user uses a global DNS service--then the upstream CDN cannot
determine the appropriate downstream CDN to serve the end-user. In determine the appropriate downstream CDN to serve the end-user. In
this case, and assuming the uCDN is capable of detecting that this case, and assuming the uCDN is capable of detecting that
situation, one option is for the upstream CDN to treat the end-user situation, one option is for the upstream CDN to treat the end-user
as it would any user not connected to a peer CDN. Another option is as it would any user not connected to a peer CDN. Another option is
for the upstream CDN to "fall back" to a pure HTTP-based redirection for the upstream CDN to "fall back" to a pure HTTP-based redirection
strategy in this case (i.e., use the first method). Note that this strategy in this case (i.e., use the first method). Note that this
problem affects existing CDNs that rely on DNS to determine where to problem affects existing CDNs that rely on DNS to determine where to
redirect client requests, but the consequences are arguably less redirect client requests, but the consequences are arguably less
serious for CDNI since the LDNS is likely in the same network as the serious for CDNI since the LDNS is likely in the same network as the
dCDN serves. One approach to ensuring that the client's IP address dCDN serves.
prefix is correctly determined in such situations is described in
[I-D.vandergaast-edns-client-subnet].
As with the prior example, this example partially illustrates the As with the prior example, this example partially illustrates the
various interfaces involved in CDNI. Operator A could learn various interfaces involved in CDNI. Operator A could learn
dynamically from Operator B the set of prefixes or regions that B is dynamically from Operator B the set of prefixes or regions that B is
willing and able to serve via the CDNI Footprint & Capabilities willing and able to serve via the CDNI Footprint & Capabilities
Advertisement interface. The distinguished name used for acquisition Advertisement interface. The distinguished name used for acquisition
and the identifier for Operator B that is prepended to the CDN-Domain and the identifier for Operator B that is prepended to the CDN-Domain
on redirection are examples of information elements that might also on redirection are examples of information elements that might also
be conveyed by CDNI interfaces (or, alternatively, statically be conveyed by CDNI interfaces (or, alternatively, statically
configured). As before, minimal metadata sufficient to obtain the configured). As before, minimal metadata sufficient to obtain the
content is carried "in-band" as part of the redirection process, and content is carried "in-band" as part of the redirection process, and
standard HTTP is used for inter-CDN acquisition. There is no standard HTTP is used for inter-CDN acquisition. There is no
explicit CDNI Logging interface discussed in this example. explicit CDNI Logging interface discussed in this example.
3.4.1. Notes on using DNSSEC
Although it is possible to use DNSSEC in combination with the
Iterative DNS-based Redirection mechanism explained above, it is
important to note that the uCDN might have to sign records on the
fly, since the CNAME returned, and thus the signature provided, can
potentially be different for each incoming query. Although there is
nothing preventing a uCDN from performing such on-the-fly signing,
this might be computationally expensive. In the case where the
number of dCDNs, and thus the number of different CNAMEs to return,
is relatively stable, an alternative solution would be for the uCDN
to pre-generate signatures for all possible CNAMEs. For each
incoming query the uCDN would then determine the appropriate CNAME
and return it together with the associated pre-generated signature.
Note: In the latter case maintaining the serial and signature of SOA
might be an issue since technically it should change every time a
different CNAME is used. However, since in practice direct SOA
queries are relatively rare, a uCDN could defer incrementing the
serial and resigning the SOA until it is queried and then do it on-
the-fly.
Note also that the NS record and the glue AAAA/A records used in step
2 in the previous section should generally be identical to those of
their authoritative zone managed by Operator B. Even if they differ,
this will not make the DNS resolution process fail, but the client
DNS server will prefer the authoritative data in its cache and use it
for subsequent queries. Such inconsistency is a general operational
issue of DNS, but it may be more important for this architecture
because the uCDN (operator A) would rely on the consistency to make
the resulting redirection work as intended. In general, it is the
administrator's responsibility to make them consistent.
3.5. Dynamic Footprint Discovery Example 3.5. Dynamic Footprint Discovery Example
There could be situations where being able to dynamically discover There could be situations where being able to dynamically discover
the set of requests that a given dCDN is willing and able to serve is the set of requests that a given dCDN is willing and able to serve is
beneficial. For example, a CDN might at one time be able to serve a beneficial. For example, a CDN might at one time be able to serve a
certain set of client IP prefixes, but that set might change over certain set of client IP prefixes, but that set might change over
time due to changes in the topology and routing policies of the IP time due to changes in the topology and routing policies of the IP
network. The following example illustrates this capability. We have network. The following example illustrates this capability. We have
chosen the example of DNS-based redirection, but HTTP-based chosen the example of DNS-based redirection, but HTTP-based
redirection could equally well use this approach. redirection could equally well use this approach.
skipping to change at page 35, line 8 skipping to change at page 38, line 8
One interface that is not shown in Figure 1 is the interface between One interface that is not shown in Figure 1 is the interface between
the user and the CSP. While for the purposes of CDNI that interface the user and the CSP. While for the purposes of CDNI that interface
is out of scope, it is worth noting that it does exist and can is out of scope, it is worth noting that it does exist and can
provide useful functions, such as end-to-end performance monitoring provide useful functions, such as end-to-end performance monitoring
and some forms of authentication and authorization. and some forms of authentication and authorization.
There is also an important interface between the user and the Request There is also an important interface between the user and the Request
Routing function of both uCDN and dCDN (shown as the "Request" Routing function of both uCDN and dCDN (shown as the "Request"
Interface in Figure 1). As we saw in some of the preceding examples, Interface in Figure 1). As we saw in some of the preceding examples,
that interface can be used as a way of passing information a subset that interface can be used as a way of passing metadata, such as the
of metadata such as the minimum information that is required for dCDN minimum information that is required for dCDN to obtain the content
to obtain the content from uCDN. from uCDN.
In this section we will provide an overview of the functions In this section we will provide an overview of the functions
performed by each of the CDNI interfaces and discuss how they fit performed by each of the CDNI interfaces and discuss how they fit
into the overall solution. We also examine some of the design into the overall solution. We also examine some of the design
tradeoffs, and explore several cross-interface concerns. We begin tradeoffs, and explore several cross-interface concerns. We begin
with an examination of one such tradeoff that affects all the with an examination of one such tradeoff that affects all the
interfaces - the use of in-band or out-of-band communication. interfaces - the use of in-band or out-of-band communication.
4.1. In-Band versus Out-of-Band Interfaces 4.1. In-Band versus Out-of-Band Interfaces
skipping to change at page 38, line 14 skipping to change at page 41, line 14
o Bytes Sent - the number of bytes in the body sent to the client o Bytes Sent - the number of bytes in the body sent to the client
o Request ID - a unique identifier for this transfer o Request ID - a unique identifier for this transfer
o User agent - the user agent, if supplied o User agent - the user agent, if supplied
o Duration - the duration of the transfer in milliseconds o Duration - the duration of the transfer in milliseconds
o Cached Bytes - the number of body bytes served from the cache o Cached Bytes - the number of body bytes served from the cache
o Referrer - the referrer string from the client, if supplied o Referer - the referrer string from the client, if supplied
Of these, only the Domain field is indirect in the downstream CDN--it Of these, only the Domain field is indirect in the downstream CDN--it
is set to the CDN-Domain used by the upstream CDN rather than the is set to the CDN-Domain used by the upstream CDN rather than the
actual origin server. This field could then used to filter traffic actual origin server. This field could then used to filter traffic
log entries so only those entries matching the upstream CDN are log entries so only those entries matching the upstream CDN are
reported to the corresponding operator. Further discussion of the LI reported to the corresponding operator. Further discussion of the LI
can be found in [I-D.ietf-cdni-logging]. can be found in [I-D.ietf-cdni-logging].
One open question is who does the filtering. One option is that the One open question is who does the filtering. One option is that the
downstream CDN filters its own logs, and passes the relevant records downstream CDN filters its own logs, and passes the relevant records
skipping to change at page 40, line 12 skipping to change at page 43, line 12
time window or inability to make use of a downstream CDN that covers time window or inability to make use of a downstream CDN that covers
a broader footprint than the geo-blocking restrictions. a broader footprint than the geo-blocking restrictions.
Similarly, some forms of access control may also be performed on a Similarly, some forms of access control may also be performed on a
per-request basis using HTTP directives. For example, being able to per-request basis using HTTP directives. For example, being able to
respond to a conditional GET request gives the upstream CDN an respond to a conditional GET request gives the upstream CDN an
opportunity to influence how the downstream CDN delivers its content. opportunity to influence how the downstream CDN delivers its content.
Minimally, the upstream CDN can invalidate (purge) content previously Minimally, the upstream CDN can invalidate (purge) content previously
cached by the downstream CDN. cached by the downstream CDN.
Fine-grain control over how the downstream CDN delivers content on
behalf of the upstream CDN is also possible. For example, by
including the Forwarded HTTP header [I-D.ietf-appsawg-http-forwarded]
with the conditional GET request, the downstream CDN can report the
end-user's IP address to the upstream CDN, giving it an opportunity
to control whether the downstream CDN should serve the content to
this particular end-user. The upstream CDN would communicate its
directive through its response to the conditional GET. The
downstream CDN can cache information for a period of time specified
by the upstream CDN, thereby reducing control overhead, but then
preventing per-request control during the corresponding caching
period.
All of these in-band techniques serve to illustrate that uCDNs have All of these in-band techniques serve to illustrate that uCDNs have
the option of enforcing some of their access control policies the option of enforcing some of their access control policies
themselves (at the expense of increased inter-CDN signaling load), themselves (at the expense of increased inter-CDN signaling load),
rather than delegating enforcement to dCDNs using the MI. As a rather than delegating enforcement to dCDNs using the MI. As a
consequence, the MI could provide a means for the uCDN to express its consequence, the MI could provide a means for the uCDN to express its
desire to retain enforcement for itself. For example, this might be desire to retain enforcement for itself. For example, this might be
done by including a "check with me" flag in the metadata associated done by including a "check with me" flag in the metadata associated
with certain content. The realization of such in-band techniques with certain content. The realization of such in-band techniques
over the various inter-CDN acquisition protocols (e.g., HTTP) over the various inter-CDN acquisition protocols (e.g., HTTP)
requires further investigation and may require small extensions or requires further investigation and may require small extensions or
skipping to change at page 42, line 13 skipping to change at page 44, line 48
alternatively, they may remain distinct. alternatively, they may remain distinct.
4.8. URI Rewriting 4.8. URI Rewriting
When using HTTP redirection, content URIs may be rewritten when When using HTTP redirection, content URIs may be rewritten when
redirection takes place within an uCDN, from an uCDN to a dCDN, and redirection takes place within an uCDN, from an uCDN to a dCDN, and
within the dCDN. In the case of cascaded CDNs, content URIs may be within the dCDN. In the case of cascaded CDNs, content URIs may be
rewritten at every CDN hop (e.g., between the uCDN and the dCDN rewritten at every CDN hop (e.g., between the uCDN and the dCDN
acting as the transit CDN, and between the transit CDN and the dCDN acting as the transit CDN, and between the transit CDN and the dCDN
serving the request. The content URI used between any uCDN/dCDN pair serving the request. The content URI used between any uCDN/dCDN pair
becomes a common handle that can be referred without ambiguity by becomes a common handle that can be referred to without ambiguity by
both CDNs in all their inter-CDN communications. This handle allows both CDNs in all their inter-CDN communications. This handle allows
the uCDN and dCDN to correlate information exchanged using other CDNI the uCDN and dCDN to correlate information exchanged using other CDNI
interfaces in both the downstream direction (e.g., when using the MI) interfaces in both the downstream direction (e.g., when using the MI)
and the upstream direction (e.g., when using the LI). and the upstream direction (e.g., when using the LI).
Consider the simple case of a single uCDN/dCDN pair using HTTP Consider the simple case of a single uCDN/dCDN pair using HTTP
redirection. We introduce the following terminology for content URIs redirection. We introduce the following terminology for content URIs
to simplify the discussion: to simplify the discussion:
"u-URI" represents a content URI in a request presented to the "u-URI" represents a content URI in a request presented to the
skipping to change at page 42, line 39 skipping to change at page 45, line 27
"d-URI" represents a content URI in a request made within the "d-URI" represents a content URI in a request made within the
delegate dCDN. delegate dCDN.
In our simple pair-wise example, the "ud-URI" effectively becomes the In our simple pair-wise example, the "ud-URI" effectively becomes the
handle that the uCDN/dCDN pair use to correlate all CDNI information. handle that the uCDN/dCDN pair use to correlate all CDNI information.
In particular, for a given pair of CDNs executing the HTTP In particular, for a given pair of CDNs executing the HTTP
redirection, the uCDN needs to map the u-URI to the ud-URI handle for redirection, the uCDN needs to map the u-URI to the ud-URI handle for
all MI message exchanges, while the dCDN needs to map the d-URI to all MI message exchanges, while the dCDN needs to map the d-URI to
the ud-URI handle for all LI message exchanges. the ud-URI handle for all LI message exchanges.
In the case of a cascaded CDNs, the transit CDN will rewrite the In the case of cascaded CDNs, the transit CDN will rewrite the
content URI when redirecting to the dCDN, thereby establishing a new content URI when redirecting to the dCDN, thereby establishing a new
handle between the transit CDN and the dCDN, that is different from handle between the transit CDN and the dCDN, that is different from
the handle between the uCDN and transit CDN. It is the the handle between the uCDN and transit CDN. It is the
responsibility of the transit CDN to manage its mapping across responsibility of the transit CDN to manage its mapping across
handles so the right handle for all pairs of CDNs is always used in handles so the right handle for all pairs of CDNs is always used in
its CDNI communication. its CDNI communication.
In summary, all CDNI interfaces between a given pair of CDNs need to In summary, all CDNI interfaces between a given pair of CDNs need to
always use the "ud-URI" handle for that specific CDN pair as their always use the "ud-URI" handle for that specific CDN pair as their
content URI reference. content URI reference.
skipping to change at page 47, line 24 skipping to change at page 49, line 32
Figure 14, we observe that in this example: Figure 14, we observe that in this example:
o each CDN supports a direct CDNI Control interface to every other o each CDN supports a direct CDNI Control interface to every other
CDN CDN
o each CDN supports a direct CDNI Metadata interface to every other o each CDN supports a direct CDNI Metadata interface to every other
CDN CDN
o each CDN supports a CDNI Logging interface with the CDN Exchange o each CDN supports a CDNI Logging interface with the CDN Exchange
o each CDN supports both a CDNI Request Routing interfaces with the o each CDN supports both a CDNI Request Routing interface with the
CDN Exchange (for aggregation and redistribution of dynamic CDN CDN Exchange (for aggregation and redistribution of dynamic CDN
footprint discovery information) and a direct RI to every other footprint discovery information) and a direct RI to every other
CDN (for actual request redirection). CDN (for actual request redirection).
---------- --------- ---------- ---------
/ CDN A \ / CDN B \ / CDN A \ / CDN B \
| +----+ | | +----+ | | +----+ | | +----+ |
//========>| C |<==============CDNI============>| C |<==========\\ //========>| C |<==============CDNI============>| C |<==========\\
|| | +----+ | C | +----+ | || || | +----+ | C | +----+ | ||
|| | +----+ | | +----+ | || || | +----+ | | +----+ | ||
skipping to change at page 50, line 41 skipping to change at page 52, line 41
We expect that the detailed designs for the specific interfaces for We expect that the detailed designs for the specific interfaces for
CDNI will need to take the transitive trust issues into account. For CDNI will need to take the transitive trust issues into account. For
example, explicit confirmation that some action (such as content example, explicit confirmation that some action (such as content
removal) has taken place in a downstream CDN may help to mitigate removal) has taken place in a downstream CDN may help to mitigate
some issues of transitive trust. some issues of transitive trust.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. Privacy Considerations
While there is a variety of security issues introduced by a single 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 which 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.
9. Security Considerations
While there are a variety of security issues introduced by a single
CDN, we are concerned here specifically with the additional issues CDN, we are concerned here specifically with the additional issues
that arise when CDNs are interconnected. For example, when a single that arise when CDNs are interconnected. For example, when a single
CDN has the ability to distribute content on behalf of a CSP, there 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 may be concerns that such content could be distributed to parties who
are not authorized to receive it, and there are mechanisms to deal are not authorized to receive it, and there are mechanisms to deal
with such concerns. Our focus in this section is on how CDN with such concerns. Our focus in this section is on how CDN
interconnection introduces new security issues not found in the interconnection introduces new security issues not found in the
single CDN case. single CDN case. For a more detailed analysis of the security
requirements of CDNI, see section 9 of [I-D.ietf-cdni-requirements].
Many of the security issues that arise in CDNI are related to the Many of the security issues that arise in CDNI are related to the
transitivity of trust (or lack thereof) described in Section 6. As transitivity of trust (or lack thereof) described in Section 6. As
noted above, the design of the various interfaces for CDNI must take 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 account of the additional risks posed by the fact that a CDN with
whom a CSP has no direct relationship is now potentially distributing whom a CSP has no direct relationship is now potentially distributing
content for that CSP. The mechanisms used to mitigate these risks content for that CSP. The mechanisms used to mitigate these risks
may be similar to those used in the single CDN case, but their may be similar to those used in the single CDN case, but their
suitability in this more complex environment must be validated. suitability in this more complex environment must be validated.
Another concern that arises in any CDN is that information about the
behavior of users (what content they access, how much content they
consume, etc.) may be gathered by the CDN. This risk certainly
exists in inter-connected CDNs, but it should be possible to apply
the same techniques to mitigate it as in the single CDN case.
CDNs today offer a variety of means to control access to content, CDNs today offer a variety of means to control access to content,
such as time-of-day restrictions, geo-blocking, and URI signing. such as time-of-day restrictions, geo-blocking, and URI signing.
These mechanisms must continue to function in CDNI environments, and These mechanisms must continue to function in CDNI environments, and
this consideration is likely to affect the design of certain CDNI this consideration is likely to affect the design of certain CDNI
interfaces (e.g. metadata, request routing.) interfaces (e.g. metadata, request routing). For more information on
URI signing in CDNI, see [I-D.leung-cdni-uri-signing].
Just as with a single CDN, each peer CDN must ensure that it is not 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 used as an "open proxy" to deliver content on behalf of a malicious
CSP. Whereas a single CDN typically addresses this problem by having CSP. Whereas a single CDN typically addresses this problem by having
CSPs explicitly register content (or origin servers) that is to be CSPs explicitly register content (or origin servers) that are to be
served, simply propagating this information to peer downstream CDNs served, simply propagating this information to peer downstream CDNs
may be problematic because it reveals more information than the may be problematic because it reveals more information than the
upstream CDN is willing to specify. (To this end, the content upstream CDN is willing to specify. (To this end, the content
acquisition step in the earlier examples force the dCDN to retrieve acquisition step in the earlier examples force the dCDN to retrieve
content from the uCDN rather than go directly to the origin server.) 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 There are several approaches to this problem. One is for the uCDN to
encoded a signed token generated from a shared secret in each URL 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 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 this token. Another one is to have each upstream CDN advertise the
set of CDN-Domains they serve, where the downstream CDN checks each set of CDN-Domains they serve, where the downstream CDN checks each
request against this set before caching and delivering the associated request against this set before caching and delivering the associated
object. Although straightforward, this approach requires operators object. Although straightforward, this approach requires operators
to reveal additional information, which may or may not be an issue. to reveal additional information, which may or may not be an issue.
8.1. Security of CDNI Interfaces 9.1. Security of CDNI Interfaces
It is noted in [I-D.ietf-cdni-requirements] that all CDNI interfaces It is noted in [I-D.ietf-cdni-requirements] that all CDNI interfaces
must be able to operate securely over insecure IP networks. Since it must be able to operate securely over insecure IP networks. Since it
is expected that the CDNI interfaces will be implemented using is expected that the CDNI interfaces will be implemented using
existing application protocols such as HTTP or XMPP, we also expect existing application protocols such as HTTP or XMPP, we also expect
that the security mechanisms available to those protocols may be used that the security mechanisms available to those protocols may be used
by the CDNI interfaces. Details of how these interfaces are secured by the CDNI interfaces. Details of how these interfaces are secured
will be specified in the relevant interface documents. will be specified in the relevant interface documents.
8.2. Digital Rights Management 9.2. Digital Rights Management
Issues of digital rights management (DRM, also sometimes called Issues of digital rights management (DRM, also sometimes called
digital restrictions management) is often employed for content digital restrictions management) is often employed for content
distributed via CDNs. In general, DRM relies on the CDN to distributed via CDNs. In general, DRM relies on the CDN to
distribute encrypted content, with decryption keys distributed to distribute encrypted content, with decryption keys distributed to
users by some other means (e.g. directly from the CSP to the end 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 user.) For this reason, DRM is considered out of scope [RFC6707] and
does not introduce additional security issues for CDNI. does not introduce additional security issues for CDNI.
9. Contributors 10. Contributors
The following individuals contributed to this document: The following individuals contributed to this document:
o Ray van Brandenburg
o Matt Caulfield o Matt Caulfield
o Francois le Faucheur o Francois le Faucheur
o Aaron Falk o Aaron Falk
o David Ferguson o David Ferguson
o John Hartman o John Hartman
o Ben Niven-Jenkins o Ben Niven-Jenkins
o Kent Leung o Kent Leung
10. Acknowledgements 11. Acknowledgements
We thank Huw Jones for helpful input to the draft.
11. Informative References 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.
[I-D.ietf-appsawg-http-forwarded] 12. Informative References
Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
draft-ietf-appsawg-http-forwarded-10 (work in progress),
October 2012.
[I-D.ietf-cdni-control-triggers] [I-D.ietf-cdni-control-triggers]
Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / Murray, R. and B. Niven-Jenkins, "CDNI Control Interface /
Triggers", draft-ietf-cdni-control-triggers-02 (work in Triggers", draft-ietf-cdni-control-triggers-02 (work in
progress), December 2013. progress), December 2013.
[I-D.ietf-cdni-footprint-capabilities-semantics] [I-D.ietf-cdni-footprint-capabilities-semantics]
Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R.,
and K. Ma, "CDNI Request Routing: Footprint and and K. Ma, "CDNI Request Routing: Footprint and
Capabilities Semantics", draft-ietf-cdni-footprint- Capabilities Semantics", draft-ietf-cdni-footprint-
capabilities-semantics-02 (work in progress), February capabilities-semantics-02 (work in progress), February
2014. 2014.
[I-D.ietf-cdni-logging] [I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R. Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-09 (work in progress), February 2014. logging-11 (work in progress), March 2014.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M.,
Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- Leung, K., and K. Ma, "CDN Interconnect Metadata", draft-
ietf-cdni-metadata-06 (work in progress), February 2014. ietf-cdni-metadata-06 (work in progress), February 2014.
[I-D.ietf-cdni-redirection] [I-D.ietf-cdni-redirection]
Danhua, W., Niven-Jenkins, B., He, X., Chen, G., and W. Niven-Jenkins, B. and R. Brandenburg, "Request Routing
Ni, "Request Routing Redirection Interface for CDN Redirection Interface for CDN Interconnection", draft-
Interconnection", draft-ietf-cdni-redirection-01 (work in ietf-cdni-redirection-02 (work in progress), April 2014.
progress), October 2013.
[I-D.ietf-cdni-requirements] [I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", draft-ietf-cdni- Interconnection (CDNI) Requirements", draft-ietf-cdni-
requirements-17 (work in progress), January 2014. requirements-17 (work in progress), January 2014.
[I-D.vandergaast-edns-client-subnet] [I-D.leung-cdni-uri-signing]
Contavalli, C., Gaast, W., Leach, S., and E. Lewis, Leung, K., Faucheur, F., Downey, B., Brandenburg, R., and
"Client Subnet in DNS Requests", draft-vandergaast-edns- S. Leibrand, "URI Signing for CDN Interconnection (CDNI)",
client-subnet-02 (work in progress), July 2013. draft-leung-cdni-uri-signing-05 (work in progress), March
2014.
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
for Content Internetworking (CDI)", RFC 3466, February for Content Internetworking (CDI)", RFC 3466, February
2003. 2003.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012. Statement", RFC 6707, September 2012.
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
 End of changes. 54 change blocks. 
143 lines changed or deleted 220 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/