Authentication, Authorization and Accounting Frank M. Alfano Internet Draft Peter J. McCann Document: draft-alfano-aaa-qosreq-00.txt Tom Towle Expires: December 2003 Richard Ejzak Lucent Technologies June 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 protocol would be used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources used during the life of the application flow. A QoS AAA protocol should also support dynamic authorization of QoS as a function of application and account state. While we assume the existence of some QoS reservation protocol to allow endpoints to request QoS from network elements, complete requirements for such a protocol are outside the scope of this document and a QoS AAA protocol could be used to support more than one kind of reservation protocol. A 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 for a wide variety of flexible service deployment models. Alfano, McCann Expires - December 2003 [Page 1] Requirements for QoS-AAA June 2003 Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................6 3. Term Definitions...............................................6 4. Generic Requirements on a QoS Reservation Signaling Protocol...7 4.1 Identity Information.......................................7 4.2 Flow Information...........................................7 4.3 Authentication Information.................................8 5. Generic Requirements on a QoS AAA Protocol.....................8 5.1 Inter-domain Support.......................................8 5.2 Identity-based Routing.....................................8 6. Requirements for QoS Authentication............................8 6.1 Authentication Check.......................................8 7. Requirements for QoS Authorization.............................9 7.1 Flow Information...........................................9 7.2 Application State Pointer..................................9 7.3 Dynamic Authorization......................................9 7.4 Bearer Gating..............................................9 8. Requirements for QoS Accounting...............................10 8.1 Accounting Records........................................10 8.2 Accounting Rules..........................................10 8.3 Sending Accounting Records................................10 8.4 Loss of Bearer Notification Requirements..................10 8.5 Accounting Correlation....................................11 9. Interaction with other AAA Applications.......................11 10. Use Scenario.................................................12 10.1 Bearer Gating............................................12 10.2 Loss of Bearer...........................................13 11. Security Considerations......................................13 12. Reference....................................................13 13. Author's Addresses...........................................14 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 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 Alfano et al. Expires - December 2003 [Page 2] Requirements for QoS-AAA June 2003 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, such as: 1. RSVP. 2. NSIS. 3. Link-specific means. 4. SIP/SDP. The most obvious choice, RSVP [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 protocol. The new Next Steps in Signaling (NSIS) work [3] currently being undertaken may address some of these issues. In the meantime, deployments such 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 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 Alfano et al. Expires - December 2003 [Page 3] Requirements for QoS-AAA June 2003 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 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 the network layer when a change in the bearer element point of attachment to 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 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 propose that a AAA protocol be developed that can be used by bearer elements to authenticate, authorize, and account for individual application flows that require QoS. A high-level picture of the resulting architecture is shown in Figure 1. Alfano et al. Expires - December 2003 [Page 4] Requirements for QoS-AAA June 2003 +------+ +------+ | Subs | | | | DB | | AS | | | | | +---\--+ +---/--+ \ / \ / /-\----------/\ //// \\\\ || || | AAA Cloud | || || \\\\ //// \-------+-----/ | +---+--+ Application | | Flow ===============+ BE +==========>> | | +------+ Figure 1. An architecture supporting QoS-AAA Figure 1 depicts a bearer element through which application flows need to pass, a cloud of AAA servers, a database containing subscriber records, and an application server. Here the term "AAA Cloud" is used to refer to the network of AAA proxy/broker 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. Alfano et al. Expires - December 2003 [Page 5] Requirements for QoS-AAA June 2003 The remainder of this document outlines high-level requirements for the QoS AAA protocol. Section 3 defines some terms that are used in subsequent discussion. Section 4 describes a small number of generic requirements on a QoS reservation 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 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 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 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 for a particular application flow. This may be a home subscriber database or an application server. Alfano et al. Expires - December 2003 [Page 6] Requirements for QoS-AAA June 2003 Bearer Element A bearer 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 only a subset of the bearer elements along a path are required to process and authorize QoS requests. In a typical service provider scenario, the first-hop router (NAS) will be required to play this role. Subscriber Database A Subscriber Database holds information related to network users such as what services they have signed up for. In particular, a user may subscribe to QoS independent of any application, which would enable authorization for QoS without consultation of an application server. 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 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. 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 The QoS signaling protocol MUST carry information sufficient to identify an authorizing entity for a QoS request. For instance, the identity may be represented as the NAI of a user or FQDN of an application server. 4.2 Flow Information The QoS signaling protocol MUST carry information sufficient to identify the application flow(s). However, the protocol MUST allow flow information to be under-specified ("wild carded") in the case when specific endpoints are not known at the time of resource reservation. Alfano et al. Expires - December 2003 [Page 7] Requirements for QoS-AAA June 2003 Flow information would include elements such as IP addresses and port numbers, so that intervening bearer elements can classify packets and give them proper QoS treatment. Also, the flow information would be used when consulting the subscriber profile or application servers for authorization decisions. 4.3 Authentication Information The QoS signaling protocol MUST be integrity protected. For example, each message could carry a cryptographic message authentication code 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. The authentication information would be verified by the AAA infrastructure before authorization is granted. 5. Generic Requirements on a QoS AAA Protocol In this section we list some high-level requirements that must be met by any QoS AAA protocol 5.1 Inter-domain Support The QoS AAA protocol MUST support inter-domain operation where the bearer elements, subscriber databases, and application servers can each belong to different administrative domains. 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. 6.1 Authentication Check The QoS AAA protocol MUST support verification of authentication information present in QoS signaling messages. Alfano et al. Expires - December 2003 [Page 8] Requirements for QoS-AAA June 2003 7. Requirements for QoS Authorization In this section we list some QoS AAA requirements specific to authorization. 7.1 Flow Information The QoS AAA protocol MUST carry flow information to and from the authorizing entity. However, the protocol MUST allow flow information to be under-specified ("wild carded") in the case when specific endpoints are not known at the time of initial resource authorization. 7.2 Application State Pointer The QoS AAA protocol MUST carry information sufficient for an application server to identify the appropriate application session. 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 Dynamic Authorization The QoS AAA protocol MUST support dynamic authorization; that is, it MUST be possible to push updates towards the bearer element(s) from authorizing entities. This requirement would support runtime changes to a subscriber profile or application state transitions that would authorize/de- authorize application flows. 7.4 Bearer Gating Even though a given flow may be authorized, 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 the endpoint into thinking that its request had been denied when in reality the bearer flow was merely temporarily disabled. Alfano et al. Expires - December 2003 [Page 9] Requirements for QoS-AAA June 2003 The QoS AAA protocol MUST allow the authorizing entity to gate authorized application flows. 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) 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. 8.3 Sending Accounting Records The bearer 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 Notification Requirements The QoS AAA protocol MUST allow the bearer element to report loss of bearer to the authorizing entity. Alfano et al. Expires - December 2003 [Page 10] Requirements for QoS-AAA June 2003 8.5 Accounting Correlation The QoS AAA protocol MUST support the exchange of sufficient information to allow for correlation between bearer accounting records and application accounting records. For example, an application server might create and pass an accounting correlation identifier to the bearer element. This correlation identifier would be stored by the bearer element for inclusion in subsequent accounting records. This would allow the home network to link the bearer accounting information with application layer accounting records emitted by an application server. 9. Interaction with other AAA Applications It is likely that an endpoint attached to a first-hop bearer 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 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. Also, it may be useful to allow application servers to push QoS authorization information to a bearer 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 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: Alfano et al. Expires - December 2003 [Page 11] Requirements for QoS-AAA June 2003 The QoS AAA protocol MUST support dynamic authorization initiated by the authorizing entity. 10. Use Scenario This section provides an example use case for the proposed application. An application in a host computer (application endpoint) wants to open a video session with a video server. The application endpoint and the video server negotiate the resources to be used for the session and for which the application will be financially responsible. When 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 to the application endpoint. The application endpoint makes a request for resources from the bearer element. The video server and the bearer element will verify that the application endpoint 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, the application endpoint passes the session identifier received from the video server to the bearer element via the QoS signaling protocol. The bearer element makes a request to the video server identified in the session identifier. The video server passes the relevant QoS state information to the bearer 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 element.) Included in the answer message is an accounting correlation id to be included in all accounting messages from the bearer entity. 10.1 Bearer Gating The video server can control the flow of packets on the bearer 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 element to allow the flow of packets. The bearer element returns the state of the packet flow in the response message to the video server. Alfano et al. Expires - December 2003 [Page 12] Requirements for QoS-AAA June 2003 10.2 Loss of Bearer The bearer element determines that bearer connectivity of the application flow 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 element informs the video server of the loss of bearer in a request message containing bearer state information. 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 relationship exists between the authorizing entity (the home AAA server or application server) and the bearer element (AAA client). This relationship implies that the bearer element should grant service based on the say-so of the authorizing entity, presumably because the used resources will be paid for in some later settlement phase. 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. The authentication outlined in Section 6 MUST be cryptographically strong and protected against replay and other attacks. 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 the authorization to the actual flow of packets using the QoS bearer in the bearer element. Actual mechanisms applied to the bearer traffic for this purpose might include, e.g., ingress filtering and/or IPSec, but in general are beyond the scope of a QoS AAA protocol. 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. Alfano et al. Expires - December 2003 [Page 13] Requirements for QoS-AAA June 2003 [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 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", draft-ietf-mmusic-sdp-new-13.txt, May 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, 2003. Work In Progress. 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 - December 2003 [Page 14] Requirements for QoS-AAA June 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 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. 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. Alfano et al. Expires - December 2003 [Page 15] Requirements for QoS-AAA June 2003 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 - December 2003 [Page 16]