wdiff draft-alfano-aaa-qosreq-00.txt draft-alfano-aaa-qosreq-01.txt

Authentication, Authorization and Accounting Frank M. Alfano
Internet Draft Peter J. McCann
Document: draft-alfano-aaa-qosreq-00.txt draft-alfano-aaa-qosreq-01.txt Tom Towle
Expires: December 2003 April 2004 Richard Ejzak
Lucent Technologies
June
Hannes Tschofenig
Siemens
October 2003

Requirements for a QoS AAA Protocol

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. 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.

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."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document describes requirements for a protocol that would
perform Authentication, Authorization, and Accounting for Quality-of-
Service reservations. This Such a protocol would be used by elements along
the path of a given application flow entities to
authenticate a user's reservation request, to ensure that the
reservation is authorized, authorized and to account
for resources used during provide accounting functionality.

The requirements covered in this document primarily address the life
communication of the application flow. A QoS AAA protocol should also support dynamic authorization of QoS as a
function of application protocols and account state. While we assume not the
existence of some QoS reservation protocol to allow endpoints signaling protocols,
although they have to
request QoS from network elements, complete requirements for such a
protocol are outside the scope provide some degree of this document and interworking. Therefore,
we list a QoS AAA
protocol could be used to support more than one kind minimal set of reservation
protocol. A requirements on supported QoS AAA protocol could be used between any bearer-level
network element that lies along the path of an application flow and
an application server that lies anywhere in the network, allowing signaling
protocols.

Requirements for a wide variety of flexible service deployment models. QoS AAA Protocol October 2003

Table of Contents

1. Introduction...................................................2
1.1 QoS Signaling..............................................3
1.2 Architecture...............................................3
2. Conventions used in this document..............................6 Keywords.......................................................5
3. Term Definitions...............................................6 Terminology....................................................5
4. Generic Requirements on a QoS Reservation Signaling Protocol...7 Protocol...............7
4.1 Identity Information.......................................7 User Authentication/Authorization..........................7
4.2 Flow Information...........................................7 Support for different authorization scenarios..............7
4.3 Authentication Information.................................8 Providing Authorization Information........................7
4.4 Reauthorization............................................8
4.5 Integrity and Replay Protection............................8
4.6 Confidentiality Protection.................................8
5. Generic Requirements on a QoS AAA Protocol.....................8 Protocol.....................9
5.1 Inter-domain Support.......................................8 Support.......................................9
5.2 Identity-based Routing.....................................8 Routing.....................................9
6. Requirements for QoS Authentication............................8 Authentication............................9
6.1 Flexible Authentication Check.......................................8 Support............................9
7. Requirements for QoS Authorization.............................9 Authorization............................10
7.1 Flow Information...........................................9 Making an Authorization Decision..........................10
7.2 Application State Pointer..................................9 Triggering an Authorization Process.......................10
7.3 Dynamic Authorization......................................9 Associating QoS Reservations and Application State........10
7.4 Dynamic Authorization.....................................11
7.5 Bearer Gating..............................................9 Gating.............................................11
8. Requirements for QoS Accounting...............................10 Accounting...............................11
8.1 Accounting Records........................................10 Records........................................11
8.2 Accounting Rules..........................................10 Rules..........................................11
8.3 Sending Accounting Records................................10 Records................................12
8.4 Loss of Bearer Notification Requirements..................10 Failure Notification......................................12
8.5 Accounting Correlation....................................11 Correlation....................................12
9. Interaction with other AAA Applications.......................11 Applications.......................12
10. Use Scenario.................................................12 Scenario.................................................13
10.1 Bearer Gating............................................12 Gating............................................14
10.2 Loss of Bearer...........................................13 Connectivity.....................................14
11. Security Considerations......................................13 Considerations......................................14
12. Reference....................................................13 References...................................................15
13. Author's Addresses...........................................14 Addresses...........................................16

1. Introduction

