< draft-alfano-aaa-qosreq-00.txt		draft-alfano-aaa-qosreq-01.txt >
	Authentication, Authorization and Accounting Frank M. Alfano		Authentication, Authorization and Accounting Frank M. Alfano
	Internet Draft Peter J. McCann		Internet Draft Peter J. McCann
	Document: draft-alfano-aaa-qosreq-00.txt Tom Towle		Document: draft-alfano-aaa-qosreq-01.txt Tom Towle
	Expires: December 2003 Richard Ejzak		Expires: April 2004 Richard Ejzak
	Lucent Technologies		Lucent Technologies
	June 2003		Hannes Tschofenig
			Siemens
			October 2003
	Requirements for a QoS AAA Protocol		Requirements for a QoS AAA Protocol
	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 [1]. Internet-Drafts are		all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are
	working documents of the Internet Engineering Task Force (IETF), its		working documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also		areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 37 ¶
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This document describes requirements for a protocol that would		This document describes requirements for a protocol that would
	perform Authentication, Authorization, and Accounting for Quality-of-		perform Authentication, Authorization, and Accounting for Quality-of-
	Service reservations. This protocol would be used by elements along		Service reservations. Such a protocol would be used by entities to
	the path of a given application flow to authenticate a reservation		authenticate a user's reservation request, to ensure that the
	request, ensure that the reservation is authorized, and to account		reservation is authorized and to provide accounting functionality.
	for resources used during the life of the application flow. A QoS
	AAA protocol should also support dynamic authorization of QoS as a		The requirements covered in this document primarily address the
	function of application and account state. While we assume the		communication of AAA protocols and not the QoS signaling protocols,
	existence of some QoS reservation protocol to allow endpoints to		although they have to provide some degree of interworking. Therefore,
	request QoS from network elements, complete requirements for such a		we list a minimal set of requirements on supported QoS signaling
	protocol are outside the scope of this document and a QoS AAA		protocols.
	protocol could be used to support more than one kind of reservation
	protocol. A QoS AAA protocol could be used between any bearer-level		Requirements for a QoS AAA Protocol October 2003
	network element that lies along the path of an application flow and
	an application server that lies anywhere in the network, allowing for
	a wide variety of flexible service deployment models.
	Table of Contents		Table of Contents
	1. Introduction...................................................2		1. Introduction...................................................2
	2. Conventions used in this document..............................6		1.1 QoS Signaling..............................................3
	3. Term Definitions...............................................6		1.2 Architecture...............................................3
	4. Generic Requirements on a QoS Reservation Signaling Protocol...7		2. Keywords.......................................................5
	4.1 Identity Information.......................................7		3. Terminology....................................................5
	4.2 Flow Information...........................................7		4. Generic Requirements on a QoS Signaling Protocol...............7
	4.3 Authentication Information.................................8		4.1 User Authentication/Authorization..........................7
	5. Generic Requirements on a QoS AAA Protocol.....................8		4.2 Support for different authorization scenarios..............7
	5.1 Inter-domain Support.......................................8		4.3 Providing Authorization Information........................7
	5.2 Identity-based Routing.....................................8		4.4 Reauthorization............................................8
	6. Requirements for QoS Authentication............................8		4.5 Integrity and Replay Protection............................8
	6.1 Authentication Check.......................................8		4.6 Confidentiality Protection.................................8
	7. Requirements for QoS Authorization.............................9		5. Generic Requirements on a QoS AAA Protocol.....................9
	7.1 Flow Information...........................................9		5.1 Inter-domain Support.......................................9
	7.2 Application State Pointer..................................9		5.2 Identity-based Routing.....................................9
	7.3 Dynamic Authorization......................................9		6. Requirements for QoS Authentication............................9
	7.4 Bearer Gating..............................................9		6.1 Flexible Authentication Support............................9
	8. Requirements for QoS Accounting...............................10		7. Requirements for QoS Authorization............................10
	8.1 Accounting Records........................................10		7.1 Making an Authorization Decision..........................10
	8.2 Accounting Rules..........................................10		7.2 Triggering an Authorization Process.......................10
	8.3 Sending Accounting Records................................10		7.3 Associating QoS Reservations and Application State........10
	8.4 Loss of Bearer Notification Requirements..................10		7.4 Dynamic Authorization.....................................11
	8.5 Accounting Correlation....................................11		7.5 Bearer Gating.............................................11
	9. Interaction with other AAA Applications.......................11		8. Requirements for QoS Accounting...............................11
	10. Use Scenario.................................................12		8.1 Accounting Records........................................11
	10.1 Bearer Gating............................................12		8.2 Accounting Rules..........................................11
	10.2 Loss of Bearer...........................................13		8.3 Sending Accounting Records................................12
	11. Security Considerations......................................13		8.4 Failure Notification......................................12
	12. Reference....................................................13		8.5 Accounting Correlation....................................12
	13. Author's Addresses...........................................14		9. Interaction with other AAA Applications.......................12
			10. Use Scenario.................................................13
			10.1 Bearer Gating............................................14
			10.2 Loss of Connectivity.....................................14
			11. Security Considerations......................................14
			12. References...................................................15
			13. Author's Addresses...........................................16
	1. Introduction		1. Introduction
	To meet the quality-of-service needs of applications such as voice-		To meet the quality-of-service needs of applications such as voice-
	over-IP, it will often be necessary to explicitly request resources		over-IP, it will often be necessary to explicitly request resources
	from the network. This will allow the network to identify packets		from the network. This will allow the network to identify packets
	belonging to such application flows and ensure that bandwidth, delay,		belonging to such application flows and ensure that bandwidth, delay,
	and error rate requirements are met. By performing admission control		and error rate requirements are met. By performing admission control
			Requirements for a QoS AAA Protocol October 2003
	on individual flows, the network can avoid congestion and the		on individual flows, the network can avoid congestion and the
	resulting high packet drop rates.		resulting high packet drop rates.
	Not every network deployment requires explicit reservation: for		1.1 QoS Signaling
	example, if the network resources are provisioned far in excess of
	demand, there will never be any contention for those resources and
	there will be no need to manage them with a reservation protocol.
	Also, if the transport or application layers can provide self-
	correcting congestion control, it may be possible to operate the
	network even with high utilization and still meet the QoS
	requirements of the various applications. However, when bandwidth is
	expensive and must be carefully managed, such as in wide-area
	cellular networks, and/or when applications and transport protocols
	lack the capability or cannot be trusted to perform congestion
	control, explicit reservation techniques are required. Note that a
	reservation protocol might be used regardless of the mechanisms used
	to enforce QoS, e.g., IntSrv or DiffSrv.
	A variety of protocols could be used to make a reservation request,		A variety of protocols can be used to signal QoS information and to
	such as:		make a reservation, such as RSVP, NSIS, SIP/SDP or link-layer
			specific mechanisms.
	1. RSVP.		RSVP [2] is the existing IETF-defined QoS signaling protocol. The
	2. NSIS.		Next Steps in Signaling (NSIS) working group [3] is currently
	3. Link-specific means.		developing a general signaling model based on two-layer architecture.
	4. SIP/SDP.
	The most obvious choice, RSVP [2], is the existing IETF-defined		In the meantime, deployments such as 3rd generation cellular networks
	reservation protocol. For a variety of reasons, RSVP has not seen		are defining their own reservation procedures: these include link-
	widespread deployment as an end-to-end reservation protocol. The new		layer specific means, such as the PDP Context Activation procedures
	Next Steps in Signaling (NSIS) work [3] currently being undertaken		of 3GPP [4,5] or the service instance establishment procedures of
	may address some of these issues. In the meantime, deployments such		3GPP2 [6]. This list can easily be extended.
	as 3rd generation cellular networks are defining their own
	reservation procedures: these include link-specific means, such as
	the PDP Context Activation procedures of 3GPP [4,5] or the service
	instance establishment procedures of 3GPP2 [6]. Also, these
	procedures are often tightly coupled to the application, and in the
	3GPP/3GPP2 IP Multimedia Core Network subsystems, one could even say
	that the Session Initiation Protocol (SIP) [7] and Session
	Description Protocol (SDP) [8] are being used to request resource
	reservations from the network. This tight coupling is in the form of
	private interfaces between the bearer elements (GGSN, PDSN) and the
	SIP application servers. For example, when a first-hop wireless
	router receives a request for radio-link QoS, it might interact with
	the nearest SIP proxy to see if the request should be authorized.
	There are several inter-related reasons that are often cited for the		In other areas QoS signaling mechanisms are often tightly coupled to
	tight coupling. First, application knowledge is sometimes needed to		the application signaling. In the 3GPP/3GPP2 IP Multimedia Core
	authorize the use of bearer resources; for example, a SIP-layer		Network subsystems the Session Initiation Protocol (SIP) [7] and
	application might authorize (and later, account for and charge) the		Session Description Protocol (SDP) [8] are essentially being used to
	use of the bearer on behalf of a party other than the one requesting		request resource reservations from the network. Special purpose
	it. Also, the application server might enable/disable ("gate") the		protocols are used for communication between the SIP servers and
	bearer flow according to the high-level state of the call. Second,		network elements.
	applications can often be enhanced if knowledge about the bearer is
	available. For instance, when a mobile node is suddenly disconnected
	from the network, application servers can generate BYE messages to
	terminate the call with the other party. Also, application servers
	implementing an emergency call might provide higher priority access
	and might also require the bearer elements to provide location
	information about the device being used to place the call. Finally,
	the operator may wish to correlate accounting records from the bearer
	path with those from the application layer. Such correlation might
	be used to provide alternative billing or settlement with 3rd
	parties.
	Despite the advantages of closer coupling between application and		1.2 Architecture
	bearer, the use of private, local interfaces between SIP servers and
	the bearer path leads to several disadvantages:
	* Use of SIP servers other than the ones provided by the operator		This draft describes requirements on a AAA protocol for QoS
	becomes more difficult.		reservations stemming from the new (primarily wireless) network
	* Deployment of some new applications requires close coordination		deployments in light of recent efforts to revisit QoS signaling
	with the network operator.		within the IETF. The goal is to meet these requirements of network
	* It becomes impossible to handle mobility at the network layer		operators while at the same time supporting a variety of QoS
	when a change in the bearer element point of attachment to the		signaling protocols and avoiding the need for monolithic, vertically
	Internet requires a change in the associated SIP server.		integrated applications (such as e.g., a SIP proxy server in every
	* Use of protocols other than SIP to establish sessions becomes		router). A high-level picture of the resulting architecture is shown
	impossible.		in Figure 1.
	All of these drawbacks can be viewed as a result of the conflict		Requirements for a QoS AAA Protocol October 2003
	between the SIP-based reservation architecture and the end-to-end
	service model espoused by most Internet architects, which emphasizes
	a narrow interface between application, transport, and network. Any
	widening of these interfaces must be done in a carefully controlled
	way that preserves the openness, robustness, and flexibility of the
	Internet. Such interfaces must support inter-domain operation,
	imposing no limitations on where application servers can be placed,
	and allowing for a clean layering so as not to interfere with
	network-layer functionality.
	To meet the requirements of network operators while at the same time		+-------------+
	preserving the best of the end-to-end Internet service model, we		| Resource |
	propose that a AAA protocol be developed that can be used by bearer		| Authorizing |
	elements to authenticate, authorize, and account for individual		| Entity |
	application flows that require QoS. A high-level picture of the		+-----+-------+
	resulting architecture is shown in Figure 1.		|
			|
			/-\----+-----/\
			//// \\\\
			|| ||
			| AAA Cloud |
			|| ||
			\\\\ ////
			\-------+-----/
			|
			+-------------+ +---+--+
			| Entity | Application | |
			| Requesting |<<=================+ NE +==========>>
			| Resource | Flow | |
			+-------------+ +------+
			Figure 1: Architecture
	+------+ +------+		Figure 1 depicts an entity requesting a resource, a network element
	| Subs | | |		(NE) through which application flows need to pass (i.e., an entity
	| DB | | AS |		which enforces the QoS reservation), a cloud of AAA servers and an
	| | | |		entity authorizing the QoS request. In many cases, the authentication
	+---\--+ +---/--+		terminates at the user's home network where a database containing
	\ /		subscriber records is located. This is often the entity that executes
	\ /		the authorization decision. Finally, there might be an interaction
	/-\----------/\		with an application signaling protocol.
	//// \\\\
	|| ||
	| AAA Cloud |
	|| ||
	\\\\ ////
	\-------+-----/
	|
	+---+--+
	Application | |
	Flow ===============+ BE +==========>>
	| |
	+------+
	Figure 1. An architecture supporting QoS-AAA
	Figure 1 depicts a bearer element through which application flows		Note that the entity authorizing the QoS reservation request might be
	need to pass, a cloud of AAA servers, a database containing		a AAA server, an application server or another entity. These entities
	subscriber records, and an application server. Here the term "AAA		are collectively referred as the "Resource Authorizing Entity" in
	Cloud" is used to refer to the network of AAA proxy/broker		Figure 1.
	arrangements that may be in place. Also, note that there may be more
	than one bearer element that needs to interact with the AAA cloud
	along the path of a given application flow, although the figure only
	depicts one for clarity. Similarly, a given user may have subscriber
	records stored in more than one place and might make use of multiple
	application servers. In the simplest case, bearer elements will
	request authentication and authorization for QoS from the AAA cloud,
	which will route the request to the home network and consult a static
	subscriber record of the endpoint making the request and return a
	grant/deny decision. In more complex deployment models, the
	authorization will be based on dynamic application state, so the
	request must be authenticated and authorized based on information
	from one or more application servers. If defined properly, the
	interface between the bearer element and AAA cloud would be identical
	in both cases. Bearer elements are therefore insulated from the
	details of particular applications and need not know that application
	servers are involved at all. Also, the AAA cloud would naturally
	encompass business relationships such as those between network
	operators and third-party application providers, enabling flexible
	intra- or inter-domain authorization, accounting, and settlement.
	The remainder of this document outlines high-level requirements for		The term "AAA Cloud" is used to refer to the network of AAA proxies
	the QoS AAA protocol. Section 3 defines some terms that are used in		and brokers. Furthermore, there might be more than one network
	subsequent discussion. Section 4 describes a small number of generic		element that needs to interact with the AAA infrastructure although
	requirements on a QoS reservation protocol. Section 5 gives generic		Figure 1 depicts only one for clarity. Similarly, a given user might
	requirements for a QoS AAA protocol. Section 6 gives requirements		support different authentication methods; he might have more than one
	specific to Authentication. Section 7 gives requirements specific to		home network; or, he might use different means of authorization.
	Authorization. Section 8 gives requirements specific to Accounting.
			The remainder of this document is organized as follows:
			Section 3 defines some terms that are used in subsequent discussion.
			Requirements for a QoS AAA Protocol October 2003
			Section 4 describes some generic requirements for a QoS signaling
			protocol.
			Section 5 gives generic requirements for a QoS AAA protocol.
			Section 6 gives requirements specific to Authentication.
			Section 7 gives requirements specific to Authorization.
			Section 8 gives requirements specific to Accounting.
	Section 9 discusses the relationship of a QoS AAA protocol to other		Section 9 discusses the relationship of a QoS AAA protocol to other
	AAA applications. Section 10 gives an example use scenario.		AAA applications.
			Section 10 gives an example use scenario.
	Finally, Section 11 outlines some security considerations.		Finally, Section 11 outlines some security considerations.
	2. Conventions used in this document		2. Keywords
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119 [9].		document are to be interpreted as described in RFC-2119 [9].
	3. Term Definitions		3. Terminology
	Accounting Rules		Accounting Rules
	An accounting rule is a collection of data that identifies one		An accounting rule is a collection of data that identifies one
	or more IP flows and provides related information. An accounting		or more IP flows and provides related information. An accounting
	rule defines the accounting treatment such as on-line or off-		rule defines the accounting treatment such as on-line (i.e.,
	line accounting. The data may also identify, for example, volume		pre-paid) or off-line accounting. The data may also identify,
	or time based accounting, rating information, termination		for example, volume or time based accounting, rating
	actions for on-line accounting (e.g., drop or re-route packets),		information, termination actions for on-line accounting (e.g.,
	record correlation identifiers, etc.		drop or re-route packets), record correlation identifiers, etc.
	Application Server		Application Server
	An application server is a network entity that exchanges		An application server is a network entity that exchanges
	signaling messages with an application endpoint. It may be a		signaling messages with an application endpoint. It may be a
	source of authorization for QoS-enhanced application flows. For		source of authorization for QoS-enhanced application flows. For
	example, a SIP server is one kind of application server.		example, a SIP server is one kind of application server.
	Application Endpoint		Application Endpoint
	An application endpoint is an entity in an end user device that		An application endpoint is an entity in an end user device that
	exchanges signaling messages with application servers or		exchanges signaling messages with application servers or
	directly with other application endpoints. Based on the result		directly with other application endpoints. Based on the result
	of this signaling, the endpoint will make a request for QoS from		of this signaling, the endpoint will make a request for QoS from
	the network. For example, a SIP User Agent is one kind of		the network. For example, a SIP User Agent is one kind of
	application endpoint.		application endpoint.
	Authorizing Entity		Authorizing Entity
	The authorizing entity is that entity responsible for		The authorizing entity is that entity responsible for
	authorizing QoS for a particular application flow. This may be		authorizing QoS requests for a particular application flow.
	a home subscriber database or an application server.		This may be a AAA server (with a subscriber database) or an
			application server or some other entity.
	Bearer Element		Requirements for a QoS AAA Protocol October 2003
	A bearer element is a network entity such as an IP router on the
	path between two endpoints, through which IP packets belonging		Network Element
	to application flows pass. Note that only a subset of the bearer		A network element is a network entity such as an IP router on
	elements along a path are required to process and authorize QoS		the path between two endpoints, through which IP packets
	requests. In a typical service provider scenario, the first-hop		belonging to application flows pass. Typically only a small
	router (NAS) will be required to play this role.		subset of the network elements along a path communicates with
			the AAA infrastructure for the purpose of QoS authorization. In
			a typical service provider scenario, the first-hop router will
			be required to play this role. A motivation of this
			architectural simplification is referred to as the New Jersey
			Turnpike Model and is described in detail in Section 4 of [11].
			Network elements are responsible for enforcing the result of the
			authorization process.
	Subscriber Database		Subscriber Database
	A Subscriber Database holds information related to network users		A Subscriber Database holds information related to network users
	such as what services they have signed up for. In particular, a		such as information about their subscribed service. A user
	user may subscribe to QoS independent of any application, which		might, for example, have a subscription for a 'gold' service
	would enable authorization for QoS without consultation of an		that authorizes him for higher QoS parameters than 'normal'
	application server.		users.
	Termination Actions		Termination Actions
	On-line accounting allows for the on-line accounting		On-line accounting allows the on-line accounting authorization
	authorization entity to terminate flows in real time. A		entity to terminate flows in real time. A termination action
	termination action defines the action to be taken by the bearer		defines the action to be taken by the network element for the
	element for the case where a flow has been terminated. For		case where a flow has been terminated. For example flow packets
	example flow packets might be dropped, might be redirected, or		might be dropped, might be redirected, or might be allowed to
	might be allowed to continue but not be counted.		continue but not be counted.
	4. Generic Requirements on a QoS Reservation Signaling Protocol		QoS signaling protocol
			A protocol used to carry QoS information between two end points
			and intercepted by entities along the path. The QoS signaling
			protocols discussed in this context follow the data path (i.e.,
			they are path-coupled).
			QoS AAA protocol
			The QoS AAA protocol runs between a network element (acting as a
			AAA client) and the resource authorizing entity (acting as a AAA
			server). For example, upon receipt of a QoS request from the
			resource requesting entity, the network element might copy
			authentication credentials and QoS flow information into a AAA
			message which is forwarded to the resource authorizing entity,
			possibly via one or more proxy AAA servers. The authorizing
			entity returns an authorization decision (yes/no) for the flow,
			and accounting data would be sent to the authorizing entity
			while the flow is active.
			Requirements for a QoS AAA Protocol October 2003
			4. Generic Requirements on a QoS Signaling Protocol
	While the details of a particular QoS signaling protocol are outside		While the details of a particular QoS signaling protocol are outside
	the scope of this document, we do list here some generic requirements		the scope of this document, we do list here some generic requirements
	that any QoS signaling protocol must meet in order to act as a front		that any QoS signaling protocol must meet in order to act as a front
	end for a QoS AAA protocol.		end for a QoS AAA protocol.
	4.1 Identity Information		4.1 Identification of Resource Authorizing Entity
	The QoS signaling protocol MUST carry information sufficient to		The QoS signaling protocol MUST carry information sufficient to
	identify an authorizing entity for a QoS request.		identify the resource authorizing entity. Note that the network
			element and the resource authorizing entity will often be in
			different administrative domains.
	For instance, the identity may be represented as the NAI of a user or		4.2 User Authentication/Authorization
	FQDN of an application server.
	4.2 Flow Information		The QoS signaling protocol MUST carry information to allow the
			authorizing entity to compute the authorization decision. In most
			cases this information will allow the authorizing entity to
			authenticate the user. Note that authentication is not necessarily
			required since authorization can also be accomplished for an
			anonymous user.
	The QoS signaling protocol MUST carry information sufficient to		Section 5.7.1 of [13] points to these requirements for the NSIS area.
	identify the application flow(s). However, the protocol MUST allow		RSVP extended the admission control procedure by adding user
	flow information to be under-specified ("wild carded") in the case		authentication as described in [14]. Additional authorization
	when specific endpoints are not known at the time of resource		capability has been added with the help of authorization tokens as
	reservation.		described in [15] and [16].
	Flow information would include elements such as IP addresses and port		It is important to provide cryptographic authentication or to protect
	numbers, so that intervening bearer elements can classify packets and		the authorization information (e.g., tokens) appropriately to counter
	give them proper QoS treatment. Also, the flow information would be		identity spoofing and attacks against the authorization information
	used when consulting the subscriber profile or application servers		(e.g., replay attacks). These attacks might lead to fraud as
	for authorization decisions.		described in [17].
	4.3 Authentication Information		4.3 Support for different authorization scenarios
	The QoS signaling protocol MUST be integrity protected.		[11] and [12] describe a two and a three party approach for computing
			the authorization decision. The QoS signaling protocol SHOULD support
			these general authorization scenarios. This wide range of
			authorization scenarios is required to make the QoS AAA protocol
			applicable in all deployment environments.
	For example, each message could carry a cryptographic message		4.4 Providing Authorization Information
	authentication code to ensure that only valid requests are granted by
	the network. This is especially important when a user is being held		The QoS signaling protocol MUST carry sufficient information between
	responsible for charges associated with a QoS session. The		the authorizing entity and the enforcing entity (and vice versa) to
	authentication information would be verified by the AAA		compute an authorization decision and to execute it.
	infrastructure before authorization is granted.
			Requirements for a QoS AAA Protocol October 2003
			This information might include flow identification, QoS objects for
			determining the authorization (in the direction to the authorizing
			entity) as well as for provisioning (in the direction from the
			authorizing entity to the enforcing entity) and price information.
			Flow information can be used for determining the authorization
			decision in those case where it meaningful.
			In many cases it MUST be possible to determine the price of the QoS
			reservation and to communicate the price to the user (or at least to
			provide sufficient information to allow the user to compute the
			price). As described in [11] one or both end-points may need to know
			the price information.
			4.5 Reauthorization
			The QoS signaling protocol MUST allow the network to trigger a
			reauthorization procedure at any time to support periodic and event
			triggered authorization.
			4.6 Integrity and Replay Protection
			The QoS signaling protocol MUST be integrity and replay protected.
			To support this requirement each signaling message would, for
			example, carry a keyed message digest to ensure that only valid
			requests are granted by the network. This is especially important
			when a user is being held responsible for charges associated with a
			QoS session. Prior to providing integrity and replay protection it
			is necessary to dynamically establish session keys. This is
			particularly important in a mobile environment as described in
			Section 7 of [11].
			Integrity and replay protection is required for NSIS as described in
			[17] (see Section 4.2 and 4.3 of [17]).
			4.7 Confidentiality Protection
			The QoS signaling protocol MUST provide confidentiality protection in
			those cases where authorization information is vulnerable to replay
			attacks. As an example, single-use authorization tokens may rely on
			the use of a secure channel. An adversary who is able to eavesdrop
			authorization tokens might be able to reuse them. They only provide a
			proof of possession and do not serve the purpose of cryptographic
			authentication where a liveness guarantee has to be provided by the
			parties executing the protocol.
			Requirements for a QoS AAA Protocol October 2003
	5. Generic Requirements on a QoS AAA Protocol		5. Generic Requirements on a QoS AAA Protocol
	In this section we list some high-level requirements that must be met		In this section we list some high-level requirements that must be met
	by any QoS AAA protocol		by a QoS AAA protocol.
	5.1 Inter-domain Support		5.1 Inter-domain Support
	The QoS AAA protocol MUST support inter-domain operation where the		The QoS AAA protocol MUST support inter-domain operation. In
	bearer elements, subscriber databases, and application servers can		particular, users may roam outside their home network, leading to a
	each belong to different administrative domains.		situation where the network element and authorizing entity are in
			different administrative domains. This implies the existence of a
			roaming agreement between the two networks. In general, one or both
			end-points involved in a communication may be roaming, meaning that
			the network elements along the data path may belong to multiple
			administrative domains, none of which are the home domain of either
			end-point.
	5.2 Identity-based Routing		5.2 Identity-based Routing
	The QoS AAA protocol MUST route AAA requests to the authorizing		The QoS AAA protocol MUST route AAA requests to the authorizing
	entity based on the identity information given in the QoS signaling		entity based on the identity information given in the QoS signaling
	protocol.		protocol.
	6. Requirements for QoS Authentication		6. Requirements for QoS Authentication
	In this section we list some QoS AAA requirements specific to		In this section we list some QoS AAA requirements specific to
	authentication.		authentication and authorization.
	6.1 Authentication Check		6.1 Flexible Authentication Support
	The QoS AAA protocol MUST support verification of authentication		The QoS AAA protocol MUST support verification of authentication
	information present in QoS signaling messages.		information present in QoS signaling messages. The QoS AAA protocol
			MUST support a variety of different authentication protocols.
			Different QoS architectures are likely to have a different security
			infrastructure with different requirements.
			The PacketCable architecture, for example, heavily utilizes Kerberos
			whereas the 3GPP architecture makes use of the UMTS AKA algorithm.
			Requirements for a QoS AAA Protocol October 2003
	7. Requirements for QoS Authorization		7. Requirements for QoS Authorization
	In this section we list some QoS AAA requirements specific to		In this section we list some QoS AAA requirements specific to
	authorization.		authorization.
	7.1 Flow Information		7.1 Making an Authorization Decision
	The QoS AAA protocol MUST carry flow information to and from the		The QoS AAA protocol MUST exchange sufficient information between the
	authorizing entity. However, the protocol MUST allow flow information		authorizing entity and the enforcing entity (and vice versa) to
	to be under-specified ("wild carded") in the case when specific		compute an authorization decision and to execute this decision.
	endpoints are not known at the time of initial resource
	authorization.
	7.2 Application State Pointer		This information might include flow identification, QoS objects for
			determining the authorization as well as for provisioning and price
			information.
			The flow identification provided to the QoS AAA protocol MUST allow
			flow information to be under-specified ("wild carded"). This might be
			the case for aggregates and when endpoints are unknown at the time of
			initial resource authorization.
			7.2 Triggering an Authorization Process
			The QoS AAA protocol MUST allow periodic and event triggered
			execution of the authorization process.
			The trigger for re-authorization might be originated at the enforcing
			entity or even at the authorizing entity. In any case it should be
			possible to carry information with the QoS AAA protocol to allow the
			enforcing or some other trusted entity to determine when to trigger
			authorization. For example, a time-based trigger, a volume-based
			trigger or even triggers based on consumed financial resources might
			lead to a reauthorization procedure.
			7.3 Associating QoS Reservations and Application State
	The QoS AAA protocol MUST carry information sufficient for an		The QoS AAA protocol MUST carry information sufficient for an
	application server to identify the appropriate application session.		application server to identify the appropriate application session.
			This allows an application session to be associated with a particular
			QoS reservation.
	Note that this requirement might be met by the same mechanism as for		Note that if flow information is sufficient to identify an
	requirement 7.1, if flow information alone is sufficient to identify		application session then no separate identifier is required. Although
	an application session.		this is not true for NSIS other QoS signaling protocols use different
			identifiers.
	7.3 Dynamic Authorization		Requirements for a QoS AAA Protocol October 2003
			7.4 Dynamic Authorization
	The QoS AAA protocol MUST support dynamic authorization; that is, it		The QoS AAA protocol MUST support dynamic authorization; that is, it
	MUST be possible to push updates towards the bearer element(s) from		MUST be possible to push updates towards the network element(s) from
	authorizing entities.		authorizing entities.
	This requirement would support runtime changes to a subscriber		This requirement would support runtime application state transitions
	profile or application state transitions that would authorize/de-		or even a change in the subscriberÆs profile that would lead to a
	authorize application flows.		different authorization state for a specific QoS reservation.
	7.4 Bearer Gating
	Even though a given flow may be authorized, some applications may		7.5 Bearer Gating
	want to toggle the flow on or off based on application state
	transitions. This control is called bearer gating. In this case, a
	capability separate from basic authorization must be provided,
	because a negative authorization indication might lead to a failure
	indication being passed during QoS signaling. Such a failure
	indication would mislead the endpoint into thinking that its request
	had been denied when in reality the bearer flow was merely
	temporarily disabled.
	The QoS AAA protocol MUST allow the authorizing entity to gate		The QoS AAA protocol MUST allow the authorizing entity to gate
	authorized application flows.		authorized application flows.
			Even though a user might received an authorization for a given flow,
			some applications may want to toggle the flow on or off based on
			application state transitions. This control is called bearer gating.
			Unlike revocation functionality, gating leaves state information
			about the QoS reservation in place and it is only temporarily
			suspended.
	8. Requirements for QoS Accounting		8. Requirements for QoS Accounting
	In this section we list some QoS AAA requirements specific to		In this section we list some QoS AAA requirements specific to
	accounting.		accounting.
	8.1 Accounting Records		8.1 Accounting Records
	The QoS AAA protocol MUST define QoS accounting records containing		The QoS AAA protocol MUST define QoS accounting records containing
	duration or volume (bytecount) usage information, or both duration		duration or volume (byte count) usage information, or both duration
	and Volume usage information. The records MUST also contain a		and volume usage information. The records MUST also contain a
	description of the QoS attributes (e.g., bandwidth, delay, loss rate)		description of the QoS attributes (e.g., bandwidth, delay, loss rate)
	that were supported for the flow.		that were supported for the flow.
	8.2 Accounting Rules		8.2 Accounting Rules
	The QoS AAA protocol MUST allow the authorizing entity to transfer		The QoS AAA protocol MUST allow the authorizing entity to transfer
	accounting rules that are applicable to specific flows. These rules		accounting rules that are applicable to specific flows. These rules
	would define the on-line ("pre-paid") versus off-line ("post-paid")		would define the on-line ("pre-paid") versus off-line ("post-paid")
	nature of the accounting as well as convey other associated		nature of the accounting as well as convey other associated
	parameters such as record identifiers, rating information, usage		parameters such as record identifiers, rating information, usage
	quota, on-line termination actions, etc.		quota, on-line termination actions, etc.
	The QoS AAA protocol MUST allow for accounting rules to be provided		The QoS AAA protocol MUST allow for accounting rules to be provided
	at authorization time as well as to be pushed later as dynamic		at authorization time as well as to be pushed later as dynamic
	updates.		updates.
			Requirements for a QoS AAA Protocol October 2003
	8.3 Sending Accounting Records		8.3 Sending Accounting Records
	The bearer element MUST send accounting records for a particular		The network element MUST send accounting records for a particular
	application flow to the authorizing entity for that flow or to		application flow to the authorizing entity for that flow or to
	another entity identified by the authorizing entity.		another entity identified by the authorizing entity.
	8.4 Loss of Bearer Notification Requirements		8.4 Failure Notification
	The QoS AAA protocol MUST allow the bearer element to report loss of		The QoS AAA protocol MUST allow the network element to report
	bearer to the authorizing entity.		failures to the authorizing entity. These failures (such as loss of
			connectivity due to movement of a mobile node or other reasons for
			packet loss) primarily address problems in the data path and do not
			cover problems with the QoS AAA protocol.
	8.5 Accounting Correlation		8.5 Accounting Correlation
	The QoS AAA protocol MUST support the exchange of sufficient		The QoS AAA protocol MUST support the exchange of sufficient
	information to allow for correlation between bearer accounting		information to allow for correlation between accounting records
	records and application accounting records.		generated by the network elements and accounting records generated by
			an application server.
	For example, an application server might create and pass an		For example, an application server might create and pass an
	accounting correlation identifier to the bearer element. This		accounting correlation identifier to the network element. This
	correlation identifier would be stored by the bearer element for		correlation identifier would then be stored for inclusion in
	inclusion in subsequent accounting records. This would allow the		subsequent accounting records. This would allow the home network to
	home network to link the bearer accounting information with		link the accounting information of the network element with those of
	application layer accounting records emitted by an application		the application server.
	server.
	9. Interaction with other AAA Applications		9. Interaction with other AAA Applications
	It is likely that an endpoint attached to a first-hop bearer element		It is likely that an endpoint attached to a first-hop network element
	was authenticated and authorized for basic, best-effort Internet		was authenticated and authorized for basic, best-effort Internet
	access prior to requesting any special QoS from the network. If the		access prior to requesting any special QoS from the network. If the
	subscriber database for basic network access is the same as the one		subscriber database for basic network access is the same as the one
	containing a QoS subscription, it may be expeditious to define some		containing a QoS subscription, it may be expeditious to define some
	interactions between the AAA protocol used for basic access (e.g.,		interactions between the AAA protocol used for basic access (e.g.,
	NASREQ [10]) and the one outlined here for QoS. For example, it may		NASREQ [10]) and the one outlined here for QoS. For example, it may
	be useful to return some QoS-related attributes to the first-hop		be useful to return some QoS-related attributes to the first-hop
	bearer element at the time the endpoint is granted basic, best-effort		network element at the time the endpoint is granted basic, best-
	access. This would allow for some future QoS requests to be granted		effort access. This would allow for some future QoS requests to be
	based on the cached profile, rather than requiring a round-trip to		granted based on the cached profile, rather than requiring a round-
	the home subscriber database. This gives rise to the following		trip to the home subscriber database. This gives rise to the
	requirement:		following requirement:
	The QoS AAA protocol MUST define a QoS profile that can be re-used in		The QoS AAA protocol MUST define a QoS profile that can be re-used in
	other AAA applications.		other AAA applications.
			Still, it must be possible to execute the QoS AAA protocol
			independently of other AAA protocols applications.
			Requirements for a QoS AAA Protocol October 2003
	Also, it may be useful to allow application servers to push QoS		Also, it may be useful to allow application servers to push QoS
	authorization information to a bearer element prior to any explicit		authorization information to a network element prior to any explicit
	request from the endpoint. This could support application endpoints		request from the endpoint. This could support application endpoints
	that do not support an explicit QoS signaling mechanism. In this		that do not support an explicit QoS signaling mechanism. In this
	case, the authorization may be pushed via the home AAA server, which		case, the authorization may be pushed via the home AAA server, which
	presumably knows to which NAS the endpoint is currently attached.		presumably knows to which NAS the endpoint is currently attached.
	Alternatively, the QoS AAA protocol may define some sort of		Alternatively, the QoS AAA protocol may define some sort of
	redirection facility that would allow application servers to send AAA		redirection facility that would allow application servers to send AAA
	messages directly to selected bearer elements such as a NAS. This		messages directly to selected network elements such as a NAS. This
	operation could be considered a special case of dynamic authorization		operation could be considered a special case of dynamic authorization
	where no explicit request for QoS was made prior to the		where no explicit request for QoS was made prior to the
	authorization:		authorization:
	The QoS AAA protocol MUST support dynamic authorization initiated by		The QoS AAA protocol MUST support dynamic authorization initiated by
	the authorizing entity.		the authorizing entity.
	10. Use Scenario		10. Scenarios
	This section provides an example use case for the proposed		This section provides a few example scenarios:
	application.
	An application in a host computer (application endpoint) wants to		An application in a mobile node wants to open a video session with a
	open a video session with a video server. The application endpoint		video server. The mobile node and the video server negotiate the
	and the video server negotiate the resources to be used for the		resources to be used for the session and for which the application
	session and for which the application will be financially		will be financially responsible. When resource negotiation has
	responsible. When negotiation of resources has completed, the video		completed, the video server stores the resource information and
	server stores the resource information and assigns a session		assigns a session identifier to the information that can be used as
	identifier to the information that can be used as the primary key for		the primary key for later information queries. This identifier has
	later information queries. This identifier is passed to the		to be known to both parties - the mobile node and the video server.
	application endpoint.
	The application endpoint makes a request for resources from the		The mobile node starts to use a QoS signaling protocol. The signaling
	bearer element. The video server and the bearer element will verify		message will hit a network element (most likely the first hop router)
	that the application endpoint has not requested more resources than		in the visited network. The video server and the network element will
			verify that the mobile node has not requested more resources than
	what were negotiated and for which the application has agreed to be		what were negotiated and for which the application has agreed to be
	financially responsible. To enable the authorization of the bearer		financially responsible. To link the application protocol session
	requested resources, the application endpoint passes the session		with this particular resource request, the mobile node passes the
	identifier received from the video server to the bearer element via		session identifier received from the video server to the network
	the QoS signaling protocol. The bearer element makes a request to		element via the QoS signaling protocol. The network element makes a
	the video server identified in the session identifier. The video		request to the video server (or some other centralized node) as
	server passes the relevant QoS state information to the bearer		identified in the session identifier. The video server passes the
	element in an answer message, associating the origin host information		relevant QoS state information to the network element in an answer
	from the request with the state information stored by the video		message, associating the origin host information from the request
	server. (This can then be used later for pushing information to the		with the state information stored by the video server. (This can
	bearer element.) Included in the answer message is an accounting		then be used later for pushing information to the network element.)
	correlation id to be included in all accounting messages from the		All accounting messages from a network entity include an accounting
	bearer entity.		correlation id.
			Requirements for a QoS AAA Protocol October 2003
	10.1 Bearer Gating		10.1 Bearer Gating
	The video server can control the flow of packets on the bearer		The video server can control the flow of packets on the network
	element by sending packet flow gating information in the answer		element by sending packet flow gating information in the answer
	message delivered for resource authorization. If the flow of packets		message delivered for resource authorization. If the flow of packets
	is not immediately enabled, some event at the video server will		is not immediately enabled, some event at the video server will
	trigger the server to enable the flow. The video server sends a		trigger the server to enable the flow. The video server sends a
	request containing flow gating information to the bearer element to		request containing flow gating information to the network element to
	allow the flow of packets. The bearer element returns the state of		allow the flow of packets. The network element returns the state of
	the packet flow in the response message to the video server.		the packet flow in the response message to the video server.
	10.2 Loss of Bearer		10.2 Loss of Connectivity
	The bearer element determines that bearer connectivity of the		The network element determines connectivity to the end host has been
	application flow has been lost. The video server needs this		lost. The video server needs this information in order to take
	information in order to take corrective action, charge appropriately,		corrective action, charge appropriately, and/or release resources
	and/or release resources associated with the session. The bearer		associated with the session. The network element informs the video
	element informs the video server of the loss of bearer in a request		server of the loss of connectivity in a request message containing
	message containing bearer state information. The video server		state information of the network element. The video server
	acknowledges the request in an answer message. The video server may		acknowledges the request in an answer message. The video server may
	then issue a session abort request message to other network		then issue a session abort request message to other network
	functional entities.		functional entities.
	11. Security Considerations		11. Security Considerations
	The QoS AAA protocol whose requirements are given in this draft		The QoS AAA protocol whose requirements are given in this draft
	assumes that a security relationship exists between the authorizing		assumes that a trust relationship exists between the authorizing
	entity (the home AAA server or application server) and the bearer		entity and the network element. This trust relationship does not need
	element (AAA client). This relationship implies that the bearer		to be pre-existing at the protocol startup but could also be
	element should grant service based on the say-so of the authorizing		dynamically established. The relationship may be direct or it may be
	entity, presumably because the used resources will be paid for in		indirect via a AAA cloud consisting of brokers and proxies. Each
	some later settlement phase. The relationship may be direct or it		link in this chain of relationships MUST be secured to prevent
	may be indirect via a AAA cloud consisting of brokers and proxies.
	Each link in this chain of relationships MUST be secured to prevent
	spoofed authorizations.		spoofed authorizations.
			This relationship implies that the bearer element should grant
			service based on the decision of the authorizing entity, presumably
			because the used resources will be paid for. The establishment of a
			trust relationship between the involved networks therefore also
			implies the setup of a financial settlement.
	The authentication outlined in Section 6 MUST be cryptographically		The authentication outlined in Section 6 MUST be cryptographically
	strong and protected against replay and other attacks.		strong and protected against replay and other attacks. Various
			threats against a QoS signaling protocol (and on the AAA
			infrastructure) are described in [17].
	Once QoS resources have been authorized, it may be possible for an		Once QoS resources have been authorized, it may be possible for an
	unauthorized party to subvert them for its own use. Steps MUST be		unauthorized party to subvert them for its own use. Steps MUST be
	taken to bind the authorization to the actual flow of packets using		taken to prevent an adversary from injecting or spoofing data
	the QoS bearer in the bearer element. Actual mechanisms applied to		packets, which could then receive preferred treatment (i.e., steal
	the bearer traffic for this purpose might include, e.g., ingress		Requirements for a QoS AAA Protocol October 2003
	filtering and/or IPSec, but in general are beyond the scope of a QoS
	AAA protocol.		other user's QoS resources). Although beyond the scope of this
			document cryptographic protection of the data traffic should be
			considered either at the network or at the link layer.
			Among other things, Section 9 implies to off-load some authorization
			decisions from the user's home network to the visted network. Making
			the user's profile available to entities outside the home network
			might raise some privacy concerns.
	12. Reference		12. Reference
	[1] Bradner, S., "The Internet Standards Process -- Revision 3",		[1] Bradner, S., "The Internet Standards Process -- Revision 3",
	BCP 9, RFC 2026, October 1996.		BCP 9, RFC 2026, October 1996.
	[2] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S.,		[2] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S.,
	"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional		"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
	Specification", RFC 2205, September 1997.		Specification", RFC 2205, September 1997.
	[3] Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J., and		[3] Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J., and
	Van den Bosch, S., "Next Steps in Signaling: Framework", draft-		Van den Bosch, S., "Next Steps in Signaling: Framework",
	ietf-nsis-fw-02.txt, March 2003. Work In Progress.		Internet Draft, Internet Engineering Task Force, September
			2003. Work in progress.
	[4] 3GPP TS 29.208, "End-to-end Quality of Service (QoS) Signaling		[4] 3GPP TS 29.208, "End-to-end Quality of Service (QoS) Signaling
	Flows", April 2003.		Flows", April 2003.
	[5] 3GPP TS 29.207, "Policy control over Go interface", March 2003.		[5] 3GPP TS 29.207, "Policy control over Go interface", March 2003.
	[6] 3GPP2 C.S0017-0 (also TIA IS-707-A), "Data Service Options for		[6] 3GPP2 C.S0017-0 (also TIA IS-707-A), "Data Service Options for
	Spread Spectrum Systems."		Spread Spectrum Systems."
	[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R., Handley, M., and Schooler, E., "SIP:		Peterson, J., Sparks, R., Handley, M., and Schooler, E., "SIP:
	Session Initiation Protocol", RFC 3261, June 2002.		Session Initiation Protocol", RFC 3261, June 2002.
	[8] Handley, M., Jacobson, V., Perkins, C., "SDP: Session		[8] Handley, M., Jacobson, V., Perkins, C., "SDP: Session
	Description Protocol", draft-ietf-mmusic-sdp-new-13.txt, May		Description Protocol", Internet Draft, Internet Engineering
	2003. Work In Progress.		Task Force, September 2003. Work In Progress.
	[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[10] Calhoun, P., Zorn, G., Spence, D., Mitton, D., "Diameter		[10] Calhoun, P., Zorn, G., Spence, D., Mitton, D., "Diameter
	Network Access Server Application", draft-ietf-aaa-diameter-		Network Access Server Application", Internet Draft, Internet
	nasreq-11.txt, February, 2003. Work In Progress.		Engineering Task Force, October, 2003. Work In Progress.
			[11] H. Tschofenig, M. Buechli, S. Van den Bosch and H. Schulzrinne:
			"NSIS Authentication, Authorization and Accounting Issues",
			Requirements for a QoS AAA Protocol October 2003
			Internet Draft, Internet Engineering Task Force, March 2003.
			Work in progress.
			[12] H. Tschofenig, M. Buechli, S. Van den Bosch, H. Schulzrinne and
			T. Chen: "QoS NSLP Authorization Issues", Internet Draft,
			Internet Engineering Task Force, June 2003. Work in progress.
			[13] M. Brunner: "Requirements for QoS signaling protocols",
			Internet Draft, Internet Engineering Task Force, August 2003.
			Work in progress.
			[14] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
			Herzog, S., Hess, R.: "Identity Representation for RSVP", RFC
			3182, October, 2001.
			[15] L. Hamer, B. Gage, and H. Shieh: "Framework for session set-up
			with media authorization," RFC 3521, Internet Engineering Task
			Force, April 2003.
			[16] L. Hamer, B. Gage, B. Kosinski, and H. Shieh: "Session
			Authorization Policy Element", RFC 3520, Internet Engineering
			Task Force, April 2003.
			[17] Tschofenig, H. and D. Kroeselberg: "Security Threats for NSIS",
			Internet Draft, Internet Engineering Task Force, June 2003.
	13. Author's Addresses		13. Author's Addresses
	Frank M. Alfano		Frank M. Alfano
	Lucent Technologies		Lucent Technologies
	Rm 9C-226L		Rm 9C-226L
	1960 Lucent Lane		1960 Lucent Lane
	Naperville, IL 60563		Naperville, IL 60563
	Phone: +1 630 979 7209		Phone: +1 630 979 7209
	Email: falfano@lucent.com		Email: falfano@lucent.com
	Peter J. McCann		Peter J. McCann
	Lucent Technologies		Lucent Technologies
	Rm 9C-226R		Rm 9C-226R
	1960 Lucent Lane		1960 Lucent Lane
	Naperville, IL 60563		Naperville, IL 60563
	Phone: +1 630 713 9359		Phone: +1 630 713 9359
	Email: mccap@lucent.com		Email: mccap@lucent.com
			Requirements for a QoS AAA Protocol October 2003
	Thomas T. Towle		Thomas T. Towle
	Lucent Technologies		Lucent Technologies
	Rm 9C-229		Rm 9C-229
	1960 Lucent Lane		1960 Lucent Lane
	Naperville, IL 60563		Naperville, IL 60563
	Phone: +1 630 979 7303		Phone: +1 630 979 7303
	Email: ttowle@lucent.com		Email: ttowle@lucent.com
	Richard Ejzak		Richard Ejzak
	Lucent Technologies		Lucent Technologies
	Rm 7H-245		Rm 7H-245
	1960 Lucent Lane		1960 Lucent Lane
	Naperville, IL 60563		Naperville, IL 60563
	Phone: +1 630 979 7036		Phone: +1 630 979 7036
	Email: ejzak@lucent.com		Email: ejzak@lucent.com
			Hannes Tschofenig
			Siemens AG
			Otto-Hahn-Ring 6
			81739 Munich
			Germany
			EMail: Hannes.Tschofenig@siemens.com
	Intellectual Property Statement		Intellectual Property Statement
	At the time of submission the authors are not aware of any		At the time of submission the authors are not aware of any
	intellectual property rights that pertain to the implementation or		intellectual property rights that pertain to the implementation or
	use of the technology described in this document. However, this does		use of the technology described in this document. However, this does
	not preclude the possibility that Lucent Technologies, Inc. or other		not preclude the possibility that Lucent Technologies, Inc. or other
	entities may have such rights. The patent licensing policy of Lucent		entities may have such rights. The patent licensing policy of Lucent
	Technologies, Inc. is on file with the IETF Secretariat.		Technologies, Inc. is on file with the IETF Secretariat.
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	skipping to change at page 15, line 43 ¶		skipping to change at page 18, line 5 ¶
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the		has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and		IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of		standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication and any assurances of		claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		licenses to be made available, or the result of an attempt made to
	obtain a general license or permission for the use of such		obtain a general license or permission for the use of such
	proprietary rights by implementers or users of this specification can		proprietary rights by implementers or users of this specification can
	be obtained from the IETF Secretariat.		be obtained from the IETF Secretariat.
			Requirements for a QoS AAA Protocol October 2003
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to practice		rights that may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved. This		Copyright (C) The Internet Society (2003). All Rights Reserved. This
	document and translations of it may be copied and furnished to		document and translations of it may be copied and furnished to
End of changes. 81 change blocks.
	346 lines changed or deleted		489 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/