idnits 2.17.1 draft-calhoun-diameter-accounting-04.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 14 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 15 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. ** The abstract seems to contain references ([2], [3], [9], [10]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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) == Unused Reference: '4' is defined on line 560, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 563, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-13 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-06) exists of draft-calhoun-diameter-nasreq-02 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-06 -- 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) -- Possible downref: Normative reference to a draft: ref. '7' ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) -- No information found for draft-calhoun-diameter-strong-security - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-08) exists of draft-ietf-roamops-actng-06 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-06) exists of draft-ietf-aaa-acct-00 ** Downref: Normative reference to an Informational draft: draft-ietf-aaa-acct (ref. '11') ** Obsolete normative reference: RFC 2393 (ref. '12') (Obsoleted by RFC 3173) ** Obsolete normative reference: RFC 2409 (ref. '13') (Obsoleted by RFC 4306) Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Jari Arkko 3 Category: Standards Track Oy LM Ericsson Ab 4 Title: draft-calhoun-diameter-accounting-04.txt Pat R. Calhoun 5 Date: March 2000 Sun Microsystems, Inc. 6 Pankaj Patel 7 Convergys Corporation 8 Glen Zorn 9 Cisco Systems, Inc. 11 DIAMETER Accounting Extension 13 Status of this Memo 15 This document is an individual contribution for consideration by the 16 AAA Working Group of the Internet Engineering Task Force. Comments 17 should be submitted to the diameter@ipass.com mailing list. 19 Distribution of this memo is unlimited. 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at 29 any time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at: 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at: 38 http://www.ietf.org/shadow.html. 40 Copyright (C) The Internet Society 1999. All Rights Reserved. 42 Abstract 44 The DIAMETER protocol provides Authentication and Authorization for 45 dial-up PPP clients [2] and for Mobile-IP [3]. The ROAMOPS WG has 46 been working on an accounting data format, called Accounting Data 47 Interchange Format (ADIF) [10], as a method to transfer accounting 48 information over a wide variety of transports. 50 This extension describes how accounting records can be securely 51 transmitted over the DIAMETER protocol. When combined with the 52 Strong Security [9] extension, accounting records MAY traverse 53 intermediate proxies in a secure fashion and is compatible with 54 the referral broker model. This extension allows for both 55 real-time and batched accounting transfers. 57 Table of Contents 59 1.0 Introduction 60 1.1 Requirements language 61 1.2 Authorization-Server Directed Model 62 1.3 Protocol Messages 63 1.4 Fault Resilience 64 1.5 Session Records 65 1.6 Accounting in brokering environments 66 2.0 Command-Codes AVP Values 67 2.1 Accounting-Request (ACR) Command 68 2.2 Accounting-Answer (ACA) Command 69 2.3 Accounting-Poll-Ind (ACP) Command 70 3.0 Mandatory AVPs 71 3.1 Accounting-Record-Type AVP 72 3.2 ADIF-Record AVP 73 3.3 Accounting-Interim-Interval AVP 74 3.4 Accounting-Delivery-Max-Batch AVP 75 3.5 Accounting-Delivery-Max-Delay AVP 76 3.6 Accounting-Record-Number AVP 77 4.0 IANA Considerations 78 5.0 Security Considerations 79 6.0 Acknowledgments 80 7.0 References 81 8.0 Authors' Addresses 82 9.0 Full Copyright Statement 84 1.0 Introduction 86 This accounting protocol is based on an authorization-server directed 87 model with capabilities for both efficient batch and fast real-time 88 delivery of accounting information. Several fault resilience methods 89 [11] have been built in to the protocol in order minimize loss of 90 accounting data in various fault situations and under different 91 assumptions about the capabilities of the used devices. 93 1.1 Requirements language 95 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 96 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 97 described in [6]. 99 1.2 Authorization-Server Directed Model 101 The authorization-server directed model means that at authorization 102 time, the device generating the accounting data gets information from 103 the authorization server regarding the way accounting data shall be 104 forwarded. This information includes accounting record timeliness 105 requirements. 107 As discussed in [11], batch transfer of accounting data is more CPU- 108 and bandwidth efficient than real-time transfer. However, there are 109 many applications where real-time transfer is a requirement for at 110 least some of the accounting records. These applications include 111 roaming, where most (local) accounting records can be transferred in 112 batch mode, but roaming (visiting) accounting records should be 113 transferred fast due to the needs of credit limit checks and fraud 114 detection. For these reasons this accounting protocol defines both 115 batch and real-time transfer modes, and allows their use 116 simultaneously. The authorization server (chain) directs the 117 selection of proper transfer strategy, based on its knowledge of the 118 user and relationships of roaming partnerships. The server (or 119 proxies in between) use the Accounting-Delivery-Max-Batch, 120 Accounting-Delivery-Max-Delay, and Accounting-Interim-Interval AVPs 121 to control the operation of the DIAMETER peer operating as a client. 122 The first two attributes set the requirements in terms of number of 123 records and maximum delay before accounting data transfer for this 124 session SHOULD begin. The DIAMETER peer acting as a client MAY 125 deliver the data earlier due to a full batch of records, device 126 reboot, lack of memory, or explicit configuration. The DIAMETER 127 client MUST begin the transfer in the given limits unless prevented 128 from doing so by network partitions, failures of peers, network 129 congestion, or client overload. 131 The Accounting-Interim-Interval AVP, when present, instructs the 132 DIAMETER node acting as a client to produce accounting records 133 continuously even during a session. 135 Typically, the authorization server uses a few batching/real-time 136 classes, such as the local users whose data might be transferred once 137 in an hour and the roaming users whose data would be transferred 138 immediately. Each Accounting-Delivery-Max-Batch / Accounting- 139 Delivery-Max-Delay AVP pair with different values forms one pool of 140 accounting data in the DIAMETER node acting as a client. That is, a 141 new record is placed to same pool as the previous one if the 142 authorization server returned same values for both AVPs and the pool 143 has not been emptied in between. 145 The Extension number for this draft is five (5). This value is used 146 in the Extension-Id Attribute value Pair (AVP) as defined in [7]. 148 1.3 Protocol Messages 150 The DIAMETER peer, acting as a client, generating the accounting data 151 will use the Accounting-Request message to send one or more 152 accounting records to its peer. The receiver (server) MUST reply with 153 the Accounting-Answer message with appropriate confirmations. 155 It is possible that a DIAMETER Proxy breaks up a batch of accounting 156 records and sends them towards different DIAMETER Home servers. In 157 this case, it is possible that a separate Accounting-Answer message 158 contain the response for each block. Therefore, a DIAMETER node MUST 159 be prepared to handle this scenario. 161 Upon receipt of an Accounting-Request, a home DIAMETER server MUST 162 generate a response. A home server is the node that "owns" the realm 163 portion of the user's NAI. The response includes the Result-Code, 164 which MAY contain an error if the ADIF-Record, or some other AVP, is 165 not acceptable. 167 Each DIAMETER Accounting protocol message MAY be compressed using 168 IPComp [12] in order to reduce the used network bandwidth. DIAMETER 169 peers MUST use a negotiation mechanisms such as IKE [13] in order to 170 ensure that both peers are able to handle IPComp. 172 1.4 Fault Resilience 174 DIAMETER Base protocol [11] mechanisms are used to overcome small 175 message loss and network faults of temporary nature. 177 DIAMETER peers acting as clients MUST implement the use of alternate 178 servers to guard against server failures and certain network 179 failures. DIAMETER peers acting as servers or related off-line 180 processing systems MUST detect duplicate accounting records caused by 181 the sending of same record to several servers and duplication of 182 messages in transit. This detection MUST be based on the inspection 183 of the Session-Id [1] and Accounting-Record-Number AVP pairs. 185 DIAMETER clients MAY have non-volatile memory for the safe storage of 186 accounting records over reboots or extended network failures, network 187 partitions, and server failures. If such memory is available the 188 client SHOULD store new accounting records there as soon as the 189 records are created and until a positive acknowledgement of their 190 reception from the DIAMETER Server has been received. Upon a reboot, 191 the client MUST starting sending the records in the non-volatile 192 memory to the accounting server with appropriate modifications in 193 termination cause, session length, and other relevant information in 194 the records. 196 A further extension of this protocol may include AVPs to control how 197 many accounting records may at most be stored in the DIAMETER client 198 without committing them to the non-volatile memory or transferring 199 them to the DIAMETER server. 201 The client SHOULD NOT remove the accounting data from any of its 202 memory areas before the correct Accounting-Answer has been received. 203 The client MAY remove oldest, undelivered or yet unacknowledged 204 accounting data if it runs out of resources such as memory. It is an 205 implementation dependent matter for the client to accept new sessions 206 under this condition. 208 1.5 Session Records 210 In all accounting records the Session-Id AVP, ADIF-Record AVP, and 211 User-Name AVPs MUST be present. If strong authentication is required, 212 as described in [9], the CMS-Data AVP may be used to authenticate the 213 ADIF-Record AVP. It is not typically necessary, nor recommended, that 214 the strong authentication cover any additional AVPs since the ADIF- 215 Record, and associated CMS-Data, MAY need to be submitted to a third 216 party (see section 1.6 below). 218 However, if the accounting records are being in sent in batch mode, 219 the sender can create several "blocks" of accounting records by 220 making use of the AVP Tag field (bit 'T' [1]). Each block has a 221 unique tag value, and an optional CMS-Data AVP. If it is known that 222 multiple ADIF-Records are being sent to the same home DIAMETER 223 server, it is possible to have one CMS-Data AVP cover multiple the 224 ADIF-Records. This optimization reduces the crypto computation that 225 would otherwise be necessary. 227 Different types of session records are sent depending on the actual 228 type of accounted service and the authorization server's directions 229 for interim accounting. If the accounted service is a one-time event, 230 meaning that the start and stop of the event are simultaneous, then 231 the Accounting-Record-Type AVP MUST be present and set to the value 232 EVENT_RECORD. 234 If the accounted service is of a measurable length, then the AVP MUST 235 use the values START_RECORD, STOP_RECORD, and possibly, 236 INTERIM_RECORD. If the authorization server has directed interim 237 accounting to be enabled for the session, but no interim interval was 238 specified, two accounting records MUST be generated for each service 239 of type session. When the initial Accounting-Request is sent for a 240 given session is sent, the Accounting-Record-Type AVP MUST be set to 241 the value START_RECORD. When the last Accounting-Request is sent, the 242 value MUST be STOP_RECORD. 244 If a specified interim interval exists, the DIAMETER client MUST 245 produce additional records between the START_RECORD and STOP_RECORD, 246 marked INTERIM_RECORD. The production of these records is directed 247 both by Accounting-Interim-Interval as well as any re-authentication 248 or re-authorization of the session. If a batch size of greater than 249 1 has been specified by the authorization server, then the DIAMETER 250 client MUST ensure that new interim records overwrite previous 251 interim records for the same session and batch as this reduces the 252 amount of memory required to store the records. In effect, this means 253 that interim records are delivered at least as often as dictated by 254 Accounting-Delivery-Max-Delay. 256 1.6 Accounting in brokering environments 258 The DIAMETER base protocol [1] describes brokers that provide 259 redirect services, by allowing AAA servers within a roaming 260 consortium to directly communicate. Referral services can be secured 261 using the strong security extension defined in [9]. Since brokers can 262 also provide settlement services, they typically need to be aware of 263 the accounting information exchange, and since they are no longer 264 part of the message exchange, the DIAMETER protocol MUST allow the 265 broker to receive the accounting record. The strong security [9] 266 provides the broker with the assurances it needs that both parties 267 agreed with the accounting information submitted. 269 When the local AAA server issues an Accounting-Request to the home 270 AAA server, it includes an ADIF-Record AVP as well as a CMS-Data AVP 271 [9], which contains the signature of the local AAA server. The home 272 server MUST add it's own signature to the CMS-Data AVP, that covers 273 both the ADIF-Record and the local AAA's signature. The whole is 274 submitted to the local AAA server in the Accounting-Answer. The local 275 AAA server MUST submit the ADIF-Record, and associated CMS-Data AVP 276 to the broker. The broker can verify that both parties participated 277 and accepted the accounting record, by validating the signatures. 279 2.0 Command-Codes AVP Values 280 This section defines new Command-Code [1] values that MUST be 281 supported by all DIAMETER implementations that conform to this 282 specification. The following Command Codes are currently defined in 283 this document: 285 Command-Name Abbrev. Code Reference 286 -------------------------------------------------------- 287 Accounting-Request ACR 271 2.1 288 Accounting-Answer ACA 272 2.2 289 Accounting-Poll-Ind ACP 273 2.3 291 2.1 Accounting-Request (ACR) Command 293 The Accounting-Request command, indicated by the Command-Code AVP set 294 to 271, is sent by a DIAMETER node, acting as a client, in order to 295 exchange accounting information with a peer. The Accounting 296 information is contained within an ADIF record, as described in [10]. 298 The Accounting-Request command MAY contain accounting information for 299 more than a single session, which allows it to send batched 300 accounting information. When the batch mode is used, the session-Id 301 AVP [1] MUST be present and the CMS-Data AVP [9] MAY be present, and 302 MUST have a tag of the same value as the ADIF-Record AVP. When the 303 Accounting-Request is being submitted to a broker, and includes the 304 CMS-Data AVP [9], the CMS-Data AVP MUST be signed by both the local 305 and home DIAMETER server using the countersignature procedures 306 described in [9]. 308 Message Format 310 ::= 311 312 313 ( && 314 && 315 && 316 && 317 && 318 ) 319 [ 320 321 ] 323 2.2 Accounting-Answer (ACA) Command 324 The Accounting-Answer command, indicated by the Command-Code AVP set 325 to 272, is used to acknowledge an Accounting-Request command. The 326 Accounting-Answer command contains the same Session-Id and ADIF- 327 Record AVPs that were sent in the Accounting-Request command. This 328 can be signed using the CMS-Data AVP for strong AVP authentication, 329 which MAY be used for the purposes of repudiation. 331 Only the target DIAMETER Server, known as the home DIAMETER Server, 332 SHOULD respond with the Accounting-Answer command. 334 If the Accounting-Request command contained more than one ADIF-Record 335 AVP, the Accounting-Answer SHOULD contain the same number of ADIF- 336 Record AVPs. However, it is possible for the DIAMETER Server to 337 acknowledge each ADIF-Record in a separate response. This allows the 338 sender of the ADIF-Records to send a batch of records, whose final 339 destination are different. 341 Message Format 343 ::= 344 345 346 347 348 ( && 349 && 350 && 351 ) 352 [ 353 354 ] 356 2.3 Accounting-Poll-Ind (ACP) Command 358 The Accounting-Poll-Ind command, indicated by the Command-Code AVP 359 set to 273, is sent by a DIAMETER Server in order to force the peer 360 to send current accounting data. This data MUST include not yet sent 361 accounting records from completed sessions, as well as INTERIM_RECORD 362 records from all ongoing sessions. 364 The receiver MUST use the Accounting-Request command to send the 365 accounting data. 367 The use of Accounting-Poll-Ind is useful in situations where a 368 DIAMETER server comes up after an unscheduled downtime, and wishes to 369 synchronize with the client(s) sooner than at the end of the next 370 INTERIM_RECORD or at the end of a session. 372 Warning: The use of the Accounting-Poll-Ind message is discouraged in 373 roaming networks, since it is unfeasible for a server to attempt to 374 poll all of it's roaming partner's DIAMETER peers. 376 Message Format 378 ::= 379 380 381 382 [ 383 384 ] 386 3.0 Mandatory AVPs 388 The following table describes the DIAMETER AVPs defined in the Mobie 389 IP extension, their AVP Code values, types, possible flag values and 390 whether the AVP MAY be encrypted. 392 +---------------------+ 393 | AVP Flag rules | 394 |----+-----+----+-----|----+ 395 AVP Section Value | | |SHLD| MUST|MAY | 396 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr| 397 -----------------------------------------|----+-----+----+-----|----| 398 Accounting- 480 3.1 Integer32| M | T,P | | V | Y | 399 Record-Type | | | | | | 400 ADIF-Record 481 3.2 Data | M | T,P | | V | Y | 401 Accounting- 482 3.3 Integer32| M | P | | T,V | Y | 402 Interim-Interval | | | | | | 403 Accounting- 483 3.4 Integer32| M | P | | T,V | Y | 404 Delivery-Max-Batch | | | | | | 405 Accounting- 484 3.5 Integer32| M | P | | T,V | Y | 406 Delivery-Max-Delay | | | | | | 407 Accounting- 485 3.6 Integer32| M | P | | T,V | Y | 408 Record-Number | | | | | | 410 3.1 Accounting-Record-Type AVP 412 The Accounting-Record-Type AVP (AVP Code 480) is of type Interger32 413 and contains the type of accounting record that can be found in the 414 corresponding ADIF-Record AVP. The following values are currently 415 defined for the Accounting-Record-Type AVP: 417 EVENT_RECORD 1 418 An Accounting Event Record is used to indicate a service of 419 indivisible nature has occurred. This record contains all 420 information relevant to the service, and is the only record of 421 the service. 423 START_RECORD 2 424 An Accounting Start, Interim, and Stop Records are used to 425 indicate that a service of a measurable length has been given. 426 An Accounting Start Record is used to initiate an accounting 427 session, and contains accounting information that is relevant 428 to the initiation of the session. 430 INTERIM_RECORD 3 431 An Interim Accounting Record contains cumulative accounting 432 information for an existing accounting session. Interim 433 Accounting Records SHOULD be sent every time a re- 434 authentication or re-authorization occurs. The selection of 435 whether to use INTERIM_RECORD records is directed by the 436 Accounting-Interim-Interval AVP. 438 STOP_RECORD 4 439 An Accounting Stop Record is sent to terminate an accounting 440 session and contains cumulative accounting information relevant 441 to the existing session. 443 3.2 ADIF-Record AVP 445 The ADIF-Record AVP (AVP Code 481) is of type Data and contains the 446 ADIF payload, as defined in [10]. 448 3.3 Accounting-Interim-Interval AVP 450 The Accounting-Interim-Interval AVP (AVP Code 482) is of type 451 Integer32 and is sent from the DIAMETER authenticating/authorizing 452 server to the DIAMETER client. The client uses information in this 453 AVP to decide how and when to produce accounting records. With 454 different values in this AVP, service sessions can result in one, 455 two, or two+N accounting records, based on the needs of the home- 456 organization. The following accounting record production behaviour is 457 directed by the inclusion of this AVP: 459 1. The omission of the Accounting-Interim-Interval AVP or its 460 inclusion with Value field set to 0 means that EVENT_RECORD, 461 START_RECORD, and STOP_RECORD are produced, as appropriate for 462 the service. 464 2. The inclusion of the AVP with Value field set to a non-zero 465 value means that INTERIM_RECORD records MUST be produced 466 between the START_RECORD and STOP_RECORD records. The Value 467 field of this AVP is the nominal interval between these records 468 in seconds. The DIAMETER node that originates the accounting 469 information, known as the client, MUST produce the first 470 INTERIM_RECORD record roughly at the time when this nominal 471 interval has elapsed from the START_RECORD, the next one again 472 as the interval has elapsed once more, and so on until the 473 session ends and a STOP_RECORD record is produced. 475 The client MUST ensure that the interim record production times 476 are randomized so that large accounting message storms are not 477 created either among records or around a common service start 478 time. 480 3.4 Accounting-Delivery-Max-Batch AVP 482 The Accounting-Delivery-Max-Batch AVP (AVP Code 483) is of type 483 Integer32 and is included in an Accounting-Answer. This AVP controls 484 how accounting data is transferred to the accounting server. The AVP 485 sets the requirements in terms of number of locally collected records 486 before accounting data transfer SHOULD begin. The DIAMETER node that 487 receives this AVP MAY deliver the data earlier due to satisfying 488 requirements set by Accounting-Delivery-Max-Delay, device reboot, 489 lack of memory, or explicit configuration. The DIAMETER node MUST 490 begin the transfer in the given limits unless prevented from doing so 491 by network partitions, client or server failures, network congestion, 492 or client overload. 494 3.5 Accounting-Delivery-Max-Delay AVP 496 The Accounting-Delivery-Max-Delay AVP (AVP Code 484) is of type 497 Integer32 and is included in an Accounting-Answer. This AVP controls 498 how accounting data is transferred to the authorization request. The 499 AVP sets the requirements in terms of maximum delay before accounting 500 data transfer SHOULD begin. The DIAMETER node that receives this AVP 501 MAY deliver the data earlier due to satisfying requirements set by 502 Accounting-Delivery-Max-Batch, device reboot, lack of memory, or 503 explicit configuration. The DIAMETER node MUST begin the transfer in 504 the given limits unless prevented from doing so by network 505 partitions, client or server failures, network congestion, or client 506 overload. 508 3.6 Accounting-Record-Number AVP 509 The Accounting-Record-Number AVP (AVP Code 485) is of type Integer32 510 and identifies this record within one session. As Session-Id AVPs are 511 globally unique, the combination of Session-Id and Accounting- 512 Record-Number AVPs is also globally unique, and can be used in 513 matching accounting records with confirmations. An easy way to 514 produce unique numbers is to set the value to 0 for records of type 515 EVENT_RECORD and START_RECORD, and set the value to 1 for the first 516 INTERIM_RECORD, 2 for the second, and so on until the value for 517 STOP_RECORD is one more than for the last INTERIM_RECORD. 519 4.0 IANA Considerations 521 The command codes defined in Section 2.0 are values taken from the 522 Command-Code AVP [1] address space and extended in [2], [3] and [9]. 523 IANA should record the values as defined in Section 2.0. 525 The AVPs defined in section 3.0 and 5.0 were alllocated from from the 526 AVP numbering space defined in [1], and extended in [2], [3] and [9]. 527 IANA should record the values as defined in Section 3.0. 529 This document introduces the Accounting-Record-Type AVP, which 530 contains pre-defined values. This document defines the values 1-3. 531 All remaining values are available for assignment via a Designated 532 Expert [8]. 534 5.0 Security Considerations 536 This DIAMETER extension assumes that the accounting data is secured 537 either through a hop-by-hop authentication mechanism, as described in 538 [1], or using a strong authentication mechanism as defined in [9]. 540 6.0 Acknowledgments 542 The authors would like to thank Nenad Trifunovic, Tony Johansson and 543 Pankaj Patel for their participation in the Document Reading Party. 544 Thanks to the various people that have contributed to accounting 545 related requirements at the IETF's AAA Working Group and other 546 related WGs. 548 7.0 References 550 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman. "DIAMETER Base 551 Protocol", draft-calhoun-diameter-13.txt, IETF work in progress, 552 March 2000. 554 [2] P. Calhoun, W. Bulley, A. Rubens, J. Haag. "DIAMETER NASREQ 555 Extension", draft-calhoun-diameter-nasreq-02.txt, IETF work in 556 progress, March 2000. 557 [3] P. Calhoun, C. Perkins. "DIAMETER Mobile IP Extension", draft- 558 calhoun-diameter-mobileip-06.txt, IETF work in progress, March 559 2000. 560 [4] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 561 Authentication Dial In User Service (RADIUS)." RFC 2138, April 562 1997. 563 [5] C. Rigney, "RADIUS Accounting." RFC 2139, April 1997. 564 [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement 565 Levels", BCP 14, RFC 2119, March 1997. 566 [7] G. Zorn, P. Calhoun. "Limiting Fraud in Roaming", draft-ietf- 567 roamops-fraud-limit-00.txt, IETF work in progress, May 1999. 568 [8] Narten, Alvestrand, "Guidelines for Writing an IANA 569 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 570 [9] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 571 Extension", draft-calhoun-diameter-strong-security-02.txt, IETF 572 work in progress, March 2000. 573 [10] B. Aboba, D. Lidyard, "The Accounting Data Interchange Format 574 (ADIF)", draft-ietf-roamops-actng-06.txt, IETF work in progress, 575 August 1999. 576 [11] B. Aboba, J. Arkko, D. Harrington. "Introduction to Accounting 577 Management", draft-ietf-aaa-acct-00.txt, IETF work in progress, 578 January 2000. 579 [12] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload 580 Compression Protocol (IPComp)", RFC 2393, December 1998. 581 [13] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 582 2409, November 1998. 584 8.0 Authors' Addresses 586 Questions about this memo can be directed to: 588 Jari Arkko 589 Oy LM Ericsson Ab 590 02420 Jorvas 591 Finland 593 Phone: +358 40 5079256 594 E-Mail: Jari.Arkko@ericsson.com 596 Pat R. Calhoun 597 Network and Security Research Center, Sun Labs 598 Sun Microsystems, Inc. 599 15 Network Circle 600 Menlo Park, California, 94025 601 USA 603 Phone: 1-650-786-7733 604 Fax: 1-650-786-6445 605 E-mail: pcalhoun@eng.sun.com 607 Pankaj Patel 608 Convergys Corporation 609 4600 Montgomery Road 610 Cincinnati, OH 45212 611 USA 613 Phone: 1-513-723-2018 614 E-Mail: pankaj.patel@convergys.com 616 Glen Zorn 617 Cisco Systems, Inc. 618 500 108th Avenue N.E., Suite 500 619 Bellevue, WA 98004 620 USA 622 Phone: +1 425 468 0955 623 E-Mail: gwz@acm.org 625 9.0 Full Copyright Statement 627 Copyright (C) The Internet Society (1999). All Rights Reserved. 629 This document and translations of it may be copied and furnished to 630 others, and derivative works that comment on or otherwise explain it 631 or assist in its implementation may be prepared, copied, published 632 and distributed, in whole or in part, without restriction of any 633 kind, provided that the above copyright notice and this paragraph are 634 included on all such copies and derivative works. However, this 635 document itself may not be modified in any way, such as by removing 636 the copyright notice or references to the Internet Society or other 637 Internet organizations, except as needed for the purpose of 638 developing Internet standards in which case the procedures for 639 copyrights defined in the Internet Standards process must be 640 followed, or as required to translate it into languages other than 641 English. The limited permissions granted above are perpetual and will 642 not be revoked by the Internet Society or its successors or assigns. 643 This document and the information contained herein is provided on an 644 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 645 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 646 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 647 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 648 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.