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/ |