Network Working Group T. Choi Internet-Draft ETRI Intended Status: Standard Track J. Shinn Expires: April 20, 2014 Solbox Inc. J. Sung KT J. Lee SKT J. Koo LGU+ Y. Bang KAIST October 17, 2013 Request Interface for Iterative Request Routing Redirection draft-choi-cdni-req-intf-01 Abstract This document specifies the request interface between a CDN end-user and an upstream CDN or downstream CDN to request CDN request routing redirection. It specifies the CDNI Request Interface information elements and the actual protocol for exchanging them. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 29, 2012. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal TS Choi et al. Expires April 20, 2014 [Page 1] INTERNET DRAFT Request Interface October 17, 2013 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Request Interface Function Overview . . . . . . . . . . . . . . 3 3. Request Interface Information Elements . . . . . . . . . . . . 3 4. Request Procedures . . . . . . . . . . . . . . . . . . . . . . 4 4.1. HTTP-based Iterative Request Routing Redirection with Loop Prevention . . . . . . . . . . . . . . . . . . . . . 4 4.2. DNS-based Iterative Request Routing Redirection with Loop Prevention . . . . . . . . . . . . . . . . . . . . . 9 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 11 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 TS Choi et al. Expires April 20, 2014 [Page 2] INTERNET DRAFT Request Interface October 17, 2013 1. Introduction According to the CDNi requirements[I-D.ietf-cdni-requirements] and the CDNI Framework [I-D.ietf-cdni-framework], the need for interconnected CDNs to be able to support iterative and recursive CDNi request routing and implement an access control mechanism that enforces the CSP's distribution policy is described. Recursive CDNi request routing is specified by request routing redirection interface [I-D.ietf-cdni-redirection]. URI signing is specified in URI signing [I-D.leung-cdni-uri-signing]. Meanwhile, both iterative request routing redirection and URI signing require interactions between an end-user and uCDN or dCDN. This implies the need for an interface to support such interactions. To meet the needs, this document specifies an interface called "Request Interface" which resides between end-users and CDN providers. It describes information elements and transport protocols for the interface. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Request Interface Function Overview Request interface operates between a user agent and CDN provider (either uCDN or dCDN). Since one end of this interface is user application such as web browser, it is desirable not to invent a new protocol for this function. Instead, it uses well-known protocols used by the existing CDN applications such as HTTP and DNS. The main function of this interface is to support the iterative request routing redirection and URI singing. For the iterative request routing redirection, it also supports loop prevention mechanism. 3. Request Interface Information Elements To meet the requirements of request routing redirection, we define the term "CDN-Provider-ID". It uniquely identifies each CDN provider during the course of request routing redirection. It consists of "CDN provider name" and "MaxNumRedHops". A pair of an AS number and an additional qualifier is used for CDN provider name. Since more than one CDN providers can belong to the same AS, an additional qualifier is used to guarantee the uniqueness. MaxNumRedHops TS Choi et al. Expires April 20, 2014 [Page 3] INTERNET DRAFT Request Interface October 17, 2013 represents a maximum allowed redirections. The value is decreased once every redirection occurs until it reaches 0. To avoid its usage abuse (e.g., end user or CDN operator can set huge number like 100 or above), a reasonable upper bound has to be agreed among CDN providers. Security aspect of it is for further study. A few examples of the CDN provider names are 100:0 and 200:1. The former means that a CDN provider belong to AS 100 and it is the only CDN provider within that AS. The latter represents the first CDN provider in the AS 200. There are other CDN providers in the same AS. One example of CDN-Provider-ID is "CDN-Provider-Name=100:0 & MaxNumRedHops=10", which means that a CDN provider that belong to AS number 100 and it is the only CDN provider and a maximum allowed redirection is 10. An example how a list of CDN-Provider-IDs can be carried in the URI query string when a certain cascaded request routing redirection occurs is the following. We assume that redirection is cascaded three times: uCDN -> dCDN1 -> dCDN2. dCDN1, then, carries the following URL, "http://cdn.csp.com?uCDN-Provider- ID=100:0&dCDN1-Provider-ID=200:1&MaxNumRedHops=9". Note that MaxNumbRedHops carries the latest number instead of adding in every CDN-Provider-ID to save the space in URI query string. It is applicable for both HTTP-based and DNS redirections. For HTTP- based redirection, we define a HTTP request routing redirection header "CDN-Provider-ID". For each step of redirection, it is attached to the beginning of the provider domain URL. For example, uCDN initiates a redirection with its URL, http://100:0:10.cdn.csp.com. dCDN further attaches its own CDN- Provider-ID in the front when another level of redirection is required. For DNS-based redirection, the CDN-Provider-ID can be attached in the DNS CNAME. For URI singing, detailed format of information elements carried over this interface is defined in [I-D.ietf-leung-cdni-uri-signing-02] 4. Request Procedures This section specifies two request procedures: HTTP-based and DNS- based iterative request routing redirection with loop prevention. 4.1. HTTP-based Iterative Request Routing Redirection with Loop Prevention In this section, we describe an iterative procedure of HTTP-based request routing redirection with loop prevention. TS Choi et al. Expires April 20, 2014 [Page 4] INTERNET DRAFT Request Interface October 17, 2013 End-User dCDNn dCDNn-1 dCDN1 uCDN |DNS cdn.csp.com | | | | |------------------------------------------------------->| | | | | |(1) |IPaddr of uCDN's Request Router | | | |<-------------------------------------------------------| |HTTP cdn.csp.com | | } | |------------------------------------------------------->| | | | | |(2) |302 peer-uCDN.dCDN1.net/cdn.csp.com?uCDN-Provider-ID | |<-------------------------------------------------------| |DNS peer-uCDN.dCDN1.net | | | |-------------------------------------------->| | | | | |(3) | |IPaddr of dCDN1's Request Router| | | |<--------------------------------------------| | | | | | | |HTTP peer-uCDN.dCDN1.net/cdn.csp.com?uCDN-Provider-ID | |-------------------------------------------->| | | | | |(4) | |302 peer-dCDN1.dCDN2.net/cdn.csp.com?dCDN1-Provider-ID | |<--------------------------------------------| | | | | | | | | ....... |(5) | | | | | | |302 peer-dCDNn-1.dCDNn.net/cdn.csp.com?dCDNn-1-Provider-ID |<-------------------------------| | | | | | | | |DNS peer-dCDNn-1.dCDNn.net | | | |------------------------------->| | | | | |(6) | | |IPaddr of dCDNn's Request Router| | | |<-------------------------------| | | | | | | | |HTTP peer-dCDNn-1.dCDNn.net/cdn.csp.com | | |------------------------------->| | | | | |(7) | | |302 node1.peer-dCDNn-1.dCDNn.net/cdn.csp.com | | |<-------------------------------| | | | | | | | |DNS node1.peer-dCDNn-1.dCDNn.net| | | |------------------>| | | | | | |(8) | | |IPaddr of dCDNn's Delivery Node } | | |<------------------| | | | | | | | | |HTTP node1.peer-dCDNn-1.dCDNn.net/cdn.csp.com| | |------------------>| | | | TS Choi et al. Expires April 20, 2014 [Page 5] INTERNET DRAFT Request Interface October 17, 2013 | |(9) | | | | |DNS dCDNn-acq.dCDNn-1.net| | | |----------->| | | | | |(10) | | | |IPaddr of dCDNn-1's Request Router | | |<-----------| | | | |HTTP dCDNn-acq.dCDNn-1.net?dCDNn-Provider-ID | |----------->| | | | | |(11) | | | | | ....... | | | | | | | | |HTTP dCDN1-acq.uCDN.net?dCDN1-Provider-ID | | | |--------->| | | | | |(12) | | |302 node2.dCDN1.acq.uCDN.net | | | |<---------| | | |DNS node2.dCDN1-acq.uCDN.net | | | |--------->| | | | | |(13) | | |IPaddr of uCDN's Delivery Node | | | |<---------| | | | | |(14) | | | | Data | | | | |<---------| | | | ....... | | |Data | | | | |<------------------| | | | Figure 1: HTTP-based request routing redirection iterative procedure The steps illustrated in the figure are as follows: 1. A DNS resolver for uCDN provider processes the DNS request for its customer based on CDN-domain cdn.csp.com. It returns the IP address of a request router in uCDN provider. 2. A Request Router for uCDN provider processes the HTTP request and recognizes that the end-user is best served by dCDN1. So it returns a 302 redirect message for a new URL constructed by "stacking" dCDN1's distinguished CDN-domain (peer- uCDN.dCDN1.net) on the front of the original URL. It also adds uCDN's CDN-Provider-ID in the URI query string of the HTTP request message. (e.g., uCDN-Provider-ID=100:0 & MaxNumRedHops=10). This information is not processed by the customer but conveyed in the HTTP message without any modification of the step 4. The details on how it is used for loop prevention is described in the step 4. TS Choi et al. Expires April 20, 2014 [Page 6] INTERNET DRAFT Request Interface October 17, 2013 3. The end-user does a DNS lookup using dCDN1's distinguished CDN-domain (peer-uCDN.dCDN1.net). dCDN1's DNS resolver returns the IP address of a request router for dCDN1. 4. The request router for dCDN1 processes the HTTP request. There are two options: redirect further to another dCDN (i.e., cascading the request) or process it by itself. In either cases, it performs loop prevention step first. It checks a list of CDN-provider-IDs in the URI query string: it contains a list of CDN providers which requested redirections so far. If either it contains own CDN provider name or MaxNumRedHops becomes 0, it means that the redirection loop has occurred or the number of redirection hops has reached the maximum. Once loop is detected, details on the next steps is described in the section 3. If it is loop free, it either redirects further or processes based on the local policy. For the former, it selects another dCDN provider and and sends an HTTP redirect message with its own CDN-Provider-ID included in its URI query string (e.g., uCDN-Provider-ID=100:0 & dCDN1-Provider-ID=200:1 & MaxNumRedHops=9) attached. For the latter, it selects a suitable delivery node to serve the end-user request, and returns a 302 redirect message for a new URL constructed by replacing the hostname by a subdomain of the dCDN1's distinguished CDN-domain that points to the selected delivery node. Then it goes to the step 6. 5. If further redirection is decided, it repeats steps 2 - 4 until it either selects dCDN provider to serve the request or MaxNumRedHops expires. If the former occurs, it resumes the step 6. If the latter occurs, it follows the processes described in the section 3. 6. Assuming that dCDNn is selected as a serving dCDN provider, the end-user does a DNS lookup using dCDNn's distinguished CDN-domain (peer-dCDNn-1.dCDNn.net). dCDNn-1's DNS resolver returns the IP address of a request router for dCDNn. 7. The request router for dCDN1 processes the HTTP request and selects a suitable delivery node to serve the end-user request, and returns a 302 redirect message for a new URL constructed by replacing the hostname by a subdomain of the dCDNn's distinguished CDN-domain that points to the selected delivery node. 8. The end-user does a DNS lookup using dCDNn's delivery node subdomain (node1.peer-dCDNn-1.dCDNn.net). dCDNn's DNS resolver returns the IP address of the delivery node. TS Choi et al. Expires April 20, 2014 [Page 7] INTERNET DRAFT Request Interface October 17, 2013 9. The end-user requests the content from dCDNn's delivery node. In the case of a cache hit, steps 10 ~ 14 below do not happen, and the content data is directly returned by the delivery node to the end-user. In the case of a cache miss, the content needs to be acquired by dCDN from either parent dCDN or uCDN (not the CSP). The distinguished CDN-domain peer-dCDNn-1.dCDNn.net indicates that this content is to be acquired from dCDNn-1; stripping the CDN-domain reveals the original CDN-domain cdn.csp.com and dCDNn may verify that this CDN-domain belongs to a known peer (so as to avoid being tricked into serving as an open proxy). It then does a DNS request for an inter-CDN acquisition CDN-domain as agreed above (in this case, dCDNn- acq.dCDNn-1.net). This process repeats recursively until it finds a CDN provider that can serve the requested content. 10. dCDNn-1's DNS resolver processes the DNS request and returns the IP address of a request router in dCDNn-1. 11. The request router for dCDNn-1 processes the HTTP request from dCDNn's delivery node. dCDNn-1 request router recognizes that the request is from a peer CDN rather than an end-user because of the dedicated inter-CDN acquisition domain (dCDNn-acq.dCDNn-1.net). It also performs loop prevention process as described in step 4 based on the provided CDN- Provider-ID (e.g., uCDN-Provider-ID=100:0 & dCDN1-Provider- ID=200:1 & ... & dCDNn-Provider-ID=1000:0 & MaxNumRedHops=1). Depending on the number of levels of redirection and availability of contents, the same process repeats until either content serving CDN provider is found or MaxNumRedHps expires. 12. Assuming that all intermediate dCDNs also have a cache miss, The request router for uCDN selects a suitable delivery node to serve the inter-CDN acquisition request and returns a 302 redirect message for a new URL constructed by replacing the hostname by a subdomain of the uCDN's distinguished inter-CDN acquisition domain that points to the selected delivery node. 13. uCDN DNS resolver processes the DNS request and returns the IP address of the delivery node in uCDN. 14. uCDN serves content for the requested CDN-domain to dCDN and finally to end-user. Although not shown, it is at this point that uCDN processes the rest of the URL: it extracts information identifying the origin server, validates that this server has been registered, and determines the content provider that owns the origin server. It may also perform its own content acquisition steps if needed before returning the content to dCDN. TS Choi et al. Expires April 20, 2014 [Page 8] INTERNET DRAFT Request Interface October 17, 2013 4.2. DNS-based Iterative Request Routing Redirection with Loop Prevention In this section, we describe an iterative procedure of DNS-based request routing redirection with loop prevention. TS Choi et al. Expires April 20, 2014 [Page 9] INTERNET DRAFT Request Interface October 17, 2013 End-User dCDNn dCDNn-1 dCDN1 uCDN |DNS cdn.csp.com | | | | |------------------------------------------------------->| | | | | | |CNAME uCDNProviderID.dCDN1.cdn.csp.com | |(1) |NS records for dCDN1.cdn.csp.com| | | |<-------------------------------------------------------| |DNS dCDN1.cdn.csp.com | | | |-------------------------------------------->| | | | | | | | | ....... |(2) | | | | | | |CNAME dCDN1.cdn.csp.com | | | |NS records for dCDN1.cdn.csp.com| | | |<-------------------------------| | | |DNS dCDNn.cdn.csp.com | | | |------------------>| | | | | | |(3) | | |IPaddr of dCDNn's Delivery Node } | | |<------------------| | | | | | | | | |HTTP cdn.csp.com | | | | |------------------>| | | | | |(4) | | | | |DNS dCDNn-acq.dCDNn-1.net| | | |----------->| | | | | | | | | | | ....... |(5) | | | | | | | |DNS dCDN1 ProviderID.dCDN1-acq.uCDN.net | | | |--------->| | | | | |(6) | | |IPaddr of uCDN's Delivery Node | | | |<---------| | | | | |(7) | | | | Data | | | | |<---------| | | | ....... | | |Data | | | | |<------------------| | | | Figure 2: DNS-based request routing redirection iterative procedure The steps illustrated in the figure are as follows: 1. Request Router for uCDN provider processes the DNS request for CDN- domain cdn.csp.com and recognizes that the end-user is best TS Choi et al. Expires April 20, 2014 [Page 10] INTERNET DRAFT Request Interface October 17, 2013 served by another CDN. (This may depend on the IP address of the user's local DNS resolver, or other information discussed below.) The Request Router returns a DNS CNAME response by "stacking" the distinguished identifier for dCDN1 and uCDN's CDN-Provider-ID (e.g., 100:0.10) onto the original CDN-domain (e.g., dCDN1.cdn.csp.com), plus an NS record that maps dCDN1.cdn.csp.com to dCDN1's Request Router. 2. The end-user does a DNS lookup using the modified CDN-domain (i.e., dCDN1.cdn.csp.com). dCDN1 Request Router processes the request and decides to serve the request or redirect further to another CDN provider. It also checks redirection loop. This process iterates until either serving dCDN is selected or MaxNumRedHops expires. In this case, dCDNn is selected as a serving dCDN. If the former occurs, it proceeds to step 3. If the latter occurs, it follows the processes described in the section 3. 3. The end-user does a DNS lookup using the modified CDN-domain (i.e., dCDN1.cdn.csp.com). This causes dCDNn's request router returns an IP address of a suitable delivery node. 4. The end-user requests the content from dCDNn's delivery node. In the case of a cache hit, steps 5 ~ 7 do not happen, and the content data is directly returned by the delivery node to the end-user. In the case of a cache miss, the content needs to be acquired by dCDNn from either parent dCDN or uCDN (not the CSP). It also performs loop prevention process as described in the step 2 based on the provided CDN-Provider-ID (e.g., 100:0.200:1.....900:0.1) 5. Depending on the number of levels of redirection and availability of contents, the same process repeats until either content serving CDN provider is found or MaxNumRedHps expires. 6. Assuming that all intermediate dCDNs also miss cache, uCDN is selected as a content delivery CDN provider. Thus, the request router for uCDN selects a suitable delivery node to serve the inter-CDN acquisition request and returns IP address of the suitable uCDN delivery node. 7. uCDN serves content to dCDN1 and further down to end-user. Although not shown, it is at this point that uCDN processes the rest of the URL: it extracts information identifying the origin server, validates that this server has been registered, and determines the content provider that owns the origin server. 5 Security Considerations TS Choi et al. Expires April 20, 2014 [Page 11] INTERNET DRAFT Request Interface October 17, 2013 TBD. 6 IANA Considerations TBD. 7. References 7.1. Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-cdni-framework] Peterson, L. and B. Davie, "Framework for CDN Interconnection", February 2013. [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", July 2013. [I-D.ietf-cdni-redirection] Wang, H. and Niven-Jenkins, B., "Request Routing Redirection Interface for Content Distribution Network Interconnection", April 2013. [I-D.leung-cdni-uri-signing] Leung, K. and Le Faucheur, F., "URI Signing for Content Distribution Network Interconnection", May 2013. 7.2. Informative References TBD. Authors' Addresses Taesang Choi ETRI 161 Gajong-Dong Yusong-Gu, Daejeon Republic of Korea Phone: +82-42-860-5628 Email: choits@etri.re.kr John Dongho Shinn Solbox Inc. TS Choi et al. Expires April 20, 2014 [Page 12] INTERNET DRAFT Request Interface October 17, 2013 7F, Haesung Bldg. 747-2 Yeoksam-Dong Kangnam-Gu, Seoul Republic of Korea Phone: +82-10-3005-4785 Email: eastsky@solbox.com Jonggyu Sung KT Infra Laboratory 463-1, Jeonmin-dong Yuseong-gu, Daejeon Republic of Korea Phone: 82-10-3096-8237 Email: jonggyu.sung@kt.com Jongmin Lee SK Telecom 11, Euljiro-2ga Jung-gu, Seoul Republic of Korea Phone: 82-10-9429-6260 Email: jminlee@sk.com Ja-Ryeong Koo LG U plus Corporation Namdaemunro 5-ga Jung-gu, Seoul Republic of Korea Phone: 82-10-8080-6115 Email: wjbkoo@lguplus.co.kr Yong Hwan Bang KAIST 8F, N29 Bldg. 373-1 Gusung-Dong Yousong-Gu, Daejeon Republic of Korea Phone: +82-42-350-7516 Email: yjhvyp@gmail.com TS Choi et al. Expires April 20, 2014 [Page 13]