--- 1/draft-ietf-cdi-request-routing-reqs-00.txt 2007-12-18 18:42:24.000000000 +0100 +++ 2/draft-ietf-cdi-request-routing-reqs-01.txt 2007-12-18 18:42:24.000000000 +0100 @@ -1,23 +1,21 @@ Internet Draft B. Cain - Cereva Networks + Storigen Systems O. Spatscheck AT&T Labs M. May Activia Networks A. Barbir Nortel Networks - February 2002 - Request-Routing Requirements for Content Internetworking - draft-ietf-cdi-request-routing-reqs-00.txt + draft-ietf-cdi-request-routing-reqs-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -172,47 +170,47 @@ The methods in which a client request is directed may be different depending on the architecture of the request-routing system. Currently, there are two well-known types of request-routing systems [KNOWN_MECH]. These two types are described below: 1. DNS-based Request-Routing Systems: The Domain Name System (DNS) is used for the direction of client requests. In this approach, one or more domain names are assigned to the request-routing system; these names are then used as part of a URI reference to - direct client requests [DNSMAP]. The limitations of DNS-based - systems are described [KNOWN_MECH] and in section 2.1.1. + direct client requests. The limitations of DNS-based systems are + described [KNOWN_MECH] and in section 2.1.1. 2. "In-Line" Request-Routing Systems: These request-routing systems are "in-line" to client requests. Examples of in-line request-routing systems are those that may be implemented within a proxy or a layer-7 router. In-line request-routing systems have full visibility into content requests (e.g. full URL) as well as visibility of the client's IP address [note: this isn't always true if transparent proxies are in place]. The distinction between these request-routing system types is important because of the differences in: - The view of the content identifier (partial vs. whole). - The view of the client (e.g. client's IP vs. client's local DNS). - The implementation requirements of the two types (e.g. DNS caching). 2.1.1 DNS-Based Request-Routing Systems - In DNS-based request-routing systems [ARCH] [DNSMAP], only aggregate - sets of content may be "directed" because a domain name (e.g. - images.blah.com) can only (reasonably) represent a larger set of - content. A DNS-based request-routing system works well in scenarios - where many surrogates share large sets of content. + In DNS-based request-routing systems [ARCH, KNOWN_MECH], only + aggregate sets of content may be "directed" because a domain name + (e.g. images.blah.com) can only (reasonably) represent a larger set + of content. A DNS-based request-routing system works well in + scenarios where many surrogates share large sets of content. DNS-based request-routing systems suffer from the following limitations: - The request-routing system knows only the domain name of the requested content. This precludes the RRS from knowing the full content path (e.g. URI) and the content type (e.g. HTTP, RTSP). - The request-routing system knows the client's local DNS server, not the client itself. @@ -625,46 +623,65 @@ - Request-routing protocols MUST support (at a minimum) a simple capability exchange/advertisement. - Request-routing protocols MUST NOT exchange policy information. - Request-routing protocols MUST accommodate policy based request- routing systems. 4. Security Considerations - TBD + Since request routing systems are responsible for routing client + requests to surrogates protecting request routing systems from + attackers is crucial. If any request routing system is compromised + an attacker could deny service to all or some clients and/or alter + the content distributed by the "master" or "authoritative" origin + server for all or some clients. Protecting the request routing system + requires multiple components: + + 1. Request routing systems have to ensure that their peers are + properly authenticated and the integrity of the communication between + the peers is ensured. This could be achieved by the use of IPSEC or + TLS. Any protocols designed for communication between request routing + systems MUST address this issue. + + 2. Each request routing system has to decide if its peer is + authorized to advertise a particular piece of content for a + particular region. To address this issue every request routing + system MUST allow the operator to specify a policy which reflects the + legal framework governing the authorization of advertisement. + + 3. To contain the damage a broken instance of a request routing + system can make each request routing system MUST apply the policy + specified in 2. on any advertisement received before re-advertising + the advertisement. 5. References [MODEL] Day, M., Cain, B., Tomlinson, G., P. Rzewski "A Model for - Content Internetworking (CIG)", draft-day-cdnp-model-08.txt (work in - progress), October 2001. + Content Internetworking (CDI)", draft-ietf-cdi-model-02.txt (work in + progress), May 2002. [KNOWN MECH] Barbir, A., Cain, B., Douglis, F., Green, M., Hofmann, M., Nair, R., Potter, D. and O. Spatscheck, "Known CDN Request- - Routing Mechanisms", draft-cain-cdnp-known-req-route-02.txt (work in - progress), June 2001. + Routing Mechanisms", draft-ietf-cdi-known-request-routing-01.txt + (work in progress), May 2002. [ARCH] Green, M., Cain, B., Tomlinson, G., Thomas, S. and P. Rzewski, - "Content Internetworking Architectural Overview", draft-green-cdnp- - gen-arch-03.txt (work in progress), March 2001. - - [DNSMAP] Deleuze, C., Gautier, L., and M. Hallgren, "A DNS Based - Mapping Peering System for Peering CDNs", draft-deleuze-cdnp-dnsmap- - peer-00.txt (work in progress), November 2000. + "Content Internetworking Architectural Overview", draft-ietf-cdi- + architecture-00.txt (work in progress), February 2002. 6. Author's Address: Brad Cain - Cereva Networks - bcain@cereva.com + Storigen Systems + bcain@storigen.com Oliver Spatscheck AT&T Labs spatsch@research.att.com Martin May Activia Networks Martin.May@activia.net Abbie Barbir