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/