To meet the quality-of-service needs of applications such as voice-
over-IP, it will often be necessary to explicitly request resources
from the network. This will allow the network to identify packets
belonging to such application flows and ensure that bandwidth, delay,
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
resulting high packet drop rates.

Not every network deployment requires explicit reservation: for
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

1.1 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. Signaling

A variety of protocols could can be used to signal QoS information and to
make a reservation request, reservation, such as:

1. RSVP.
2. NSIS.
3. Link-specific means.
4. SIP/SDP.

The most obvious choice, as RSVP, NSIS, SIP/SDP or link-layer
specific mechanisms.

RSVP [2], [2] is the existing IETF-defined
reservation protocol. For a variety of reasons, RSVP has not seen
widespread deployment as an end-to-end reservation QoS signaling protocol. The new
Next Steps in Signaling (NSIS) work working group [3] is currently being undertaken
may address some of these issues.
developing a general signaling model based on two-layer architecture.

In the meantime, deployments such as 3rd generation cellular networks
are defining their own reservation procedures: these include link-specific link-
layer 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 This list can easily be extended.

In other areas QoS signaling mechanisms are often tightly coupled to
the application, and in application signaling. In the 3GPP/3GPP2 IP Multimedia Core
Network subsystems, one could even say
that subsystems the Session Initiation Protocol (SIP) [7] and
Session Description Protocol (SDP) [8] are essentially 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 Special purpose
protocols are often cited for the
tight coupling. First, application knowledge is sometimes needed to
authorize the use of bearer resources; for example, a SIP-layer
application might authorize (and later, account for and charge) the
use of the bearer on behalf of a party other than the one requesting
it. Also, the application server might enable/disable ("gate") the
bearer flow according to the high-level state of the call. Second,
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 for communication between application and
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
becomes more difficult.
* Deployment of some new applications requires close coordination
with the
network operator.
* It becomes impossible to handle mobility at elements.

1.2 Architecture

This draft describes requirements on a AAA protocol for QoS
reservations stemming from the new (primarily wireless) network layer
when a change
deployments in the bearer element point light of attachment recent efforts to revisit QoS signaling
within the
Internet requires a change in the associated SIP server.
* Use of protocols other than SIP to establish sessions becomes
impossible.

All of these drawbacks can be viewed as a result of the conflict
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 IETF. The goal is to interfere with
network-layer functionality.

To meet the these requirements of network
operators while at the same time
preserving the best of the end-to-end Internet service model, we
propose that supporting a AAA protocol be developed that can be used by bearer
elements to authenticate, authorize, variety of QoS
signaling protocols and account avoiding the need for individual
application flows that require QoS. monolithic, vertically
integrated applications (such as e.g., a SIP proxy server in every
router). A high-level picture of the resulting architecture is shown
in Figure 1.

+------+ +------+
| Subs | | |

Requirements for a QoS AAA Protocol October 2003

+-------------+
| DB Resource |
| AS Authorizing |
| Entity |
+-----+-------+
|
|
+---\--+ +---/--+
\ /
\ /
/-\----------/\
/-\----+-----/\
//// \\\\
|| ||
| AAA Cloud |
|| ||
\\\\ ////
\-------+-----/
|
+-------------+ +---+--+
| Entity | Application | |
Flow ===============+ BE
| Requesting |<<=================+ NE +==========>>
| Resource | Flow | |
+-------------+ +------+
Figure 1. An architecture supporting QoS-AAA 1: Architecture

Figure 1 depicts an entity requesting a bearer resource, a network element
(NE) through which application flows need to pass, pass (i.e., an entity
which enforces the QoS reservation), a cloud of AAA servers, 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, and records is located. This is often the entity that executes
the authorization decision. Finally, there might be an interaction
with an application server. Here signaling protocol.

Note that the entity authorizing the QoS reservation request might be
a AAA server, an application server or another entity. These entities
are collectively referred as the "Resource Authorizing Entity" in
Figure 1.

