idnits 2.17.1 draft-aboba-acct-01.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): ---------------------------------------------------------------------------- ** 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: ---------------------------------------------------------------------------- ** 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 the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 34 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' Introduction to Accounting Management' ) ** The document seems to lack a Security Considerations 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 106 has weird spacing: '...tion be measu...' == Line 849 has weird spacing: '...need to keep ...' == Line 956 has weird spacing: '...section descr...' == Line 1142 has weird spacing: '...xisting prot...' == Line 1249 has weird spacing: '...J., et al. ...' == (4 more instances...) -- 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 (8 June 1999) is 9088 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '24' on line 1281 looks like a reference -- Missing reference section? '43' on line 1349 looks like a reference -- Missing reference section? '25' on line 1284 looks like a reference -- Missing reference section? '26' on line 1288 looks like a reference -- Missing reference section? '4' on line 1213 looks like a reference -- Missing reference section? '11' on line 1236 looks like a reference -- Missing reference section? '45' on line 1355 looks like a reference -- Missing reference section? '3' on line 1209 looks like a reference -- Missing reference section? '1' on line 1203 looks like a reference -- Missing reference section? '2' on line 1206 looks like a reference -- Missing reference section? '44' on line 1352 looks like a reference -- Missing reference section? '40' on line 1338 looks like a reference -- Missing reference section? '38' on line 1331 looks like a reference -- Missing reference section? '13' on line 1243 looks like a reference -- Missing reference section? '15' on line 1249 looks like a reference -- Missing reference section? '12' on line 1240 looks like a reference -- Missing reference section? '20' on line 1267 looks like a reference -- Missing reference section? '9' on line 1228 looks like a reference -- Missing reference section? '5' on line 1215 looks like a reference -- Missing reference section? '6' on line 1219 looks like a reference -- Missing reference section? '7' on line 1222 looks like a reference -- Missing reference section? '8' on line 1225 looks like a reference -- Missing reference section? '10' on line 1231 looks like a reference -- Missing reference section? '14' on line 1246 looks like a reference -- Missing reference section? '16' on line 1252 looks like a reference -- Missing reference section? '17' on line 1255 looks like a reference -- Missing reference section? '18' on line 1259 looks like a reference -- Missing reference section? '19' on line 1263 looks like a reference -- Missing reference section? '21' on line 1271 looks like a reference -- Missing reference section? '22' on line 1275 looks like a reference -- Missing reference section? '23' on line 1278 looks like a reference -- Missing reference section? '27' on line 1292 looks like a reference -- Missing reference section? '28' on line 1295 looks like a reference -- Missing reference section? '29' on line 1299 looks like a reference -- Missing reference section? '30' on line 1302 looks like a reference -- Missing reference section? '31' on line 1305 looks like a reference -- Missing reference section? '32' on line 1309 looks like a reference -- Missing reference section? '33' on line 1313 looks like a reference -- Missing reference section? '34' on line 1317 looks like a reference -- Missing reference section? '35' on line 1320 looks like a reference -- Missing reference section? '36' on line 1323 looks like a reference -- Missing reference section? '37' on line 1327 looks like a reference -- Missing reference section? '39' on line 1335 looks like a reference -- Missing reference section? '41' on line 1342 looks like a reference -- Missing reference section? '42' on line 1346 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 47 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft Corporation 3 Category: Informational Jari Arkko 4 Ericsson 5 8 June 1999 7 Introduction to Accounting Management 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. Internet- 17 Drafts are draft documents valid for a maximum of six months and may be 18 updated, replaced, or obsoleted by other documents at any time. It is 19 inappropriate to use Internet-Drafts as reference material or to cite 20 them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 The distribution of this memo is unlimited. It is filed as , and expires December 1, 1999. Please send comments 30 to the authors. 32 2. Copyright Notice 34 Copyright (C) The Internet Society (1999). All Rights Reserved. 36 3. Abstract 38 The field of Accounting Management is concerned with the collection of 39 resource consumption data for the purposes of capacity and trend 40 analysis, cost allocation, auditing, and billing. This document 41 describes each of these problems, and discusses the issues involved in 42 design of modern accounting systems. 44 Since accounting applications do not have uniform security and 45 reliability requirements, it is not possible to devise a single 46 accounting protocol and set of security services that will meet all 47 needs. Thus the goal of accounting management is to provide a set of 48 tools that can be used to meet the requirements of each application. 49 This document describes the currently available tools as well as the 50 state of the art in accounting protocol design. A companion document, 51 draft-brownlee-accounting-attributes-00.txt, reviews the state of the 52 art in accounting attributes and record formats. 54 4. Table of Contents 56 1. Status of this Memo 57 2. Copyright notice 58 3. Abstract 59 4. Table of Contents 60 5. Introduction 61 5.1 Terminology 62 5.2 Accounting management architecture 63 5.3 Accounting management objectives 64 5.4 Intra-domain and inter-domain accounting 65 5.5 Requirements summary 66 6. Scaling and reliability properties of accounting systems 67 6.1 Fault resilience 68 6.2 Resource consumption 69 6.3 Data collection models 70 7. Review of existing accounting protocols 71 7.1 Accounting protocols 72 7.2 Accounting data transfer 73 8. Security issues 74 9. Acknowledgements 75 10. References 76 11. Authors' Addresses 77 12. Copyright Statement 78 13. Expiration date 80 5. Introduction 82 The field of Accounting Management is concerned with the collection of 83 resource consumption data for the purposes of capacity and trend 84 analysis, cost allocation, auditing, and billing. This document 85 describes each of these problems, and discusses the issues involved in 86 design of modern accounting systems. 88 Since accounting applications do not have uniform security and 89 reliability requirements, it is not possible to devise a single 90 accounting protocol and set of security services that will meet all 91 needs. Thus the goal of accounting management is to provide a set of 92 tools that can be used to meet the requirements of each application. 93 This document describes the currently available tools as well as the 94 state of the art in accounting protocol design. A companion document, 95 draft-brownlee-accounting-attributes-00.txt, reviews the state of the 96 art in accounting attributes and record formats. 98 5.1. Terminology 100 This document frequently uses the following terms: 102 Accounting 103 The collection of resource consumption data for the purposes 104 of capacity and trend analysis, cost allocation, auditing, and 105 billing. Accounting management requires that resource 106 consumption be measured, rated, assigned, and communicated 107 between appropriate parties. 109 Archival accounting 110 In archival accounting, the goal is to collect all accounting 111 data, to reconstruct missing entries as best as possible in 112 the event of data loss, and to archive data for a mandated 113 time period. Legal or financial requirements frequently 114 mandate archival accounting practices, and may often dictate 115 that data be kept confidential, regardless of whether it is to 116 be used for billing purposes or not. 118 Rating The act of determining the price to be charged for use of a 119 resource. 121 Billing The act of preparing an invoice. 123 Usage sensitive billing 124 A billing process that depends on usage information to prepare 125 an invoice can be said to be usage-sensitive. In contrast, a 126 process that is independent of usage information is said to be 127 non-usage-sensitive. 129 Auditing The act of verifying the correctness of a procedure. 131 Cost Allocation 132 The act of allocating costs between entities. Note that cost 133 allocation and rating are fundamentally different processes. 134 In cost allocation the objective is typically to allocate a 135 known cost among several entities. In rating the objective is 136 to determine the amount owed. In cost allocation, the cost per 137 unit of resource may need to be determined; in rating, this is 138 typically a given. 140 Interim accounting 141 An interim accounting packet provides a snapshot of usage 142 during a user's session. It is typically implemented in order 143 to provide for partial accounting of a user's session in the 144 event of a device reboot or other network problem that 145 prevents the reception of a session summary packet or session 146 record. 148 Session record 149 A session record represents a summary of the resource 150 consumption of a user over the entire session. Accounting 151 gateways creating the session record may do so by processing 152 interim accounting events or accounting events from several 153 devices serving the same user. 155 Accounting Protocol 156 A protocol used to convey data for accounting purposes. 158 Intra-domain accounting 159 Intra-domain accounting involves the collection of information 160 on resource within an administrative domain, for use within 161 that domain. In intra-domain accounting, accounting packets 162 and session records typically do not cross administrative 163 boundaries. 165 Inter-domain accounting 166 Inter-domain accounting involves the collection of information 167 on resource usage of an entity with an administrative domain, 168 for use within another administrative domain. In inter-domain 169 accounting, accounting packets and session records will 170 typically cross administrative boundaries. 172 Real-time accounting 173 Real-time accounting involves the processing of information on 174 resource usage within a defined time window. Time constraints 175 are typically imposed in order to limit financial risk. 177 Accounting server 178 The accounting server receives accounting data from devices 179 and translates it into session records. The accounting server 180 may also take responsibility for the routing of session 181 records to interested parties. 183 5.2. Accounting management architecture 185 The accounting management architecture involves interactions between 186 network devices, accounting servers, and billing servers. The network 187 device collects resource consumption data in the form of accounting 188 metrics. This information is then transferred to an accounting server. 189 Typically this is accomplished via an accounting protocol, although it 190 is also possible for devices to generate session records. 192 The accounting server then processes the accounting data received from 193 the network device. This processing may include summarization of interim 194 accounting information, elimination of duplicate data, or generation of 195 session records. 197 The processed accounting data is then submitted to a billing server, 198 which typically handles rating and invoice generation, but may also 199 carry out auditing, cost allocation, trend analysis or capacity planning 200 functions. Session records may be batched and compressed by the 201 accounting server prior to submission to the billing server in order to 202 reduce the volume of accounting data and the bandwidth required to 203 accomplish the transfer. 205 One of the functions of the accounting server is to distinguish between 206 the inter and intra-domain accounting events and to route them 207 appropriately. Intra-domain accounting events are typically routed to 208 the local billing server, while inter-domain accounting events will be 209 routed to accounting servers operating within other administrative 210 domains. While it is not required that session record formats used in 211 inter and intra-domain accounting be the same, such rationalization is 212 desirable, since it eliminates translations that would otherwise be 213 required. 215 The diagram below illustrates the accounting management architecture: 217 +------------+ 218 | | 219 | Network | 220 | Device | 221 | | 222 +------------+ 223 | 224 Accounting | 225 Protocol | 226 | 227 | 228 V 229 +------------+ +------------+ 230 | | | | 231 | Org B | Inter-domain | Org A | 232 | Acctg. |<----------------------------->| Acctg. | 233 | Server | session records | Server | 234 | | | | 235 +------------+ +------------+ 236 | | 237 | Intra-domain | 238 Transfer | session records | 239 Protocol | | 240 | | 241 V V 242 +------------+ +------------+ 243 | | | | 244 | Org B | | Org A | 245 | Billing | | Billing | 246 | Server | | Server | 247 | | | | 248 +------------+ +------------+ 250 5.3. Accounting management objectives 252 Accounting Management involves the collection of resource consumption 253 data for the purposes of capacity and trend analysis, cost allocation, 254 auditing, and billing. Since each of these tasks have different 255 requirements, we will discuss each task in detail. 257 5.3.1. Trend analysis and capacity planning 259 In trend analysis and capacity planning, the goal is typically a 260 forecast of future usage. Since such forecasts are inherently 261 imperfect, high reliability is typically not required, and moderate data 262 loss can typically be tolerated. 264 In certain cases, it may be desirable to use statistical sampling 265 techniques to reduce data collection requirements while still providing 266 the forecast with the desired statistical accuracy. Such a sampling 267 process may be insensitive even to large amounts of packet loss as long 268 as bias is not introduced. 270 The security requirements for trend analysis and capacity planning 271 depend on the circumstances of data collection and the sensitivity of 272 the data. Additional security services may be required when data is 273 being transferred between administrative domains. For example, when 274 information is being collected and analyzed within the same 275 administrative domain, integrity protection and authentication may be 276 used in order to guard against collection of invalid data. In inter- 277 domain applications confidentiality may be desirable to guard against 278 snooping by third parties. 280 5.3.2. Billing 282 When accounting data is used for billing purposes, the requirements 283 depend on whether the billing process is usage-sensitive or not. 285 5.3.2.1. Non-usage sensitive billing 287 Since by definition, non-usage-sensitive billing does not require usage 288 information, in theory all accounting data can be lost without affecting 289 the billing process. Of course wholesale data loss will affect other 290 tasks such as trend analysis or auditing, so that this would still cause 291 problems. 293 5.3.2.2. Usage-sensitive billing 295 Since usage-sensitive billing processes depend on usage information, 296 packet loss may translate directly to revenue loss. As a result, the 297 billing process may need to meet requirements arising from financial 298 reporting standards, or legal requirements, and therefore an archival 299 accounting approach may be required. 301 Usage-sensitive systems may also have additional requirements relating 302 to processing delay. Today credit risk is commonly managed by 303 computerized fraud detection systems that are designed to detect unusual 304 activity. While efficiency concerns might otherwise dictate batched 305 transmission of accounting data, where it is desirable to minimize 306 financial risk, a different approach may be required. 308 Since financial exposure increases with processing delay, it may be 309 necessary to transmit each event individually or to minimize batch size, 310 to require positive acknowledgment before providing service, or even to 311 utilize quality of service techniques to minimize queuing delays. 313 The degree of financial exposure is application-dependent. For dialup 314 Internet access from a local provider, charges are low and therefore the 315 risk of loss is small. However, in the case of dialup roaming or voice 316 over IP, time-based charges may be substantial and therefore the risk of 317 fraud is larger. In such situations it is highly desirable to quickly 318 detect unusual account activity, and it may be desirable for 319 authorization to depend on ability to pay. In situations where valuable 320 resources can be reserved, or where charges can be high, very large 321 bills may be rung up quickly, and therefore real-time processing may be 322 required. 324 In usage-sensitive systems, accounting data may result in monetary 325 transfers, and as a result, the security and reliability requirements 326 are greater. Thus security services such as authentication and integrity 327 protection are frequently used, and confidentiality and non-repudiation 328 may also be desirable. 330 5.3.3. Auditing 332 With enterprise networking expenditures on the rise, interest in 333 auditing is increasing. Auditing, which is the act of verifying the 334 correctness of a procedure, commonly relies on accounting data. Auditing 335 tasks include verifying correctness of an invoice submitted by a service 336 provider, or verification that usage is conforming to usage policy, 337 service level agreements, or security guidelines. 339 To permit a credible audit, the accounting data collection methods put 340 in place must be at least as reliable as those used by the invoicing 341 service provider. Similarly, security policies involved in auditing of 342 an invoice should be at least as stringent as those used in preparation 343 of the original invoice. Due to financial and legal requirements, 344 archival accounting practices are frequently required in this 345 application. 347 Where auditing procedures are used to verify conformance to usage or 348 security policies, security services may be desired. This typically will 349 include integrity protection and authentication of accounting data, as 350 well as confidentiality and possibly data object security. In order to 351 permit response to security incidents in progress, auditing applications 352 frequently are built to operate with low processing delay. 354 5.3.4. Cost allocation 356 The application of cost allocation and billback methods by enterprise 357 customers is not yet widespread. However, with the convergence of 358 telephony and data communications, there is increasing interest in 359 applying cost allocation and billback procedures to networking costs, as 360 is now commonly practiced with telecommunications costs. 362 Cost allocation models, including traditional costing mechanisms 363 described in [21]-[23] and activity-based costing techniques described 364 in [24] are typically based on detailed analysis of usage data, and as a 365 result they are almost always usage-sensitive. Whether cost allocation 366 models are applied to allocation of costs between partners in a venture 367 or to allocation of costs between departments in a single firm, cost 368 allocation models often have profound behavioral and financial impacts. 369 As a result, systems developed for this purposes are typically as 370 concerned with reliable data collection and security as are billing 371 applications. Due to financial and legal requirements, archival 372 accounting practices are frequently required in this application. 374 5.4. Intra-domain and inter-domain accounting 376 Much of the early work on accounting management focused on intra-domain 377 accounting applications. However, with the increasing deployment of 378 services such as dialup roaming, Internet fax, Internet telephony and 379 QoS, applications requiring inter-domain accounting are becoming 380 increasingly common. 382 Inter-domain accounting differs from intra-domain accounting in several 383 important ways. Intra-domain accounting involves the collection of 384 information on resource consumption within an administrative domain, for 385 use within that domain. In intra-domain accounting, accounting packets 386 and session records typically do not cross administrative boundaries. As 387 a result, intra-domain accounting applications typically experience low 388 rates of packet loss and involve transfer of data between trusted 389 entities. 391 In contrast, inter-domain accounting involves the collection of 392 information on resource consumption within an administrative domain, for 393 use within another administrative domain. In inter-domain accounting, 394 accounting packets and session records will typically cross 395 administrative boundaries. As a result, inter-domain accounting 396 applications may experience substantial packet loss. In addition, the 397 entitities involved in the transfers cannot be assumed to trust each 398 other. 400 Since inter-domain accounting applications involve transfers of 401 accounting data between domains, additional security measures may be 402 desirable. In addition to authentication and integrity protection, it 403 may be desirable to deploy security services such as confidentiality, 404 replay protection, data object integrity, or non-repudiation. In inter- 405 domain accounting each involved party also typically requires a copy of 406 each accounting event for invoice generation and auditing. 408 5.5. Requirements summary 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | | | 412 | Usage | Intra-domain | Inter-domain | 413 | | | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | | | | 416 | Capacity | Robustness | Robustness | 417 | Planning | against moderate | against high | 418 | | packet loss | packet loss | 419 | | | | 420 | | Integrity, | Integrity, | 421 | | authentication, | authentication, | 422 | | replay protection | replay protection| 423 | | [confidentiality] | confidentiality | 424 | | | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | | | | 427 | Non-Usage | Robustness against | Robustness | 428 | Sensitive | packet loss not | against packet | 429 | Billing | required | loss not | 430 | | | required | 431 | | | | 432 | | Integrity, | Integrity, | 433 | | authentication, | authentication, | 434 | | replay protection | replay protection| 435 | | [confidentiality] | confidentiality | 436 | | | | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | | | | 439 | | Archival | Archival | 440 | Usage | accounting | accounting | 441 | Sensitive | | | 442 | Billing, | Integrity, | Integrity, | 443 | Cost | authentication, | authentication, | 444 | Allocation & | replay protection | replay protection| 445 | Auditing | [confidentiality] | confidentiality | 446 | | | [non-repudiation]| 447 | | | | 448 | | | [Bounds on | 449 | | | processing delay]| 450 | | | | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Key 454 [] = optional 456 6. Scaling and reliability characteristics of accounting systems 458 With the continuing growth of the Internet, it is important that 459 accounting management systems be scalable and reliable. This section 460 discusses the resources consumed by accounting management systems as 461 well as the scalability and reliability properties exhibited by various 462 data collection models. 464 6.1. Fault resilience 466 As noted earlier, in applications such as usage-sensitive billing, cost 467 allocation and auditing, an archival approach to accounting is 468 frequently mandated, due to financial and legal requirements. Since in 469 such situations loss of accounting data can translate directly into 470 revenue loss, financial incentives exist to engineer a high degree of 471 fault resilience. Faults which may be encountered include: 473 Packet loss 474 Accounting server failures 475 Network failures 476 Device reboots 478 To date, much of the debate on accounting reliability has focussed on 479 resilience against packet loss and the differences between UDP and TCP- 480 based transport. However, it should be understood that resilience 481 against packet loss is only one aspect of the program required to meet 482 archival accounting requirements. 484 As noted in [43], "once the cable is cut you don't need more 485 retransmissions, you need a *lot* nore voltage." Thus, the choice of 486 UDP or TCP transport has no impact on resilience against faults such as 487 network partition, accounting server failures or device reboots. What 488 does provide resilience against these faults is non-volatile storage. 490 The importance of non-volatile storage in design of reliable accounting 491 systems cannot be over-emphasized. Without such storage, event-driven 492 systems will lose data once the transmission timeout has been exceeded, 493 and polling or event-driven batching designs will experience data loss 494 once the internal memory used for event storage has been exceeded. 496 Thus, it may be plausibly argued that non-volatile storage is more 497 important to accounting reliability than network connectivity, since for 498 many years reliable accounting systems were implemented based solely on 499 physical storage, without any network connectivity. For example, phone 500 usage data used to be stored on paper, film, or magnetic media and 501 carried from the place of collection to a central location for bill 502 processing. 504 6.1.1. Interim accounting 506 Interim accounting provides protection against loss of session summary 507 data by providing checkpoint information that can be used to reconstruct 508 the session record in the event that the session summary information is 509 lost. This technique may be applied to any data collection model (i.e. 510 event-driven or polling) and is supported in both RADIUS [25] and in 511 TACACS+ [26]. 513 While interim accounting can provide resilience against packet loss, 514 server failures, short-duration network failures, or device reboot, its 515 applicability is limited. Since most packet loss on the Internet is due 516 to congestion, sending interim accounting data over the wire can 517 actually make the problem worse by increasing bandwidth usage. As a 518 result, on-the-wire interim accounting is best restricted to use with 519 high-value accounting data such as information on long-lived sessions. 520 To protect against loss of data on such sessions, the interim reporting 521 interval is typically set several standard deviations larger than the 522 average session duration. This ensures that most sessions will not 523 result in generation of interim accounting events and the additional 524 bandwidth consumed by interim accounting will be moderate. 526 However, as the interim accounting interval decreases toward the the 527 average session time, the additional bandwidth consumed by interim 528 accounting increases markedly, and as a result, the interval must be set 529 with caution. This practice is particularly suspect since it increases 530 use of network bandwidth in normal operation, while providing benefits 531 only in the event of a fault. 533 Where non-volatile storage is unavailable, interim accounting can also 534 result in excessive consumption of memory that could be better allocated 535 to storage of session data. As a result, implementors should be careful 536 to ensure that new interim accounting data overwrites previous data 537 rather than accumulating additional interim records thereby worsening 538 the buffer exhaustion problem. 540 Given the decreasing cost of non-volatile memory, it may be preferable 541 to store interim accounting data in non-volatile storage. Stored interim 542 events are then replaced by session data when the session completes, and 543 the session data can itself be erased once the data has been 544 transmitted. This approach avoids interim data being transmitted over 545 the wire, except in the case of a device reboot. 547 6.1.2. Packet loss 549 As packet loss is a fact of life on the Internet, accounting protocols 550 need to be resilient against such losses. This is particularly important 551 in inter-domain accounting, where packets often pass through Network 552 Access Points (NAPs) where packet loss may be substantial. Resilience 553 against packet loss can be accomplished via implementation of a retry 554 mechanism on top of UDP, or use of TCP. On-the-wire interim accounting 555 provides only limited benefits in mitigating the effects of packet loss. 557 When implementing UDP retransmission, there are a number of issues to 558 keep in mind: 560 Retry behavior 561 Congestion control 562 Timeout behavior 564 In designing a UDP retry mechanism, it is important that the retry 565 timers relate to the round-trip time, so that retransmissions will not 566 typically occur within the period in which acknowledgements may be 567 expected to arrive. Accounting bandwidth may be significant in some 568 circumstances, so that the added traffic due to unnecessary 569 retransmissions may increase congestion levels. 571 Congestion control in accounting data transfer is a somewhat 572 controversial issue. Since accounting traffic is often considered 573 mission-critical, it has been argued that congestion control is not a 574 requirement; better to let other less-critical traffic back off in 575 response to congestion. Moreover, without non-volatile storage, 576 congestive backoff in accounting applications can result in data loss 577 due to buffer exhaustion. 579 However, there are very persuasive arguments that in modern accounting 580 implementations, it is possible to implement congestion control while 581 improving throughput and maintaining high reliability. 583 In circumstances where there is sustained packet loss, there simply is 584 not sufficient capacity to maintain existing transmission rates. Thus, 585 aggregate throughput will actually improve if congestive backoff is 586 implemented. This is due to elimination of retransmissions and ability 587 to utilize techniques such as RED to desynchronize flows. In addition, 588 with QoS mechanisms such as differentiated services, it is possible to 589 mark accounting packets for preferential handling so as to provide for 590 lower packet loss if desired. Thus such choices need not be hard coded 591 within the application, but can be left to the network administrator. 592 Furthermore, systems implementing non-volatile storage allow for 593 backlogged accounting data to be placed in permanent storage pending 594 transmission so that buffer exhaustion resulting from congestive backoff 595 is not a concern. 597 Since UDP is not really a transport protocol, UDP-based accounting 598 protocols such as [4] often do not prescribe timeout behavior. Thus one 599 implementation may throw the accounting data away after 3 constant 600 duration retries to the same server, while another may implement 601 exponential backoff to a given server, then switch to another server, up 602 to a total timeout interval of 12 hours, while storing the untransmitted 603 data on non-volatile storage. The difference between these behaviors may 604 be of intense concern, since the former approach will not satisfy 605 archival accounting requirements while the latter may. 607 6.1.3. Accounting server failures 609 In the event of an accounting server failure, it may not be possible for 610 a device to transmit accounting data to its primary accounting server. 611 For protocols using TCP, opening of a connection to the secondary 612 accounting server can occur after a timeout or loss of the primary 613 connection, or it can occur on expiration of a timer. For protocols 614 using UDP, transmission to the secondary server can occur after a number 615 of retries or timer expiration. In either case, it is possible for the 616 primary and secondary accounting servers to receive the same record, so 617 that elimination of duplicates is required. 619 Since accounting server failures can result in data accumulation on 620 accounting clients, use of non-volatile storage can ensure against the 621 loss of such data due to transmission timeouts or buffer exhaustion. 623 On-the-wire interim accounting provides only limited benefits in 624 mitigating the effects of accounting server failures. 626 6.1.4. Network failures 628 Network failures may result in partial or complete loss of connectivity 629 for the accounting client. In the event of partial connectivity loss, it 630 may not be possible to reach the primary accounting server, in which 631 case switchover to the secondary accounting server is necessary. In the 632 event of a network partition, it may be necessary to store accounting 633 events in device memory or non-volatile storage until connectivity can 634 be re-established. 636 As with accounting server failures, on-the-wire interim accounting 637 provides only limited benefits in mitigating the effects of network 638 failures. 640 6.1.5. Device reboots 642 In the event of a device reboot, it is desirable to minimize the loss of 643 data on sessions in progress. Such losses may be significant even if the 644 devices themselves are very reliable, due to long-lived sessions, which 645 can comprise a significant fraction of total resource consumption. 646 Sending interim accounting data over the wire is typically implemented 647 to guard against loss of these high-value sessions. When interim 648 accounting is combined with non-volatile storage it becomes possible to 649 guard against data loss in much shorter sessions. This is possible since 650 interim accounting data need only be stored in non-volatile memory until 651 the session completes, at which time the interim data may be replaced by 652 the session record. As a result, interim accounting data need never be 653 sent over the wire, and it is possible to decrease the interim interval 654 so as to provide a very high degree of protection against data loss. 656 6.1.6. Fault resilience summary 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | | | 660 | Fault | Counter-measures | 661 | | | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | | | 664 | Packet | Retransmission based on RTT | 665 | loss | Congestion control | 666 | | Well-defined timeout behavior | 667 | | Duplicate elimination | 668 | | Interim accounting* | 669 | | Non-volatile storage | 670 | | | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | | | 673 | Accounting | Primary-secondary servers | 674 | server & net | Duplicate elimination | 675 | failures | Interim accounting* | 676 | | Non-volatile storage | 677 | | | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | | | 680 | Device | Interim accounting* | 681 | reboots | Non-volatile storage | 682 | | | 683 | | | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 Key 687 * = limited usefulness without non-volatile storage 689 6.2. Resource consumption 691 In the process of growing to meet the needs of providers and customers, 692 accounting management systems consume a variety of resources, including: 694 Network bandwidth 695 Memory 696 Non-volatile storage 697 State on the accounting management system 698 CPU on the management system and managed devices 700 In order to understand the limits to scaling of accounting management 701 systems, we examine each of these resources in turn. 703 6.2.1. Network bandwidth 705 Accounting management systems consume network bandwidth in the 706 transferring of accounting data. The network bandwidth consumed is 707 proportional to the amount of data transferred, as well as required 708 network overhead. Since accounting data for a given event may be 100 709 octets or less, if each event is transferred individually, overhead can 710 represent a considerable proportion of total bandwidth consumption. As 711 a result, it is often desirable to transfer accounting data in batches, 712 enabling network overhead to be spread over a larger payload, and 713 enabling efficient use of compression. 715 6.2.2. Memory 717 In accounting systems without non-volatile storage, accounting data must 718 be stored in volatile memory during the period between when it is 719 generated and when it is transferred. The resulting memory consumption 720 will depend on retry and retransmission algorithms. Since systems 721 designed for high reliability will typically wish to retry for long 722 periods, or may store interim accounting data, the resulting memory 723 consumption can be considerable. As a result, if non-volatile storage is 724 unavailable, it may be desirable to compress accounting data awaiting 725 transmission. 727 As noted earlier, implementors of interim accounting should take care to 728 ensure against excessive memory usage by overwriting older interim 729 accounting data with newer data for the same session rather than 730 accumulating interim data in the buffer. 732 6.2.3. Non-volatile storage 734 Since accounting data stored in memory will typically be lost in the 735 event of a device reboot or a timeout, it may be desirable to provide 736 non-volatile storage for undelivered accounting data. With the costs of 737 flash RAM declining rapidly, it is likely that network devices will be 738 capable of incorporating non-volatile storage within the next few years. 740 As described in [11], non-volatile storage may be used to store interim 741 or session records in a standard ASCII format. As with memory 742 utilization, interim accounting overwrite is desirable so as to prevent 743 excessive storage consumption. Note that the use of ASCII data 744 representation enables use of highly efficient text compression 745 algorithms that can minimize storage requirements. Such compression 746 algorithms are only typically applied to session records so as to enable 747 implementation of interim data overwrite. 749 6.2.4. State on the accounting management system 751 In order to keep track of received accounting data, accounting 752 management systems may need to keep state on managed devices or 753 concurrent sessions. Since the number of devices is typically much 754 smaller than the number of concurrent sessions, it is desirable to keep 755 only per-device state if possible. 757 6.2.5. CPU requirements 759 CPU consumption of the managed and managing nodes will be proportional 760 to the complexity of the required accounting processing. Operations such 761 as ASN.1 encoding and decoding, compression/decompression, and 762 encryption/decryption can consume considerable resources, both on 763 accounting clients and servers. 765 The effect of these operations on accounting system reliability should 766 not be under-estimated, particularly in the case of devices with 767 moderate CPU resources. In the event that devices are over-taxed by 768 accounting tasks, it is likely that overall device reliability will 769 suffer. 771 6.2.6. Efficiency measures 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | | | 775 | Resource | Efficiency measures | 776 | | | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | | | 779 | Network | Batching | 780 | Bandwidth | Compression | 781 | | | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | | | 784 | Memory | Compression | 785 | | Interim accounting overwrite | 786 | | | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | | | 789 | Non-volatile | Compression | 790 | Storage | Interim accounting overwrite | 791 | | | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | | | 794 | System | Per-device state | 795 | state | | 796 | | | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | | | 799 | CPU | Hardware assisted | 800 | requirements | compression/encryption | 801 | | | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 6.3. Data collection models 806 Several data collection models are currently in use today for the 807 purposes of accounting data collection. These include: 809 Polling model 810 Event-driven model 811 Event-driven polling model 813 6.3.1. Polling model 815 In the polling model, an accounting manager will poll devices for 816 accounting information at regular intervals. In order to ensure against 817 loss of data, the polling interval will need to be shorter than the 818 maximum time that accounting data can be stored on the polled device. 819 For devices without non-volatile stage, this is typically determined by 820 available memory; for devices with non-volatile storage the maximum 821 polling interval is determined by the size of non-volatile storage. 823 The polling model results in an accumulation of data within individual 824 devices, and as a result, data is typically transferred to the 825 accounting manager in a batch, resulting in an efficient transfer 826 process. In terms of Accounting Manager state, polling systems scale 827 with the number of managed devices, and system bandwidth usage scales 828 with the amount of data transferred. 830 Without non-volatile storage, the polling model results in loss of 831 accounting data due to device reboots, but not due to packet loss or 832 network failures of sufficiently short duration to be handled within 833 available memory. This is because the Accounting Manager will continue 834 to poll until the data is received. In situations where operational 835 difficulties are encountered, the volume of accounting data will 836 frequently increase so as to make data loss more likely. However, in 837 this case the polling model will detect the problem since attempts to 838 reach the managed devices will fail. 840 The polling model is typically not appropriate for implementation of 841 roaming services, including wireless data, internet telephony, QoS 842 provisioning or Internet access. This is because in order to retrieve 843 accounting data on roaming users, the Accounting Management station 844 would need to periodically poll the devices of all potential roaming 845 partners, most of which would not hold any relevant data. 847 Per-device state is typical of polling-based network management systems, 848 which often also carry out accounting management functions, since 849 network management systems need to keep track of the state of network 850 devices for operational purposes. 852 6.3.2. Event-driven model 854 In the event-driven model, a device will contact the accounting server 855 or manager when it is ready to transfer accounting data. Most event- 856 driven accounting systems, such as those based on RADIUS accounting, 857 described in [4], transfer only one accounting event per packet, which 858 is inefficient. 860 Without non-volatile storage, a pure event-driven model only stores 861 individual accounting events that have not yet been delivered and as a 862 result it has the smallest memory requirements of any of the models. 863 However, the event-driven model is also the least reliable, since 864 accounting data loss will occur due to device reboots, sustained packet 865 loss, or network failures of duration greater than the timeout interval. 866 Since accounting servers will not receive events if operational 867 difficulties are encountered, event-driven accounting systems are not 868 very useful in monitoring of device health. 870 The event-driven model is frequently used for implementation of roaming 871 services, since this model allows accounting data to be sent to the 872 roaming partners with low processing delay. This permits application of 873 fraud prevention techniques. However, because roaming accounting events 874 are frequently of high value, the poor reliability of this model is an 875 issue. As a result, the event-driven polling model may be more 876 appropriate. 878 Per-session state is typical of event-driven systems without batching, 879 and as a result, a pure event-driven approach is to be avoided wherever 880 possible. 882 6.3.3. Event-driven polling model 884 In the event-driven polling model an accounting manager will poll the 885 device for accounting data only when it receives an event. The 886 accounting client can generate an event when a batch of a given size has 887 been gathered, when data of a certain type is available or after a 888 minimum time period has elapsed. Note that while transfer efficiency 889 will increase with batch size, without non-volatile storage, the 890 potential data loss from a device reboot will also increase. 892 Without non-volatile storage, an event-driven polling model will lose 893 data due to device reboots, but not due to packet loss, or network 894 partitions of short-duration. Unless a minimum delivery interval is set, 895 event-driven polling systems are not useful in monitoring of device 896 health. 898 The event-driven polling model can be highly suitable for use in roaming 899 since it permits accounting data to be sent to the roaming partners with 900 low processing delay. At the same time non-roaming accounting can be 901 handled via more efficient polling techniques, thereby providing the 902 best of both worlds. 904 Where batching can be implemented the state required in event-driven 905 polling can be reduced to scale with the number of active devices. If 906 portions of the network vary widely in usage, then this state may 907 actually be less than that of the polling approach. 909 6.3.4. Data collection summary 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | | | | 913 | Model | Pros | Cons | 914 | | | | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | | | | 917 | Polling | Per-device state | Not robust | 918 | | Robust against | against device | 919 | | packet loss | reboot, server | 920 | | Batch transfers | or network | 921 | | | failures* | 922 | | | Polling interval | 923 | | | determined by | 924 | | | storage limit | 925 | | | High processing | 926 | | | delay | 927 | | | Unsuitable for | 928 | | | use in roaming | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | | | | 931 | Event-driven | Low processing | Not robust | 932 | | delay | against packet | 933 | | Suitable for | loss, device | 934 | | use in roaming | reboot, or | 935 | | | network | 936 | | | failures* | 937 | | | Low efficiency | 938 | | | Per-session state| 939 | | | | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | | | | 942 | Event-driven | Low processing | Not robust | 943 | polling | delay | against device | 944 | | Suitable for use | reboot, network | 945 | | in roaming | failures* | 946 | | Batch transfers | | 947 | | | | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 Key 951 * = non-volatile storage needed to address this 953 7. Review of existing accounting protocols 955 Accounting systems have been successfully implemented using protocols 956 such as RADIUS, TACACS+, and SNMP. This section describes the 957 characteristic of each of these protocols, as well as transfer protocols 958 such as HTTP, FTP, and SMTP. For a review of accounting attributes and 959 record formats, see [45]. 961 7.1. Accounting protocols 963 7.1.1. RADIUS 965 RADIUS accounting, described in [4], was developed as an add-on to the 966 RADIUS authentication protocol, described in [3]. As a result, RADIUS 967 accounting shares the event-driven approach of RADIUS authentication, 968 without support for batching or polling. As a result, RADIUS accounting 969 scales with the number of accounting events instead of the number of 970 devices, and accounting transfers are inefficient. In addition, since 971 RADIUS accounting is based on UDP and timeout and retry parameters are 972 not specified, implementations vary widely in their approach to 973 reliability, with some implementations retrying until delivery or buffer 974 exhaustion, and others losing accounting data after a few retries. 976 As a result, RADIUS accounting implementations are vulnerable to packet 977 loss as well as network failures and device reboots. These deficiencies 978 are magnified when RADIUS accounting is applied in inter-domain 979 accounting as is required in roaming, as noted in [1] and [2]. On the 980 other hand, the event-driven approach of RADIUS accounting is well 981 suited to handling of accounting events which require low processing 982 delay, such as is required for credit risk management or fraud 983 detection. 985 While RADIUS accounting does provide hop-by-hop authentication and 986 integrity protection, and IPSEC can be employed to provide hop-by-hop 987 confidentiality, data object security is not supported, and thus systems 988 based on RADIUS accounting are not capable of being deployed with 989 untrusted proxies, or in situations requiring non-repudiation, as noted 990 in [2]. 992 While in principle extensible with the definition of new attributes, 993 RADIUS suffers from the very small standard attribute space (256 994 attributes). 996 7.1.2. TACACS+ 998 TACACS+ as defined in [26] offers an accounting model with start, stop, 999 and interim update messages. Since TACACS+ is based on TCP, 1000 implementations are typically resilient against packet loss and short- 1001 lived network partitions, and TACACS+ scales with the number of devices. 1002 TACACS+ does not support batching, and as a result, is suitable for 1003 handling of accounting events that require moderate though not the 1004 lowest processing delay, since it runs over TCP. 1006 TACACS+ provides for hop-by-hop authentication and integrity protection 1007 as well as hop-by-hop confidentiality. Data object security is not 1008 supported, and therefore systems based on TACACS+ accounting are not 1009 deployable in the presence of untrusted proxies. TACACS+ does not 1010 support non-repudiation. 1012 7.1.3. SNMP 1014 SNMP, described in [27]-[41], has been widely deployed in a wide variety 1015 of intra-domain accounting applications, typically using the polling 1016 data collection model. Since polling allows data to be collected on 1017 multiple accounting events simultaneously, this model results in per- 1018 device state, and supports batch transfers for high efficiency, thus 1019 improving scaling properties and enabling efficient transfers. Since the 1020 management agent is able to retry requests when a response is not 1021 received, such systems are resilient against packet loss or even short- 1022 lived network partitions. While polling implementations without non- 1023 volatile storage can only store accounting events up to the limits of 1024 their memory, and thus are not robust against device reboots or network 1025 failures, when combined with non-volatile storage, they can be made 1026 highly reliable. Thus, addition of support for file-based storage and 1027 subsequent transfer of SNMP-based accounting data is highly desirable. 1028 File-based storage of SNMP data is described in [43], and an FTP MIB is 1029 described in [44]. 1031 Although with SNMP v2 it is also possible support confirmed 1032 notifications, so as to implement an event-driven polling model, we are 1033 not aware of any SNMP-based accounting systems that make use of this 1034 facility. With SNMPv3, it is possible to incorporate view-based access 1035 controls, described in [40], as well as user-based security, described 1036 in [38]. As a result, SNMP v3-based accounting implementations can 1037 provide for hop-by-hop authentication, integrity and replay protection, 1038 confidentiality and access-control. They cannot however provide data- 1039 object based security required for deployment with untrusted proxies, 1040 nor does SNMPv3 support non-repudiation. 1042 Where multiple administrative domains are involved, such as in the 1043 shared use networks and roaming associations described in [1], more 1044 sophisticated access controls are often required. Since in shared use 1045 networks the same device may be accessed by multiple organizations, it 1046 is often necessary to control access to accounting data according to the 1047 user's organization. This ensures that organizations may be given 1048 access to accounting data relating to their users, but not to data 1049 relating to users of other organizations. This implies that access 1050 rights will depend not only on the element being collected, but on the 1051 identity of the user to whom that data relates. Through use of the 1052 contextName, it is possible to run multiple copies of an SNMP MIB, one 1053 for each accessing organization or context. This permits access to be 1054 controlled using the view-based access control model described in [40]. 1056 However, as the number of network devices within the shared use or 1057 roaming network grows, the polling model of data collection becomes 1058 increasingly impractical since most devices will not carry data relating 1059 to the polling organization. As a result, shared-use networks or roaming 1060 associations relying on SNMP-based accounting have generally collected 1061 data for all organizations and then sorted the resulting session records 1062 for delivery to each organization. While functional, this approach will 1063 typically result in increased processing delay as the number of 1064 organizations and data records grows. 1066 7.2. Accounting data transfer 1068 In order for session records to be transmitted between accounting 1069 servers, a transfer protocol is required. Transfer protocols in use 1070 today include SMTP, FTP, and HTTP. 1072 7.2.1. SMTP-based accounting record transfer 1074 To date, few accounting management systems have been built on SMTP since 1075 the implementation of a store-and-forward message system has 1076 traditionally required access to non-volatile storage which has to date 1077 not been widely available on network devices. However, an examination 1078 of the characteristics of SMTP-based implementations reveals that they 1079 possess many desirable characteristics. 1081 Accounting management systems using SMTP for accounting transfer will 1082 typically support batching so that message processing overhead will be 1083 spread over multiple accounting records. As a result, these systems 1084 result in per-active device state. Since accounting systems using SMTP 1085 as a transfer mechanism have access to substantial non-volatile storage, 1086 they can generate, compress if necessary, and store accounting records 1087 until they are transferred to the collection site. As a result, 1088 accounting systems implemented using SMTP can be highly efficient and 1089 scalable. Using IPSEC, TLS or Kerberos, hop-by-hop security services 1090 such as authentication, integrity protection and confidentiality can be 1091 provided. 1093 As described in [13] and [15], data object security is available for 1094 SMTP, and in addition, the facilities described in [12] make it possible 1095 to request and receive signed receipts, which enables non-repudiation as 1096 described in [12]-[18]. As a result, accounting systems utilizing SMTP 1097 for accounting data transfer are capable of satisfying the most 1098 demanding security requirements. However, such systems are not typically 1099 capable of providing low processing delay, although this may be 1100 addressed by the enhancements described in [20]. 1102 7.2.2. Other transfer mechanisms 1104 File transfer protocols such as FTP and HTTP have been used for transfer 1105 of accounting data. For example, Reference [9] describes a means for 1106 representing ASN.1-based accounting data for storage on archival media. 1107 Through the use of the Bulk File MIB, described in [43], accounting data 1108 from an SNMP MIB can be stored in ASN.1, bulk binary or Bulk ascii 1109 format, and then subsequently retrieved as required using the FTP Client 1110 MIB described in [44]. 1112 Given access to sufficient non-volatile storage, accounting systems 1113 based on record formats and transfer protocols can avoid loss of data 1114 due to long-duration network partitions, server failures or device 1115 reboots. Since it is possible for the transfer to be driven from the 1116 collection site, the collector can retry transfers until successful, or 1117 with HTTP may even be able to restart partially completed transfers. As 1118 a result, file transfer-based systems can be made highly reliable, and 1119 the batching of accounting records makes possible efficient transfers 1120 and application of required security services with lessened overhead. 1122 8. Security issues 1124 As noted previously in this document, accounting applications vary in 1125 their security and reliability requirements. Some uses such as capacity 1126 planning may only require authentication, integrity and replay 1127 protection, and modest reliability while other applications such as 1128 inter-domain usage-sensitive billing may require the highest degree of 1129 security and reliability, since in these cases the transfer of 1130 accounting data will lead directly to the transfer of funds. 1132 Since accounting applications do not have uniform security and 1133 reliability requirements, it is not possible to devise a single 1134 accounting protocol and set of security services that will meet all 1135 needs. Rather, the goal of accounting management should be to provide a 1136 set of tools that can be used to construct accounting systems meeting 1137 the requirements of an individual application. 1139 As a result, it is important to analyze a given accounting application 1140 to ensure that the methods chosen meet the security and reliability 1141 requirements of the application. Based on the analysis given previously, 1142 it appears that existing protocols are capable of meeting the security 1143 requirements for capacity planning and non-usage sensitive billing 1144 applications. For usage sensitive billing, as well as cost allocation 1145 and auditing applications, new work is required to support the file- 1146 based storage and transfer of bulk data needed to ensure high 1147 reliability. For time sensitive applications such as those supporting 1148 fraud detection or roaming, no existing protocol simultaneously meets 1149 the requirements for high security and reliability, as well as low 1150 processing delay. A summary is given below: 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | | | | 1154 | Usage | Intra-domain | Inter-domain | 1155 | | | | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | | | | 1158 | Capacity | SNMP v3 | SNMP v3 w/ | 1159 | Planning | TACACS+ accounting | contextName | 1160 | | | | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | | | | 1163 | Non-Usage | SNMP v3 | SNMP v3 w/ | 1164 | Sensitive | RADIUS accounting | contextName | 1165 | Billing | DIAMETER accounting| | 1166 | | TACACS+ accounting | | 1167 | | | | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | | | | 1170 | | Session record | Session record | 1171 | Usage | storage and | storage | 1172 | Sensitive | file transfer | and file transfer| 1173 | Billing, | via secure | via ultra- | 1174 | cost | protocol | secure protocol | 1175 | allocation & | (i.e. FTP or HTTP | (i.e. S/MIME- | 1176 | auditing | over TLS) | based EDI with | 1177 | (no time | | receipts) | 1178 | sensitivity or | | | 1179 | roaming) | | | 1180 | | | | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | | | | 1183 | | Low overhead, | Low overhead, | 1184 | Time | event driven | event driven | 1185 | Sensitive | polling with | polling with | 1186 | Billing, | authenticity | data object | 1187 | fraud | and privacy | security and | 1188 | detection, | support | receipt support | 1189 | roaming | | | 1190 | | No existing | No existing | 1191 | | protocol | protocol | 1192 | | | | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 9. Acknowledgements 1197 The authors would like to thank Jan Melen (Ericsson), Jarmo Savolainen 1198 (Ericsson), and Glen Zorn (Microsoft) for many useful discussions of 1199 this problem space. 1201 10. References 1203 [1] Aboba, B., Lu J., Alsop J., Ding J., and W. Wang, "Review of 1204 Roaming Implementations", RFC 2194, September 1997. 1206 [2] Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming 1207 Protocols", RFC 2477, January 1999. 1209 [3] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 1210 Authentication Dial In User Service (RADIUS)", RFC 2138, April, 1211 1997. 1213 [4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. 1215 [5] Gray, J., Reuter, A., Transaction Processing: Concepts and 1216 Techniques, Morgan Kaufmann Publishers, San Francisco, California, 1217 1993. 1219 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1220 Levels", BCP 14, RFC 2119, March 1997. 1222 [7] Crocker, D., Overrell, P., "Augmented BNF for Syntax 1223 Specifications: ABNF", RFC 2234, November 1997. 1225 [8] Aboba, B., and M. Beadles, "The Network Access Identifier", 1226 RFC 2486, January 1999. 1228 [9] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Accounting 1229 Information for ATM Networks", RFC 2512, February 1999. 1231 [10] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Managed 1232 Objects for Controlling the Collection and Storage of Accounting 1233 Information for Connection-Oriented Networks", RFC 2513, February 1234 1999. 1236 [11] Aboba, B., Lidyard, D., "The Accounting Data Interchange Format 1237 (ADIF)", Internet draft (work in progress), draft-ietf-roamops- 1238 actng-05.txt, November 1998. 1240 [12] Fajman, R., "An Extensible Message Format for Message Disposition 1241 Notifications", RFC 2298, March 1998. 1243 [13] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 1244 2015, October 1996. 1246 [14] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting 1247 of Mail System Administrative Messages", RFC 1892, January 1996. 1249 [15] Galvin, J., et al. "Security Multiparts for MIME: Multi- 1250 part/Signed and Multipart/Encrypted", RFC 1847, October 1995. 1252 [16] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1253 1995. 1255 [17] Shih, C., Jansson, M., Drummond,R., "MIME-based Secure EDI", 1256 Internet draft (work in progress), draft-ietf-ediint- 1257 as1-09.txt, December 1998. 1259 [18] Shih, C., Jansson, M., Drummond, R., Yarbrough, L. "Requirements 1260 for Inter-operable Internet EDI", Internet draft (work in 1261 progress), draft-ietf-ediint-req-06.txt, December 1998. 1263 [19] Borenstein, N., Freed, N, "MIME (Multipurpose Internet Mail 1264 Extensions) Part One: Mechanisms for Specifying and Describing 1265 the Format of Internet Message Bodies", RFC 1521, December 1993. 1267 [20] Joffe, N., Wing, D., Masinter, L., "SMTP Service Extension for 1268 Immediate Delivery", Internet draft (work in progress), draft-ietf- 1269 fax-smtp-session-04.txt, August 1998. 1271 [21] Johnson, H. T., Kaplan, R. S., Relevance Lost: The Rise and Fall of 1272 Management Accounting, Harvard Business School Press, Boston, 1273 Massachusetts, 1987. 1275 [22] Horngren, C. T., Foster, G., Cost Accounting: A Managerial 1276 Emphasis. Prentice Hall, Englewood Cliffs, New Jersey, 1991. 1278 [23] Kaplan, R. S., Atkinson, Anthony A., Advanced Management 1279 Accounting, Prentice Hall, Englewood Cliffs, New Jersey, 1989. 1281 [24] Cooper, R., Kaplan, R. S., The Design of Cost Management Systems. 1282 Prentice Hall, Englewood Cliffs, New Jersey, 1991. 1284 [25] Rigney, C., Willens, S., Calhoun, P., "RADIUS Extensions", draft- 1285 ietf-radius-ext-03.txt, Internet Draft (work in progress), January 1286 1999. 1288 [26] Carrel, D., Grant, L., "The TACACS+ Protocol Version 1.78", 1289 Internet draft (work in progress), draft-grant-tacacs-02.txt, 1290 January 1997. 1292 [27] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 1293 Describing SNMP Management Frameworks", RFC 2571, April 1999. 1295 [28] Rose, M., and K. McCloghrie, "Structure and Identification of 1296 Management Information for TCP/IP-based Internets", RFC 1155, May 1297 1990. 1299 [29] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 1300 March 1991. 1302 [30] M. Rose, "A Convention for Defining Traps for use with the SNMP", 1303 RFC 1215, March 1991. 1305 [31] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 1306 of Management Information for Version 2 of the Simple Network 1307 Management Protocol (SNMPv2)", RFC 1902, January 1996. 1309 [32] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 1310 Conventions for Version 2 of the Simple Network Management Protocol 1311 (SNMPv2)", RFC 1903, January 1996. 1313 [33] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance 1314 Statements for Version 2 of the Simple Network Management Protocol 1315 (SNMPv2)", RFC 1904, January 1996. 1317 [34] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1318 Management Protocol", RFC 1157, May 1990. 1320 [35] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1321 "Introduction to Community-based SNMPv2", RFC 1901, January 1996. 1323 [36] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport 1324 Mappings for Version 2 of the Simple Network Management Protocol 1325 (SNMPv2)", RFC 1906, January 1996. 1327 [37] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 1328 Processing and Dispatching for the Simple Network Management 1329 Protocol (SNMP)", RFC 2572, April 1999. 1331 [38] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 1332 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 1333 2574, April 1999. 1335 [39] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 1336 2573, April 1999. 1338 [40] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 1339 Control Model (VACM) for the Simple Network Management Protocol 1340 (SNMP)", RFC 2575, April 1999. 1342 [41] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 1343 Operations for Version 2 of the Simple Network Management Protocol 1344 (SNMPv2)", RFC 1905, January 1996. 1346 [42] Rose, M.T., The Simple Book, Second Edition, Prentice Hall, Upper 1347 Saddle River, NJ, 1996. 1349 [43] Stewart, B., "Bulk File MIB", Internet draft (work in progress), 1350 draft-stewart-bulk-file-mib-00.txt, November 1998. 1352 [44] Stewart, B., "FTP Client MIB", Internet draft (work in progress), 1353 draft-stewart-ftp-client-mib-00.txt, November 1998. 1355 [45] Brownlee, N., "Accounting Attributes and Record Formats", Internet 1356 draft (work in progress), draft-brownlee-accounting- 1357 attributes-00.txt, May 1999. 1359 11. Author's Addresses 1361 Bernard Aboba 1362 Microsoft Corporation 1363 One Microsoft Way 1364 Redmond, WA 98052 1366 Phone: 425-936-6605 1367 EMail: bernarda@microsoft.com 1369 Jari Arkko 1370 Oy LM Ericsson Ab 1371 02420 Jorvas 1372 Finland 1374 Phone: +358 40 5079256 1375 EMail: Jari.Arkko@ericsson.com 1377 12. Full Copyright Statement 1379 Copyright (C) The Internet Society (1999). All Rights Reserved. 1380 This document and translations of it may be copied and furnished to 1381 others, and derivative works that comment on or otherwise explain it or 1382 assist in its implmentation may be prepared, copied, published and 1383 distributed, in whole or in part, without restriction of any kind, 1384 provided that the above copyright notice and this paragraph are included 1385 on all such copies and derivative works. However, this document itself 1386 may not be modified in any way, such as by removing the copyright notice 1387 or references to the Internet Society or other Internet organizations, 1388 except as needed for the purpose of developing Internet standards in 1389 which case the procedures for copyrights defined in the Internet 1390 Standards process must be followed, or as required to translate it into 1391 languages other than English. The limited permissions granted above are 1392 perpetual and will not be revoked by the Internet Society or its 1393 successors or assigns. This document and the information contained 1394 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1395 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1396 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1397 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1398 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1400 13. Expiration Date 1402 This memo is filed as , and expires December 1403 1, 1999.