idnits 2.17.1 draft-arkko-acctreqlis-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- 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 1) being 67 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 an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 171 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 319 instances of too long lines in the document, the longest one being 19 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 15 has weird spacing: '...), its areas...' == Line 16 has weird spacing: '... its worki...' == Line 20 has weird spacing: '... and may ...' == Line 21 has weird spacing: '...afts as refer...' == Line 30 has weird spacing: '... To learn...' == (166 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.) -- The document date (6 August 1998) is 9393 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 498, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 502, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 506, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 513, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 516, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 519, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 523, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 527, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 532, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 538, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 546, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 551, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 555, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 563, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 567, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 570, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 574, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 578, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 581, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 585, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 592, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 597, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 601, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 605, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 608, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 611, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 614, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2194 (ref. '1') == Outdated reference: A later version (-10) exists of draft-ietf-roamops-roamreq-07 ** Downref: Normative reference to an Informational draft: draft-ietf-roamops-roamreq (ref. '2') ** Obsolete normative reference: RFC 2138 (ref. '3') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '4') (Obsoleted by RFC 2866) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) -- No information found for draft-ietf-asid-ldif - is the name correct? -- Possible downref: Normative reference to a draft: ref. '8' -- Unexpected draft version: The latest known version of draft-ietf-atommib-atmacct is -03, but you're referring to -04. (However, the state information for draft-ietf-asid-ldif is not up-to-date. The last update was unsuccessful) == Outdated reference: A later version (-06) exists of draft-ietf-atommib-acct-04 == Outdated reference: A later version (-08) exists of draft-ietf-roamops-actng-04 -- Possible downref: Normative reference to a draft: ref. '11' ** Obsolete normative reference: RFC 2271 (ref. '12') (Obsoleted by RFC 2571) ** Obsolete normative reference: RFC 2272 (ref. '13') (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2273 (ref. '14') (Obsoleted by RFC 2573) ** Obsolete normative reference: RFC 2274 (ref. '15') (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 2275 (ref. '16') (Obsoleted by RFC 2575) -- No information found for draft-ietf- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '17' ** Obsolete normative reference: RFC 1892 (ref. '19') (Obsoleted by RFC 3462) == Outdated reference: A later version (-17) exists of draft-ietf-ediint-as1-05 == Outdated reference: A later version (-09) exists of draft-ietf-ediint-req-04 ** Downref: Normative reference to an Informational draft: draft-ietf-ediint-req (ref. '23') -- Duplicate reference: RFC2119, mentioned in '24', was also mentioned in '6'. ** Obsolete normative reference: RFC 1521 (ref. '25') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) == Outdated reference: A later version (-04) exists of draft-ietf-fax-smtp-session-02 -- Possible downref: Normative reference to a draft: ref. '26' -- Possible downref: Non-RFC (?) normative reference: ref. '27' -- Possible downref: Non-RFC (?) normative reference: ref. '28' -- Possible downref: Non-RFC (?) normative reference: ref. '29' -- Possible downref: Non-RFC (?) normative reference: ref. '30' == Outdated reference: A later version (-01) exists of draft-ietf-radius-acct-interim-00 -- Possible downref: Normative reference to a draft: ref. '31' -- Possible downref: Normative reference to a draft: ref. '32' == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-01 -- Possible downref: Normative reference to a draft: ref. '33' == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-00 -- Possible downref: Normative reference to a draft: ref. '34' == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-authent-01 -- Possible downref: Normative reference to a draft: ref. '35' Summary: 23 errors (**), 0 flaws (~~), 46 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jari Arkko 2 INTERNET-DRAFT Ericsson 3 Category: Standards Track 4 5 6 August 1998 7 Requirements for Internet-Scale Accounting Management 9 1. Status of this Memo 11 The document is an Internet-Draft and is in full conformance with all 12 of the provisions of Section 10 of RFC 2026. 14 This document is an Internet-Draft. Internet-Drafts are working docu- 15 ments of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute work- 17 ing documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference mate- 22 rial or to cite them other than as ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 To learn the current status of any Internet-Draft, please check the 31 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 32 Directories on ftp.ietf.org (US East Coast), nic.nordu.net 33 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 35 The distribution of this memo is unlimited. It is filed as , and expires February 1, 1999. Please send 37 comments to the authors. 39 2. Abstract 41 Over the years, as Internet services have evolved, sophisticated 42 inter-domain applications such as roaming, voice over IP, Internet 43 fax, and QoS provisioning have arisen. This document discusses 44 whether accounting for these services services can be reliably and 45 securely accomplished using established techniques, and explores the 46 requirements for Internet-scale Accounting Management. 48 3. Table of Contents 50 1. Status of this Memo 51 2. Abstract 52 3. Table of Contents 53 4. Introduction 54 4.1 Terminology 55 4.2 Requirements language 56 5. Flexibility properties of accounting systems 57 6. Requirements 58 6.1. Flexibility 59 6.2. Scalability 60 6.3. Security 61 6.4. Accounting record transfer 62 6.5. Accounting record information 63 7. Analysis of current protocols 64 8. Conclusions 65 9. Acknowledgements 66 10. References 67 11. Authors' Addresses 69 4. Introduction 71 Over the years, as Internet services have evolved, sophisticated 72 inter-domain applications such as roaming, voice over IP, Internet 73 fax, and QoS provisioning have arisen. This document discusses 74 whether accounting for these services services can be reliably and 75 securely accomplished using established techniques, and explores the 76 requirements for Internet-scale Accounting Management. 78 4.1. Terminology 80 This document frequently uses the following terms: 82 Accounting 83 The act of collecting information on resource usage for the 84 purpose of trend analysis, auditing, billing, or cost allo- 85 cation. 87 Rating The act of determining the price to be charged for use of a 88 resource. 90 Billing The act of preparing an invoice. 92 Auditing The act of verifying the correctness of a procedure. 94 Cost Allocation 95 The act of allocating costs between entities. Note that cost 96 allocation and rating are fundamentally different processes. 98 Interim accounting 99 An interim accounting packet provides a snapshot of usage 100 during a user's session. It is typically implemented in 101 order to provide for partial accounting of a user's session 102 in the event of a device reboot or other network problem 103 that prevents the reception of a session summary packet or 104 session record. 106 Session record 107 A session record represents a summary of the resource con- 108 sumption of a user over the entire session. Accounting gate- 109 ways creating the session record may do so by processing 110 interim accounting events. 112 Accounting Protocol 113 A protocol used to convey data for accounting purposes. 115 Intra-domain accounting 116 Intra-domain accounting involves the collection of informa- 117 tion on resource within an administrative domain, for use 118 within that domain. In intra-domain accounting, accounting 119 packets and session records typically do not cross adminis- 120 trative boundaries. 122 Inter-domain accounting 123 Inter-domain accounting involves the collection of informa- 124 tion on resource usage of an entity with an administrative 125 domain, for use within another administrative domain. In 126 inter-domain accounting, accounting packets and session 127 records will typically cross administrative boundaries. 129 Real-time accounting 130 Real-time accounting involves the processing of information 131 on resource usage within a defined time window. Time con- 132 straints are typically imposed in order to limit financial 133 risk. 135 4.2. Requirements language 137 In this document, the key words "MAY", "MUST, "MUST NOT", 138 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 139 interpreted as described in [24]. 141 5. Flexibility properties of accounting systems 143 This document is concerned with understanding how a general mechanism 144 can be used for the accounting management of a number of different 145 applications. It is therefore appropriate that we examine the poten- 146 tially differing requirements: 148 Information While there are some generally applicable information 149 elements in accounting (such as service name and time 150 information), different services typically have widely 151 different needs to convey information. It must be pos- 152 sible to extend the basic accounting mechanisms to new 153 application areas in a well-defined manner. 155 Security An intra-domain trend analysis application has very low 156 or non-existent security requirements; hop-by-hop 157 integrity support is almost certainly sufficient. In 158 contrast, an inter-domain billing application has very 159 high security requirements including data-object 160 integrity through proxies, confidentiality, and so on. 162 Data amount Many applications produce relatively small amounts of 163 data from each event, such as the few dozen variables 164 needed to describe a dial-in session with a NAS. In 165 contrast, some other applications may require the 166 inclusion of lengthy public key material and signa- 167 tures, or detailed descriptions of the provided ser- 168 vice. 170 Delay Many applications don't require immediate delivery of 171 accounting information, and are unwilling to pay the 172 price of such fast service. Other applications do 173 require immediate delivery. Yet other applications 174 insist also on fast acknowledgement of the delivery in 175 order to minimize the time the user has to wait before 176 service can be provided. 178 Applications differ also much depending on the amount of resources 179 they can dedicate for the accounting tasks: 181 CPU resources An application such as the accounting of dial-in ses- 182 sions of a NAS produces relatively infrequent account- 183 ing events. Other applications, such as accounting the 184 browsing of a web page produce substantially higher 185 amounts of events. 187 Storage resources 188 Many existing systems have no non-volatile memory or 189 use memory types that don't allow constant modifica- 190 tions. In contrast, future systems are likely to 191 employ large and cheap non-volatile memories. 193 Code size and complexity 194 For a workstation size computer the support of a number 195 of encryption algorithms, IPSec, MIME encoding, SMTP, 196 TCP, and so on is relatively easy. For a smaller device 197 such as an embedded processor in a fax or copy machine, 198 phone, set top box, and so on there are much tighter 199 requirements on how much protocol support can be 200 included. 202 If possible, these differing requirements and constraints should still 203 be supported within one accounting management mechanism. 205 6. Requirements 207 6.1. Flexibility 209 The following flexibility requirements suggest themselves: 211 Extensibility The protocol MUST be extensible to new services. It 212 MUST be possible to define service-specific extensions 213 to the accounting protocol. There MUST be a possibility 214 to define new standard and vendor-specific attributes. 216 There MUST be a possibility to define new messages. 217 There MUST be a possibility to detect version differ- 218 ences between protocol peers, and to revert to least 219 common denominator behaviour. 221 Security It MUST be possible to use the accounting protocol both 222 in situations which need and tolerate only hop-by-hop 223 integrity protection, as well as in situations which 224 need full integrity and confidentiality protection for 225 data objects and hop-by-hop. 227 Data amount It MUST be possible to use the accounting protocol both 228 in situations in which the amount of transferred infor- 229 mation fits the MTU and in which it doesn't. 231 Delay It MUST be possible to use the accounting protocol both 232 when real-time transfer of information is needed and 233 when it is not tolerated. 235 Fast UDP Delivery 236 It MUST be possible to use the accounting protocol both 237 with TCP and UDP. UDP is needed when real-time require- 238 ments dictate that retransmission policies are speci- 239 fied in a different manner than what TCP allows. For 240 instance, when a critical service requests to send an 241 accounting record and expects an acknowledgement, it 242 may be necessary to switch to an alternate server if 243 the primary server does not respond to a retransmitted 244 packet within a second. 246 Storage It MUST be possible to use the accounting protocol both 247 in devices which have a large non-volatile memory and 248 which don't. 250 Code size It MUST be possible to have conforming accounting pro- 251 tocol implementations from a stripped down version 252 which includes nothing more than basic protocol, UDP, 253 IP, and MD5 to a version which includes all security 254 and transport protocol support. 256 Proxy support It MUST be possible to forward accounting protocol mes- 257 sages through proxies with all supported transfer mod- 258 els. 260 6.2. Scalability 262 The following scalability requirements are set: 264 Per-device state 265 It MUST be possible to implement the accounting systems 266 with a per-device state when real-time requirements 267 don't call for event-driven information transfer. 269 Amortize overhead 270 It MUST be possible to amortize the packet header and 271 security overhead over several accounting records when 272 real-time requirements don't call for event-driven 273 information transfer. 275 6.3. Security 277 The following security related requirements are set: 279 Data object integrity 280 Data object integrity MUST be supported even through 281 proxies. 283 Data object confidentiality 284 Data object confidentiality MUST be supported even 285 through proxies. 287 Hop-by-hop integrity 288 Hop-by-hop integrity MUST be supported. 290 Hop-by-hop confidentiality 291 Hop-by-hop confidentiality MUST be supported. 293 IPSec/TLS Standard Internet security mechanisms such as IPSec or 294 TLS MUST be supportd for hop-by-hop security protec- 295 tion. 297 Data-based access control 298 Access control MUST be based also on the data in the 299 accounting records (such as for whose customers the 300 data is). 302 6.4. Accounting record transfer 304 The following requirements are set on how the accounting protocol 305 allows records to be transferred. 307 Polling It MUST be possible to use the polling model. 309 Event-driven It MUST be possible to use the event-driven model. 311 Event-driven polling 312 It MUST be possible to use the event-driven polling 313 model. 315 Interim-accounting 316 It MUST be possible to use the interim accounting 317 model. 319 Transfer negotiation 320 It MUST be possible for the service device and the 321 accounting server to negotiate the desired transfer 322 model and interim accounting parameters. 324 6.5. Accounting record information 326 The following requirements are related to the information in the 327 accounting records transferred by the protocol: 329 Finite sessions 330 The accounting protocol MUST support the accounting of 331 service usage in which a session begins at a certain 332 time and ends at a later time. 334 Infinite sessions 335 The accounting protocol MUST support sessions of indef- 336 inite length. [Discussion: This requirement is set by 337 services which are turned on at one time such as when 338 you order for some web space from a server, continue 339 for possibly a very long time, and might but need not 340 be terminated later.] 342 Indivisible events 343 The accounting protocol MUST support the accounting of 344 service usage which consists of an indivisible event. 345 [Discussion: In theory, this could be simulated with a 346 start followed immediately by stop, perhaps even in the 347 same packet. However, this is clumsy for a number of 348 services such as ordering a pizza.] 350 Service naming The protocol MUST have a standard attribute which iden- 351 tifies the name of the provided service. [Discussion: 352 Should there be something to manage these names, e.g. 353 object identifiers?] 355 Service amount specification 356 The protocol MUST have a standard attribute which gives 357 the "amount" of service provided. Amount is interpreted 358 in an service-specific manner, but it could be the 359 amount of calls made, amount of pizzas delivered, and 360 so on. The interpretation of the amount attribute is 361 defined in service-specific extensions to the account- 362 ing protocol. It MUST be possible to represent also 363 real numbers and not just integers. 365 Service length specification 366 The protocol MUST have a standard attribute which gives 367 the "length" of the service provided. Length is inter- 368 preted in the same way for all services, and MUST have 369 at least a one second granularity. 371 Service parameter specification 372 The protocol MUST have a standard attribute which gives 373 parameter information about the provided service. The 374 interpretation of this parameter is service-specific, 375 and defined in service-specific extensions to the 376 accounting protocol. [Discussion: Introduction of this 377 attribute may remove many of unnecessary RFCs about 378 video movie name attributes, pizza name attributes, and 379 so on.] 381 Note that the amount of money used for the service is 382 NOT required to be within the standard attributes. 384 7. Analysis of current protocols 386 In the following table we analyze how RADIUS Accounting as defined in 387 [4], TACACS+ as defined in [32], SNMP v3 as defined in [12]-[16], SMTP 388 and EDI functionality described in [17]-[23], and DIAMETER as defined 389 in [33] - [35] compare. We have used the following notation in the 390 table: 392 NO The protocol does not and can not support the feature. 394 YES The protocol supports the feature. 396 CAN The basic protocol could support the feature, given a simple 397 appropriate extension such as a new attribute is defined. 399 +-----------------------------+--------+--------+--------+--------+--------+ 400 | FEATURE | RADIUS | TACACS+| SNMPv3 | SMTP |DIAMETER| 401 +-----------------------------+--------+--------+--------+--------+--------+ 402 |Flexibility | | | | | | 403 | Extensibility | NO | NO(?)| YES | YES | YES | 404 | Security | NO | NO | NO | YES | YES | 405 | Data amount | NO | YES | NO | YES | YES | 406 | Delay | NO | NO | YES | YES | YES | 407 | Fast UDP delivery | YES | YES | YES | NO | YES | 408 | Storage | YES | YES | YES | NO | YES | 409 | Code size | NO | NO | YES | NO | YES | 410 | Proxy support | YES | YES | YES | YES | YES | 411 +-----------------------------+--------+--------+--------+--------+--------+ 412 |Scalability | | | | | | 413 | Per-device state | NO | NO | NO(?)| YES | CAN | 414 | Amortize overhead | NO | NO | NO(?)| YES | CAN | 415 +-----------------------------+--------+--------+--------+--------+--------+ 416 |Security | | | | | | 417 | Data object integrity | NO | NO | NO | YES | YES | 418 | Data object confidentiality| NO | NO | NO | YES | YES | 419 | Hop-by-hop integrity | YES | YES | YES | YES | YES | 420 | Hop-by-hop confidentiality | NO | YES | YES | YES | YES | 421 | IPSec/TLS | CAN | CAN | CAN | YES | YES | 422 | Data-based access control | YES | YES | NO | YES | YES | 423 +-----------------------------+--------+--------+--------+--------+--------+ 424 |Accounting record transfer | | | | | | 425 | Polling | NO | NO | YES | YES | CAN | 426 | Event-driven | YES | YES | YES | YES | YES | 427 | Event-driven polling | NO | NO | YES | YES | CAN | 428 | Interim accounting | YES | YES | CAN | YES | CAN | 429 | Transfer negotiation | YES | NO(?)| NO | CAN | CAN | 430 +-----------------------------+--------+--------+--------+--------+--------+ 431 |Accounting record information| | | | | | 432 | Finite sessions | YES | YES | CAN | CAN | YES | 433 | Infinite sessions | CAN | CAN | CAN | CAN | CAN | 434 | Indivisible events | CAN | CAN | CAN | CAN | CAN | 435 | Service naming | CAN | CAN | CAN | CAN | CAN | 436 | Service amount specificatio| CAN | CAN | CAN | CAN | CAN | 437 | Service length specificatio| CAN | CAN | CAN | CAN | CAN | 438 | Service parametrization | CAN | CAN | CAN | CAN | CAN | 439 +-----------------------------+--------+--------+--------+--------+--------+ 441 8. Conclusions 443 As noted above, RADIUS, TACACS+, and DIAMETER accounting are suitable 444 for use in low-delay applications, SMTP is well suited for applica- 445 tions requiring high security and efficient transfer, and implementing 446 non-volatile storage, and SNMP v3 is suitable for use in intra-domain 447 accounting applications without need for data object security. How- 448 ever, since no single protocol satisfies all the requirements, we 449 believe that the need for a special-purpose accounting protocol arises 450 in the situations that involve more than one of the following require- 451 ments: 453 - Accounting applications which require low processing delay in order 454 to detect security or appropriate use violations in progress, manage 455 credit risk or prevent fraud. In such applications, it is often 456 required that accounting-data be handled in an event-driven manner, 457 and sent in small batches. 459 - Accounting applications which must incorporate information from many 460 devices or transfer very large volumes of data. In such applications, 461 efficiency is very important. 463 - Light-weight accounting applications running on small devices. 465 While RADIUS and TACACS+ are in principle capable of handling the 466 above two requirements, the lack of data object security, extensibil- 467 ity, and support for large record sizes makes it hard use these proto- 468 cols. 470 The following decisions now await resolving: 472 - The first decision is whether to handle credit risk management, 473 fraud detection, and so as a part of an accounting protocol, or 474 whether to handle it as a part of yet to be defined resource manage- 475 ment protocol. Support for these tasks could be included in products 476 that use the DIAMETER resource management extensions [34], for 477 instance. If the resource management protocol is used for this purpose 478 then many of the requirements set in this document will apply to it. 479 If not, a separate protocol needs to be constructed for the accounting 480 part. [Discussion: The line between a resource management and account- 481 ing tasks is blurred in my mind - what IS the actual difference?] 483 - The second decision is to decide whether the support for large- 484 voleme or light-weight applications is important enough to warrant the 485 definition of a new protocol. 487 - The third decision is to decide whether the accounting work may 488 assume the universal existence of large non-volatile memories or not. 490 9. Acknowledgements 492 The authors would like to thank Pat Calhoun (Sun Microsystems), Jan 493 Melen (Ericsson), Jarmo Savolainen (Ericsson), and Glen Zorn 494 (Microsoft) for many useful discussions of this problem space. 496 10. References 498 [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming 499 Implementations." RFC 2194, Microsoft, Aimnet, i-Pass Alliance, 500 Asiainfo, Merit, September 1997. 502 [2] B. Aboba, G. Zorn. "Roaming Requirements." Internet draft (work 503 in progress), draft-ietf-roamops-roamreq-07.txt, Microsoft, March 504 1998. 506 [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 507 cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, 508 Daydreamer, April, 1997. 510 [4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April, 511 1997. 513 [5] J. Gray, A. Reuter. Transaction Processing: Concepts and Tech- 514 niques, Morgan Kaufmann Publishers, San Francisco, California, 1993. 516 [6] S. Bradner. "Key words for use in RFCs to Indicate Requirement 517 Levels." RFC 2119, Harvard University, March, 1997. 519 [7] D. Crocker, P. Overrell. "Augmented BNF for Syntax Specifica- 520 tions: ABNF." RFC 2234, Internet Mail Consortium, Demon Internet 521 Ltd., November 1997. 523 [8] G. Good. "The LDAP Data Interchange Format (LDIF) - Technical 524 Specification." Internet draft (work in progress), draft-ietf-asid- 525 ldif-02.txt, Netscape, July 1997. 527 [9] K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. "Accounting 528 Information for ATM Networks." Internet draft (work in progress), 529 draft-ietf-atommib-atmacct-04.txt, Cisco Systems, Telecom Finland, 530 MCI, November 1996. 532 [10] K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. "Managed 533 Objects for Controlling the Collection and Storage of Accounting 534 Information for Connection-Oriented Networks." Internet draft (work 535 in progress), draft-ietf-atommib-acct-04.txt, Cisco Systems, Telecom 536 Finland, MCI, November 1996. 538 [11] B. Aboba, D. Lidyard. "Accounting Data Interchange Format 539 (ADIF)." Internet draft (work in progress), draft-ietf-roamops- 540 actng-04.txt, Microsoft, Telco Research, March 1998. 542 [12] D. Harrington, R. Presuhn, B. Wijnen, "An Architecture for 543 Describing SNMP Management Frameworks", RFC 2271, Cabletron, BMC Soft- 544 ware, IBM, January 1998. 546 [13] J. Case, D. Harrington, R. Presuhn, B. Wijnen, "Message Process- 547 ing and Dispatching for the Simple Network Management Protocol 548 (SNMP)", RFC 2272, SNMP Research, Cabletron Systems, BMC Software, 549 IBM, January 1998. 551 [14] D. Levi, P. Meyer, B. Stewart, "SNMPv3 Applications", RFC 2273, 552 SNMP Research, Secure Computing Corporation, Cisco Systems, January 553 1998. 555 [15] U. Blumenthal, B. Wijnen, "User-based Security Model (USM) for 556 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 557 2274, IBM, January 1998. 559 [16] B. Wijnen, R. Presuhn, K. McCloghrie, "View-based Access Control 560 Modem (VACM) for the Simple Network Management Protocol (SNMP)", RFC 561 2275, IBM, BMC Software, Cisco Systems, January 1998. 563 [17] R. Fajman. "An Extensible Message Format for Message Disposi- 564 tion Notifications." Internet draft (work in progress), draft- 565 ietf- receipt-mdn-08.txt, National Institute of Health, August 1998. 567 [18] M. Elkins. "MIME Security with Pretty Good Privacy (PGP)." 568 RFC 2015, The Aerospace Corporation, October, 1996. 570 [19] G. Vaudreuil. "The Multipart/Report Content Type for the Report- 571 ing of Mail System Administrative Messages." RFC 1892, Octel Network 572 Services, January, 1996. 574 [20] J. Galvin., et al. "Security Multiparts for MIME: Multi- 575 part/Signed and Multipart/Encrypted." RFC 1847, Trusted Information 576 Systems, October, 1995. 578 [21] D. Crocker. "MIME Encapsulation of EDI Objects." RFC 1767, Bran- 579 denburg Consulting, March, 1995. 581 [22] C. Shih, M. Jansson, R. Drummond. MIME-based Secure EDI." 582 Internet draft (work in progress), draft-ietf-ediint- 583 as1-05.txt, Actra, LiNK, Drummond Group, July 1997. 585 [23] C. Shih, M. Jansson, R. Drummond, L. Yarbrough. "Requirements for 586 Inter-operable Internet EDI." Internet draft (work in progress), 587 draft-ietf-ediint-req-04.txt, Actra, LiNK, Drummond Group, July 1997. 589 [24] S. Bradner. "Key words for use in RFCs to Indicate Requirement 590 Levels." RFC 2119, Harvard University, March, 1997. 592 [25] Borenstein, N., Freed, N. "MIME (Multipurpose Internet Mail 593 Extensions) Part One: Mechanisms for Specifying and Describing the 594 Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, 595 December 1993. 597 [26] N. Joffe, D. Wing, L. Masinter. "SMTP Service Extension for Imme- 598 diate Delivery", Internet draft (work in progress), draft-ietf-fax- 599 smtp-session-02.txt, Cisco Systems, Xerox, February 1997. 601 [27] H. T. Johnson, R. S. Kaplan. Relevance Lost: The Rise and Fall of 602 Management Accounting, Harvard Business School Press, Boston, Mas- 603 sachusetts, 1987. 605 [28] C. T. Horngren, G. Foster. Cost Accounting: A Managerial Empha- 606 sis. Prentice Hall, Englewood Cliffs, New Jersey, 1991. 608 [29] R. S. Kaplan, Anthony A. Atkinson. Advanced Management 609 Accounting. Prentice Hall, Englewood Cliffs, New Jersey, 1989. 611 [30] R. Cooper, R. S. Kaplan. The Design of Cost Management Systems. 612 Prentice Hall, Englewood Cliffs, New Jersey, 1991. 614 [31] P. R. Calhoun, M. A. Beadles, A. Ratcliffe. "RADIUS Accounting 615 Interim Accounting Record Extension", Internet draft (work in 616 progress), draft-ietf-radius-acct-interim-00.txt, July 1997. 618 [32] D. Carrel, L. Grant. "The TACACS+ Protocool Version 1.78", Inter- 619 net draft (work in progress), draft-grant-tacacs-02.txt, Cisco Sys- 620 tems, January, 1997. 622 [33] P. R. Calhoun, A. Rubens. "DIAMETER Base Protocol", Internet 623 draft (work in progress), draft-calhoun-diameter-01.txt, Sun Microsys- 624 tems, Merit Networks, March, 1998. 626 [34] P. R. Calhoun. "DIAMETER Resource Management Extensions", Inter- 627 net draft (work in progress), draft-calhoun-diameter-res-mgmt-00.txt, 628 Sun Microsystems, March, 1998. 630 [35] P. R. Calhoun. "DIAMETER User Authentication Extensions", Inter- 631 net draft (work in progress), draft-calhoun-diameter-authent-01.txt, 632 Sun Microsystems, March, 1998. 634 11. Authors' Addresses 636 Jari Arkko 637 Oy LM Ericsson Ab 638 02420 Jorvas 639 Finland 641 Phone: +358 40 5079256 642 EMail: Jari.Arkko@ericsson.com