INTERNET DRAFT                                            Pat R. Calhoun
Category: Standards Track                         Sun Microsystems, Inc.
Title: draft-calhoun-diameter-res-mgmt-06.txt               Nancy Greene
Date: September 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 March 2001                   [Page 1]


INTERNET DRAFT                                            September 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 March 2001                   [Page 2]


INTERNET DRAFT                                            September 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 March 2001                   [Page 3]


INTERNET DRAFT                                            September 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 March 2001                   [Page 4]


INTERNET DRAFT                                            September 2000


      <Session-Resource-Query>  ::=  <DIAMETER  Header,  Command-Code  =
      277>
                                    <Host-Name AVP>
                                    [<Destination-NAI AVP>]
                                    [<Session-Id AVPs>]
                                    [<Query-Index AVP>]
                                    [<Timestamp AVP>
                                     <Nonce AVP>
                                     <Integrity-Check-Value AVP>]


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

      <Session-Resource-Reply>  ::=  <DIAMETER  Header,  Command-Code  =
      278>
                                    <Host-Name AVP>
                                    <Destination-NAI AVP>
                                    <Result-Code AVP>
                                    [<Query-Index AVP>]
                                    [<Resource-Token AVPs>]
                                    [<Timestamp AVP>
                                     <Nonce AVP>
                                     <Integrity-Check-Value AVP>]


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 March 2001                   [Page 5]


INTERNET DRAFT                                            September 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  |    |  V  | Y  |
   Resource-Token   501     3.2    Data     | M  |  P  |    |  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.

      <Resource-Token>  ::= <AVP Header>
                            <Session-Id AVP>
                            <Host-Name AVP>
                            <User-Name AVP>
                            <Timestamp AVP>
                            <Extension-Id>
                            [<Service-Specific AVPs>]

   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 March 2001                   [Page 6]


INTERNET DRAFT                                            September 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-17.txt, IETF work in progress,
        September 2000.

   [2]  P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ
        Extension", draft-calhoun-diameter-nasreq-05.txt, IETF work in
        progress, September 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-11.txt, IETF work in progress, Sep-
        tember 2000.

   [5]  Aboba et al, "Network Access AAA Evaluation Criteria", draft-
        ietf-aaa-na-reqts-07.txt, IETF work in progress, August 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-08.txt, IETF work
        in progress, September 2000.




Calhoun, Greene            expires March 2001                   [Page 7]


INTERNET DRAFT                                            September 2000


   [9]  P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security
        Extension", draft-calhoun-diameter-strong-crypto-05.txt, IETF
        work in progress, September 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 March 2001                   [Page 8]


INTERNET DRAFT                                            September 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 March 2001                   [Page 9]