idnits 2.17.1 draft-calhoun-diameter-res-mgmt-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-17 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-06) exists of draft-calhoun-diameter-nasreq-05 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-07 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-11 -- Possible downref: Normative reference to a draft: ref. '4' ** Downref: Normative reference to an Informational draft: draft-ietf-aaa-na-reqts (ref. '5') == Outdated reference: A later version (-06) exists of draft-ietf-nasreq-criteria-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nasreq-criteria (ref. '6') == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-accounting-08 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-07) exists of draft-calhoun-diameter-strong-crypto-05 -- Possible downref: Normative reference to a draft: ref. '9' Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Pat R. Calhoun 2 Category: Standards Track Sun Microsystems, Inc. 3 Title: draft-calhoun-diameter-res-mgmt-06.txt Nancy Greene 4 Date: September 2000 Nortel 6 DIAMETER 7 Resource Management Extensions 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at: 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at: 28 http://www.ietf.org/shadow.html. 30 This document is an individual contribution for consideration by the 31 AAA Working Group of the Internet Engineering Task Force. Comments 32 should be submitted to the diameter@diameter.org mailing list. 34 Distribution of this memo is unlimited. 36 Copyright (C) The Internet Society 1999. All Rights Reserved. 38 Abstract 40 DIAMETER is an authentication, authorization and accounting (AAA) 41 protocol used for network access services, such as dial-up (NASREQ) 42 and Mobile IP. Some DIAMETER servers maintain state information of 43 active sessions on the access servers, which is used mostly to 44 enforce some local policy decisions. This extension describes an 45 extension to the DIAMETER protocol that allows the server to query 46 for active session state information from access servers in order to 47 rebuild state information should it be lost for any reason. 49 Table of Contents 51 1.0 Introduction 52 1.1 Specification of Requirements 53 1.2 State synchronization 54 2.0 Command-Code Values 55 2.1 Session-Resource-Query 56 2.2 Session-Resource-Reply 57 3.0 Mandatory AVPs 58 3.1 Query-Index AVP 59 3.2 Resource-Token AVP 60 4.0 IANA Considerations 61 5.0 Security Considerations 62 6.0 References 63 7.0 Authors' Addresses 64 8.0 Full Copyright Statement 66 1.0 Introduction 68 DIAMETER [1] is an authentication, authorization and accounting (AAA) 69 protocol used for network access services, such as dial-up (NASREQ) 70 [2] and Mobile IP [3]. 72 The NASREQ AAA requirements [6] require that AAA servers maintain 73 session state information. This is typically used to enfore a local 74 policy decision, such as limiting the number of simultaneous sessions 75 for a specific user, maintaining IP address pools, etc. The AAA WG's 76 network access requirements [5] require that an AAA protocol be able 77 to query for session state information, in the event that this 78 information is lost. 80 This extension describes an extension to the DIAMETER protocol that 81 allows a DIAMETER node to query for active session state information 82 from its peers in order to rebuild state information. Although it is 83 envisioned that this would be used when state information was lost, 84 and needed to be rebuilt, it is possible for a node to periodically 85 query for state information in order to ensure that its state is 86 current. 88 This document only concerns itself with the ability to query for 89 session state information. Resources are actually reserved when a 90 user is successfully authorized. Therefore, relevant application- 91 specific extensions, such as [2] and [3], MUST define what resources 92 are to be managed, by specifying what AVPs MUST be present in the 93 Resource-Token AVP. 95 The Extension number for this draft is three (3). DIAMETER nodes 96 conforming to this specification MUST include an Extension-Id AVP 97 with a value of three in the Device-Reboot-Ind Command [1]. 99 1.1 Specification of Requirements 101 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 102 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 103 described in [7]. 105 1.2 State synchronization 107 When a DIAMETER node determines that it is has lost all state 108 information it had for a specific peer, it SHOULD issue a Session- 109 Resource-Query message to the peer. The node in question MAY postpone 110 all authorization messages from the peer until state has been 111 restored. 113 Upon receipt of the Session-Resource-Query, all Resource-Token AVPs 114 for the requested sessions, indicated via one or more Session-Id AVP, 115 MUST be returned in a Session-Resource-Reply. The absence of any 116 Session-Id AVP is an indication that all active sessions are to be 117 returned. 119 If the node is unable to send all of the information within a single 120 message, it MUST include the Query-Index AVP, with a value that has 121 local significance. A node that receives a Session-Resource-Reply 122 with a Query-Index AVP SHOULD issue another Session-Resource-Query 123 message with the Query-Index AVP intact, requesting the rest of the 124 state information. 126 +----------+ SRQ (no Query-Index AVP) ---> +----------+ 127 | | <--- SRR (Query-Index AVP = x) | | 128 | DIAMETER | SRQ (Query-Index AVP = x) ---> | DIAMETER | 129 | Node A | <--- SRR (Query-Index AVP = y) | Node B | 130 | | SRQ (Query-Index AVP = y) ---> | | 131 +----------+ <--- SRR (no Query-Index AVP) +----------+ 133 Figure 1: Session State Exchange 135 The above example depicts DIAMETER Node a issuing an SRQ to Node B. 136 Upon replying with an SRR, node B determines that it is unable to 137 include all of the Resource-Token AVPs in a single reply, and 138 therefore includes the Query-Index AVP with a value of x. 140 Upon receipt of the response, node A processes all Resource-Token 141 AVPs and issues a subsequent SRQ with the Query-Index AVP set to x. 142 Node B receives the SRQ, and using the Query-Index AVP determines 143 which sessions need to be included in the corresponding SRR. 145 This exchange continues until node B returns an SRR that does not 146 include the Query-Index AVP, indicating that there is no further 147 session state information to be returned. 149 2.0 Command-Code Values 151 This section defines Command-Code [1] values that MUST be supported 152 by all DIAMETER implementations conforming to this specification. 153 The following Command Codes are defined in this specification: 155 Command-Name Abbrev. Code Reference 156 -------------------------------------------------------- 157 Session-Resource-Query SRQ 277 2.1 158 Session-Resource-Reply SRR 278 2.2 160 2.1 Session-Resource-Query (SRQ) 162 The Session-Resource-Query (SRQ), indicated by the Command-Code field 163 set to 277, MAY be sent by a DIAMETER node to any of its peer to 164 request a state update. The presence of one or more Session-Id AVPs 165 in the Session-Resource-Query message indicates that the server only 166 wants to receive the Resource-Token for the specified session(s). 168 Message Format 169 ::= 171 172 [] 173 [] 174 [] 175 [ 176 177 ] 179 2.2 Session-Resource-Reply (SRR) 181 The Session-Resource-Reply (SRR), indicated by the Command-Code field 182 set to 278, is sent in response to a SRQ message. The SRR message 183 contains a Resource-Token for each active session that was requested 184 via the Session-Id AVP. The absence of any Session-Id AVP in the SRQ 185 implies that Resource-Tokens for all active sessions MUST be 186 returned. 188 In the event that all of the state information cannot be sent at 189 once, the SRR message MUST include the Query-Index AVP. 191 Message Format 193 ::= 195 196 197 198 [] 199 [] 200 [ 201 202 ] 204 3.0 Mandatory AVPs 206 The following table describes the DIAMETER AVPs defined in the 207 Resource Management extension, their AVP Code values, types, possible 208 flag values and whether the AVP MAY be encrypted. 210 +---------------------+ 211 | AVP Flag rules | 212 |----+-----+----+-----|----+ 213 AVP Section Value | | |SHLD| MUST|May | 214 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr| 215 -----------------------------------------|----+-----+----+-----|----+ 216 Query-Index 500 3.1 Integer32| M | P | | V | Y | 217 Resource-Token 501 3.2 Data | M | P | | V | Y | 219 3.1 Query-Index AVP 221 The Query-Index AVP (AVP Code 500) is of type Integer32 and MUST only 222 be present in the Session-Resource-Query and the Session-Resource- 223 Reply messages. The Query-Index AVP has local significance to the 224 issuer of the Session-Resource-Reply message, and is used to identify 225 the state information that remains to be sent in a subsequent SRR 226 message. 228 3.2 Resource-Token AVP 230 The Resource-Token AVP (AVP Code 501) encapsulates AVPs and is used 231 to track state information that is pertinent to an active session. 232 The issuer of the SRR message is responsible for creating a 233 Resource-Token AVP for all active sessions requested. 235 The following describes the minimum number of AVPs that MUST be 236 present in a Resource-Token AVP. Service-specific AVPs MAY also be 237 present, as defined in the appropriate service extension document. 239 ::= 240 241 242 243 244 245 [] 247 The Host-Name AVP contains the NAI of the access router that is 248 servicing the user, while the timestamp AVP contains the time at 249 which the successful DIAMETER authorization response was received, 250 and the service was initiated. 252 4.0 IANA Considerations 254 The command codes defined in Section 2.0 are values taken from the 255 Command-Code [1] address space and extended in [2], [4] and [8]. 256 IANA should record the values as defined in Section 2.0. 258 The AVPs defined in section 3.0 were alllocated from from the AVP 259 numbering space defined in [1], and extended in [2], [4] and [8]. 260 IANA should record the values as defined in Section 3.0. 262 5.0 Security Considerations 264 This DIAMETER extension assumes that the Resource Management data is 265 secured either through a hop-by-hop authentication mechanism, as 266 described in [1], or using a strong authentication mechanism as 267 defined in [9]. 269 6.0 References 271 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "DIAMETER Base 272 Protocol", draft-calhoun-diameter-17.txt, IETF work in progress, 273 September 2000. 275 [2] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ 276 Extension", draft-calhoun-diameter-nasreq-05.txt, IETF work in 277 progress, September 2000. 279 [3] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft-calhoun- 280 diameter-framework-07.txt, IETF work in progress, April 2000. 282 [4] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft- 283 calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep- 284 tember 2000. 286 [5] Aboba et al, "Network Access AAA Evaluation Criteria", draft- 287 ietf-aaa-na-reqts-07.txt, IETF work in progress, August 2000. 289 [6] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 290 Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work 291 in progress, June 2000. 293 [7] S. Bradner, "Key words for use in RFCs to Indicate Requirement 294 Levels", BCP 14, RFC 2119, March 1997. 296 [8] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "DIAMETER Accounting 297 Extension", draft-calhoun-diameter-accounting-08.txt, IETF work 298 in progress, September 2000. 300 [9] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 301 Extension", draft-calhoun-diameter-strong-crypto-05.txt, IETF 302 work in progress, September 2000. 304 7.0 Authors' Addresses 306 Questions about this memo can be directed to: 308 Pat R. Calhoun 309 Network and Security Research Center, Sun Labs 310 Sun Microsystems, Inc. 311 15 Network Circle 312 Menlo Park, California, 94025 313 USA 315 Phone: +1 650-786-7733 316 Fax: +1 650-786-6445 317 E-mail: pcalhoun@eng.sun.com 319 Nancy Greene 320 Public Data Networks 321 Nortel (Northern Telecom) 322 PO Box 3511 Station C 323 Ottawa, Ontario K1Y 4H7 324 Canada 326 Phone: +1 613-763-9789 327 Fax: +1 613-763-8904 328 E-mail: ngreene@nortel.ca 330 8.0 Full Copyright Statement 332 Copyright (C) The Internet Society (1999). All Rights Reserved. 334 This document and translations of it may be copied and furnished to 335 others, and derivative works that comment on or otherwise explain it 336 or assist in its implementation may be prepared, copied, published 337 and distributed, in whole or in part, without restriction of any 338 kind, provided that the above copyright notice and this paragraph are 339 included on all such copies and derivative works. However, this docu- 340 ment itself may not be modified in any way, such as by removing the 341 copyright notice or references to the Internet Society or other 342 Internet organizations, except as needed for the purpose of develop- 343 ing Internet standards in which case the procedures for copyrights 344 defined in the Internet Standards process must be followed, or as 345 required to translate it into languages other than English. The 346 limited permissions granted above are perpetual and will not be 347 revoked by the Internet Society or its successors or assigns. This 348 document and the information contained herein is provided on an "AS 349 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 350 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 351 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 352 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 353 OR FITNESS FOR A PARTICULAR PURPOSE.