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