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]