[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Authentication, Authorization and Accounting            Frank M. Alfano
Internet Draft                                          Peter J. McCann
Document: draft-alfano-aaa-qosreq-01.txt                      Tom Towle
Expires: April 2004                                       Richard Ejzak
                                                    Lucent Technologies
                                                      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.  Such a protocol would be used by entities to
   authenticate a user's reservation request, to ensure that the
   reservation is authorized and to provide accounting functionality.

   The requirements covered in this document primarily address the
   communication of AAA protocols and not the QoS signaling protocols,
   although they have to provide some degree of interworking. Therefore,
   we list a minimal set of requirements on supported QoS signaling
   protocols.






Alfano, et al.           Expires - April 2004                 [Page 1]


                 Requirements for a QoS AAA Protocol     October 2003



Table of Contents

   1. Introduction...................................................2
      1.1 QoS Signaling..............................................3
      1.2 Architecture...............................................3
   2. Keywords.......................................................5
   3. Terminology....................................................5
   4. Generic Requirements on a QoS Signaling Protocol...............7
      4.1 User Authentication/Authorization..........................7
      4.2 Support for different authorization scenarios..............7
      4.3 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.....................9
      5.1 Inter-domain Support.......................................9
      5.2 Identity-based Routing.....................................9
   6. Requirements for QoS Authentication............................9
      6.1 Flexible Authentication Support............................9
   7. Requirements for QoS Authorization............................10
      7.1 Making an Authorization Decision..........................10
      7.2 Triggering an Authorization Process.......................10
      7.3 Associating QoS Reservations and Application State........10
      7.4 Dynamic Authorization.....................................11
      7.5 Bearer Gating.............................................11
   8. Requirements for QoS Accounting...............................11
      8.1 Accounting Records........................................11
      8.2 Accounting Rules..........................................11
      8.3 Sending Accounting Records................................12
      8.4 Failure Notification......................................12
      8.5 Accounting Correlation....................................12
   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

   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



Alfano et al.            Expires - April 2003                 [Page 2]


                 Requirements for a QoS AAA Protocol     October 2003


   on individual flows, the network can avoid congestion and the
   resulting high packet drop rates.

1.1 QoS Signaling

   A variety of protocols can be used to signal QoS information and to
   make a reservation, such as RSVP, NSIS, SIP/SDP or link-layer
   specific mechanisms.

   RSVP [2] is the existing IETF-defined QoS signaling protocol. The
   Next Steps in Signaling (NSIS) working group [3] is currently
   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-
   layer specific means, such as the PDP Context Activation procedures
   of 3GPP [4,5] or the service instance establishment procedures of
   3GPP2 [6]. This list can easily be extended.

   In other areas QoS signaling mechanisms are often tightly coupled to
   the application signaling. In the 3GPP/3GPP2 IP Multimedia Core
   Network subsystems the Session Initiation Protocol (SIP) [7] and
   Session Description Protocol (SDP) [8] are essentially being used to
   request resource reservations from the network. Special purpose
   protocols are used for communication between the SIP servers and
   network elements.

1.2 Architecture

   This draft describes requirements on a AAA protocol for QoS
   reservations stemming from the new (primarily wireless) network
   deployments in light of recent efforts to revisit QoS signaling
   within the IETF. The goal is to meet these requirements of network
   operators while at the same time supporting a variety of QoS
   signaling protocols and avoiding the need for 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.













Alfano et al.            Expires - April 2003                 [Page 3]


                 Requirements for a QoS AAA Protocol     October 2003


                                        +-------------+
                                        | Resource    |
                                        | Authorizing |
                                        | Entity      |
                                        +-----+-------+
                                              |
                                              |
                                       /-\----+-----/\
                                   ////               \\\\
                                 ||                       ||
                                |         AAA Cloud         |
                                 ||                       ||
                                   \\\\               ////
                                       \-------+-----/
                                               |
         +-------------+                   +---+--+
         |  Entity     |    Application    |      |
         |  Requesting |<<=================+  NE  +==========>>
         |  Resource   |       Flow        |      |
         +-------------+                   +------+
                         Figure 1: Architecture

   Figure 1 depicts an entity requesting a resource, a network element
   (NE) through which application flows need to pass (i.e., an entity
   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.

   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 proxies
   and brokers. Furthermore, there might be more than one network
   element that needs to interact with the AAA infrastructure although
   Figure 1 depicts only one for clarity.  Similarly, a given user might
   support different authentication methods; he might have more than one
   home network; or, he might use different means of authorization.

   The remainder of this document is organized as follows:

   Section 3 defines some terms that are used in subsequent discussion.




Alfano et al.            Expires - April 2003                 [Page 4]


                 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
   AAA applications.
   Section 10 gives an example use scenario.
   Finally, Section 11 outlines some security considerations.

2. 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. 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 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 AAA server (with a subscriber database) or an
       application server or some other entity.




Alfano et al.            Expires - April 2003                 [Page 5]


                 Requirements for a QoS AAA Protocol     October 2003


   Network Element
       A 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. Typically only a small
       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
       A Subscriber Database holds information related to network users
       such as information about their subscribed service. A user
       might, for example, have a subscription for a 'gold' service
       that authorizes him for higher QoS parameters than 'normal'
       users.

    Termination Actions
       On-line accounting allows the on-line accounting authorization
       entity to terminate flows in real time. A termination action
       defines the action to be taken by the 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.






Alfano et al.            Expires - April 2003                 [Page 6]


                 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
   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 Identification of Resource Authorizing Entity

   The QoS signaling protocol MUST carry information sufficient to
   identify the resource authorizing entity.  Note that the network
   element and the resource authorizing entity will often be in
   different administrative domains.

4.2 User Authentication/Authorization

   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.

   Section 5.7.1 of [13] points to these requirements for the 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 authorization tokens as
   described in [15] and [16].

   It is important to provide cryptographic authentication or to protect
   the authorization information (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
   described in [17].

4.3 Support for different authorization scenarios

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

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.



Alfano et al.            Expires - April 2003                 [Page 7]


                 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.






Alfano et al.            Expires - April 2003                 [Page 8]


                 Requirements for a QoS AAA 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 a QoS AAA protocol.

5.1 Inter-domain Support

   The QoS AAA protocol MUST support inter-domain operation. In
   particular, users may roam outside their home network, leading to a
   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

   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 and authorization.

6.1 Flexible Authentication 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.













Alfano et al.            Expires - April 2003                 [Page 9]


                 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 Making an Authorization Decision

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

   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
   application server to identify the appropriate application session.
   This allows an application session to be associated with a particular
   QoS reservation.

   Note that if flow information is sufficient to identify an
   application session then no separate identifier is required. Although
   this is not true for NSIS other QoS signaling protocols use different
   identifiers.







Alfano et al.            Expires - April 2003                [Page 10]


                 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 network element(s) from
   authorizing entities.

   This requirement would support runtime application state transitions
   or even a change in the subscriberÆs profile that would 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,
   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

   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 (byte count) usage information, or both duration
   and 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.



Alfano et al.            Expires - April 2003                [Page 11]


                 Requirements for a QoS AAA Protocol     October 2003


8.3 Sending Accounting Records

   The 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 Failure Notification

   The QoS AAA protocol MUST allow the network element to report
   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 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
   accounting correlation identifier to the network element.  This
   correlation identifier would then be stored for inclusion in
   subsequent accounting records.  This would allow the home network to
   link the accounting information of the network element with those of
   the application server.

9. Interaction with other AAA Applications

   It is likely that an endpoint attached to a first-hop 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
   network element at the time the endpoint is granted basic, 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 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.


Alfano et al.            Expires - April 2003                [Page 12]


                 Requirements for a QoS AAA Protocol     October 2003



   Also, it may be useful to allow application servers to push QoS
   authorization information to a 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 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. Scenarios

   This section provides a few example scenarios:

   An application in a mobile node wants to open a video session with a
   video server.  The 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 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 has
   to be known to both parties - the mobile node and the video server.

   The mobile node starts to use a QoS signaling protocol. The signaling
   message will hit a network element (most likely the first hop router)
   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
   financially responsible.  To link the application protocol session
   with this particular resource request, the mobile node passes the
   session identifier received from the video server to the network
   element via the QoS signaling protocol.  The 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 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 network element.)
   All accounting messages from a network entity include an accounting
   correlation id.




Alfano et al.            Expires - April 2003                [Page 13]


                 Requirements for a QoS AAA Protocol     October 2003


10.1 Bearer Gating

   The video server can control the flow of packets on the 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 network element to
   allow the flow of packets.  The network element returns the state of
   the packet flow in the response message to the video server.

10.2 Loss of Connectivity

   The network element determines connectivity to the 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 network element informs the video
   server of the loss of connectivity in a request message containing
   state 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 trust relationship exists between the authorizing
   entity and the network element. This trust relationship does not need
   to be pre-existing at the protocol startup but could also be
   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 prevent an adversary from injecting or spoofing data
   packets, which could then receive preferred treatment (i.e., steal


Alfano et al.            Expires - April 2003                [Page 14]


                 Requirements for a QoS AAA Protocol     October 2003


   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

   [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",
        Internet Draft, Internet Engineering Task Force, September
        2003.  Work 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", 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", 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",



Alfano et al.            Expires - April 2003                [Page 15]


                 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



Alfano et al.            Expires - April 2003                [Page 16]


                 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.




Alfano et al.            Expires - April 2003                [Page 17]


                 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.


















Alfano et al.            Expires - April 2003                [Page 18]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/