The term "AAA Cloud" is used to refer to the network of AAA proxy/broker
arrangements that may be in place. Also, note that proxies
and brokers. Furthermore, there may might be more than one bearer network
element that needs to interact with the AAA cloud
along the path of a given application flow, infrastructure although the figure only
Figure 1 depicts only one for clarity. Similarly, a given user may might
support different authentication methods; he might have subscriber
records stored in more than one place and
home network; or, he might make use different means 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. authorization.

The remainder of this document outlines high-level requirements for
the QoS AAA protocol. 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 a small number of some generic requirements on for a QoS reservation 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
AAA applications.
Section 10 gives an example use scenario.
Finally, Section 11 outlines some security considerations.

2. Conventions used in this document Keywords

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 [9].

3. Term Definitions Terminology

Accounting Rules
An accounting rule is a collection of data that identifies one
or more IP flows and provides related information. An accounting
rule defines the accounting treatment such as on-line (i.e.,
pre-paid) or off-
line off-line accounting. The data may also identify,
for example, volume or time based accounting, rating
information, termination actions for on-line accounting (e.g.,
drop or re-route packets), record correlation identifiers, etc.

Application Server
An application server is a network entity that exchanges
signaling messages with an application endpoint. It may be a
source of authorization for QoS-enhanced application flows. For
example, a SIP server is one kind of application server.

Application Endpoint
An application endpoint is an entity in an end user device that
exchanges signaling messages with application servers or
directly with other application endpoints. Based on the result
of this signaling, the endpoint will make a request for QoS from
the network. For example, a SIP User Agent is one kind of
application endpoint.

Authorizing Entity
The authorizing entity is that entity responsible for
authorizing QoS requests for a particular application flow.
This may be a home AAA server (with a subscriber database database) or an
application server.

Bearer server or some other entity.

Requirements for a QoS AAA Protocol October 2003

Network Element
A bearer network element is a network entity such as an IP router on
the path between two endpoints, through which IP packets
belonging to application flows pass. Note that Typically only a small
subset of the bearer network elements along a path are required to process and authorize communicates with
the AAA infrastructure for the purpose of QoS
requests. authorization. In
a typical service provider scenario, the first-hop router (NAS) 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
A Subscriber Database holds information related to network users
such as what services they information about their subscribed service. A user
might, for example, have signed up for. In particular, a
user may subscribe to QoS independent of any application, which
would enable authorization subscription for a 'gold' service
that authorizes him for higher QoS without consultation of an
application server. parameters than 'normal'
users.

Termination Actions
On-line accounting allows for the on-line accounting authorization
entity to terminate flows in real time. A termination action
defines the action to be taken by the bearer network element for the
case where a flow has been terminated. For example flow packets
might be dropped, might be redirected, or might be allowed to
continue but not be counted.

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 Reservation Signaling Protocol

While the details of a particular QoS signaling protocol are outside
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
end for a QoS AAA protocol.

4.1 Identity Information Identification of Resource Authorizing Entity

The QoS signaling protocol MUST carry information sufficient to
identify an the resource authorizing entity for a QoS request.

For instance, entity. Note that the identity may be represented as network
element and the NAI of a user or
FQDN of an application server. resource authorizing entity will often be in
different administrative domains.

4.2 Flow Information User Authentication/Authorization

The QoS signaling protocol MUST carry information sufficient to
identify allow the application flow(s). However,
authorizing entity to compute the protocol MUST allow
flow authorization decision. In most
cases this information will allow the authorizing entity to be under-specified ("wild carded") in
authenticate the case
when specific endpoints are user. Note that authentication is not known at necessarily
required since authorization can also be accomplished for an
anonymous user.

Section 5.7.1 of [13] points to these requirements for the time NSIS area.
RSVP extended the admission control procedure by adding user
authentication as described in [14]. Additional authorization
capability has been added with the help of resource
reservation.

Flow authorization tokens as
described in [15] and [16].

