draft-ietf-cdi-request-routing-reqs-00.txt   draft-ietf-cdi-request-routing-reqs-01.txt 
Internet Draft B. Cain Internet Draft B. Cain
Cereva Networks Storigen Systems
O. Spatscheck O. Spatscheck
AT&T Labs AT&T Labs
M. May M. May
Activia Networks Activia Networks
A. Barbir A. Barbir
Nortel Networks Nortel Networks
February 2002
Request-Routing Requirements for Content Internetworking 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 Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 4, line 33 skipping to change at page 4, line 33
The methods in which a client request is directed may be different The methods in which a client request is directed may be different
depending on the architecture of the request-routing system. depending on the architecture of the request-routing system.
Currently, there are two well-known types of request-routing systems Currently, there are two well-known types of request-routing systems
[KNOWN_MECH]. These two types are described below: [KNOWN_MECH]. These two types are described below:
1. DNS-based Request-Routing Systems: The Domain Name System (DNS) 1. DNS-based Request-Routing Systems: The Domain Name System (DNS)
is used for the direction of client requests. In this approach, is used for the direction of client requests. In this approach,
one or more domain names are assigned to the request-routing one or more domain names are assigned to the request-routing
system; these names are then used as part of a URI reference to system; these names are then used as part of a URI reference to
direct client requests [DNSMAP]. The limitations of DNS-based direct client requests. The limitations of DNS-based systems are
systems are described [KNOWN_MECH] and in section 2.1.1. described [KNOWN_MECH] and in section 2.1.1.
2. "In-Line" Request-Routing Systems: These request-routing 2. "In-Line" Request-Routing Systems: These request-routing
systems are "in-line" to client requests. Examples of in-line systems are "in-line" to client requests. Examples of in-line
request-routing systems are those that may be implemented within a request-routing systems are those that may be implemented within a
proxy or a layer-7 router. In-line request-routing systems have proxy or a layer-7 router. In-line request-routing systems have
full visibility into content requests (e.g. full URL) as well as 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 visibility of the client's IP address [note: this isn't always true
if transparent proxies are in place]. if transparent proxies are in place].
The distinction between these request-routing system types is The distinction between these request-routing system types is
important because of the differences in: important because of the differences in:
- The view of the content identifier (partial vs. whole). - 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 view of the client (e.g. client's IP vs. client's local DNS).
- The implementation requirements of the two types (e.g. DNS - The implementation requirements of the two types (e.g. DNS
caching). caching).
2.1.1 DNS-Based Request-Routing Systems 2.1.1 DNS-Based Request-Routing Systems
In DNS-based request-routing systems [ARCH] [DNSMAP], only aggregate In DNS-based request-routing systems [ARCH, KNOWN_MECH], only
sets of content may be "directed" because a domain name (e.g. aggregate sets of content may be "directed" because a domain name
images.blah.com) can only (reasonably) represent a larger set of (e.g. images.blah.com) can only (reasonably) represent a larger set
content. A DNS-based request-routing system works well in scenarios of content. A DNS-based request-routing system works well in
where many surrogates share large sets of content. scenarios where many surrogates share large sets of content.
DNS-based request-routing systems suffer from the following DNS-based request-routing systems suffer from the following
limitations: limitations:
- The request-routing system knows only the domain name of the - The request-routing system knows only the domain name of the
requested content. This precludes the RRS from knowing the full requested content. This precludes the RRS from knowing the full
content path (e.g. URI) and the content type (e.g. HTTP, RTSP). content path (e.g. URI) and the content type (e.g. HTTP, RTSP).
- The request-routing system knows the client's local DNS server, - The request-routing system knows the client's local DNS server,
not the client itself. not the client itself.
skipping to change at page 13, line 27 skipping to change at page 13, line 27
- Request-routing protocols MUST support (at a minimum) a simple - Request-routing protocols MUST support (at a minimum) a simple
capability exchange/advertisement. capability exchange/advertisement.
- Request-routing protocols MUST NOT exchange policy information. - Request-routing protocols MUST NOT exchange policy information.
- Request-routing protocols MUST accommodate policy based request- - Request-routing protocols MUST accommodate policy based request-
routing systems. routing systems.
4. Security Considerations 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 5. References
[MODEL] Day, M., Cain, B., Tomlinson, G., P. Rzewski "A Model for [MODEL] Day, M., Cain, B., Tomlinson, G., P. Rzewski "A Model for
Content Internetworking (CIG)", draft-day-cdnp-model-08.txt (work in Content Internetworking (CDI)", draft-ietf-cdi-model-02.txt (work in
progress), October 2001. progress), May 2002.
[KNOWN MECH] Barbir, A., Cain, B., Douglis, F., Green, M., Hofmann, [KNOWN MECH] Barbir, A., Cain, B., Douglis, F., Green, M., Hofmann,
M., Nair, R., Potter, D. and O. Spatscheck, "Known CDN Request- M., Nair, R., Potter, D. and O. Spatscheck, "Known CDN Request-
Routing Mechanisms", draft-cain-cdnp-known-req-route-02.txt (work in Routing Mechanisms", draft-ietf-cdi-known-request-routing-01.txt
progress), June 2001. (work in progress), May 2002.
[ARCH] Green, M., Cain, B., Tomlinson, G., Thomas, S. and P. Rzewski, [ARCH] Green, M., Cain, B., Tomlinson, G., Thomas, S. and P. Rzewski,
"Content Internetworking Architectural Overview", draft-green-cdnp- "Content Internetworking Architectural Overview", draft-ietf-cdi-
gen-arch-03.txt (work in progress), March 2001. architecture-00.txt (work in progress), February 2002.
[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.
6. Author's Address: 6. Author's Address:
Brad Cain Brad Cain
Cereva Networks Storigen Systems
bcain@cereva.com bcain@storigen.com
Oliver Spatscheck Oliver Spatscheck
AT&T Labs AT&T Labs
spatsch@research.att.com spatsch@research.att.com
Martin May Martin May
Activia Networks Activia Networks
Martin.May@activia.net Martin.May@activia.net
Abbie Barbir Abbie Barbir
 End of changes. 10 change blocks. 
24 lines changed or deleted 41 lines changed or added

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