INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-calhoun-diameter-res-mgmt-05.txt Nancy Greene Date: July 2000 Nortel DIAMETER Resource Management Extensions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. This document is an individual contribution for consideration by the AAA Working Group of the Internet Engineering Task Force. Comments should be submitted to the diameter@diameter.org mailing list. Distribution of this memo is unlimited. Copyright (C) The Internet Society 1999. All Rights Reserved. Calhoun, Greene expires January 2001 [Page 1] INTERNET DRAFT July 2000 Abstract DIAMETER is an authentication, authorization and accounting (AAA) protocol used for network access services, such as dial-up (NASREQ) and Mobile IP. Some DIAMETER servers maintain state information of active sessions on the access servers, which is used mostly to enforce some local policy decisions. This extension describes an extension to the DIAMETER protocol that allows the server to query for active session state information from access servers in order to rebuild state information should it be lost for any reason. Table of Contents 1.0 Introduction 1.1 Specification of Requirements 1.2 State synchronization 2.0 Command-Code Values 2.1 Session-Resource-Query 2.2 Session-Resource-Reply 3.0 Mandatory AVPs 3.1 Query-Index AVP 3.2 Resource-Token AVP 4.0 IANA Considerations 5.0 Security Considerations 6.0 References 7.0 Authors' Addresses 8.0 Full Copyright Statement 1.0 Introduction DIAMETER [1] is an authentication, authorization and accounting (AAA) protocol used for network access services, such as dial-up (NASREQ) [2] and Mobile IP [3]. The NASREQ AAA requirements [6] require that AAA servers maintain session state information. This is typically used to enfore a local policy decision, such as limiting the number of simultaneous sessions for a specific user, maintaining IP address pools, etc. The AAA WG's network access requirements [5] require that an AAA protocol be able to query for session state information, in the event that this information is lost. This extension describes an extension to the DIAMETER protocol that allows a DIAMETER node to query for active session state information from its peers in order to rebuild state information. Although it is envisioned that this would be used when state information was lost, Calhoun, Greene expires January 2001 [Page 2] INTERNET DRAFT July 2000 and needed to be rebuilt, it is possible for a node to periodically query for state information in order to ensure that its state is current. This document only concerns itself with the ability to query for session state information. Resources are actually reserved when a user is successfully authorized. Therefore, relevant application- specific extensions, such as [2] and [3], MUST define what resources are to be managed, by specifying what AVPs MUST be present in the Resource-Token AVP. The Extension number for this draft is three (3). DIAMETER nodes conforming to this specification MUST include an Extension-Id AVP with a value of three in the Device-Reboot-Ind Command [1]. 1.1 Specification of Requirements In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [7]. 1.2 State synchronization When a DIAMETER node determines that it is has lost all state information it had for a specific peer, it SHOULD issue a Session- Resource-Query message to the peer. The node in question MAY postpone all authorization messages from the peer until state has been restored. Upon receipt of the Session-Resource-Query, all Resource-Token AVPs for the requested sessions, indicated via one or more Session-Id AVP, MUST be returned in a Session-Resource-Reply. The absence of any Session-Id AVP is an indication that all active sessions are to be returned. If the node is unable to send all of the information within a single message, it MUST include the Query-Index AVP, with a value that has local significance. A node that receives a Session-Resource-Reply with a Query-Index AVP SHOULD issue another Session-Resource-Query message with the Query-Index AVP intact, requesting the rest of the state information. Calhoun, Greene expires January 2001 [Page 3] INTERNET DRAFT July 2000 +----------+ SRQ (no Query-Index AVP) ---> +----------+ | | <--- SRR (Query-Index AVP = x) | | | DIAMETER | SRQ (Query-Index AVP = x) ---> | DIAMETER | | Node A | <--- SRR (Query-Index AVP = y) | Node B | | | SRQ (Query-Index AVP = y) ---> | | +----------+ <--- SRR (no Query-Index AVP) +----------+ Figure 1: Session State Exchange The above example depicts DIAMETER Node a issuing an SRQ to Node B. Upon replying with an SRR, node B determines that it is unable to include all of the Resource-Token AVPs in a single reply, and therefore includes the Query-Index AVP with a value of x. Upon receipt of the response, node A processes all Resource-Token AVPs and issues a subsequent SRQ with the Query-Index AVP set to x. Node B receives the SRQ, and using the Query-Index AVP determines which sessions need to be included in the corresponding SRR. This exchange continues until node B returns an SRR that does not include the Query-Index AVP, indicating that there is no further session state information to be returned. 2.0 Command-Code Values This section defines Command-Code [1] values that MUST be supported by all DIAMETER implementations conforming to this specification. The following Command Codes are defined in this specification: Command-Name Abbrev. Code Reference -------------------------------------------------------- Session-Resource-Query SRQ 277 2.1 Session-Resource-Reply SRR 278 2.2 2.1 Session-Resource-Query (SRQ) The Session-Resource-Query (SRQ), indicated by the Command-Code field set to 277, MAY be sent by a DIAMETER node to any of its peer to request a state update. The presence of one or more Session-Id AVPs in the Session-Resource-Query message indicates that the server only wants to receive the Resource-Token for the specified session(s). Message Format Calhoun, Greene expires January 2001 [Page 4] INTERNET DRAFT July 2000 ::= [] [] [] [ ] 2.2 Session-Resource-Reply (SRR) The Session-Resource-Reply (SRR), indicated by the Command-Code field set to 278, is sent in response to a SRQ message. The SRR message contains a Resource-Token for each active session that was requested via the Session-Id AVP. The absence of any Session-Id AVP in the SRQ implies that Resource-Tokens for all active sessions MUST be returned. In the event that all of the state information cannot be sent at once, the SRR message MUST include the Query-Index AVP. Message Format ::= [] [] [ ] 3.0 Mandatory AVPs The following table describes the DIAMETER AVPs defined in the Resource Management extension, their AVP Code values, types, possible flag values and whether the AVP MAY be encrypted. Calhoun, Greene expires January 2001 [Page 5] INTERNET DRAFT July 2000 +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section Value | | |SHLD| MUST|May | Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----+ Query-Index 500 3.1 Integer32| M | P | | T,V | Y | Resource-Token 501 3.2 Data | M | P | | T,V | Y | 3.1 Query-Index AVP The Query-Index AVP (AVP Code 500) is of type Integer32 and MUST only be present in the Session-Resource-Query and the Session-Resource- Reply messages. The Query-Index AVP has local significance to the issuer of the Session-Resource-Reply message, and is used to identify the state information that remains to be sent in a subsequent SRR message. 3.2 Resource-Token AVP The Resource-Token AVP (AVP Code 501) encapsulates AVPs and is used to track state information that is pertinent to an active session. The issuer of the SRR message is responsible for creating a Resource-Token AVP for all active sessions requested. The following describes the minimum number of AVPs that MUST be present in a Resource-Token AVP. Service-specific AVPs MAY also be present, as defined in the appropriate service extension document. ::= [] The Host-Name AVP contains the NAI of the access router that is servicing the user, while the timestamp AVP contains the time at which the successful DIAMETER authorization response was received, and the service was initiated. 4.0 IANA Considerations The command codes defined in Section 2.0 are values taken from the Calhoun, Greene expires January 2001 [Page 6] INTERNET DRAFT July 2000 Command-Code [1] address space and extended in [2], [4] and [8]. IANA should record the values as defined in Section 2.0. The AVPs defined in section 3.0 were alllocated from from the AVP numbering space defined in [1], and extended in [2], [4] and [8]. IANA should record the values as defined in Section 3.0. 5.0 Security Considerations This DIAMETER extension assumes that the Resource Management data is secured either through a hop-by-hop authentication mechanism, as described in [1], or using a strong authentication mechanism as defined in [9]. 6.0 References [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "DIAMETER Base Protocol", draft-calhoun-diameter-16.txt, IETF work in progress, July 2000. [2] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ Extension", draft-calhoun-diameter-nasreq-04.txt, IETF work in progress, July 2000. [3] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft-calhoun- diameter-framework-07.txt, IETF work in progress, April 2000. [4] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft- calhoun-diameter-mobileip-09.txt, IETF work in progress, July 2000. [5] Aboba et al, "Network Access AAA Evaluation Criteria", draft- ietf-aaa-na-reqts-03.txt, IETF work in progress, April 2000. [6] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work in progress, June 2000. [7] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [8] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "DIAMETER Accounting Extension", draft-calhoun-diameter-accounting-07.txt, IETF work in progress, July 2000. Calhoun, Greene expires January 2001 [Page 7] INTERNET DRAFT July 2000 [9] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security Extension", draft-calhoun-diameter-strong-crypto-04.txt, IETF work in progress, July 2000. 7.0 Authors' Addresses Questions about this memo can be directed to: Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: +1 650-786-7733 Fax: +1 650-786-6445 E-mail: pcalhoun@eng.sun.com Nancy Greene Public Data Networks Nortel (Northern Telecom) PO Box 3511 Station C Ottawa, Ontario K1Y 4H7 Canada Phone: +1 613-763-9789 Fax: +1 613-763-8904 E-mail: ngreene@nortel.ca 8.0 Full Copyright Statement Copyright (C) The Internet Society (1999). 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 docu- ment 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 develop- ing 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 Calhoun, Greene expires January 2001 [Page 8] INTERNET DRAFT July 2000 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. Calhoun, Greene expires January 2001 [Page 9]