It is important to provide cryptographic authentication or to protect
the authorization information would include elements such (e.g., tokens) appropriately to counter
identity spoofing and attacks against the authorization information
(e.g., replay attacks). These attacks might lead to fraud as IP addresses
described in [17].

4.3 Support for different authorization scenarios

[11] and port
numbers, so that intervening bearer elements can classify packets [12] describe a two and
give them proper a three party approach for computing
the authorization decision. The QoS treatment. Also, 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.

4.4 Providing Authorization Information

The QoS signaling protocol MUST carry sufficient information between
the authorizing entity and the enforcing entity (and vice versa) to
compute an authorization decision and to execute it.

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 would can be used when consulting the subscriber profile or application servers for determining the authorization decisions.

4.3 Authentication Information
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.

For example,

To support this requirement each signaling message could would, for
example, carry a cryptographic keyed message
authentication code 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
authentication QoS signaling protocol MUST provide confidentiality protection in
those cases where authorization information would 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 verified provided by the
parties executing the protocol.

Requirements for a QoS AAA
infrastructure before authorization is granted. Protocol October 2003

5. Generic Requirements on a QoS AAA Protocol

In this section we list some high-level requirements that must be met
by any a QoS AAA protocol protocol.

5.1 Inter-domain Support

The QoS AAA protocol MUST support inter-domain operation operation. In
particular, users may roam outside their home network, leading to a
situation where the
bearer elements, subscriber databases, network element and application servers can
each belong to 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

The QoS AAA protocol MUST route AAA requests to the authorizing
entity based on the identity information given in the QoS signaling
protocol.

6. Requirements for QoS Authentication

In this section we list some QoS AAA requirements specific to
authentication.
authentication and authorization.

6.1 Flexible Authentication Check Support

The QoS AAA protocol MUST support verification of authentication
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

In this section we list some QoS AAA requirements specific to
authorization.

7.1 Flow Information Making an Authorization Decision

The QoS AAA protocol MUST carry flow exchange sufficient information between the
authorizing entity and the enforcing entity (and vice versa) to
compute an authorization decision and from to execute this decision.

This information might include flow identification, QoS objects for
determining the
authorizing entity. However, 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") in carded"). This might be
the case for aggregates and when specific endpoints are not known 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 Pointer

The QoS AAA protocol MUST carry information sufficient for an
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
requirement 7.1, if flow information alone is sufficient to identify an
application session.

7.3 session then no separate identifier is required. Although
this is not true for NSIS other QoS signaling protocols use different
identifiers.

Requirements for a QoS AAA Protocol October 2003

7.4 Dynamic Authorization

The QoS AAA protocol MUST support dynamic authorization; that is, it
MUST be possible to push updates towards the bearer network element(s) from
authorizing entities.

This requirement would support runtime changes to a subscriber
profile or application state transitions
or even a change in the subscriber�s profile that would authorize/de-
authorize application flows.

7.4 lead to a
different authorization state for a specific QoS reservation.

7.5 Bearer Gating

The QoS AAA protocol MUST allow the authorizing entity to gate
authorized application flows.

Even though a user might received an authorization for a given flow may be authorized, flow,
some applications may 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
Unlike revocation functionality, gating leaves state information
about the endpoint into thinking that its request
had been denied when QoS reservation in reality the bearer flow was merely place and it is only temporarily disabled.

The QoS AAA protocol MUST allow the authorizing entity to gate
authorized application flows.
suspended.

8. Requirements for QoS Accounting

In this section we list some QoS AAA requirements specific to
accounting.

8.1 Accounting Records

The QoS AAA protocol MUST define QoS accounting records containing
duration or volume (bytecount) (byte count) usage information, or both duration
and Volume volume usage information. The records MUST also contain a
description of the QoS attributes (e.g., bandwidth, delay, loss rate)
that were supported for the flow.

8.2 Accounting Rules

The QoS AAA protocol MUST allow the authorizing entity to transfer
accounting rules that are applicable to specific flows. These rules
would define the on-line ("pre-paid") versus off-line ("post-paid")
nature of the accounting as well as convey other associated
parameters such as record identifiers, rating information, usage
quota, on-line termination actions, etc.

