idnits 2.17.1 draft-calhoun-diameter-accounting-01.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 20 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 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [3], [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 927 has weird spacing: '... copied and ...' == Line 928 has weird spacing: '...s, and deriv...' == Line 930 has weird spacing: '...blished and d...' == Line 931 has weird spacing: '...hat the above...' == Line 932 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 861, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 864, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-08 -- Possible downref: Normative reference to a draft: ref. '1' -- No information found for draft-calhoun-diameter-auth - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-02 -- 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) == Outdated reference: A later version (-04) exists of draft-calhoun-diameter-proxy-02 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-08) exists of draft-ietf-roamops-actng-05 -- 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' Summary: 11 errors (**), 0 flaws (~~), 17 warnings (==), 10 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-01.txt Pat R. Calhoun 4 Date: October 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 Abstract 41 The DIAMETER protocol provides Authentication and Authorization for 42 dial-up PPP clients [2] and for Mobile-IP [3]. The ROAMOPS WG has 43 been working on an accounting data format, called Accounting Data 44 Interchange Format (ADIF) [10], as a method to transfer accounting 45 information over a wide variety of transports. This document describes 46 how ADIF can be securely transmitted over the DIAMETER protocol. 48 Table of Contents 50 1.0 Introduction 51 1.1 Copyright Statement 52 1.2 Requirements language 53 1.3 Changes in version 01 54 2.0 Command Codes 55 2.1 Accounting-Request 56 2.2 Accounting-Answer 57 2.3 Accounting-Poll-Ind 58 3.0 DIAMETER AVPs 59 3.1 Accounting-Record-Type 60 3.2 ADIF-Record 61 3.3 Accounting-Confirmation 62 3.4 Session-Token 63 3.5 Accounting-Interim-Interval 64 3.6 Accounting-Delivery-Max-Batch 65 3.7 Accounting-Delivery-Max-Delay 66 3.8 Accounting-Record-Number 67 4.0 Protocol overview 68 4.1 Authorization-Server Directed Model 69 4.2 Protocol Messages 70 4.3 Fault Resilience 71 4.4 Session Records 72 4.5 Accounting in brokering environments 73 5.0 IANA Considerations 74 6.0 Acknowledgments 75 7.0 References 76 8.0 Authors' Addresses 77 9.0 Full Copyright Statement 79 1.0 Introduction 81 The DIAMETER protocol provides Authentication and Authorization for 82 dial-up PPP clients [2] and for Mobile-IP [3]. The ROAMOPS WG has 83 been working on an accounting data format, called Accounting Data 84 Interchange Format (ADIF) [10], as a method to transfer accounting 85 information over a wide variety of transports. This document 86 describes how ADIF can be securely transmitted over the DIAMETER 87 protocol. 89 This document describes how Accounting Records can be transmitted 90 within the DIAMETER protocol in a secure fashion, even when the 91 messages must traverse DIAMETER proxies [1, 9]. This extension allows 92 for both real-time and batched accounting transfers. 94 This document introduces AVPs that are very similar to some found in 95 the base [1] and the end-to-end security extension [9]. However, 96 since this extension requires that the AVPs in question must have 97 bits set which are not currently permitted in both the stated drafts, 98 a new version of the AVP has been defined here. However, a future 99 version of this document may make use of the original AVPs once the 100 [1] and [9] have been corrected. If there is interest in this 101 extension, the impact of changing [1] and [9] must be carefully 102 evaluated. 104 The Extension number for this draft is five (5). This value is used 105 in the Extension-Id Attribute value Pair (AVP) as defined in [7]. 107 1.1 Copyright Statement 109 Copyright (C) The Internet Society 1999. All Rights Reserved. 111 1.2 Requirements language 113 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 114 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 115 described in [6]. 117 1.3 Changes in version 01 119 This document contains several minor editor changes found during the 120 DIAMETER Document Reading Party in addition to the following: 122 - Removed the Accounting-Session-Id in favor for the Session-Id as 123 described in the base protocol. 125 - Removed the Accounting-Digital-Signature in favor for the 126 Digital-Signature described in the secure proxy extension. 128 - Renamed the Accounting-Certificate to Session-Token. 130 - Removed the Accounting-Session-Id from the Session-Token 132 - Removed the Session-Record accounting type. 134 - Added the Accounting-Poll-Ind Command Code. 136 - Added the Accounting-Delivery-Max-Batch and Accounting- 137 Delivery-Max-Delay AVPs. 139 - Added the Accounting-Record-Number, which is a way to identify 140 an accounting record. 142 2.0 Command Codes 144 This section will define the Commands [1] for DIAMETER 145 implementations supporting the Mobile IP extension. 147 Command Name Command Code 148 ----------------------------------- 149 Accounting-Request ??? 150 Accounting-Answer ??? 151 Accounting-Poll-Ind ??? 153 2.1 Accounting-Request 155 Description 157 The Accounting-Request command is sent by a DIAMETER node in order 158 to exchange accounting information with a peer. The Accounting 159 information is contained within an ADIF record, as described in 160 [10]. 162 The Accounting-request command MAY contain accounting information 163 for more than a single session, which allows it to send batched 164 accounting information. When the batch mode is used, the session- 165 Id AVP [1] MUST be present and the Digital-Signature AVP [6] MAY 166 be present, and MUST have a tag of the same value as the ADIF- 167 Record AVP. 169 The Accounting-Request message MAY contain the Accounting- 170 Confirmation AVP, with the corresponding Digital-Signature AVP 171 signed by the user's home AAA server, when the request is being 172 issued to a broker that allows direct communication (see section 173 4.5). 175 Message Format 177 ::= 178 179 180 [] 181 ( && 182 && 183 && 184 && 185 [ && 186 ] && 187 && 188 ) 189 190 191 { || 192 } 194 The length of the DIAMETER Command AVP must be 12 when the Command 195 Code is set to ??? (Accounting-Request). 197 2.2 Accounting-Answer 199 Description 201 The Accounting-Answer command is used to acknowledge an 202 Accounting-Request command. The Accounting-Answer command contains 203 the same Session-Id AVP that was sent in the Accounting-Request 204 command, and the MD5 hash in Accounting-Confirmation AVP forms a 205 confirmation that the right accounting record was accepted. This 206 can be signed using the Digital-Signature AVP for end-to-end 207 message integrity and possible non-repudiation. 209 Only the target DIAMETER Server, known as the home DIAMETER 210 Server, SHOULD respond with the Accounting-Answer command. 212 If the Accounting-Request command contained more than one ADIF- 213 Record AVP, the Accounting-Answer SHOULD contain the same number 214 of ADIF-Record AVPs. However, it is possible for the DIAMETER 215 Server to acknowledge each ADIF-Record in a separate response. 216 This allows the sender of the ADIF-Records to send a batch of 217 records, whose final destination are different. 219 Message Format 221 ::= 222 223 224 225 [] 226 ( && 227 && 228 && 229 && 230 ) 231 232 233 { || 234 } 236 The length of the DIAMETER Command AVP must be 12 when the Command 237 Code is set to ??? (Accounting-Answer). 239 2.3 Accounting-Poll-Ind 241 Description 243 The Accounting-Poll-Ind command is sent by a DIAMETER Server in 244 order to force the Client to send current accounting data. This 245 data MUST include not yet sent accounting records from completed 246 sessions, as well as INTERIM_RECORD records from all ongoing 247 sessions. 249 The Client MUST use Accounting-Request command to send the 250 accounting data. 252 The use of Accounting-Poll-Ind is useful in situations where a 253 DIAMETER Server comes up after an unscheduled downtime, and wishes 254 to synchronize with the Client(s) sooner than at the end of the 255 next INTERIM_RECORD or at the end of a session. Accounting-Order 256 SHOULD NOT be used in a roaming situation due to the excessive 257 polling through the roaming network. 259 Warning: The use of the Accounting-Poll-Ind message is discouraged 260 in roaming networks, since it is unfeasible for a server to 261 attempt to poll all of it's roaming partner's DIAMETER Clients. 263 Message Format 265 ::= 266 267 268 [] 269 270 271 { || 272 } 274 The length of the DIAMETER Command AVP must be 12 when the Command 275 Code is set to ??? (Accounting-Poll-Ind). 277 3.0 DIAMETER AVPs 279 This section will define the mandatory AVPs which MUST be supported 280 by all DIAMETER implementations supporting this extension. The 281 following AVPs are defined in this document: 283 Attribute Name Attribute Code Definition in Section 284 ------------------------------------------------------------------- 285 Accounting-Record-Type ??? 3.1 286 ADIF-Record ??? 3.2 287 Accounting-Confirmation ??? 3.3 288 Session-Token ??? 3.4 289 Accounting-Interim-Interval ??? 3.5 290 Accounting-Delivery-Max-Batch ??? 3.6 291 Accounting-Delivery-Max-Delay ??? 3.7 292 Accounting-Record-Number ??? 3.8 294 3.1 Accounting-Record-Type 296 Description 298 The Accounting-Record-Type AVP contains the type of record that 299 can be found in the ADIF-Record AVP. 301 AVP Format 303 0 1 2 3 304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 AVP Header (AVP Code = ???) 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Integer32 | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 AVP Flags 312 The 'M' bit MUST be set. The 'T' bit MAY be set if more than 313 one Accounting record is being sent in an Accounting-Request 314 message. The 'P' bit MAY be set if end to end message 315 integrity is required, but may not be necessary if the 316 Digital-Signature is used. The 'H', 'E', 'V' bits MUST NOT be 317 set. 319 Integer32 320 The Integer32 field contains the record type that can be found 321 in the ADIF-Record AVP. The following values are currently 322 defined: 324 EVENT_RECORD 1 325 An Accounting Event Record is used to indicate a service 326 of indivisible nature has occurred. This record contains 327 all information relevant to the service, and is the only 328 record of the service. 330 START_RECORD 2 331 An Accounting Start, Interim, and Stop Records are used 332 to indicate that a service of a measurable length has 333 been given. An Accounting Start Record is used to 334 initiate an accounting session, and contains accounting 335 information that is relevant to the initiation of the 336 session. 338 INTERIM_RECORD 3 339 An Interim Accounting Record contains cumulative 340 accounting information for an existing Accounting 341 session. Interim Accounting Records SHOULD be sent 342 everytime a re-authentication or re-authorization occurs. 344 STOP_RECORD 4 345 An Accounting Stop Record is sent to terminate an 346 accounting session and contains cumulative accounting 347 information relevant to the existing session. 349 The selection of whether to use INTERIM_RECORD records is 350 directed by the Accounting-Interim-Interval AVP. 352 3.2 ADIF-Record 354 Description 356 This attribute contains an ADIF record, as defined in [10]. 358 AVP Format 360 0 1 2 3 361 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 AVP Header (AVP Code = ???) 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Data ... 366 +-+-+-+-+-+-+-+-+ 367 AVP Flags 368 The 'M' bit MUST be set. The 'T' bit MAY be set if more than 369 one Accounting record is being sent in an Accounting-Request 370 message. The 'P' bit MAY be set if end to end message 371 integrity is required, but may not be necessary if the 372 Digital-Signature is used. The 'H', 'E', 'V' bits MUST NOT be 373 set. 375 Data 376 The Data field contains an ADIF payload as defined in [10]. 378 3.3 Accounting-Confirmation 380 Description 382 This AVP contains an MD5 hash of a previous ADIF-Record, and is 383 used to confirm receipt of the ADIF-Record. When signed via the 384 Digital-Signature, this AVP provides the sender of the 385 Accounting-Request with proof that the receiver accepted the 386 Accounting record. 388 AVP Format 390 0 1 2 3 391 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 AVP Header (AVP Code = ???) 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Data ... 396 +-+-+-+-+-+-+-+-+ 398 AVP Flags 399 The 'M' bit MUST be set. The 'T' bit MAY be set if more than 400 one Accounting record is being sent in an Accounting-Request 401 message. The 'P' bit MAY be set if end to end message 402 integrity is required, but may not be necessary if the 403 Digital-Signature is used. The 'H', 'E', 'V' bits MUST NOT be 404 set. 406 Data 407 The Data field contains an MD5 hash of the ADIF-Record AVP 408 being confirmed. 410 3.4 Session-Token 412 Description 413 The Session-Token AVP is created by the home DIAMETER server as a 414 result of a successful Authentication and/or Authorization. This 415 "token" is used in the subsequent Accounting-Request messages as a 416 proof that the user was in fact authorized for the service. The 417 document [7] and section 4.1 provides further information on this 418 AVP. 420 AVP Format 422 0 1 2 3 423 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 AVP Header (AVP Code = ???) 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Length of Session-Id | Length of User-Name | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Length of Digital-Signature | Digital-Signature Transform | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Session-Lifetime | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Timestamp | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Session-Id... | User-Name... | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Digital-Signature... 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 AVP Flags 441 The 'M' bit MUST be set. The 'T' bit MAY be set if more than 442 one Accounting record is being sent in an Accounting-Request 443 message. The 'P' bit MAY be set if end to end message 444 integrity is required, but may not be necessary if the 445 Accounting-Digital-Signature is used. The 'H', 'E', 'V' bits 446 MUST NOT be set. 448 Length of Session-Id 449 This 16 bit field contains the length of the Session-Id field 450 found in this AVP. 452 Length of User-Name 453 This 16 bit field contains the length of the User-Name field 454 found in this AVP. 456 Length of Digital-Signature 457 This 16 bit field contains the length of the Digital-Signature 458 field found in this AVP. 460 Digital-Signature Transform 461 This 16 bit field contains the transform used to generate the 462 Digital-Signature field, as defined in the Digital-Signature 463 AVP in [9]. 465 Session-Lifetime 466 This 32 bit field contains the number of seconds that the 467 session has been autorized for. This field MUST be the same as 468 the value of the Session-Timeout AVP [1]. 470 TimeStamp 471 This 32 bit field contains a timestamp representing when this 472 AVP was created. The format of this field is identical to the 473 Timestamp AVP defined in [1]. 475 Session-Id 476 This variable length field contains the Session-Id, and MUST be 477 identical to the value found in the Session-Id AVP [1]. 479 User-Name 480 This variable length field contains the User-Name and MUST be 481 identical to the value of the User-Name AVP [1]. 483 Digital-Signature 484 This variable length field contains a signature of the AVP's 485 data, not including the AVP header and is generated using the 486 transform specified in the Digital-Signature-Transform field. 488 3.5 Accounting-Interim-Interval 490 Description 492 The Accounting-Interim-Interval AVP is sent from the DIAMETER 493 authenticating/authorizing server to the DIAMETER Client. The 494 Client uses information in the AVP to decide how and when to 495 produce accounting records. With different values in this AVP, 496 service sessions can result in one, two, or two+N accounting 497 records, based on the needs of the home-organization. 499 AVP Format 501 0 1 2 3 502 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 AVP Header (AVP Code = ???) 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Integer32 | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 AVP Flags 509 As defined in the DIAMETER Base Protocol. 511 Integer32 512 The following accounting record production behaviour is 513 directed by the inclusion of this AVP: 515 1. The omission of the Accounting-Interim-Interval AVP or 516 its inclusion with Value field set to 0 means that 517 EVENT_RECORD, START_RECORD, and STOP_RECORD are produced, as 518 appropriate for the service. 520 2. The inclusion of the AVP with Value field set to a non- 521 zero value means that INTERIM_RECORD records MUST be 522 produced between the START_RECORD and STOP_RECORD records. 523 The Value field of this AVP is the nominal interval between 524 these records in seconds. The Client MUST produce the first 525 INTERIM_RECORD record roughly at the time when this nominal 526 interval has elapsed from the START_RECORD, the next one 527 again as the interval has elapsed once more, and so on until 528 the session ends and a STOP_RECORD record is produced. 530 The Client MUST ensure that the interim record production 531 times are randomized so that large accounting message storms 532 are not created either among records or around a common 533 service start time. 535 3.6 Accounting-Delivery-Max-Batch 537 Description 539 This attribute is sent to a device as a response to an 540 authorization request. It controls how accounting data is 541 transferred to the accounting server. The attribute sets the 542 requirements in terms of number of locally collected records 543 before accounting data transfer SHOULD begin. The DIAMETER Client 544 MAY deliver the data earlier due to satisfying requirements set by 545 Accounting- Delivery-Max-Delay, device reboot, lack of memory, or 546 explicit configuration. The DIAMETER Client MUST begin the 547 transfer in the given limits unless prevented from doing so by 548 network partitions, client or server failures, network congestion, 549 or client overload. 551 AVP Format 552 0 1 2 3 553 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 AVP Header (AVP Code = ???) 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Integer32 | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 AVP Flags 561 As defined in the DIAMETER Base Protocol. 563 Integer32 564 The Integer32 field contains the number of accounting records 565 that may be stored locally at the DIAMETER Client before data 566 transfer SHOULD begin. Refer to section 4.1 for information on 567 how a record is placed on a particular batch, and how different 568 maximum batch and delay attributes may be given to different 569 sessions. 571 3.7 Accounting-Delivery-Max-Delay 573 Description 575 This attribute is sent to a device as a response to an 576 authorization request. It controls how accounting data is 577 transferred to the accounting server. The attribute sets the 578 requirements in terms of maximum delay before accounting data 579 transfer SHOULD begin. The DIAMETER Client MAY deliver the data 580 earlier due to satisfying requirements set by Accounting- 581 Delivery-Max-Batch, device reboot, lack of memory, or explicit 582 configuration. The DIAMETER Client MUST begin the transfer in the 583 given limits unless prevented from doing so by network partitions, 584 client or server failures, network congestion, or client overload. 586 AVP Format 588 0 1 2 3 589 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 AVP Header (AVP Code = ???) 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Integer32 | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 AVP Flags 597 As defined in the DIAMETER Base Protocol. 599 Integer32 600 The Integer32 field contains the number of seconds that may 601 elapse before accounting data transfer SHOULD begin from the 602 DIAMETER Client. Refer to section 4.1 for information on how a 603 record is placed on a particular batch, and how different 604 maximum batch and delay attributes may be given to different 605 sessions. 607 3.8 Accounting-Record-Number 609 Description 611 The Accounting-Record-Number AVP identifies this record within one 612 session. As Session-Id AVPs are globally unique, the combination 613 of Session-Id and Accounting-Record- Number AVPs is also globally 614 unique, and can be used in matching accounting records with 615 confirmations. 617 AVP Format 619 0 1 2 3 620 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 AVP Header (AVP Code = ???) 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Integer32 | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 AVP Flags 628 As defined in the DIAMETER Base Protocol. 630 Integer32 631 This number uniquely identifies the record within a session. An 632 easy way to produce unique numbers is to set the value to 0 for 633 records of type EVENT_RECORD and START_RECORD, and set the 634 value to 1 for the first INTERIM_RECORD, 2 for the second, and 635 so on until the value for STOP_RECORD is one more than for the 636 last INTERIM_RECORD. 638 4.0 Protocol overview 640 This accounting protocol is based on an authorization-server directed 641 model with capabilities for both efficient batch and fast real-time 642 delivery of accounting information. Several fault resilience methods 643 [11] have been built in to the protocol in order minimize loss of 644 accounting data in various fault situations and under different 645 assumptions about the capabilities of the used devices. 647 4.1 Authorization-Server Directed Model 649 The authorization-server directed model means that at authorization 650 time, the device generating the accounting data gets information from 651 the authorization server regarding the way accounting data shall be 652 forwarded. This information includes a certificate to prove that the 653 session truly was authorized, as well as accounting record timeliness 654 requirements. 656 When the user's home DIAMETER Server successfully authenticates 657 and/or authorizes a session, it generates the Session-Token AVP that 658 is returned in the response. The document [7] describes a possible 659 format for the AVP, which is also described in section 3.6. 661 As discussed in [11], batch transfer of accounting data is more CPU- 662 and bandwidth efficient than real-time transfer. However, there are 663 many applications where real-time transfer is a requirement for at 664 least some of the accounting records. These applications include 665 roaming, where most (local) accounting records can be transferred in 666 batch mode, but roaming (visiting) accounting records should be 667 transferred fast due to the needs of credit limit checks and fraud 668 detection. For these reasons this accounting protocol defines both 669 batch and real-time transfer modes, and allows their use 670 simultaneously. The authorization server (chain) directs the 671 selection of proper transfer strategy, based on its knowledge of the 672 user and relationships of roaming partnerships. The server (or 673 proxies in between) use the Accounting-Delivery-Max-Batch, 674 Accounting-Delivery-Max-Delay, and Accounting-Interim-Interval AVPs 675 to control the operation of the DIAMETER Client. The first two 676 attributes set the requirements in terms of number of records and 677 maximum delay before accounting data transfer for this session SHOULD 678 begin. The DIAMETER Client MAY deliver the data earlier due to a 679 full batch of records, device reboot, lack of memory, or explicit 680 configuration. The DIAMETER Client MUST begin the transfer in the 681 given limits unless prevented from doing so by network partitions, 682 client or server failures, network congestion, or client overload. 684 The Accounting-Interim-Interval AVP, when present, instructs the 685 DIAMETER Client to produce accounting records continuously even 686 during a session. 688 Typically, the authorization server uses a few batching/real-time 689 classes, such as the local users whose data might be transferred once 690 in an hour and the roaming users whose data would be transferred 691 immediately. Each Accounting-Delivery-Max-Batch / Accounting- 692 Delivery-Max-Delay AVP pair with different values forms one pool of 693 accounting data in the DIAMETER Client. That is, a new record is 694 placed to same pool as the previous one if the authorization server 695 returned same values for both AVPs and the pool has not been emptied 696 in between. 698 4.2 Protocol Messages 700 The DIAMETER Client generating the accounting data will use the 701 Accounting-Request message to send one or more accounting records to 702 the DIAMETER Server. The Server MUST reply with the Accounting-Answer 703 message with appropriate confirmations. 705 It is possible that a DIAMETER Proxy breaks up a batch of accounting 706 records and sends them towards different DIAMETER Home Servers. In 707 this case it is possible that a separate Accounting-Answer message 708 contain the response for each block. Therefore, a Client MUST be 709 prepared to handle this scenario. 711 Upon receipt of an Accounting-Request, a home DIAMETER Server MUST 712 generate a response. The response includes the Result-Code, which MAY 713 contain an error if the ADIF-Record, or some other AVP, is not 714 acceptable. Furthermore, an Accounting-Confirmation MUST be returned. 715 The Accounting-Confirmation is an MD5 hash of the ADIF-Record data 716 which is being confirmed. 718 Each DIAMETER Accounting protocol message MAY be compressed using 719 IPComp in order to reduce the used network bandwidth. DIAMETER peers 720 MUST use a negotiation mechanisms such as ISAKMP/IKE in order to 721 ensure that both peers are able to handle IPComp. Note that it 722 usually makes sense to compress only Accounting-Request messages with 723 possibly lengthy ADIF data, not Accounting-Answer messages. 725 4.3 Fault Resilience 727 DIAMETER Base protocol mechanisms are used to overcome small message 728 loss and network faults of temporary nature. 730 DIAMETER Clients MUST implement the use of alternate servers to guard 731 against server failures and certain network failures. DIAMETER 732 Servers or related off-line processing systems MUST detect duplicate 733 accounting records caused by the sending of same record to several 734 servers and duplication of messages in transit. This detection MUST 735 be based on the inspection of Accounting-Record-Id and Host-IP- 736 Address AVP pairs. 738 DIAMETER Clients MAY have non-volatile memory for the safe storage of 739 accounting records over reboots or extended network failures, network 740 partitions, and server failures. If such memory is available the 741 Client SHOULD store new accounting records there as soon as the 742 records are created and until a positive acknowledgement of their 743 reception from the DIAMETER Server has been received. Upon a reboot, 744 the Client MUST starting sending the records in the non-volatile 745 memory to the accounting server with appropriate modifications in 746 termination cause, session length, and other relevant information in 747 the records. 749 A further extension of this protocol may include AVPs to control how 750 many accounting records may at most be stored in the DIAMETER Client 751 without committing them to the non-volatile memory or transferring 752 them to the DIAMETER Server. 754 The Client SHOULD NOT remove the accounting data from any of its 755 memory areas before the correct Accounting-Answer has been received. 756 The Client MAY remove oldest, undelivered or yet unacknowledged 757 accounting data if it runs out of resources such as memory. It is an 758 implementation dependent matter for the client to accept new sessions 759 under this condition. 761 4.4 Session Records 763 In all accounting records the Session-Id AVP, ADIF-Record AVP, and 764 User-Name AVPs MUST be present. If only one accounting record is 765 present in the message, the whole message may be protected using the 766 Digital-Signature, as defined in [9]. 768 However, if the accounting records are being in sent in batch mode, 769 the sender can create several "blocks" of accounting records by 770 making use of the AVP Tag field (bit 'T' [1]). Each block is 771 individually signed, unless all blocks are destined for the same home 772 DIAMETER Server. 774 Different types of session records are sent depending on the actual 775 type of accounted service and the authorization server's directions 776 for interim accounting. If the accounted service is of an indivisible 777 nature, then the Accounting-Record-Type AVP MUST be present and set 778 to the value EVENT_RECORD. This can be used to account for services 779 such as "send an e-mail to this wireless terminal". 781 If the accounted service is of a measurable length, then the AVP MUST 782 use the values START_RECORD, STOP_RECORD, and possibly, 783 INTERIM_RECORD. If the authorization server has directed interim 784 accounting to be on but with no specified interim interval, two 785 accounting records MUST be generated for each service of type 786 session. When the initial Accounting-Request is sent for a given 787 session is sent, the Accounting-Record-Type AVP MUST be set to the 788 value START_RECORD. When the last Accounting-Request is sent, the 789 value MUST be STOP_RECORD. 791 If a specified interim interval exists, the DIAMETER Client MUST 792 produce additional records between the START_RECORD and STOP_RECORD, 793 marked INTERIM_RECORD. The production of these records is directed 794 both by Accounting-Interim-Interval as well as any re-authentication 795 or -authorization of the session. If a batch size of greater than 1 796 has been specified by the authorization server, then the DIAMETER 797 Client MUST ensure that new interim records overwrite previous 798 interim records for the same session and batch as this reduces the 799 amount of memory required to store the records. In effect, this means 800 that interim records are delivered at least as often as dictated by 801 Accounting-Delivery-Max-Delay. 803 4.5 Accounting in brokering environments 805 The DIAMETER base protocol describes brokers that provide redirect 806 services, by allowing AAA servers within a roaming consortium to 807 directly communicate in a secure fashion. However, since brokers can 808 also provide settlement services, it needs to be aware of the 809 accounting information exchange. Historically, the thought was to 810 have the broker "proxy" the accounting records from the local to the 811 home network. 813 A new model has been defined that allows the local AAA server to 814 issue the Accounting-Request message to the home AAA server, which 815 includes the ADIF-Record AVP with the corresponding Digital-Signature 816 AVP. The home server generates the Accounting-Confirmation AVP and 817 the Digital-Signature AVP, which is returned in the Accounting-Answer 818 message. The local AAA server then forwards both the ADIF-Record and 819 the Accounting-Confirmation AVPs with both Digital-Signature AVPs to 820 the broker in an Accounting-Request message. The broker replies by 821 issuing an Accounting-Answer message that includes its own 822 Accounting-Confirmation and Digital-Signature AVPs. 824 This new model eliminates the need for application end-to-end 825 security, by allowing the peers to communicate directly, and reduces 826 the latency that would otherwise be added through the proxy process. 828 5.0 IANA Considerations 830 The numbers for the Command Code AVPs (section 2) is taken from the 831 numbering space defined for Command Codes in [1]. The numbers for the 832 various AVPs defined in section 3 were taken from the AVP numbering 833 space defined in [1]. The numbering for the AVP and Command Codes 834 MUST NOT conflict with values specified in [1] and other DIAMETER 835 related Internet Drafts. 837 This document introduces the Accounting-Record-Type AVP, which may 838 contain pre-defined values. This document defines the values 1-3. 839 All remaining values are available for assignment via IETF Consensus 840 [8]. 842 6.0 Acknowledgments 844 The authors would like to thank Nenad Trifunovic, Tony Johansson and 845 Pankaj Patel for their participation in the Document Reading Party. 846 Thanks to the various people that have contributed to accounting 847 related requirements at the IETF's AAA Working Group and other 848 related WGs. 850 7.0 References 852 [1] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol", 853 draft-calhoun-diameter-08.txt, Work in Progress, 854 August 1999. 855 [2] P. R. Calhoun, "DIAMETER Authentication Extension", 856 draft-calhoun-diameter-auth-06.txt, Work in Progress, 857 August 1999. 858 [3] P. R. Calhoun, C. Perkins, "DIAMETER Mobile IP Extension", 859 draft-calhoun-diameter-mobileip-02.txt, Work in Progress, 860 August 1999. 861 [4] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 862 Authentication Dial In User Service (RADIUS)." RFC 2138, 863 April 1997. 864 [5] C. Rigney, "RADIUS Accounting." RFC 2139, April 1997. 865 [6] S. Bradner, "Key words for use in RFCs to Indicate 866 Requirement Levels", BCP 14, RFC 2119, March 1997. 867 [7] G. Zorn, P. R. Calhoun, "Limiting Fraud in Roaming", 868 draft-ietf-roamops-fraud-limit-00.txt, May 1999. 869 [8] Narten, Alvestrand,"Guidelines for Writing an IANA 870 Considerations Section in RFCs", BCP 26, RFC 2434, 871 October 1998 872 [9] P. Calhoun, W. Bulley, "DIAMETER Proxy Server Extensions", 873 draft-calhoun-diameter-proxy-02.txt, Work in Progress, 874 August 1999. 875 [10] B. Aboba, D. Lidyard, "The Accounting Data Interchange 876 Format (ADIF)", draft-ietf-roamops-actng-05.txt, 877 Work in Progress, November 1998. 878 [11] B. Aboba, J. Arkko. Introduction to Accounting Management. 879 draft-aboba-acct-01.txt. Work in progress, June 1999. 881 8.0 Authors' Addresses 883 Questions about this memo can be directed to: 885 Jari Arkko 886 Oy LM Ericsson Ab 887 02420 Jorvas 888 Finland 890 Phone: +358 40 5079256 891 E-Mail: Jari.Arkko@ericsson.com 893 Pat R. Calhoun 894 Network and Security Research Center, Sun Labs 895 Sun Microsystems, Inc. 896 15 Network Circle 897 Menlo Park, California, 94025 898 USA 900 Phone: 1-650-786-7733 901 Fax: 1-650-786-6445 902 E-mail: pcalhoun@eng.sun.com 904 Pankaj Patel 905 Convergys Corporation 906 4600 Montgomery Road 907 Cincinnati, OH 45212 908 USA 910 Phone: 1-513-723-2018 911 E-Mail: pankaj.patel@convergys.com 913 Glen Zorn 914 Microsoft Corporation 915 One Microsoft Way 916 Redmond, WA 98052 917 USA 919 Phone: 1-425-703-1559 921 E-Mail: gwz@acm.org 923 9.0 Full Copyright Statement 925 Copyright (C) The Internet Society (1999). All Rights Reserved. 927 This document and translations of it may be copied and furnished 928 to others, and derivative works that comment on or otherwise 929 explain it or assist in its implmentation may be prepared, copied, 930 published and distributed, in whole or in part, without 931 restriction of any kind, provided that the above copyright notice 932 and this paragraph are included on all such copies and derivative 933 works. However, this docu- ment itself may not be modified in any 934 way, such as by removing the copyright notice or references to the 935 Internet Society or other Inter- net organizations, except as needed 936 for the purpose of developing Internet standards in which case 937 the procedures for copyrights defined in the Internet Standards 938 process must be followed, or as required to translate it into 939 languages other than English. The limited permis- sions granted 940 above are perpetual and will not be revoked by the Internet 941 Society or its successors or assigns. This document and the 942 information contained herein is provided on an "AS IS" basis and 943 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 944 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 945 LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN 946 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 947 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."