idnits 2.17.1 draft-calhoun-diameter-accounting-09.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 16 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 17 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.) -- The document date (February 2001) is 8471 days in the past. Is this intentional? 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: '4' is defined on line 656, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 659, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 2138 (ref. '4') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '5') (Obsoleted by RFC 2866) ** Obsolete normative reference: RFC 2409 (ref. '7') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) == Outdated reference: A later version (-07) exists of draft-calhoun-diameter-strong-crypto-06 -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Normative reference to a draft: ref. '10' ** Downref: Normative reference to an Informational draft: draft-ietf-aaa-acct (ref. '11') ** Obsolete normative reference: RFC 2393 (ref. '12') (Obsoleted by RFC 3173) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group Jari Arkko 3 Internet-Draft Oy LM Ericsson Ab 4 Category: Standards Track Pat R. Calhoun 5 Sun Microsystems, Inc. 6 Glen Zorn 7 Cisco Systems, Inc. 8 February 2001 10 Diameter Accounting Extensions 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at 22 any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at: 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at: 31 http://www.ietf.org/shadow.html. 33 This document is an individual contribution for consideration by the 34 AAA Working Group of the Internet Engineering Task Force. Comments 35 should be submitted to the diameter@diameter.org mailing list. 37 Distribution of this memo is unlimited. 39 Copyright (C) The Internet Society 2000. All Rights Reserved. 41 Abstract 43 The Diameter protocol provides Authentication, Authorization and 44 Accounting for network access technologies, such as NASREQ, 45 ROAMOPS and Mobile IP. This extension describes how accounting 46 records can be securely transmitted over the Diameter protocol. 47 When combined with the Strong Security extension, accounting 48 records MAY traverse intermediate proxies in a secure fashion and 49 is compatible with the referral broker model. This extension 50 allows real-time accounting transfers. 52 Table of Contents 54 1.0 Introduction 55 1.1 Requirements language 56 1.2 Authorization-Server Directed Model 57 1.3 Protocol Messages 58 1.4 Accounting Info, Usage and Service Specific AVPs 59 1.4.1 Extension document requirements 60 1.5 Fault Resilience 61 1.6 Session Records 62 1.7 Accounting in brokering environments 63 2.0 Command-Codes Values 64 2.1 Accounting-Request (ACR) Command 65 2.2 Accounting-Answer (ACA) Command 66 2.3 Accounting-Poll-Ind (ACP) Command 67 2.4 Accounting-Status-Ind (ASI) Command 68 3.0 Accounting Message Information AVPs 69 3.1 Accounting-Record-Type AVP 70 3.2 Accounting-Interim-Interval AVP 71 3.3 Accounting-Record-Number AVP 72 3.4 Accounting-State AVP 73 3.5 Accounting-Session-Id AVP 74 3.6 Accounting-Authentication-Type AVP 75 4.0 Accounting Usage AVPs 76 4.1 Accounting-Input-Octets AVP 77 4.2 Accounting-Output-Octets AVP 78 4.5 Accounting-Session-Time AVP 79 4.6 Accounting-Input-Packets AVP 80 4.7 Accounting-Output-Packets AVP 81 5.0 Result-Code Values 82 6.0 IANA Considerations 83 7.0 Security Considerations 84 8.0 Acknowledgments 85 9.0 References 86 10.0 Authors' Addresses 87 11.0 Full Copyright Statement 89 1.0 Introduction 91 This accounting protocol is based on an authorization-server directed 92 model with capabilities for real-time delivery of accounting 93 information. Several fault resilience methods [11] have been built in 94 to the protocol in order minimize loss of accounting data in various 95 fault situations and under different assumptions about the 96 capabilities of the used devices. 98 1.1 Requirements language 100 In this document, the key words "MAY", "MUST", "MUST NOT", 101 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 102 interpreted as described in [6]. 104 1.2 Authorization-Server Directed Model 106 The authorization-server directed model means that at authorization 107 time, the device generating the accounting data gets information from 108 the authorization server regarding the way accounting data shall be 109 forwarded. This information includes accounting record timeliness 110 requirements. 112 As discussed in [11], real-time transfer of accounting records is a 113 requirement, such as the need to perform credit limit checks and 114 fraud detection. However, [10] states that batch accounting is not a 115 current requirement, and is therefore not supported by this 116 extension. Should Batched Accounting be required in the future, a new 117 Diameter extension will need to be created, or it could be handled 118 using another protocol. 120 The authorization server (chain) directs the selection of proper 121 transfer strategy, based on its knowledge of the user and 122 relationships of roaming partnerships. The server (or proxies in 123 between) uses the Accounting-Interim-Interval AVP to control the 124 operation of the Diameter peer operating as a client. The 125 Accounting-Interim-Interval AVP, when present, instructs the Diameter 126 node acting as a client to produce accounting records continuously 127 even during a session. 129 The Extension number for this draft is five (5). This value is used 130 in the Extension-Id Attribute value Pair (AVP) as defined in [1]. 132 1.3 Protocol Messages 133 The Diameter peer, acting as a client, generating the accounting data 134 will use the Accounting-Request message to send accounting records to 135 its peer. The receiver (server) MUST reply with the Accounting-Answer 136 message with appropriate confirmations. 138 Upon receipt of an Accounting-Request, a home Diameter server MUST 139 generate a response. A home server is the node that "owns" the realm 140 portion of the user's NAI. The response includes the Result-Code, 141 which MAY contain an error if the accounting information is 142 incorrect. 144 Each Diameter Accounting protocol message MAY be compressed using 145 IPComp [12] in order to reduce the used network bandwidth, which MAY 146 use IKE [7] to negotiate the compression parameters. 148 1.4 Accounting Info, Usage and Service Specific AVPs 150 There are three separate type of classes of Accounting AVPs; 151 Informational, Usage and Service-Specific. The first two are 152 specified in this document, while Service-Specific AVPs are described 153 in service-specific extension documents. Informational Accounting 154 AVPs are used describe the accounting message, including numbering, 155 the type of record, interim accounting intervals, etc. The 156 Accounting Usage AVPs, on the other hand, describe usage information 157 for a given session, and are described in section 4.0. 159 1.4.1 Extension document requirements 161 Each Service-Specific Diameter extension (e.g. NASREQ, MobileIP), 162 MUST define their Service-Specific AVPs that MUST be present in the 163 Accounting-Request message in a section entitled "Accounting 164 Considerations". The extension MUST assume that the AVPs described in 165 this document will be present in all Accounting messages, so only 166 their respective service-specific AVPs need to be defined in this 167 section. 169 1.5 Fault Resilience 171 Diameter Base protocol [11] mechanisms are used to overcome small 172 message loss and network faults of temporary nature. 174 Diameter peers acting as clients MUST implement the use of alternate 175 servers to guard against server failures and certain network 176 failures. Diameter peers acting as servers or related off-line 177 processing systems MUST detect duplicate accounting records caused by 178 the sending of same record to several servers and duplication of 179 messages in transit. This detection MUST be based on the inspection 180 of the Session-Id [1] and Accounting-Record-Number AVP pairs. 182 Diameter clients MAY have non-volatile memory for the safe storage of 183 accounting records over reboots or extended network failures, network 184 partitions, and server failures. If such memory is available the 185 client SHOULD store new accounting records there as soon as the 186 records are created and until a positive acknowledgement of their 187 reception from the Diameter Server has been received. Upon a reboot, 188 the client MUST starting sending the records in the non-volatile 189 memory to the accounting server with appropriate modifications in 190 termination cause, session length, and other relevant information in 191 the records. 193 A further extension of this protocol may include AVPs to control how 194 many accounting records may at most be stored in the Diameter client 195 without committing them to the non-volatile memory or transferring 196 them to the Diameter server. 198 The client SHOULD NOT remove the accounting data from any of its 199 memory areas before the correct Accounting-Answer has been received. 200 The client MAY remove oldest, undelivered or yet unacknowledged 201 accounting data if it runs out of resources such as memory. It is an 202 implementation dependent matter for the client to accept new sessions 203 under this condition. 205 1.6 Session Records 207 In all accounting records the Session-Id and User-Name AVPs MUST be 208 present. If strong authentication is required, as described in [9], 209 the CMS-Data AVP may be used to authenticate the Accounting Data and 210 Service Specific AVPs. It is not typically necessary, nor 211 recommended, that the strong authentication cover any additional AVPs 212 since the Data and Service Specific AVP, and associated CMS-Data, MAY 213 need to be submitted to a third party (see section 1.7 below). 215 Different types of session records are sent depending on the actual 216 type of accounted service and the authorization server's directions 217 for interim accounting. If the accounted service is a one-time event, 218 meaning that the start and stop of the event are simultaneous, then 219 the Accounting-Record-Type AVP MUST be present and set to the value 220 EVENT_RECORD. 222 If the accounted service is of a measurable length, then the AVP MUST 223 use the values START_RECORD, STOP_RECORD, and possibly, 224 INTERIM_RECORD. If the authorization server has directed interim 225 accounting to be enabled for the session, but no interim interval was 226 specified, two accounting records MUST be generated for each service 227 of type session. When the initial Accounting-Request is sent for a 228 given session is sent, the Accounting-Record-Type AVP MUST be set to 229 the value START_RECORD. When the last Accounting-Request is sent, the 230 value MUST be STOP_RECORD. 232 If a specified interim interval exists, the Diameter client MUST 233 produce additional records between the START_RECORD and STOP_RECORD, 234 marked INTERIM_RECORD. The production of these records is directed 235 both by Accounting-Interim-Interval as well as any re-authentication 236 or re-authorization of the session. The Diameter client MUST 237 overwrite any previous interim accounting records that are locally 238 stored for delivery, if a new record is being generated for the same 239 session. This ensures that only one pending interim record can exist 240 on a NAS for any given session. 242 1.7 Accounting in brokering environments 244 The Diameter base protocol [1] describes brokers that provide 245 redirect services, by allowing AAA servers within a roaming 246 consortium to directly communicate. Referral services can be secured 247 using the strong security extension defined in [9]. Since brokers can 248 also provide settlement services, they typically need to be aware of 249 the accounting information exchange, and since they are no longer 250 part of the message exchange, the Diameter protocol MUST allow the 251 broker to receive the accounting record. The strong security [9] 252 provides the broker with the assurances it needs that both parties 253 agreed with the accounting information submitted. 255 When the local AAA server issues an Accounting-Request to the home 256 AAA server, it includes accounting usage and service specific AVPs as 257 well as a CMS-Data AVP [9], which contains the signature of the local 258 AAA server. The home server MUST add it's own signature to the CMS- 259 Data AVP, that covers both the same AVPs as above and the local AAA's 260 signature. The whole is submitted to the local AAA server in the 261 Accounting-Answer. The local AAA server MUST submit the accounting 262 AVPs, and associated CMS-Data AVP to the broker. The broker can 263 verify that both parties participated and accepted the accounting 264 record, by validating the signatures. 266 2.0 Command-Codes Values 268 This section defines new Command-Code [1] values that MUST be 269 supported by all Diameter implementations that conform to this 270 specification. The following Command Codes are currently defined in 271 this document: 273 Command-Name Abbrev. Code Reference 274 -------------------------------------------------------- 275 Accounting-Answer ACA 272 2.2 276 Accounting-Poll-Ind ACP 273 2.4 277 Accounting-Request ACR 271 2.1 278 Accounting-Status-Ind ASI 279 2.3 280 2.1 Accounting-Request (ACR) Command 282 The Accounting-Request command, indicated by the Command-Code field 283 set to 271, is sent by a Diameter node, acting as a client, in order 284 to exchange accounting information with a peer. 286 When the Accounting-Request is being submitted to a broker, and 287 includes the CMS-Data AVP [9], the CMS-Data AVP MUST be signed by 288 both the local and home Diameter server using the countersignature 289 procedures described in [9]. 291 The AVP listed below SHOULD include service specific accounting AVPs, 292 as described in section 1.4. 294 Message Format 296 ::= < Diameter Header: 271 > 297 { Session-Id } 298 { Host-Name } 299 { Accounting-Record-Type } 300 { Accounting-Record-Number } 301 [ Accounting-Interim-Interval ] 302 [ Accounting-State ] 303 { Accounting-Session-Id } 304 { Accounting-Authentication-Type } 305 { Accounting-Input-Octets } 306 { Accounting-Output-Octets } 307 { Accounting-Session-Time } 308 { Accounting-Input-Packets } 309 { Accounting-Output-Packets } 310 * [ AVP ] 311 [ CMS-Data ] 312 * [ Proxy-State ] 313 * [ Route-Record ] 314 * [ Routing-Realm ] 315 0*1< Integrity-Check-Value > 317 2.2 Accounting-Answer (ACA) Command 319 The Accounting-Answer command, indicated by the Command-Code field 320 set to 272, is used to acknowledge an Accounting-Request command. The 321 Accounting-Answer command contains the same Session-Id and MAY 322 contains the same Accounting Description and Usage AVPs that were 323 sent in the Accounting-Request command. If the CMS-Data AVP was 324 present in the Accounting-Request, the corresponding ACA message MUST 325 include the CMS-Data AVP signed by the responder to provide strong 326 AVP authentication, which MAY be used for the purposes of 327 repudiation. 329 Only the target Diameter Server, known as the home Diameter Server, 330 SHOULD respond with the Accounting-Answer command. However, if a 331 Diameter node in the proxy chain stores the accounting records for 332 submission to the home network in batched mode, it MUST respond to 333 the request. 335 The AVP listed below SHOULD include service specific accounting AVPs, 336 as described in section 1.4. 338 Message Format 340 ::= < Diameter Header: 272 > 341 { Session-Id } 342 { Result-Code } 343 { Host-Name } 344 { Accounting-Record-Type } 345 { Accounting-Record-Number } 346 { Accounting-Session-Id } 347 [ Accounting-Interim-Interval ] 348 [ Accounting-State ] 349 [ Accounting-Authentication-Type ] 350 [ Accounting-Input-Octets ] 351 [ Accounting-Output-Octets ] 352 [ Accounting-Session-Time ] 353 [ Accounting-Input-Packets ] 354 [ Accounting-Output-Packets ] 355 * [ AVP ] 356 [ CMS-Data ] 357 * [ Proxy-State ] 358 * [ Route-Record ] 359 * [ Routing-Realm ] 360 0*1< Integrity-Check-Value > 362 2.3 Accounting-Status-Ind (ASI) Command 363 The Accounting-Status-Ind command, indicated by the Command-Code 364 field set to 279, is sent by a Diameter node in order to inform its 365 peer of whether Accounting messages will be sent in the future. A 366 Diameter node that is about to be taken out of service SHOULD issue 367 an Accounting-Status-Ind message, with the Accounting-State AVP set 368 to DISABLED. A Diameter node that detected that it is able to issue 369 Accounting messages MUST issue an Accounting-Status-Ind message, with 370 the Accounting-State AVP set to ENABLED. 372 Message Format 374 ::= 375 { Host-Name } 376 { Accounting-State } 377 * [ AVP ] 378 * [ Proxy-State ] 379 * [ Route-Record ] 380 * [ Routing-Realm ] 381 0*1< Integrity-Check-Value > 383 2.3 Accounting-Poll-Ind (ACP) Command 385 The Accounting-Poll-Ind command, indicated by the Command-Code field 386 set to 273, is sent by a Diameter Server in order to force the peer 387 to send current accounting data. This data MUST include not yet sent 388 accounting records from completed sessions, as well as INTERIM_RECORD 389 records from all ongoing sessions. 391 Diameter implementations MAY support the Accounting-Poll-Ind command. 392 An implementation still conforms to this specification if ACP is not 393 supported. 395 The receiver MUST use the Accounting-Request command to send the 396 accounting data. 398 The use of Accounting-Poll-Ind is useful in situations where a 399 Diameter server comes up after an unscheduled downtime, and wishes to 400 synchronize with the client(s) sooner than at the end of the next 401 INTERIM_RECORD or at the end of a session. 403 Warning: The use of the Accounting-Poll-Ind message is discouraged in 404 roaming networks, since it is unfeasible for a server to attempt to 405 poll all of it's roaming partner's Diameter peers. 407 Message Format 409 ::= 410 { Session-Id } 411 { Host-Name } 412 { Accounting-Session-Id } 413 [ Destination-NAI ] 414 * [ AVP ] 415 * [ Proxy-State ] 416 * [ Route-Record ] 417 * [ Routing-Realm ] 418 0*1< Integrity-Check-Value > 420 3.0 Accounting Message Information AVPs 422 The following table describes the Diameter AVPs defined in the 423 Accounting extension, their AVP Code values, types, possible flag 424 values and whether the AVP MAY be encrypted. 426 +---------------------+ 427 | AVP Flag rules | 428 |----+-----+----+-----|----+ 429 AVP Section | | |SHLD| MUST|MAY | 430 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 431 -----------------------------------------|----+-----+----+-----|----| 432 Accounting- 45 3.6 Unsigned32 | M | P | | V | Y | 433 Authentication-Type | | | | | | 434 Accounting- 482 3.2 Unsigned32 | M | P | | V | Y | 435 Interim-Interval | | | | | | 436 Accounting- 485 3.3 Unsigned32 | M | P | | V | Y | 437 Record-Number | | | | | | 438 Accounting- 480 3.1 Unsigned32 | M | P | | V | Y | 439 Record-Type | | | | | | 440 Accounting- 44 3.5 OctetString| M | P | | V | Y | 441 Session-Id | | | | | | 442 Accounting-State 486 3.4 Unsigned32 | M | P | | V | Y | 444 3.1 Accounting-Record-Type AVP 446 The Accounting-Record-Type AVP (AVP Code 480) is of type Unsigned32 447 and contains the type of accounting record being sent. The following 448 values are currently defined for the Accounting-Record-Type AVP: 450 EVENT_RECORD 1 451 An Accounting Event Record is used to indicate that a one-time 452 event has occurred (meaning that the start and end of the event 453 are simultaneous). This record contains all information 454 relevant to the service, and is the only record of the service. 456 START_RECORD 2 457 An Accounting Start, Interim, and Stop Records are used to 458 indicate that a service of a measurable length has been given. 459 An Accounting Start Record is used to initiate an accounting 460 session, and contains accounting information that is relevant 461 to the initiation of the session. 463 INTERIM_RECORD 3 464 An Interim Accounting Record contains cumulative accounting 465 information for an existing accounting session. Interim 466 Accounting Records SHOULD be sent every time a re- 467 authentication or re-authorization occurs. Further, additional 468 interim record triggers MAY be defined by application-specific 469 Diameter extensions. The selection of whether to use 470 INTERIM_RECORD records is directed by the Accounting-Interim- 471 Interval AVP. 473 STOP_RECORD 4 474 An Accounting Stop Record is sent to terminate an accounting 475 session and contains cumulative accounting information relevant 476 to the existing session. 478 3.2 Accounting-Interim-Interval AVP 480 The Accounting-Interim-Interval AVP (AVP Code 482) is of type 481 Unsigned32 and is sent from the Diameter authenticating/authorizing 482 server to the Diameter client. The client uses information in this 483 AVP to decide how and when to produce accounting records. With 484 different values in this AVP, service sessions can result in one, 485 two, or two+N accounting records, based on the needs of the home- 486 organization. The following accounting record production behaviour is 487 directed by the inclusion of this AVP: 489 1. The omission of the Accounting-Interim-Interval AVP or its 490 inclusion with Value field set to 0 means that EVENT_RECORD, 491 START_RECORD, and STOP_RECORD are produced, as appropriate for 492 the service. 494 2. The inclusion of the AVP with Value field set to a non-zero 495 value means that INTERIM_RECORD records MUST be produced 496 between the START_RECORD and STOP_RECORD records. The Value 497 field of this AVP is the nominal interval between these records 498 in seconds. The Diameter node that originates the accounting 499 information, known as the client, MUST produce the first 500 INTERIM_RECORD record roughly at the time when this nominal 501 interval has elapsed from the START_RECORD, the next one again 502 as the interval has elapsed once more, and so on until the 503 session ends and a STOP_RECORD record is produced. 505 The client MUST ensure that the interim record production times 506 are randomized so that large accounting message storms are not 507 created either among records or around a common service start 508 time. 510 3.3 Accounting-Record-Number AVP 512 The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32 513 and identifies this record within one session. As Session-Id AVPs are 514 globally unique, the combination of Session-Id and Accounting- 515 Record-Number AVPs is also globally unique, and can be used in 516 matching accounting records with confirmations. An easy way to 517 produce unique numbers is to set the value to 0 for records of type 518 EVENT_RECORD and START_RECORD, and set the value to 1 for the first 519 INTERIM_RECORD, 2 for the second, and so on until the value for 520 STOP_RECORD is one more than for the last INTERIM_RECORD. 522 3.4 Accounting-State AVP 524 The Accounting-State AVP (AVP Code 486) is of type Unsigned32 and is 525 used to communicate to a peer whether Accounting messages will be 526 sent in the future. A node that issues an ASI with the Accounting- 527 State AVP set to DISABLED is informing its peer that it will no 528 longer be transmitting Accounting messages until a subsequent ASI 529 message is sent with the Accounting-State AVP set to ENABLED. 531 The following values have been defined: 532 1 ENABLED 533 2 DISABLED 535 3.5 Accounting-Session-Id AVP 537 The Accounting-Session-Id AVP (AVP Code 44) is of type OctetString, 538 and SHOULD be encoded in UTF-8 format. The Accounting-Session-Id is 539 not used by the Diameter protocol, since the Session-Id defined in 540 [1] is used for both authentication/authorization and accounting 541 purposes. However, a RADIUS/Diameter gateway MAY need to include the 542 Accounting-Session-Id in Diameter accounting messages. 544 3.6 Accounting-Authentication-Type AVP 546 The Accounting-Authentication-Type AVP (AVP Code 45) is of type 547 Unsigned32, and specifies how the user was authenticated. The 548 following values are supported: 549 1 RADIUS 550 2 Local 551 3 Remote 552 4 Diameter 554 4.0 Accounting Usage AVPs 556 This section contains AVPs that describe accounting usage information 557 related to a specific session. 559 +---------------------+ 560 | AVP Flag rules | 561 |----+-----+----+-----|----+ 562 AVP Section | | |SHLD| MUST|MAY | 563 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 564 -----------------------------------------|----+-----+----+-----|----| 565 Accounting- 42 4.1 Unsigned32 | M | P | | V | Y | 566 Input-Octets | | | | | | 567 Accounting- 47 4.4 Unsigned32 | M | P | | V | Y | 568 Input-Packets | | | | | | 569 Accounting- 43 4.2 Unsigned32 | M | P | | V | Y | 570 Output-Octets | | | | | | 571 Accounting- 48 4.5 Unsigned32 | M | P | | V | Y | 572 Output-Packets | | | | | | 573 Accounting- 46 4.3 Unsigned32 | M | P | | V | Y | 574 Session-Time | | | | | | 576 4.1 Accounting-Input-Octets AVP 578 The Accounting-Input-Octets AVP (AVP Code 42) is of type Unsigned64, 579 and contains the number of octets in IP packets received by the user. 581 4.2 Accounting-Output-Octets AVP 583 The Accounting-Output-Octets AVP (AVP Code 43) is of type Unsigned64, 584 and contains the number of octets in IP packets sent to the user. 586 4.3 Accounting-Session-Time AVP 587 The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32, 588 and indicates the length of the current session in seconds. 590 4.4 Accounting-Input-Packets AVP 592 The Accounting-Input-Packets (AVP Code 47) is of type Unsigned64, and 593 contains the number of IP packets received by the user. 595 4.5 Accounting-Output-Packets AVP 597 The Accounting-Output-Packets (AVP Code 48) is of type Unsigned64, 598 and contains the number of IP packets sent to the user. 600 5.0 Result-Code Values 602 Errors defined in this section indicates a particular type of failure 603 in the accounting data transfer process. Diameter clients MAY use 604 this information in deciding a retransmission strategy after the 605 error has happened. For instance, an out of space condition isn't 606 typically recovered very soon, so a Diameter node might wait longer 607 for the next retry than after network or server outage. 609 DIAMETER_OUT_OF_SPACE 4007 610 A Diameter node received the accounting request but was unable 611 to commit it to stable storage due to a temporary lack of 612 space. 614 6.0 IANA Considerations 616 The command codes defined in Section 2.0 are values taken from the 617 Command-Code [1] address space and extended in [2], [3] and [9]. 618 IANA should record the values as defined in Section 2.0. 620 The AVPs defined in section 3.0 and 5.0 were alllocated from from the 621 AVP numbering space defined in [1], and extended in [2], [3] and [9]. 622 IANA should record the values as defined in Section 3.0. 624 This document introduces the Accounting-Record-Type AVP, which 625 contains pre-defined values. This document defines the values 1-3. 626 All remaining values are available for assignment via a Designated 627 Expert [8]. 629 7.0 Security Considerations 630 This Diameter extension assumes that the accounting data is secured 631 either through a hop-by-hop authentication mechanism, as described in 632 [1], or using a strong authentication mechanism as defined in [9]. 634 8.0 Acknowledgments 636 The authors would like to thank Nenad Trifunovic, Tony Johansson and 637 Pankaj Patel for their participation in the Document Reading Party. 638 Thanks to the various people that have contributed to accounting 639 related requirements at the IETF's AAA Working Group and other 640 related WGs. 642 9.0 References 644 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman. "Diameter Base 645 Protocol", draft-calhoun-diameter-18.txt, IETF work in progress, 646 January 2001. 648 [2] P. Calhoun, W. Bulley, A. Rubens, J. Haag. "Diameter NASREQ 649 Extension", draft-calhoun-diameter-nasreq-06.txt, IETF work in 650 progress, January 2001. 652 [3] P. Calhoun, C. Perkins. "Diameter Mobile IP Extension", draft- 653 calhoun-diameter-mobileip-12.txt, IETF work in progress, January 654 2001. 656 [4] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authenti- 657 cation Dial In User Service (RADIUS)." RFC 2138, April 1997. 659 [5] C. Rigney, "RADIUS Accounting." RFC 2139, April 1997. 661 [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement 662 Levels", BCP 14, RFC 2119, March 1997. 664 [7] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 665 2409, November 1998. 667 [8] Narten, Alvestrand, "Guidelines for Writing an IANA Considera- 668 tions Section in RFCs", BCP 26, RFC 2434, October 1998 670 [9] P. Calhoun, W. Bulley, S. Farrell, "Diameter Strong Security 671 Extension", draft-calhoun-diameter-strong-crypto-06.txt, IETF 672 work in progress, January 2001. 674 [10] J. Arkko, P. Calhoun, E. Guttman, B. Nelson, B. Wolff, "AAA 675 Solutions", draft-ietf-aaa-solutions-01.txt, IETF work in pro- 676 gress, November 2000. 678 [11] B. Aboba, J. Arkko, D. Harrington. "Introduction to Accounting 679 Management", draft-ietf-aaa-acct-06.txt, IETF work in progress, 680 June 2000. 682 [12] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload 683 Compression Protocol (IPComp)", RFC 2393, December 1998. 685 10.0 Authors' Addresses 687 Questions about this memo can be directed to: 689 Jari Arkko 690 Oy LM Ericsson Ab 691 02420 Jorvas 692 Finland 694 Phone: +358 40 5079256 695 E-Mail: Jari.Arkko@ericsson.com 697 Pat R. Calhoun 698 Network and Security Research Center, Sun Labs 699 Sun Microsystems, Inc. 700 15 Network Circle 701 Menlo Park, California, 94025 702 USA 704 Phone: +1 650-786-7733 705 Fax: +1 650-786-6445 706 E-mail: pcalhoun@eng.sun.com 708 Glen Zorn 709 Cisco Systems, Inc. 710 500 108th Avenue N.E., Suite 500 711 Bellevue, WA 98004 712 USA 714 Phone: +1 425 438 8218 715 E-Mail: gwz@cisco.com 717 11.0 Full Copyright Statement 718 Copyright (C) The Internet Society (2001). All Rights Reserved. 720 This document and translations of it may be copied and furnished to 721 others, and derivative works that comment on or otherwise explain it 722 or assist in its implementation may be prepared, copied, published 723 and distributed, in whole or in part, without restriction of any 724 kind, provided that the above copyright notice and this paragraph are 725 included on all such copies and derivative works. However, this docu- 726 ment itself may not be modified in any way, such as by removing the 727 copyright notice or references to the Internet Society or other 728 Internet organizations, except as needed for the purpose of develop- 729 ing Internet standards in which case the procedures for copyrights 730 defined in the Internet Standards process must be followed, or as 731 required to translate it into languages other than English. The lim- 732 ited permissions granted above are perpetual and will not be revoked 733 by the Internet Society or its successors or assigns. This document 734 and the information contained herein is provided on an "AS IS" basis 735 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 736 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 737 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 738 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 739 FITNESS FOR A PARTICULAR PURPOSE. 741 12.0 Expiration Date 743 This memo is filed as and 744 expires in July 2001.