The QoS AAA protocol MUST allow for accounting rules to be provided
at authorization time as well as to be pushed later as dynamic
updates.

Requirements for a QoS AAA Protocol October 2003

8.3 Sending Accounting Records

The bearer network element MUST send accounting records for a particular
application flow to the authorizing entity for that flow or to
another entity identified by the authorizing entity.

8.4 Loss of Bearer Failure Notification Requirements

The QoS AAA protocol MUST allow the bearer network element to report loss of
bearer
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

The QoS AAA protocol MUST support the exchange of sufficient
information to allow for correlation between bearer accounting records
generated by the network elements and application accounting records. records generated by
an application server.

For example, an application server might create and pass an
accounting correlation identifier to the bearer network element. This
correlation identifier would then be stored by the bearer element for inclusion in
subsequent accounting records. This would allow the home network to
link the bearer accounting information of the network element with
application layer accounting records emitted by an those of
the application server.

9. Interaction with other AAA Applications

It is likely that an endpoint attached to a first-hop bearer network element
was authenticated and authorized for basic, best-effort Internet
access prior to requesting any special QoS from the network. If the
subscriber database for basic network access is the same as the one
containing a QoS subscription, it may be expeditious to define some
interactions between the AAA protocol used for basic access (e.g.,
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
bearer
network element at the time the endpoint is granted basic, best-effort best-
effort access. This would allow for some future QoS requests to be
granted based on the cached profile, rather than requiring a round-trip round-
trip to the home subscriber database. This gives rise to the
following requirement:

The QoS AAA protocol MUST define a QoS profile that can be re-used in
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
authorization information to a bearer network element prior to any explicit
request from the endpoint. This could support application endpoints
that do not support an explicit QoS signaling mechanism. In this
case, the authorization may be pushed via the home AAA server, which
presumably knows to which NAS the endpoint is currently attached.
Alternatively, the QoS AAA protocol may define some sort of
redirection facility that would allow application servers to send AAA
messages directly to selected bearer network elements such as a NAS. This
operation could be considered a special case of dynamic authorization
where no explicit request for QoS was made prior to the
authorization:

The QoS AAA protocol MUST support dynamic authorization initiated by
the authorizing entity.

10. Use Scenario Scenarios

This section provides an a few example use case for the proposed
application. scenarios:

An application in a host computer (application endpoint) mobile node wants to open a video session with a
video server. The application endpoint mobile node and the video server negotiate the
resources to be used for the session and for which the application
will be financially responsible. When resource negotiation of resources has
completed, the video server stores the resource information and
assigns a session identifier to the information that can be used as
the primary key for later information queries. This identifier is passed has
to be known to both parties - the
application endpoint. mobile node and the video server.

The application endpoint makes mobile node starts to use a request for resources from QoS signaling protocol. The signaling
message will hit a network element (most likely the
bearer element. first hop router)
in the visited network. The video server and the bearer network element will
verify that the application endpoint mobile node has not requested more resources than
what were negotiated and for which the application has agreed to be
financially responsible. To enable the authorization of the bearer
requested resources, link the application endpoint protocol session
with this particular resource request, the mobile node passes the
session identifier received from the video server to the bearer network
element via the QoS signaling protocol. The bearer network element makes a
request to the video server (or some other centralized node) as
identified in the session identifier. The video server passes the
relevant QoS state information to the bearer network element in an answer
message, associating the origin host information from the request
with the state information stored by the video server. (This can
then be used later for pushing information to the
bearer network element.) Included in the answer message is an accounting
correlation id to be included in all
All accounting messages from the
bearer entity. a network entity include an accounting
correlation id.

Requirements for a QoS AAA Protocol October 2003

10.1 Bearer Gating

The video server can control the flow of packets on the bearer network
element by sending packet flow gating information in the answer
message delivered for resource authorization. If the flow of packets
is not immediately enabled, some event at the video server will
trigger the server to enable the flow. The video server sends a
request containing flow gating information to the bearer network element to
allow the flow of packets. The bearer network element returns the state of
the packet flow in the response message to the video server.

10.2 Loss of Bearer Connectivity

The bearer network element determines that bearer connectivity of to the
application flow end host has been
lost. The video server needs this information in order to take
corrective action, charge appropriately, and/or release resources
associated with the session. The bearer network element informs the video
server of the loss of bearer connectivity in a request message containing bearer
state information. information of the network element. The video server
acknowledges the request in an answer message. The video server may
then issue a session abort request message to other network
functional entities.

11. Security Considerations

The QoS AAA protocol whose requirements are given in this draft
assumes that a security trust relationship exists between the authorizing
entity (the home AAA server or application server) and the bearer
element (AAA client). network element. This trust relationship implies that the bearer
element should grant service based on the say-so of the authorizing
entity, presumably because does not need
to be pre-existing at the used resources will protocol startup but could also be paid for in
some later settlement phase.
dynamically established. The relationship may be direct or it 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.

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
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
unauthorized party to subvert them for its own use. Steps MUST be
taken to bind prevent an adversary from injecting or spoofing data
packets, which could then receive preferred treatment (i.e., steal
Requirements for a QoS AAA Protocol October 2003

other user's QoS resources). Although beyond the authorization 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 actual flow of packets using user's home network to the QoS bearer in visted network. Making
the bearer element. Actual mechanisms applied user's profile available to entities outside the bearer traffic for this purpose home network
might include, e.g., ingress
filtering and/or IPSec, but in general are beyond the scope of a QoS
AAA protocol. raise some privacy concerns.

12. Reference

[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.

[2] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S.,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.

[3] Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J., and
Van den Bosch, S., "Next Steps in Signaling: Framework", draft-
ietf-nsis-fw-02.txt, March
Internet Draft, Internet Engineering Task Force, September
2003. Work In Progress. in progress.

[4] 3GPP TS 29.208, "End-to-end Quality of Service (QoS) Signaling
Flows", April 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
Spread Spectrum Systems."

[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and Schooler, E., "SIP:
Session Initiation Protocol", RFC 3261, June 2002.

[8] Handley, M., Jacobson, V., Perkins, C., "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-13.txt, May Internet Draft, Internet Engineering
Task Force, September 2003. Work In Progress.

[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[10] Calhoun, P., Zorn, G., Spence, D., Mitton, D., "Diameter
Network Access Server Application", draft-ietf-aaa-diameter-
nasreq-11.txt, February, Internet Draft, Internet
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

Frank M. Alfano
Lucent Technologies
Rm 9C-226L
1960 Lucent Lane
Naperville, IL 60563
Phone: +1 630 979 7209
Email: falfano@lucent.com

Peter J. McCann
Lucent Technologies
Rm 9C-226R
1960 Lucent Lane
Naperville, IL 60563
Phone: +1 630 713 9359
Email: mccap@lucent.com
Requirements for a QoS AAA Protocol October 2003

Thomas T. Towle
Lucent Technologies
Rm 9C-229
1960 Lucent Lane
Naperville, IL 60563
Phone: +1 630 979 7303
Email: ttowle@lucent.com

Richard Ejzak
Lucent Technologies
Rm 7H-245
1960 Lucent Lane
Naperville, IL 60563
Phone: +1 630 979 7036
Email: ejzak@lucent.com

Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
EMail: Hannes.Tschofenig@siemens.com

Intellectual Property Statement

At the time of submission the authors are not aware of any
intellectual property rights that pertain to the implementation or
use of the technology described in this document. However, this does
not preclude the possibility that Lucent Technologies, Inc. or other
entities may have such rights. The patent licensing policy of Lucent
Technologies, Inc. is on file with the IETF Secretariat.

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies 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
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
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
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.

Full Copyright Statement

Copyright (C) The Internet Society (2003). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.