idnits 2.17.1 draft-calhoun-diameter-res-mgmt-03.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 18 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 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 125: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 129: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 132: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 138: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 140: '...hich does not include this option MUST...' (59 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) == Unused Reference: '3' is defined on line 777, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-08 -- Possible downref: Normative reference to a draft: ref. '1' -- No information found for draft-calhoun-diameter-auth - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-02 -- Possible downref: Normative reference to a draft: ref. '3' Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Microsystems, Inc. 4 Title: draft-calhoun-diameter-res-mgmt-03.txt Nancy Greene 5 Date: February 1999 Nortel 7 DIAMETER 8 Resource Management Extensions 10 Status of this Memo 12 This document is an individual contribution for consideration by the 13 AAA Working Group of the Internet Engineering Task Force. Comments 14 should be submitted to the diameter@ipass.com mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 35 http://www.ietf.org/shadow.html. 37 Abstract 39 DIAMETER is a policy protocol used between a client and a server for 40 authentication, authorization and accounting of various services. 41 Examples of such services are for dial-up users (ROAMOPS), RSVP 42 Admission Policies (RAP), FAX Over IP (FAXIP), Voice over IP (IP 43 Tel), Integrated services, etc. 45 This document defines a set of commands which allow DIAMETER servers 46 to maintain session state information. An example of the use of 47 Resource Management would be to limit the number of sessions for a 48 given user. 50 Table of Contents 52 1.0 Introduction 53 1.1 Specification of Requirements 54 1.2 Concept of a session 55 2.0 Command Codes 56 2.1 Session-Free-Request 57 2.2 Session-Free-Answer 58 2.3 Session-Resource-Query 59 2.4 Session-Resource-Reply 60 2.5 Resource-Reclaim-Request 61 2.6 Resource-Reclaim-Answer 62 3.0 DIAMETER AVPs 63 3.1 Query-Index 64 3.2 Resource-Token 65 4.0 Protocol Definition 66 4.1 Feature Advertisement/Discovery 67 4.2 Session Free 68 4.3 Relinquish Session 69 4.4 Interaction with Device-Reboot-Indication 70 4.5 State Resync 71 5.0 References 72 6.0 Authors' Addresses 74 1.0 Introduction 76 Many services requiring Policy Server Support require the server to 77 maintain session state information. This can only be achieved if the 78 protocol has built-in mechanism to allow both the client and the 79 server to resync its state information. A message set is also 80 required to allow the client to inform the server when a session has 81 terminated. 83 An example of such a requirement is in the dial-up PPP world. With 84 the introduction of flat-rate internet access, there has been a surge 85 in fraud that allows a user to provide his username/password pair to 86 other people. The end result is that a single username can have 87 simultaneous concurrent sessions. 89 It is desirable for the Policy Server to maintain a list of the 90 active sessions so it can detect whether a user is attempting 91 fraudulent activities, and restrict the user to a single login. 93 Internet Service Providers have had to implement this functionality 94 using other less-reliable schemes in the past. Unfortunately, those 95 schemes are known to be problematic and therefore a standard method 96 of maintaining state information is desired. 98 The DIAMETER Resource Management extensions are intended to provide 99 the functionality required to have stateful Policy Servers. This 100 document does not specify what resources can be managed by a server 101 since it is service specific, but it does provide the tools required 102 for the services that require it. 104 When reading this document the reader should keep in mind that the 105 authorization of a session by the server is analogous to the 106 allocation of resources. This document does not deal with the 107 allocation of any resources and is simply a complement to the service 108 extension that requires stateful servers. 110 Message sets and the AVPs used for session setup and resource 111 allocation vary depending on the type of service a session is being 112 created for. The general concept of a session is described in this 113 document, and specific message sets for session setup and resource 114 allocation are found in other extension documents, for example, in 115 [2]. 117 The Extension number for this draft is two (2). This value is used in 118 the Extension-Id AVP as defined in [2]. 120 1.1 Specification of Requirements 122 In this document, several words are used to signify the requirements 123 of the specification. These words are often capitalized. 125 MUST This word, or the adjective "required", means that the 126 definition is an absolute requirement of the 127 specification. 129 MUST NOT This phrase means that the definition is an absolute 130 prohibition of the specification. 132 SHOULD This word, or the adjective "recommended", means that 133 there may exist valid reasons in particular circumstances 134 to ignore this item, but the full implications must be 135 understood and carefully weighed before choosing a 136 different course. 138 MAY This word, or the adjective "optional", means that this 139 item is one of an allowed set of alternatives. An 140 implementation which does not include this option MUST 141 be prepared to interoperate with another implementation 142 which does include the option. 144 1.2 Concept of a session 146 A session defines a thread of Diameter messages. All messages related 147 to a particular session MUST include a Session-Id. (Session-Id is 148 described in [1]). A session can be established by either a client or 149 a server. The Session-Id is assigned by the initiator of the session. 150 Resources can be added to, deleted from, or modified in a session. 151 How this is done for a particular service is described in the 152 relevant extensions document. For example, [2] describes session 153 setup and resource allocation for user authentication and 154 authorization. 156 This document describes the more general functions of querying for 157 information on allocated resources, and freeing a session. 159 2.0 Command Codes 161 This document defines the following DIAMETER Commands. All DIAMETER 162 implementations supporting this extension MUST support all of the 163 following commands: 165 Command Name Command Code 166 ----------------------------------- 167 Session-Free-Request 266 168 Session-Free-Answer 267 169 Session-Resource-Query 268 170 Session-Resource-Reply 269 171 Resource-Reclaim-Request 270 172 Resource-Reclaim-Answer 271 174 2.1 Session-Free-Request (SFR) 176 Description 178 The Session-Free-Request message is normally sent by a DIAMETER 179 client to a server, and provides information on specific resources 180 which have been released. 182 The Session-Free-Request message MUST include the Host-IP-Address 183 or the Host-Name as well as the Session-Id AVPs. The Session-Id is 184 used by the server to identify a specific session that was 185 previously authorized. 187 Upon receipt of this message the server MUST free any resources 188 that were previously allocated to the session during the session 189 authorization and respond with the Session-Free-Answer. 191 The Session-Free-Request MAY contain the Result-Code AVP if it is 192 a result of a Session-Reclaim-Request. 194 Message Format 196 ::= 197 198 199 200 201 { || 202 ::= 259 260 261 [] 262 263 264 { || 265 339 340 [] 341 [] 342 [] 343 344 345 { || 346 410 411 412 [] 413 [] 414 [] 415 [] 416 417 418 { || 419 469 470 471 472 473 { || 474 521 522 523 [] 524 525 526 { || 527 742 <-- Reboot-Ack (w/ Res-Mgmt Ext. Id) 743 Session-Resource-Query (Index = 0) --> 744 <-- Session-Resource-Query-Reply (Index = 10) 745 Session-Resource-Query (Index = 10) --> 746 <-- Session-Resource-Query-Reply (Index = 20) 747 Session-Resource-Query (Index = 20) --> 748 <-- Session-Resource-Query-Reply (Index = 0) 750 In the above scenario, the Server issues the initial Session- 751 Resource-Query with a zero Query-Index. The client responds but since 752 it can only fit Resource-Tokens 1 through 9, it sets the Query-Index 753 to 10 in the Session-Resource-Query-Reply. 755 Upon receipt of the response the server processes the message and 756 issues another Session-Resource-Query with the Query-Index value set 757 to 10. The client, upon receipt of the request, knows that it needs 758 to include the Resource-Tokens starting at 10. Again, since the 759 client can only include the Resource-Tokens up to 19, it sets the 760 Query-Index to 20. 762 The Server issues another Session-Resource-Query with the Query-Index 763 set to 20. At this point the client can fit the remaining Resource- 764 Tokens (20 through 26) and therefore sets the Query-Index to zero to 765 indicate that it has sent all of it's active Resource-Tokens. 767 5.0 References 769 [1] Calhoun, Rubens, "DIAMETER Base Protocol", 770 draft-calhoun-diameter-08.txt, Work in Progress, 771 February 1999. 773 [2] Calhoun, Bulley, "DIAMETER Autentication Extensions", 774 draft-calhoun-diameter-auth-04.txt, Work in Progress, 775 July 1998. 777 [3] Calhoun, Zorn, Pan, "DIAMETER Framework", 778 draft-calhoun-diameter-framework-02.txt, Work in Progress, 779 December 1998. 781 6.0 Authors' Addresses 783 Questions about this memo can be directed to: 785 Pat R. Calhoun 786 Network and Security Research Center, Sun Labs 787 Sun Microsystems, Inc. 788 15 Network Circle 789 Menlo Park, California, 94025 790 USA 792 Phone: 1-650-786-7733 793 Fax: 1-650-786-6445 794 E-mail: pcalhoun@eng.sun.com 796 Nancy Greene 797 Public Data Networks 798 Nortel (Northern Telecom) 799 PO Box 3511 Station C 800 Ottawa, Ontario K1Y 4H7 801 Canada 803 Phone: 1-613-763-9789 804 Fax: 1-613-763-8904 805 E-mail: ngreene@nortel.ca