INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-calhoun-diameter-res-mgmt-03.txt Nancy Greene Date: February 1999 Nortel DIAMETER Resource Management Extensions Status of this Memo 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@ipass.com mailing list. Distribution of this memo is unlimited. 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. Abstract DIAMETER is a policy protocol used between a client and a server for authentication, authorization and accounting of various services. Examples of such services are for dial-up users (ROAMOPS), RSVP Admission Policies (RAP), FAX Over IP (FAXIP), Voice over IP (IP Tel), Integrated services, etc. Calhoun expires August 1999 [Page 1] INTERNET DRAFT February 1999 This document defines a set of commands which allow DIAMETER servers to maintain session state information. An example of the use of Resource Management would be to limit the number of sessions for a given user. Calhoun expires August 1999 [Page 2] INTERNET DRAFT February 1999 Table of Contents 1.0 Introduction 1.1 Specification of Requirements 1.2 Concept of a session 2.0 Command Codes 2.1 Session-Free-Request 2.2 Session-Free-Answer 2.3 Session-Resource-Query 2.4 Session-Resource-Reply 2.5 Resource-Reclaim-Request 2.6 Resource-Reclaim-Answer 3.0 DIAMETER AVPs 3.1 Query-Index 3.2 Resource-Token 4.0 Protocol Definition 4.1 Feature Advertisement/Discovery 4.2 Session Free 4.3 Relinquish Session 4.4 Interaction with Device-Reboot-Indication 4.5 State Resync 5.0 References 6.0 Authors' Addresses 1.0 Introduction Many services requiring Policy Server Support require the server to maintain session state information. This can only be achieved if the protocol has built-in mechanism to allow both the client and the server to resync its state information. A message set is also required to allow the client to inform the server when a session has terminated. An example of such a requirement is in the dial-up PPP world. With the introduction of flat-rate internet access, there has been a surge in fraud that allows a user to provide his username/password pair to other people. The end result is that a single username can have simultaneous concurrent sessions. It is desirable for the Policy Server to maintain a list of the active sessions so it can detect whether a user is attempting fraudulent activities, and restrict the user to a single login. Internet Service Providers have had to implement this functionality using other less-reliable schemes in the past. Unfortunately, those schemes are known to be problematic and therefore a standard method of maintaining state information is desired. Calhoun expires August 1999 [Page 3] INTERNET DRAFT February 1999 The DIAMETER Resource Management extensions are intended to provide the functionality required to have stateful Policy Servers. This document does not specify what resources can be managed by a server since it is service specific, but it does provide the tools required for the services that require it. When reading this document the reader should keep in mind that the authorization of a session by the server is analogous to the allocation of resources. This document does not deal with the allocation of any resources and is simply a complement to the service extension that requires stateful servers. Message sets and the AVPs used for session setup and resource allocation vary depending on the type of service a session is being created for. The general concept of a session is described in this document, and specific message sets for session setup and resource allocation are found in other extension documents, for example, in [2]. The Extension number for this draft is two (2). This value is used in the Extension-Id AVP as defined in [2]. 1.1 Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. Calhoun expires August 1999 [Page 4] INTERNET DRAFT February 1999 1.2 Concept of a session A session defines a thread of Diameter messages. All messages related to a particular session MUST include a Session-Id. (Session-Id is described in [1]). A session can be established by either a client or a server. The Session-Id is assigned by the initiator of the session. Resources can be added to, deleted from, or modified in a session. How this is done for a particular service is described in the relevant extensions document. For example, [2] describes session setup and resource allocation for user authentication and authorization. This document describes the more general functions of querying for information on allocated resources, and freeing a session. 2.0 Command Codes This document defines the following DIAMETER Commands. All DIAMETER implementations supporting this extension MUST support all of the following commands: Command Name Command Code ----------------------------------- Session-Free-Request 266 Session-Free-Answer 267 Session-Resource-Query 268 Session-Resource-Reply 269 Resource-Reclaim-Request 270 Resource-Reclaim-Answer 271 2.1 Session-Free-Request (SFR) Description The Session-Free-Request message is normally sent by a DIAMETER client to a server, and provides information on specific resources which have been released. The Session-Free-Request message MUST include the Host-IP-Address or the Host-Name as well as the Session-Id AVPs. The Session-Id is used by the server to identify a specific session that was previously authorized. Upon receipt of this message the server MUST free any resources that were previously allocated to the session during the session authorization and respond with the Session-Free-Answer. Calhoun expires August 1999 [Page 5] INTERNET DRAFT February 1999 The Session-Free-Request MAY contain the Result-Code AVP if it is a result of a Session-Reclaim-Request. Message Format ::= { || ::= [] { || [] [] [] { || [] [] [] [] { || { || [] { || <-- Reboot-Ack (w/ Res-Mgmt Ext. Id) Session-Resource-Query (Index = 0) --> <-- Session-Resource-Query-Reply (Index = 10) Session-Resource-Query (Index = 10) --> <-- Session-Resource-Query-Reply (Index = 20) Session-Resource-Query (Index = 20) --> <-- Session-Resource-Query-Reply (Index = 0) In the above scenario, the Server issues the initial Session- Resource-Query with a zero Query-Index. The client responds but since it can only fit Resource-Tokens 1 through 9, it sets the Query-Index to 10 in the Session-Resource-Query-Reply. Upon receipt of the response the server processes the message and issues another Session-Resource-Query with the Query-Index value set to 10. The client, upon receipt of the request, knows that it needs to include the Resource-Tokens starting at 10. Again, since the client can only include the Resource-Tokens up to 19, it sets the Query-Index to 20. The Server issues another Session-Resource-Query with the Query-Index set to 20. At this point the client can fit the remaining Resource- Tokens (20 through 26) and therefore sets the Query-Index to zero to indicate that it has sent all of it's active Resource-Tokens. 5.0 References [1] Calhoun, Rubens, "DIAMETER Base Protocol", draft-calhoun-diameter-08.txt, Work in Progress, February 1999. [2] Calhoun, Bulley, "DIAMETER Autentication Extensions", draft-calhoun-diameter-auth-04.txt, Work in Progress, July 1998. [3] Calhoun, Zorn, Pan, "DIAMETER Framework", draft-calhoun-diameter-framework-02.txt, Work in Progress, December 1998. 6.0 Authors' Addresses Questions about this memo can be directed to: Calhoun expires August 1999 [Page 18] INTERNET DRAFT February 1999 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 Calhoun expires August 1999 [Page 19]