idnits 2.17.1 draft-ietf-aaa-acct-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): ---------------------------------------------------------------------------- ** 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 45 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack 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 is 1 instance of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 107 has weird spacing: '...tion be measu...' == Line 602 has weird spacing: '...ible to overw...' == Line 969 has weird spacing: '...need to keep ...' == Line 1129 has weird spacing: '...section descr...' == Line 1292 has weird spacing: '...ng data relat...' == (7 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '5' is defined on line 1680, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1684, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1687, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1690, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1696, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1711, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1717, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1720, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1724, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1728, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1736, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1740, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 1743, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 1757, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 1760, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 1764, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 1767, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 1770, but no explicit reference was found in the text == Unused Reference: '32' is defined on line 1774, but no explicit reference was found in the text == Unused Reference: '33' is defined on line 1778, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 1782, but no explicit reference was found in the text == Unused Reference: '35' is defined on line 1785, but no explicit reference was found in the text == Unused Reference: '36' is defined on line 1788, but no explicit reference was found in the text == Unused Reference: '37' is defined on line 1792, but no explicit reference was found in the text == Unused Reference: '39' is defined on line 1800, but no explicit reference was found in the text == Unused Reference: '41' is defined on line 1807, but no explicit reference was found in the text == Unused Reference: '42' is defined on line 1811, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '3') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '4') (Obsoleted by RFC 2866) ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2486 (ref. '8') (Obsoleted by RFC 4282) == Outdated reference: A later version (-08) exists of draft-ietf-roamops-actng-05 ** Obsolete normative reference: RFC 2298 (ref. '12') (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 1892 (ref. '14') (Obsoleted by RFC 3462) == Outdated reference: A later version (-17) exists of draft-ietf-ediint-as1-11 == Outdated reference: A later version (-09) exists of draft-ietf-ediint-req-08 ** Obsolete normative reference: RFC 1521 (ref. '19') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) == Outdated reference: A later version (-05) exists of draft-ietf-fax-timely-delivery-00 == Outdated reference: A later version (-06) exists of draft-ietf-radius-ext-05 ** Obsolete normative reference: RFC 2571 (ref. '27') (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 1902 (ref. '31') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '32') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '33') (Obsoleted by RFC 2580) ** Obsolete normative reference: RFC 1906 (ref. '36') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (ref. '37') (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (ref. '38') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2573 (ref. '39') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (ref. '40') (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 1905 (ref. '41') (Obsoleted by RFC 3416) == Outdated reference: A later version (-04) exists of draft-ietf-aaa-accounting-attributes-00 == Outdated reference: A later version (-09) exists of draft-irtf-nmrg-snmp-tcp-01 == Outdated reference: A later version (-01) exists of draft-irtf-nmrg-snmp-compression-00 ** Obsolete normative reference: RFC 2393 (ref. '50') (Obsoleted by RFC 3173) == Outdated reference: A later version (-02) exists of draft-hornstein-snmpv3-ksm-00 == Outdated reference: A later version (-34) exists of draft-ietf-cat-kerberos-pk-init-09 == Outdated reference: A later version (-08) exists of draft-ietf-cat-kerberos-pk-cross-04 == Outdated reference: A later version (-01) exists of draft-irtf-nmrg-get-subtree-mib-00 Summary: 27 errors (**), 0 flaws (~~), 47 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AAA Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft Corporation 3 Category: Informational Jari Arkko 4 Ericsson 5 12 January 2000 David Harrington 6 Cabletron Systems Inc. 8 Introduction to Accounting Management 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. Internet- 18 Drafts are draft documents valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet-Drafts as reference material or to cite 21 them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 To view the list Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 29 The distribution of this memo is unlimited. Please send comments to the 30 authors. 32 2. Copyright Notice 34 Copyright (C) The Internet Society (2000). 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-ietf-aaa-accounting-attributes-0x.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 Accounting record production 66 5.6 Requirements summary 67 6. Scaling and reliability 68 6.1 Fault resilience 69 6.2 Resource consumption 70 6.3 Data collection models 71 7. Review of existing protocols 72 7.1 Accounting protocols 73 7.2 Accounting data transfer 74 8. Summary 75 9. Acknowledgements 76 10. References 77 11. Authors' Addresses 78 12. Copyright Statement 79 13. Expiration date 81 5. Introduction 83 The field of Accounting Management is concerned with the collection of 84 resource consumption data for the purposes of capacity and trend 85 analysis, cost allocation, auditing, and billing. This document 86 describes each of these problems, and discusses the issues involved in 87 design of modern accounting systems. 89 Since accounting applications do not have uniform security and 90 reliability requirements, it is not possible to devise a single 91 accounting protocol and set of security services that will meet all 92 needs. Thus the goal of accounting management is to provide a set of 93 tools that can be used to meet the requirements of each application. 94 This document describes the currently available tools as well as the 95 state of the art in accounting protocol design. A companion document, 96 draft-ietf-aaa-accounting-attributes-0x.txt, reviews the state of the 97 art in accounting attributes and record formats. 99 5.1. Terminology 101 This document frequently uses the following terms: 103 Accounting 104 The collection of resource consumption data for the purposes 105 of capacity and trend analysis, cost allocation, auditing, and 106 billing. Accounting management requires that resource 107 consumption be measured, rated, assigned, and communicated 108 between appropriate parties. 110 Archival accounting 111 In archival accounting, the goal is to collect all accounting 112 data, to reconstruct missing entries as best as possible in 113 the event of data loss, and to archive data for a mandated 114 time period. Legal or financial requirements frequently 115 mandate archival accounting practices, and may often dictate 116 that data be kept confidential, regardless of whether it is to 117 be used for billing purposes or not. 119 Rating The act of determining the price to be charged for use of a 120 resource. 122 Billing The act of preparing an invoice. 124 Usage sensitive billing 125 A billing process that depends on usage information to prepare 126 an invoice can be said to be usage-sensitive. In contrast, a 127 process that is independent of usage information is said to be 128 non-usage-sensitive. 130 Auditing The act of verifying the correctness of a procedure. 132 Cost Allocation 133 The act of allocating costs between entities. Note that cost 134 allocation and rating are fundamentally different processes. 135 In cost allocation the objective is typically to allocate a 136 known cost among several entities. In rating the objective is 137 to determine the amount owed. In cost allocation, the cost per 138 unit of resource may need to be determined; in rating, this is 139 typically a given. 141 Interim accounting 142 An interim accounting packet provides a snapshot of usage 143 during a user's session. It is typically implemented in order 144 to provide for partial accounting of a user's session in the 145 event of a device reboot or other network problem that 146 prevents the reception or generation of a session summary 147 packet or session record. Interim accounting packets can 148 always be summarized without the loss of information. 150 Session record 151 A session record represents a summary of the resource 152 consumption of a user over the entire session. Accounting 153 gateways creating the session record may do so by processing 154 interim accounting events or accounting events from several 155 devices serving the same user. 157 Accounting Protocol 158 A protocol used to convey data for accounting purposes. 160 Intra-domain accounting 161 Intra-domain accounting involves the collection of information 162 on resource usage within an administrative domain, for use 163 within that domain. In intra-domain accounting, accounting 164 packets and session records typically do not cross 165 administrative boundaries. 167 Inter-domain accounting 168 Inter-domain accounting involves the collection of information 169 on resource usage within an administrative domain, for use 170 within another administrative domain. In inter-domain 171 accounting, accounting packets and session records will 172 typically cross administrative boundaries. 174 Real-time accounting 175 Real-time accounting involves the processing of information on 176 resource usage within a defined time window. Time constraints 177 are typically imposed in order to limit financial risk. 179 Accounting server 180 The accounting server receives accounting data from devices 181 and translates it into session records. The accounting server 182 may also take responsibility for the routing of session 183 records to interested parties. 185 5.2. Accounting management architecture 187 The accounting management architecture involves interactions between 188 network devices, accounting servers, and billing servers. The network 189 device collects resource consumption data in the form of accounting 190 metrics. This information is then transferred to an accounting server. 191 Typically this is accomplished via an accounting protocol, although it 192 is also possible for devices to generate their own session records. 194 The accounting server then processes the accounting data received from 195 the network device. This processing may include summarization of interim 196 accounting information, elimination of duplicate data, or generation of 197 session records. 199 The processed accounting data is then submitted to a billing server, 200 which typically handles rating and invoice generation, but may also 201 carry out auditing, cost allocation, trend analysis or capacity planning 202 functions. Session records may be batched and compressed by the 203 accounting server prior to submission to the billing server in order to 204 reduce the volume of accounting data and the bandwidth required to 205 accomplish the transfer. 207 One of the functions of the accounting server is to distinguish between 208 inter and intra-domain accounting events and to route them 209 appropriately. Intra-domain accounting events are typically routed to 210 the local billing server, while inter-domain accounting events will be 211 routed to accounting servers operating within other administrative 212 domains. While it is not required that session record formats used in 213 inter and intra-domain accounting be the same, this is desirable, since 214 it eliminates translations that would otherwise be required. 216 The diagram below illustrates the accounting management architecture: 218 +------------+ 219 | | 220 | Network | 221 | Device | 222 | | 223 +------------+ 224 | 225 Accounting | 226 Protocol | 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. Each of these tasks has different requirements. 256 5.3.1. Trend analysis and capacity planning 258 In trend analysis and capacity planning, the goal is typically a 259 forecast of future usage. Since such forecasts are inherently 260 imperfect, high reliability is typically not required, and moderate 261 packet loss may be tolerable. 263 In certain cases, it may be desirable to use statistical sampling 264 techniques to reduce data collection requirements while still providing 265 the forecast with the desired statistical accuracy. Such a sampling 266 process may tolerate high packet loss as long as bias is not introduced. 268 The security requirements for trend analysis and capacity planning 269 depend on the circumstances of data collection and the sensitivity of 270 the data. Additional security services may be required when data is 271 being transferred between administrative domains. For example, when 272 information is being collected and analyzed within the same 273 administrative domain, integrity protection and authentication may be 274 used in order to guard against collection of invalid data. In inter- 275 domain applications confidentiality may be desirable to guard against 276 snooping by third parties. 278 5.3.2. Billing 280 When accounting data is used for billing purposes, the requirements 281 depend on whether the billing process is usage-sensitive or not. 283 5.3.2.1. Non-usage sensitive billing 285 Since by definition, non-usage-sensitive billing does not require usage 286 information, in theory all accounting data can be lost without affecting 287 the billing process. Of course wholesale data loss would also affect 288 other tasks such as trend analysis or auditing, so that this would still 289 be intolerable. 291 5.3.2.2. Usage-sensitive billing 293 Since usage-sensitive billing processes depend on usage information, 294 packet loss may translate directly to revenue loss. As a result, the 295 billing process may need to meet requirements arising from financial 296 reporting standards, or legal requirements, and therefore an archival 297 accounting approach may be required. 299 Usage-sensitive systems may also have additional requirements relating 300 to processing delay. Today credit risk is commonly managed by 301 computerized fraud detection systems that are designed to detect unusual 302 activity. While efficiency concerns might otherwise dictate batched 303 transmission of accounting data, where it is desirable to minimize 304 financial risk, a different approach may be required. 306 Since financial exposure increases with processing delay, it may be 307 necessary to transmit each event individually or to minimize batch size, 308 to require positive acknowledgment before providing service, or even to 309 utilize quality of service techniques to minimize queuing delays. 311 The degree of financial exposure is application-dependent. For dialup 312 Internet access from a local provider, charges are low and therefore the 313 risk of loss is small. However, in the case of dialup roaming or voice 314 over IP, time-based charges may be substantial and therefore the risk of 315 fraud is larger. In such situations it is highly desirable to quickly 316 detect unusual account activity, and it may be desirable for 317 authorization to depend on ability to pay. In situations where valuable 318 resources can be reserved, or where charges can be high, very large 319 bills may be rung up quickly, and processing may need to be completed 320 within a defined time window in order to limit exposure. 322 Since in usage-sensitive systems, accounting data translates into 323 revenue, the security and reliability requirements are greater. Thus 324 security services such as authentication and integrity protection are 325 frequently used, and confidentiality and non-repudiation may also be 326 desirable. 328 5.3.3. Auditing 330 With enterprise networking expenditures on the rise, interest in 331 auditing is increasing. Auditing, which is the act of verifying the 332 correctness of a procedure, commonly relies on accounting data. Auditing 333 tasks include verifying correctness of an invoice submitted by a service 334 provider, or verifying conformance to usage policy, service level 335 agreements, or security guidelines. 337 To permit a credible audit, the auditing data collection process must be 338 at least as reliable as the accounting process being used by the entity 339 that is being audited. Similarly, security policies for the audit should 340 be at least as stringent as those used in preparation of the original 341 invoice. Due to financial and legal requirements, archival accounting 342 practices are frequently required in this application. 344 Where auditing procedures are used to verify conformance to usage or 345 security policies, security services may be desired. This typically will 346 include integrity protection and authentication of accounting data, as 347 well as confidentiality and possibly data object security. In order to 348 permit response to security incidents in progress, auditing applications 349 frequently are built to operate with low processing delay. 351 5.3.4. Cost allocation 353 The application of cost allocation and billback methods by enterprise 354 customers is not yet widespread. However, with the convergence of 355 telephony and data communications, there is increasing interest in 356 applying cost allocation and billback procedures to networking costs, as 357 is now commonly practiced with telecommunications costs. 359 Cost allocation models, including traditional costing mechanisms 360 described in [21]-[23] and activity-based costing techniques described 361 in [24] are typically based on detailed analysis of usage data, and as a 362 result they are almost always usage-sensitive. Whether these techniques 363 are applied to allocation of costs between partners in a venture or to 364 allocation of costs between departments in a single firm, cost 365 allocation models often have profound behavioral and financial impacts. 366 As a result, systems developed for this purposes are typically as 367 concerned with reliable data collection and security as are billing 368 applications. Due to financial and legal requirements, archival 369 accounting practices are frequently required in this application. 371 5.4. Intra-domain and inter-domain accounting 373 Much of the initial work on accounting management has focused on intra- 374 domain accounting applications. However, with the increasing deployment 375 of services such as dialup roaming, Internet fax, Internet telephony and 376 QoS, applications requiring inter-domain accounting are becoming 377 increasingly common. 379 Inter-domain accounting differs from intra-domain accounting in several 380 important ways. Intra-domain accounting involves the collection of 381 information on resource consumption within an administrative domain, for 382 use within that domain. In intra-domain accounting, accounting packets 383 and session records typically do not cross administrative boundaries. As 384 a result, intra-domain accounting applications typically experience low 385 packet loss and involve transfer of data between trusted entities. 387 In contrast, inter-domain accounting involves the collection of 388 information on resource consumption within an administrative domain, for 389 use within another administrative domain. In inter-domain accounting, 390 accounting packets and session records will typically cross 391 administrative boundaries. As a result, inter-domain accounting 392 applications may experience substantial packet loss. In addition, the 393 entities involved in the transfers cannot be assumed to trust each 394 other. 396 Since inter-domain accounting applications involve transfers of 397 accounting data between domains, additional security measures may be 398 desirable. In addition to authentication and integrity protection, it 399 may be desirable to deploy security services such as confidentiality, 400 replay protection, data object integrity, or non-repudiation. In inter- 401 domain accounting each involved party also typically requires a copy of 402 each accounting event for invoice generation and auditing. 404 5.5. Accounting record production 406 Typically, a single accounting record is produced per session, or in 407 some cases, a set of interim records which can be summarized in a single 408 record for billing purposes. However, to support deployment of services 409 such as wireless access or complex billing regimes, a more sophisticated 410 approach is required. 412 It is necessary to generate several accounting records from a single 413 session when pricing changes during a session. For instance, the price 414 of a service can be higher during peak hours than off-peak. For a 415 session continuing from one tariff period to another, it becomes 416 necessary for a device to report "packets sent" during both periods. 418 However, time is not the only factor requiring this approach. For 419 instance, in mobile access networks the user may roam from one place to 420 another while still being connected in the same session. If roaming 421 causes a change in the tariffs, it is necessary to account for resource 422 consumed in the first and second areas. Another example is where 423 modifications are allowed to an ongoing session. For example, it is 424 possible that a session could be re-authorized with improved QoS. This 425 would require production of accounting records at both QoS levels. 427 These examples could be addressed by using vectors or multi-dimensional 428 arrays to represent resource consumption within a single session record. 429 For example, the vector or array could describe the resource consumption 430 for each combination of factors, e.g. one data item could be the number 431 of packets during peak hour in the area of the home operator. However, 432 such an approach seems complicated and inflexible and as a result, most 433 current systems produce a set of records from one session. To permit 434 accounting systems to tie the records together a session identifier 435 needs to be present in each of the records. 437 In most cases, the network device will determine when multiple session 438 records are needed, as the local device is aware of factors affecting 439 local tariffs, such as QoS changes and roaming. However, future systems 440 are being designed that enable the home domain to control the generation 441 of accounting records. This is of importance in inter-domain accounting 442 or when network devices do not have tariff information. The centralized 443 control of accounting record production can be realized, for instance, 444 by having authorization servers require re-authorization at certain 445 times and requiring the production of accounting records upon each re- 446 authorization. 448 In conclusion, in some cases it is necessary to produce multiple 449 accounting records from a single session. It must be possible to do 450 this without requiring the user to start a new session or re- 451 authenticate. The production of multiple records can be controlled 452 either by the network device or by the AAA server. The requirements for 453 timeliness, security and reliability in multiple record sessions are the 454 same as for single-record sessions. 456 5.6. Requirements summary 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | | | 460 | Usage | Intra-domain | Inter-domain | 461 | | | | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | | | | 464 | Capacity | Robustness | Robustness | 465 | Planning | against moderate | against high | 466 | | packet loss | packet loss | 467 | | | | 468 | | Integrity, | Integrity, | 469 | | authentication, | authentication, | 470 | | replay protection | replay protection| 471 | | [confidentiality] | confidentiality | 472 | | | | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | | | | 475 | Non-Usage | Robustness against | Robustness | 476 | Sensitive | packet loss not | against packet | 477 | Billing | required | loss not | 478 | | | required | 479 | | | | 480 | | Integrity, | Integrity, | 482 | | authentication, | authentication, | 483 | | replay protection | replay protection| 484 | | [confidentiality] | confidentiality | 485 | | | | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | | | | 488 | | Archival | Archival | 489 | Usage | accounting | accounting | 490 | Sensitive | | | 491 | Billing, | Integrity, | Integrity, | 492 | Cost | authentication, | authentication, | 493 | Allocation & | replay protection | replay protection| 494 | Auditing | [confidentiality] | confidentiality | 495 | | | [non-repudiation]| 496 | | [Bounds on | | 497 | | processing delay] | [Bounds on | 498 | | | processing delay]| 499 | | | | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Key 503 [] = optional 505 6. Scaling and reliability 507 With the continuing growth of the Internet, it is important that 508 accounting management systems be scalable and reliable. This section 509 discusses the resources consumed by accounting management systems as 510 well as the scalability and reliability properties exhibited by various 511 data collection models. 513 6.1. Fault resilience 515 As noted earlier, in applications such as usage-sensitive billing, cost 516 allocation and auditing, an archival approach to accounting is 517 frequently mandated, due to financial and legal requirements. Since in 518 such situations loss of accounting data can translate to revenue loss, 519 there is incentive to engineer a high degree of fault resilience. Faults 520 which may be encountered include: 522 Packet loss 523 Accounting server failures 524 Network failures 525 Device reboots 527 To date, much of the debate on accounting reliability has focussed on 528 resilience against packet loss and the differences between UDP and TCP- 529 based transport. However, it should be understood that resilience 530 against packet loss is only one aspect of the program required to meet 531 archival accounting requirements. 533 As noted in [43], "once the cable is cut you don't need more 534 retransmissions, you need a *lot* nore voltage." Thus, the choice of 535 UDP or TCP transport has no impact on resilience against faults such as 536 network partition, accounting server failures or device reboots. What 537 does provide resilience against these faults is non-volatile storage. 539 The importance of non-volatile storage in design of reliable accounting 540 systems cannot be over-emphasized. Without such storage, session- 541 oriented event-driven systems will lose data once the transmission 542 timeout has been exceeded, and batching designs will experience data 543 loss once the internal memory used for accounting data storage has been 544 exceeded. 546 It may even be argued that non-volatile storage is more important to 547 accounting reliability than network connectivity, since for many years 548 reliable accounting systems were implemented based solely on physical 549 storage, without any network connectivity. For example, phone usage data 550 used to be stored on paper, film, or magnetic media and carried from the 551 place of collection to a central location for bill processing. 553 6.1.1. Interim accounting 555 Interim accounting provides protection against loss of session summary 556 data by providing checkpoint information that can be used to reconstruct 557 the session record in the event that the session summary information is 558 lost. This technique may be applied to any data collection model (i.e. 559 event-driven or polling) and is supported in both RADIUS [25] and in 560 TACACS+ [26]. 562 While interim accounting can provide resilience against packet loss, 563 server failures, short-duration network failures, or device reboot, its 564 applicability is limited. Interim accounting should not be thought of 565 as a mainstream reliability improvement technique since it increases use 566 of network bandwidth in normal operation, while providing benefits only 567 in the event of a fault. 569 Since most packet loss on the Internet is due to congestion, sending 570 interim accounting data over the wire can make the problem worse by 571 increasing bandwidth usage. Therefore on-the-wire interim accounting is 572 best restricted to high-value accounting data such as information on 573 long-lived sessions. To protect against loss of data on such sessions, 574 the interim reporting interval is typically set several standard 575 deviations larger than the average session duration. This ensures that 576 most sessions will not result in generation of interim accounting events 577 and the additional bandwidth consumed by interim accounting will be 578 limited. However, as the interim accounting interval decreases toward 579 the average session time, the additional bandwidth consumed by interim 580 accounting increases markedly, and as a result, the interval must be set 581 with caution. 583 Where non-volatile storage is unavailable, interim accounting can also 584 result in excessive consumption of memory that could be better allocated 585 to storage of session data. As a result, implementors should be careful 586 to ensure that new interim accounting data overwrites previous data 587 rather than accumulating additional interim records thereby worsening 588 the buffer exhaustion problem. 590 Given the decreasing cost of non-volatile memory, it may be preferable 591 to store interim accounting data in non-volatile storage. Stored interim 592 events are then replaced by session data when the session completes, and 593 the session data can itself be erased once the data has been 594 transmitted. This approach avoids interim data being transmitted over 595 the wire, except in the case of a device reboot. 597 6.1.2. Multiple record sessions 599 Generation of multiple accounting records within a session can introduce 600 scalability problems that cannot be controlled using the techniques 601 available in interim accounting. In the case of interim records kept in 602 non-volatile storage, it is possible to overwrite previous interim 603 records with the most recent one or summarize them to a session record. 604 Where interim updates are sent over the wire, it is possible to control 605 bandwidth usage by adjusting the interim accounting interval. 607 These measures are not applicable where multiple non-interim accounting 608 records are produced from a single session, since these records cannot 609 be summarized or overwritten without loss of information. As a result, 610 multiple record production can result in increased consumption of 611 bandwidth and memory. Implementors should be careful to ensure that 612 worst-case multiple record processing requirements do not exceed the 613 capabilities of their systems. 615 As an example, a tariff change at a particular time of day could, if 616 implemented carelessly, create a sudden peak in the consumption of 617 memory and bandwidth as the records need to be stored and/or 618 transported. Rather than attempting to send all of the records at once, 619 it may be desirable to keep them in non-volatile storage and send all of 620 the related records together in a batch when the session completes. It 621 may also be desirable to shape the accounting traffic flow so as to 622 reduce the peak bandwidth consumption. This can be accomplished by 623 introduction of a randomized delay interval. If the home domain can 624 also control the generation of multiple accounting records, the 625 estimation of the worst-case processing requirements can be very 626 difficult. 628 6.1.3. Packet loss 630 As packet loss is a fact of life on the Internet, accounting protocols 631 dealing with session data need to be resilient against packet loss. This 632 is particularly important in inter-domain accounting, where packets 633 often pass through Network Access Points (NAPs) where packet loss may be 634 substantial. Resilience against packet loss can be accomplished via 635 implementation of a retry mechanism on top of UDP, or use of TCP. On- 636 the-wire interim accounting provides only limited benefits in mitigating 637 the effects of packet loss. 639 UDP-based transport is frequently used in accounting applications. 640 However, this is not appropriate in all cases. Where accounting data 641 will not fit within a single UDP packet without fragmentation, use of 642 TCP transport may be preferred to use of multiple round-trips in UDP. As 643 noted in [47] and [49], this may be an issue in the retrieval of large 644 tables. 646 In addition, in cases where congestion is likely, such as in inter- 647 domain accounting, TCP congestion control and round-trip time estimation 648 will be very useful, optimizing throughput. In applications which 649 require maintenance of session state, such as simultaneous usage 650 control, TCP as well as application-layer keep alive packets provide a 651 mechanism for keeping track of session state. 653 When implementing UDP retransmission, there are a number of issues to 654 keep in mind: 656 Data model 657 Retry behavior 658 Congestion control 659 Timeout behavior 661 Accounting reliability can be influenced by how the data is modelled. 662 For example, it is almost always preferrable to use cumulative variables 663 rather than expressing accounting data in terms of a change from a 664 previous data item. With cumulative data, the current state can be 665 recovered by a successful retrieval, even after many packets have been 666 lost. However, if the data is transmitted as a change then the state 667 will not be recovered until the next cumulative update is sent. Thus, 668 such implementations are much more vulnerable to packet loss, and should 669 be avoided wherever possible. 671 In designing a UDP retry mechanism, it is important that the retry 672 timers relate to the round-trip time, so that retransmissions will not 673 typically occur within the period in which acknowledgements may be 674 expected to arrive. Accounting bandwidth may be significant in some 675 circumstances, so that the added traffic due to unnecessary 676 retransmissions may increase congestion levels. 678 Congestion control in accounting data transfer is a somewhat 679 controversial issue. Since accounting traffic is often considered 680 mission-critical, it has been argued that congestion control is not a 681 requirement; better to let other less-critical traffic back off in 682 response to congestion. Moreover, without non-volatile storage, 683 congestive backoff in accounting applications can result in data loss 684 due to buffer exhaustion. 686 However, there are very persuasive arguments that in modern accounting 687 implementations, it is possible to implement congestion control while 688 improving throughput and maintaining high reliability. 690 In circumstances where there is sustained packet loss, there simply is 691 not sufficient capacity to maintain existing transmission rates. Thus, 692 aggregate throughput will actually improve if congestive backoff is 693 implemented. This is due to elimination of retransmissions and ability 694 to utilize techniques such as RED to desynchronize flows. In addition, 695 with QoS mechanisms such as differentiated services, it is possible to 696 mark accounting packets for preferential handling so as to provide for 697 lower packet loss if desired. Thus considerable leeway is available to 698 the network administrator in controlling the treatment of accounting 699 packets and hard coding inelastic behavior is unnecessary. Typically, 700 systems implementing non-volatile storage allow for backlogged 701 accounting data to be placed in non-volatile storage pending 702 transmission, so that buffer exhaustion resulting from congestive 703 backoff need not be a concern. 705 Since UDP is not really a transport protocol, UDP-based accounting 706 protocols such as [4] often do not prescribe timeout behavior. Thus 707 implementations may exhibit widely different behavior. For example, one 708 implementation may drop accounting data after three constant duration 709 retries to the same server, while another may implement exponential 710 backoff to a given server, then switch to another server, up to a total 711 timeout interval of twelve hours, while storing the untransmitted data 712 on non-volatile storage. The difference between these approaches is like 713 night and day. For example, the former approach will not satisfy 714 archival accounting requirements while the latter may. 716 6.1.4. Accounting server failures 718 In the event of an accounting server failure, it may not be possible for 719 a device to transmit accounting data to its primary accounting server. 720 For protocols using TCP, opening of a connection to the secondary 721 accounting server can occur after a timeout or loss of the primary 722 connection, or it can occur on expiration of a timer. For protocols 723 using UDP, transmission to the secondary server can occur after a number 724 of retries or timer expiration. In either case, it is possible for the 725 primary and secondary accounting servers to receive the same record, so 726 that elimination of duplicates is required. 728 Since accounting server failures can result in data accumulation on 729 accounting clients, use of non-volatile storage can ensure against the 730 loss of such data due to transmission timeouts or buffer exhaustion. 732 On-the-wire interim accounting provides only limited benefits in 733 mitigating the effects of accounting server failures. 735 6.1.5. Network failures 737 Network failures may result in partial or complete loss of connectivity 738 for the accounting client. In the event of partial connectivity loss, it 739 may not be possible to reach the primary accounting server, in which 740 case switchover to the secondary accounting server is necessary. In the 741 event of a network partition, it may be necessary to store accounting 742 events in device memory or non-volatile storage until connectivity can 743 be re-established. 745 As with accounting server failures, on-the-wire interim accounting 746 provides only limited benefits in mitigating the effects of network 747 failures. 749 6.1.6. Device reboots 751 In the event of a device reboot, it is desirable to minimize the loss of 752 data on sessions in progress. Such losses may be significant even if the 753 devices themselves are very reliable, due to long-lived sessions, which 754 can comprise a significant fraction of total resource consumption. 755 Sending interim accounting data over the wire is typically implemented 756 to guard against loss of these high-value sessions. When interim 757 accounting is combined with non-volatile storage it becomes possible to 758 guard against data loss in much shorter sessions. This is possible since 759 interim accounting data need only be stored in non-volatile memory until 760 the session completes, at which time the interim data may be replaced by 761 the session record. As a result, interim accounting data need never be 762 sent over the wire, and it is possible to decrease the interim interval 763 so as to provide a very high degree of protection against data loss. 765 6.1.7. Fault resilience summary 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | | | 769 | Fault | Counter-measures | 770 | | | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | | | 773 | Packet | Retransmission based on RTT | 774 | loss | Congestion control | 775 | | Well-defined timeout behavior | 776 | | Duplicate elimination | 777 | | Interim accounting* | 778 | | Non-volatile storage | 779 | | Cumulative variables | 780 | | | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | | | 783 | Accounting | Primary-secondary servers | 784 | server & net | Duplicate elimination | 785 | failures | Interim accounting* | 786 | | Non-volatile storage | 787 | | | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | | | 790 | Device | Interim accounting* | 791 | reboots | Non-volatile storage | 792 | | | 793 | | | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 Key 797 * = limited usefulness without non-volatile storage 799 6.2. Resource consumption 801 In the process of growing to meet the needs of providers and customers, 802 accounting management systems consume a variety of resources, including: 804 Network bandwidth 805 Memory 806 Non-volatile storage 807 State on the accounting management system 808 CPU on the management system and managed devices 810 In order to understand the limits to scaling of accounting management 811 systems, we examine each of these resources in turn. 813 6.2.1. Network bandwidth 815 Accounting management systems consume network bandwidth in the 816 transferring of accounting data. The network bandwidth consumed is 817 proportional to the amount of data transferred, as well as required 818 network overhead. Since accounting data for a given event may be 100 819 octets or less, if each event is transferred individually, overhead can 820 represent a considerable proportion of total bandwidth consumption. As 821 a result, it is often desirable to transfer accounting data in batches, 822 enabling network overhead to be spread over a larger payload, and 823 enabling efficient use of compression. As noted in [48], compression 824 can be enabled in the accounting protocol, or can be done at the IP 825 layer as described in [50]. 827 6.2.2. Memory 829 In accounting systems without non-volatile storage, accounting data must 830 be stored in volatile memory during the period between when it is 831 generated and when it is transferred. The resulting memory consumption 832 will depend on retry and retransmission algorithms. Since systems 833 designed for high reliability will typically wish to retry for long 834 periods, or may store interim accounting data, the resulting memory 835 consumption can be considerable. As a result, if non-volatile storage is 836 unavailable, it may be desirable to compress accounting data awaiting 837 transmission. 839 As noted earlier, implementors of interim accounting should take care to 840 ensure against excessive memory usage by overwriting older interim 841 accounting data with newer data for the same session rather than 842 accumulating interim data in the buffer. 844 6.2.3. Non-volatile storage 846 Since accounting data stored in memory will typically be lost in the 847 event of a device reboot or a timeout, it may be desirable to provide 848 non-volatile storage for undelivered accounting data. With the costs of 849 flash RAM declining rapidly, it is likely that network devices will be 850 capable of incorporating non-volatile storage within the next few years. 852 As described in [11], non-volatile storage may be used to store interim 853 or session records in a standard ASCII format. As with memory 854 utilization, interim accounting overwrite is desirable so as to prevent 855 excessive storage consumption. Note that the use of ASCII data 856 representation enables use of highly efficient text compression 857 algorithms that can minimize storage requirements. Such compression 858 algorithms are only typically applied to session records so as to enable 859 implementation of interim data overwrite. 861 6.2.4. State on the accounting management system 863 In order to keep track of received accounting data, accounting 864 management systems may need to keep state on managed devices or 865 concurrent sessions. Since the number of devices is typically much 866 smaller than the number of concurrent sessions, it is desirable to keep 867 only per-device state if possible. 869 6.2.5. CPU requirements 871 CPU consumption of the managed and managing nodes will be proportional 872 to the complexity of the required accounting processing. Operations such 873 as ASN.1 encoding and decoding, compression/decompression, and 874 encryption/decryption can consume considerable resources, both on 875 accounting clients and servers. 877 The effect of these operations on accounting system reliability should 878 not be under-estimated, particularly in the case of devices with 879 moderate CPU resources. In the event that devices are over-taxed by 880 accounting tasks, it is likely that overall device reliability will 881 suffer. 883 6.2.6. Efficiency measures 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | | | 887 | Resource | Efficiency measures | 888 | | | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | | | 891 | Network | Batching | 892 | Bandwidth | Compression | 893 | | | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | | | 896 | Memory | Compression | 897 | | Interim accounting overwrite | 898 | | | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | | | 901 | Non-volatile | Compression | 902 | Storage | Interim accounting overwrite | 903 | | | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | | | 906 | System | Per-device state | 907 | state | | 908 | | | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | | | 911 | CPU | Hardware assisted | 912 | requirements | compression/encryption | 913 | | | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 6.3. 918 Data collection models 920 Several data collection models are currently in use today for the 921 purposes of accounting data collection. These include: 923 Polling model 924 Event-driven model without batching 925 Event-driven model with batching 926 Event-driven polling model 928 6.3.1. Polling model 930 In the polling model, an accounting manager will poll devices for 931 accounting information at regular intervals. In order to ensure against 932 loss of data, the polling interval will need to be shorter than the 933 maximum time that accounting data can be stored on the polled device. 934 For devices without non-volatile stage, this is typically determined by 935 available memory; for devices with non-volatile storage the maximum 936 polling interval is determined by the size of non-volatile storage. 938 The polling model results in an accumulation of data within individual 939 devices, and as a result, data is typically transferred to the 940 accounting manager in a batch, resulting in an efficient transfer 941 process. In terms of Accounting Manager state, polling systems scale 942 with the number of managed devices, and system bandwidth usage scales 943 with the amount of data transferred. 945 Without non-volatile storage, the polling model results in loss of 946 accounting data due to device reboots, but not due to packet loss or 947 network failures of sufficiently short duration to be handled within 948 available memory. This is because the Accounting Manager will continue 949 to poll until the data is received. In situations where operational 950 difficulties are encountered, the volume of accounting data will 951 frequently increase so as to make data loss more likely. However, in 952 this case the polling model will detect the problem since attempts to 953 reach the managed devices will fail. 955 The polling model scales poorly for implementation of shared use or 956 roaming services, including wireless data, internet telephony, QoS 957 provisioning or Internet access. This is because in order to retrieve 958 accounting data for users within a given domain, the Accounting 959 Management station would need to periodically poll all devices, most of 960 which would not hold any relevant data. There are also issues with 961 latency, since use of a polling interval also implies an average latency 962 of half the polling interval, which may be too high for accounting data 963 that requires low processing delay. Thus the event-driven polling or 964 even the pure event-driven approach will be more appropriate for shared 965 use or roaming implementations. 967 Per-device state is typical of polling-based network management systems, 968 which often also carry out accounting management functions, since 969 network management systems need to keep track of the state of network 970 devices for operational purposes. These systems offer average latencies 971 equal to half the polling interval. 973 6.3.2. Event-driven model without batching 975 In the event-driven model, a device will contact the accounting server 976 or manager when it is ready to transfer accounting data. Most event- 977 driven accounting systems, such as those based on RADIUS accounting, 978 described in [4], transfer only one accounting event per packet, which 979 is inefficient. 981 Without non-volatile storage, a pure event-driven model typically stores 982 accounting events that have not yet been delivered only until the 983 timeout interval expires. As a result this model has the smallest memory 984 requirements. Once the timeout interval has expired, the accounting 985 event is lost, even if the device has sufficient buffer space to 986 continue to store it. As a result, the event-driven model is the least 987 reliable, since accounting data loss will occur due to device reboots, 988 sustained packet loss, or network failures of duration greater than the 989 timeout interval. In event-driven protocols without a "keep alive" 990 message, accounting servers cannot assume a device failure should no 991 messages arrive for an extended period. Thus, event-driven accounting 992 systems are typically not useful in monitoring of device health. 994 The event-driven model is frequently used in shared use networks and 995 roaming, since this model sends data to the recipient domains without 996 requiring them to poll a vast number of devices, most of which have no 997 relevant data. Since the event-driven model typically does not support 998 batching, it permits accounting records to be sent with low processing 999 delay, enabling application of fraud prevention techniques. However, 1000 because roaming accounting events are frequently of high value, the poor 1001 reliability of this model is an issue. As a result, the event-driven 1002 polling model may be more appropriate. 1004 Per-session state is typical of event-driven systems without batching. 1005 As a result, the pure event-driven approach scales poorly. However, 1006 event-driven systems offer the lowest latency since events are processed 1007 immediately and there is no possibility of an event requiring low 1008 latency being caught behind a batch transfer. 1010 6.3.3. Event-driven model with batching 1012 In the event-driven model with batching, a device will contact the 1013 accounting server or manager when it is ready to transfer accounting 1014 data. The device can contact the server when a batch of a given size has 1015 been gathered, when data of a certain type is available or after a 1016 minimum time period has elapsed. Such systems can transfer more than one 1017 accounting event per packet and are thus more efficient. 1019 An event-driven system with batching will store accounting events that 1020 have not yet been delivered up to the limits of memory. As a result, 1021 accounting data loss will occur due to device reboots, but not due to 1022 packet loss or network failures of sufficiently short duration to be 1023 handled within available memory. Note that while transfer efficiency 1024 will increase with batch size, without non-volatile storage, the 1025 potential data loss from a device reboot will also increase. 1027 Where event-driven systems with batching have a keep-alive interval and 1028 run over reliable transport, the accounting server can assume that a 1029 failure has occurred if no messages are received within the keep-alive 1030 interval. Thus, such implementations can be useful in monitoring of 1031 device health. 1033 Through implementation of a scheduling algorithm, event-driven systems 1034 with batching can deliver appropriate service to accounting events that 1035 require low latency. For example, high-value inter-domain accounting 1036 events could be sent immediately, thus enabling use of fraud-prevention 1037 techniques, while all other events would be batched. However, there is a 1038 possibility that an event requiring low latency will be caught behind a 1039 batch transfer in progress. Thus the maximum latency is proportional to 1040 the maximum batch size divided by the link speed. 1042 Event-driven systems with batching scale with the number of active 1043 devices. As a result this approach scales better than the pure event- 1044 driven approach, or even the polling approach, and is equivalent to the 1045 event-driven polling approach. However, it has lower latency than the 1046 event-driven polling approach, since delivery of accounting data 1047 requires fewer round-trips and events requiring low latency can be 1048 accomodated if a scheduling algorithm is employed. 1050 6.3.4. Event-driven polling model 1052 In the event-driven polling model an accounting manager will poll the 1053 device for accounting data only when it receives an event. The 1054 accounting client can generate an event when a batch of a given size has 1055 been gathered, when data of a certain type is available or after a 1056 minimum time period has elapsed. Note that while transfer efficiency 1057 will increase with batch size, without non-volatile storage, the 1058 potential data loss from a device reboot will also increase. 1060 Without non-volatile storage, an event-driven polling model will lose 1061 data due to device reboots, but not due to packet loss, or network 1062 partitions of short-duration. Unless a minimum delivery interval is set, 1063 event-driven polling systems are not useful in monitoring of device 1064 health. 1066 The event-driven polling model can be suitable for use in roaming since 1067 it permits accounting data to be sent to the roaming partners with low 1068 processing delay. At the same time non-roaming accounting can be handled 1069 via more efficient polling techniques, thereby providing the best of 1070 both worlds. 1072 Where batching can be implemented, the state required in event-driven 1073 polling can be reduced to scale with the number of active devices. If 1074 portions of the network vary widely in usage, then this state may 1075 actually be less than that of the polling approach. Note that latency in 1076 this approach is higher than in event-driven accounting with batching 1077 since at least two round-trips are required to deliver data: one for the 1078 event notification, and one for the resulting poll. 1080 6.3.5. Data collection summary 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Model | Pros | Cons | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Polling | Per-device state | Not robust | 1086 | | Robust against | against device | 1087 | | packet loss | reboot, server | 1088 | | Batch transfers | or network | 1089 | | | failures* | 1090 | | | Polling interval | 1091 | | | determined by | 1092 | | | storage limit | 1093 | | | High processing | 1094 | | | delay | 1095 | | | Unsuitable for | 1096 | | | use in roaming | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Event-driven, | Lowest processing | Not robust | 1099 | no batching | delay | against packet | 1100 | | Suitable for | loss, device | 1101 | | use in roaming | reboot, or | 1102 | | | network | 1103 | | | failures* | 1104 | | | Low efficiency | 1105 | | | Per-session state| 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Event-driven, | Single round-trip | Not robust | 1108 | with batching | latency | against device | 1109 | and | Batch transfers | reboot, network | 1110 | scheduling | Suitable for | failures* | 1111 | | use in roaming | | 1112 | | Per active device | | 1113 | | state | | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Event-driven | Batch transfers | Not robust | 1116 | polling | Suitable for | against device | 1117 | | use in roaming | reboot, network | 1118 | | Per active device | failures* | 1119 | | state | Two round-trip | 1120 | | | latency | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 Key 1124 * = addressed by non-volatile storage 1126 7. Review of existing protocols 1128 Accounting systems have been successfully implemented using protocols 1129 such as RADIUS, TACACS+, and SNMP. This section describes the 1130 characteristic of each of these protocols, as well as transfer protocols 1131 such as HTTP, FTP, and SMTP. For a review of accounting attributes and 1132 record formats, see [45]. 1134 7.1. Accounting protocols 1136 7.1.1. RADIUS 1138 RADIUS accounting, described in [4], was developed as an add-on to the 1139 RADIUS authentication protocol, described in [3]. As a result, RADIUS 1140 accounting shares the event-driven approach of RADIUS authentication, 1141 without support for batching or polling. As a result, RADIUS accounting 1142 scales with the number of accounting events instead of the number of 1143 devices, and accounting transfers are inefficient. In addition, since 1144 RADIUS accounting is based on UDP and timeout and retry parameters are 1145 not specified, implementations vary widely in their approach to 1146 reliability, with some implementations retrying until delivery or buffer 1147 exhaustion, and others losing accounting data after a few retries. Due 1148 to the lack of reliability, it is not possible to do simultaneous usage 1149 control based on RADIUS accounting alone. Typically another device data 1150 source is required, such as polling of a session MIB or a command-line 1151 session over telnet. 1153 RADIUS accounting implementations are vulnerable to packet loss as well 1154 as network failures and device reboots. These deficiencies are magnified 1155 when RADIUS accounting is applied in inter-domain accounting as is 1156 required in roaming, as noted in [1] and [2]. On the other hand, the 1157 event-driven approach of RADIUS accounting is well suited to handling of 1158 accounting events which require low processing delay, such as is 1159 required for credit risk management or fraud detection. 1161 While RADIUS accounting does provide hop-by-hop authentication and 1162 integrity protection, and IPSEC can be employed to provide hop-by-hop 1163 confidentiality, data object security is not supported, and thus systems 1164 based on RADIUS accounting are not capable of being deployed with 1165 untrusted proxies, or in situations requiring non-repudiation, as noted 1166 in [2]. 1168 While RADIUS does not suppport compression, IP compression, described in 1169 [50], can be employed to provide this. While in principle extensible 1170 with the definition of new attributes, RADIUS suffers from the very 1171 small standard attribute space (256 attributes). 1173 7.1.2. TACACS+ 1175 TACACS+ as defined in [26] offers an accounting model with start, stop, 1176 and interim update messages. Since TACACS+ is based on TCP, 1177 implementations are typically resilient against packet loss and short- 1178 lived network partitions, and TACACS+ scales with the number of devices. 1179 Since TACACS+ runs over TCP, it is suitable for simultaneous usage 1180 control and handling of accounting events that require moderate though 1181 not the lowest processing delay. 1183 TACACS+ provides for hop-by-hop authentication and integrity protection 1184 as well as hop-by-hop confidentiality. Data object security is not 1185 supported, and therefore systems based on TACACS+ accounting are not 1186 deployable in the presence of untrusted proxies. TACACS+ does not 1187 support non-repudiation. While TACACS+ does not suppport compression, 1188 IP compression, described in [50], can be employed to provide this. 1190 7.1.3. SNMP 1192 SNMP, described in [27]-[41], has been widely deployed in a wide variety 1193 of intra-domain accounting applications, typically using the polling 1194 data collection model. Since polling allows data to be collected on 1195 multiple accounting events simultaneously, this model results in per- 1196 device state. Since the management agent is able to retry requests when 1197 a response is not received, such systems are resilient against packet 1198 loss or even short-lived network partitions. While implementations 1199 without non-volatile storage can only store accounting events up to the 1200 limits of their memory, and thus are not robust against device reboots 1201 or network failures, when combined with non-volatile storage, they can 1202 be made highly reliable. With SMIv2 it is possible to support confirmed 1203 notifications, so as to implement an event-driven polling model or even 1204 an event-driven batching model. However, we are not aware of any SNMP- 1205 based accounting implementations built on these models. 1207 7.1.3.1. NMRG extensions 1209 As discussed in [49], there are a number of efficiency and latency 1210 issues that arise when using SNMP for accounting. In such applications 1211 it is often necessary for management stations to retrieve large tables. 1212 In such situations, the latency can be quite high, even with the get- 1213 bulk operation. This is because the response must fit into the largest 1214 supported packet size, requiring multiple round-trips. Unless multiple 1215 threads are employed, the transfers will be serialized and the resulting 1216 latency will be a combination of multiple round-trip times, timeout and 1217 re-ransmission delays and processing overhead, which may result in 1218 unacceptable performance. Since data may change during the course of 1219 multiple retrievals, it can be difficult to get a consistent snapshot. 1221 In addition, [49] notes that SNMP is inefficient for transfer of 1222 accounting data, due to lack of compression, use of BER encoding, 1223 transmission of redundant OID prefixes, and the "get bulk overshoot" 1224 problem. As described in [54] the overshoot problem occurs when using 1225 the getbulk PDU because the manager typically does not know the number 1226 of rows in the table. As a result, it must either request too many rows, 1227 retrieving unneeded data, or too few, resulting in the need for multiple 1228 getbulk requests. 1230 To address these issues, a number of changes to SNMP are now under 1231 discussion within the IRTF Network Management Research Group (NMRG), 1232 described in [46]. These include an SNMP-over-TCP transport mapping, 1233 described in [47]; SNMP payload compression, described in [48]; and the 1234 addition of a "get subtree" protocol operation or the subtree retrieval 1235 MIB [54]. Taken together, we will refer to these changes as the "NMRG 1236 extensions." 1238 Reference [49] also discusses file-based storage of SNMP data, as 1239 described in [43], and the FTP MIB, described in [44]. Together these 1240 MIBs enable storage of SNMP data in non-volatile storage, and subsequent 1241 transfer via SNMP. It is noted that this approach requires 1242 implementation of additional MIBs as well as FTP, and requires separate 1243 security mechanisms such as IPSEC to provide integrity protection and 1244 confidentiality for the data in transit. However, the the file-based 1245 transfer approach also has an important benefit, which is compatibility 1246 with non-volatile storage. 1248 While the NMRG extensions are attractive in the long-term, they 1249 represent significant changes to SNMP and so will take quite a while to 1250 standardize and become widely available. While an SNMP over TCP 1251 transport mapping is easily implemented, it does require SNMP agents to 1252 listen on TCP ports 161 and 162. Addition of a GetSubtree PDU implies 1253 changes to every agent that the management station will interact with. 1254 However, the subtree retrieval MIB described in [54] requires no changes 1255 to the SNMP protocol or SNMP protocol engine and thus can be implemented 1256 more easily. 1258 7.1.3.2. SNMP v3 1260 7.1.3.2.1. SNMP v3 security services 1262 SNMPv1 and SNMPv2 do not incorporate security services. With SNMPv3, it 1263 is possible to incorporate view-based access controls, described in 1264 [40], as well as user-based security, described in [38]. As a result, 1265 SNMPv3-based accounting implementations can provide for hop-by-hop 1266 authentication, integrity and replay protection, confidentiality and 1267 access-control. Though data-object security and non-repudiation are not 1268 supported in the protocol, it may be possible to support these 1269 capabilities through addition of appropriate MIB variables. 1271 A Kerberos Security Model (KSM) for SNMPv3 is described in [51]. This 1272 approach is an individual submission not yet part of any IETF WG effort. 1273 It requires storage of a key on the KDC for each device and domain, 1274 while dynamically generating a session key for conversations between 1275 domains and devices. Thus, in terms of stored keys the KSM approach 1276 scales with the sum of devices and domains, whereas in terms of dynamic 1277 session keys, it scales as the product of domains and devices. 1279 As Kerberos is extended to allow initial authentication via public key, 1280 as described in [52], and cross-realm authentication, as described in 1281 [53] the KSM will inherit these capabilities. As a result, this approach 1282 may have potential to reduce or even eliminate the shared secret 1283 management problem in the long-term. 1285 7.1.3.3. Domain-based access control in SNMP v3 1287 Domain-based access controls are required where multiple administrative 1288 domains are involved, such as in the shared use networks and roaming 1289 associations described in [1]. Since the same device may be accessed by 1290 multiple organizations, it is often necessary to control access to 1291 accounting data according to the user's organization. This ensures that 1292 organizations may be given access to accounting data relating to their 1293 users, but not to data relating to users of other organizations. 1295 In order to apply domain-based access controls, it is first necessary to 1296 identify the data subset that is to have its access controlled. Several 1297 conceptual abstractions are used for identifying subsets of data in SNMP 1298 v3. These include engines, contexts, and views. 1300 7.1.3.3.1. Engines 1302 SNMP v3 supports the use of the contextEngineID field in order to 1303 identify the engine which provides access to the data. In traditional 1304 terms, this is the agent. contextEngineID support was added in order to 1305 improve handling of mobility as well as well as to improve SNMP proxy 1306 support. Use of contextEngineID enables improved mobility, allowing the 1307 agent on my laptop to be identified independently of the IP address 1308 where it is attached to the network. In SNMP v1 and v2, different 1309 endpoint addresses imply different agents. This is not the case with 1310 SNMP v3. 1312 contextEngineID also enables proxies to identify the data origin. While 1313 in SNMP v1 and v2, the data origin is automatically assumed to be the 1314 communications endpoint (SNMP agent), with SNMP v3 it is possible to 1315 distinguish the data orgin from the communications endpoint. 1317 For example, let us assume that agent A sends a trap to manager M 1318 through agent B, who forwards it. When SNMP V3 is used, while the trap 1319 received by manager M will have a source address corresponding to agent 1320 B, contextEngineID will identify agent A as the data origin of the trap. 1321 Thus, by using contextEngineID, M can identify the data origin, no 1322 matter how many intermediate SNMP agents have forwarded it. With SNMP 1323 v1 and v2, M would need to assume that the data in the trap (from A) 1324 refers to the instrumentation of the agent at the last hop (B). 1326 7.1.3.3.2. Contexts 1328 Contexts are used to identify subsets of objects that are tied to 1329 instrumentation. These subsets are defined by the agent rather than the 1330 manager since if the manager defined them, the agent would not know how 1331 to tie the contexts to the underlying instrumentation. 1333 In SNMP v3, contextName represents a slice of the data contained within 1334 a particular engine. Contexts are defined in a dynamic table, with the 1335 names defined as read-only. The agent uses the dynamic table to tell the 1336 manager what contexts it recognizes. 1338 Contexts are commonly tied to hardware components, to logical entities 1339 related to the hardware components, or to logical services. For example, 1340 contextNames might include board5, board7, repeater1, repeater2, etc. 1342 While each context may support multiple mib modules, each contextName is 1343 limited to one instance of a particular MIB module. Thus, if multiple 1344 instances of a MIB module are required per engine, then unique 1345 contextNames must be defined. If it only makes sense to have one 1346 instance of a mib module in an engine, such as the USM userTable, such a 1347 mib will typically fall into the default context "". Note that while a 1348 mib module may allow more than one instance per engine, a given SNMP v3 1349 implementation may not support this. 1351 7.1.3.3.3. Views 1353 A view is a mask for a particular contextName (subset of data). The view 1354 identifies which objects are visible, by specifying OIDs of the subtrees 1355 involved. There is also a mechanism to allow wildcards in the OID 1356 specification. 1358 For example, it is possible to define a view that includes the RMON 1359 tables, and another view that includes only the SNMPv3 security related 1360 tables. Using these views, it is possible to allow access to the RMON 1361 view for users Joe and Josephine (the RMON administrators), and access 1362 to the SNMPv3 security tables for user Adam (the security policy 1363 administrator). 1365 Views can be setup with wildcards. For a table that is indexed using IP 1366 addresses, Joe can be allowed access to all RMON rows that are in the 1367 subnet 134.141.x.x, with Josephine given access to all rows for subnet 1368 134.200.x.x. However, for this to work the table must be indexed by the 1369 differentiating variable, since views filter at the OID level, not at 1370 the data level. It is therefore not possible to define a view that 1371 filters on the value of non-index data. In this example, were the IP 1372 address to have been used merely as a data item rather than an index, it 1373 would not be possible to utilize view-based access control to achieve 1374 the desired objective (delegation of administrative responsibility 1375 according to subnet). 1377 7.1.3.3.4. Alternative approaches 1379 In order to be able to control access to accounting data on a per-domain 1380 basis, there are several alternatives. These include use of the domain 1381 as an index, engines and proxies. 1383 7.1.3.3.4.1. Domain as index 1385 Through use of view-based access control [40], it is possible to define 1386 multiple fine-grained views of an SNMP MIB, and to assign views to 1387 specific groups of users, such that access rights to the included data 1388 elements will depend on the identity of the user making the request. 1389 For example, all users of bigco.com which are allowed access to the 1390 device would be defined in the User-based security mib (or other 1391 security model mib). For simplicity in administering access control, 1392 the users can be grouped using a vacmGroupName, e.g. bigco. A view of a 1393 subset of the data objects in the MIB can be defined in the 1394 vacmViewFamilyTreeTable. A vacmAccessTable pairs groups and views. For 1395 messages received from users in the bigco group, access would only be 1396 provided to the data permitted to be viewed by bigco users, as defined 1397 in the view family tree. This requires that each domain accessing the 1398 data be given one or more separate vacmGroupNames, an appropriate 1399 ViewTable be defined, and the vacmAccessTable be configured for each 1400 group. 1402 As the number of network devices within the shared use or roaming 1403 network grows, the polling model of data collection becomes increasingly 1404 impractical since most devices will not carry data relating to the 1405 polling organization. As a result, shared-use networks or roaming 1406 associations relying on SNMP-based accounting have generally collected 1407 data for all organizations and then sorted the resulting session records 1408 for delivery to each organization. While functional, this approach will 1409 typically result in increased processing delay as the number of 1410 organizations and data records grows. 1412 This issue can be addressed in SNMPv3 through use of view-based access 1413 control and the SNMP notification tables, using the event-driven polling 1414 approach. This permits SNMPv3-enabled devices to notify domains that 1415 have accounting data awaiting collection. 1417 However, since views filter at the OID level, not at the data level, 1418 when using views to filter by domain it is necessary to use the domain 1419 as an index. For example, a table of session data could be indexed by 1420 record number and domain, allowing a view to be defined that could 1421 restrict access to domain data to the administrators of that domain. For 1422 example, user bigco could be allowed to view data relating to users 1423 within the bigco.com domain, but user smallco would not be allowed 1424 access to this view. 1426 An advantage of using domains as an index is that this technique can be 1427 used with SNMP v1 and v2 agents as well as with v3 agents. A 1428 disadvantage is that the MIBs must be specifically designed for this 1429 purpose. Since existing MIBs rarely use the domain as an index, domain 1430 separation cannot be enabled within legacy MIBs using this technique. 1432 7.1.3.3.4.1.1. Engines 1434 Another approach is to use contextEngineID to differentiate between data 1435 within individual domains. This approach would only be feasible for use 1436 with SNMP v3, where contextEngineID is supported. Since this technique 1437 can work with existing MIBs it enables domain separation to be applied 1438 to MIBs not specifically designed with domain separation in mind. 1440 One way this can be impleented is to provide multiple SNMP agents on the 1441 same system, one for each domain, differentiated by contextEngineID. 1442 However, this approach is not very scalable, particularly if there are a 1443 large number of domains involved, since it would require multiple agent 1444 implementations each with their own separate data space. 1446 As an alternative, it may be possible to allow one engine to be known by 1447 multiple contextEngineIDs. This would require that an engine be built 1448 where the engineID MIB module is multiply-instanced with different 1449 engineID values, in different contexts. However, this was not the 1450 original intent of the authors of SNMP v3, so that doing this may 1451 introduce complications. For example, the MIB module that contains the 1452 contextEngineID may explicitly require only one instance per engine. 1454 7.1.3.3.4.1.2. Proxies 1456 Another approach is to support domain separation via use of a proxy. 1457 However, the proxy application is forbidden to provide access control at 1458 the varbind level, and is designed so that the proxy does not need to 1459 look inside the PDU of the message except to determine the 1460 contextEngineID to verify it is not destined to itself. If 1461 contextEngine == securityEngine, with other qualifications, then the 1462 message is being sent to the current engine, so it is processed locally 1463 rather than being sent to the proxy forwarder. 1465 Restrictions on use of proxies to provide access control at the varbind 1466 level also affect the ability to provide support for legacy devices. If 1467 legacy devices do not support view-based access control, then the proxy 1468 will not be able to provide this capability. 1470 Issues of legacy support also exist with the NMRG extensions. A proxy 1471 receiving a "get subtree" PDU going to a non-NMRG capable device would 1472 need to translate the "get subtree" PDU into multiple getnext or getbulk 1473 requests. This issue would also exist with the subtree retrieval MIB 1474 described in [54], since unless the legacy devices also support the 1475 subtree retrieval MIB, the proxy would encouter the "getbulk overshoot" 1476 problem. Similarly, unless a device supports SNMP over TCP transport, 1477 deployment of an NMRG-capable proxy will not provide much benefit, since 1478 the proxy will need to fall back to UDP-based getnext or getbulk 1479 operations. This will result in multiple round-trips and high latency 1480 and the risk of inconsistent tables would remain. Existing proxies are 1481 built to support only the current standard operations so that new proxy 1482 code would be needed to support these NMRG extensions. 1484 Where the product of the number of domains and devices is large, such as 1485 in inter-domain accounting applications, the number of shared secrets 1486 can get out of hand. The localized key capability in the SNMPv3 USM 1487 allows a manager to have one central key, sharing it with many agents in 1488 a localized way while preventing the agents from getting at each other's 1489 data. This can assist in cross-domain security if deployed properly. 1491 Another solution is to implement a proxy for the purposes of shared 1492 secret reduction. In such a scheme, the domains will share a secret with 1493 the proxy, and the proxy will share a secret with each of the devices. 1494 Thus the number of shared secrets will scale with the sum of the number 1495 of devices and domains rather than the product. 1497 7.1.3.4. SNMP summary 1499 Given the wealth of existing accounting-related MIBs, it is likely that 1500 SNMP will remain a popular accounting protocol for the foreseeable 1501 future. Given the SNMPv3 enhancements, it is desirable for SNMP-based 1502 intra-domain accounting implementations to upgrade to SNMPv3. Such an 1503 upgrade is virtually mandatory for inter-domain applications. 1505 With SNMPv3, it is now possible to provide hop-by-hop security services. 1506 Through use of view-based access control, it is possible for SNMPv3 to 1507 provide per-domain access controls that are backward compatible with 1508 existing MIBs. Through use of the SNMPv3 notify tables, it is possible 1509 to implement an event-driven polling model, making it possible to notify 1510 domains of available data rather than requiring them to poll for it. 1511 This is critical in shared use or roaming implementations. 1513 In inter-domain accounting, management of SNMPv3 shared secrets can be 1514 assisted by the localized key capability or via implementation of a 1515 proxy. In the long term, alternative security models such as the 1516 Kerberos Security Model may further reduce the effort required to manage 1517 security. 1519 As noted in [49], SNMP-based accounting has limitations in terms of 1520 efficiency and latency that may make it inappropriate for use in 1521 situations requiring low processing delay or low overhead. These issues 1522 can be addressed via addition of extensions currently under discussion 1523 in the IRTF Network Management Research Group (NMRG). Compatibility 1524 with non-volatile storage can be achieved via implementation of the MIBs 1525 described in [43]-[44]. 1527 Since few current MIBs support the domain as an index, it can be 1528 difficult to simulate the view-based access control capability on legacy 1529 devices. Thus where legacy devices remain it may be necessary to collect 1530 data from the devices and sort it by domain, resulting in high 1531 processing delay. Elimination of this issue would require upgrading all 1532 devices to SNMPv3, as well as implementation of the NMRG extensions. 1533 Since SNMPv3 is not widely deployed today and the NMRG extensions are 1534 still under development, this "all or nothing" approach is typically not 1535 viable in the short to medium term. 1537 7.2. Accounting data transfer 1539 In order for session records to be transmitted between accounting 1540 servers, a transfer protocol is required. Transfer protocols in use 1541 today include SMTP, FTP, and HTTP. 1543 7.2.1. SMTP-based accounting record transfer 1545 To date, few accounting management systems have been built on SMTP since 1546 the implementation of a store-and-forward message system has 1547 traditionally required access to non-volatile storage which has not been 1548 widely available on network devices. However, SMTP-based 1549 implementations have many desirable characteristics, particularly with 1550 regards to security. 1552 Accounting management systems using SMTP for accounting transfer will 1553 typically support batching so that message processing overhead will be 1554 spread over multiple accounting records. As a result, these systems 1555 result in per-active device state. Since accounting systems using SMTP 1556 as a transfer mechanism have access to substantial non-volatile storage, 1557 they can generate, compress if necessary, and store accounting records 1558 until they are transferred to the collection site. As a result, 1559 accounting systems implemented using SMTP can be highly efficient and 1560 scalable. Using IPSEC, TLS or Kerberos, hop-by-hop security services 1561 such as authentication, integrity protection and confidentiality can be 1562 provided. 1564 As described in [13] and [15], data object security is available for 1565 SMTP, and in addition, the facilities described in [12] make it possible 1566 to request and receive signed receipts, which enables non-repudiation as 1567 described in [12]-[18]. As a result, accounting systems utilizing SMTP 1568 for accounting data transfer are capable of satisfying the most 1569 demanding security requirements. However, such systems are not typically 1570 capable of providing low processing delay, although this may be 1571 addressed by the enhancements described in [20]. 1573 7.2.2. Other transfer mechanisms 1575 File transfer protocols such as FTP and HTTP have been used for transfer 1576 of accounting data. For example, Reference [9] describes a means for 1577 representing ASN.1-based accounting data for storage on archival media. 1578 Through the use of the Bulk File MIB, described in [43], accounting data 1579 from an SNMP MIB can be stored in ASN.1, bulk binary or Bulk ascii 1580 format, and then subsequently retrieved as required using the FTP Client 1581 MIB described in [44]. 1583 Given access to sufficient non-volatile storage, accounting systems 1584 based on record formats and transfer protocols can avoid loss of data 1585 due to long-duration network partitions, server failures or device 1586 reboots. Since it is possible for the transfer to be driven from the 1587 collection site, the collector can retry transfers until successful, or 1588 with HTTP may even be able to restart partially completed transfers. As 1589 a result, file transfer-based systems can be made highly reliable, and 1590 the batching of accounting records makes possible efficient transfers 1591 and application of required security services with lessened overhead. 1593 8. Summary 1595 As noted previously in this document, accounting applications vary in 1596 their security and reliability requirements. Some uses such as capacity 1597 planning may only require authentication, integrity and replay 1598 protection, and modest reliability while other applications such as 1599 inter-domain usage-sensitive billing may require the highest degree of 1600 security and reliability, since in these cases the transfer of 1601 accounting data will lead directly to the transfer of funds. 1603 Since accounting applications do not have uniform security and 1604 reliability requirements, it is not possible to devise a single 1605 accounting protocol and set of security services that will meet all 1606 needs. Rather, the goal of accounting management should be to provide a 1607 set of tools that can be used to construct accounting systems meeting 1608 the requirements of an individual application. 1610 As a result, it is important to analyze a given accounting application 1611 to ensure that the methods chosen meet the security and reliability 1612 requirements of the application. Based on the analysis given previously, 1613 it appears that existing protocols are capable of meeting the security 1614 requirements for capacity planning and non-usage sensitive billing 1615 applications. For usage sensitive billing, as well as cost allocation 1616 and auditing applications, new work is required to support file-based 1617 storage and transfer of bulk data. Where high-value sessions are 1618 involved, such as in roaming, Mobile IP, or telephony, fraud detection 1619 support may require low processing delay. Currently, no existing 1620 protocol simultaneously meets the requirements for high security and 1621 reliability, as well as low processing delay. A summary is given below: 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | | | | 1625 | Usage | Intra-domain | Inter-domain | 1626 | | | | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 | | | | 1629 | Capacity | SNMPv1, v2, v3 | SNMPv3 | 1630 | Planning or | RADIUS accounting | | 1631 | Non-Usage | TACACS+ accounting | | 1632 | Sensitive | | | 1633 | Billing | | | 1634 | | | | 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | | Non-volatile | Non-volatile | 1637 | Usage | storage | storage | 1638 | Sensitive | | | 1639 | Billing, | SNMPv3 w/NMRG | SNMPv3 w/NMRG | 1640 | cost | extensions | extensions | 1641 | allocation & | TACACS+ accounting | | 1642 | auditing | | | 1643 | | | | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | | | | 1646 | | Non-volatile | Non-volatile | 1647 | | storage | storage | 1648 | | Low overhead, | Low overhead, | 1649 | Time | event driven | event driven | 1650 | Sensitive | batching | batching | 1651 | Billing, | Authenticity | Data object | 1652 | fraud | and privacy | security and | 1653 | detection, | support | receipt support | 1654 | roaming | | | 1655 | | No existing | No existing | 1656 | | protocol | protocol | 1657 | | | | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 9. Acknowledgements 1662 The authors would like to thank Bert Wijnen (IBM), Jan Melen (Ericsson) 1663 and Jarmo Savolainen (Ericsson) for many useful discussions of this 1664 problem space. 1666 10. References 1668 [1] Aboba, B., Lu J., Alsop J., Ding J., and W. Wang, "Review of 1669 Roaming Implementations", RFC 2194, September 1997. 1671 [2] Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming 1672 Protocols", RFC 2477, January 1999. 1674 [3] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 1675 Authentication Dial In User Service (RADIUS)", RFC 2138, April, 1676 1997. 1678 [4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. 1680 [5] Gray, J., Reuter, A., Transaction Processing: Concepts and 1681 Techniques, Morgan Kaufmann Publishers, San Francisco, California, 1682 1993. 1684 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1685 Levels", BCP 14, RFC 2119, March 1997. 1687 [7] Crocker, D., Overrell, P., "Augmented BNF for Syntax 1688 Specifications: ABNF", RFC 2234, November 1997. 1690 [8] Aboba, B., and M. Beadles, "The Network Access Identifier", 1691 RFC 2486, January 1999. 1693 [9] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Accounting 1694 Information for ATM Networks", RFC 2512, February 1999. 1696 [10] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Managed 1697 Objects for Controlling the Collection and Storage of Accounting 1698 Information for Connection-Oriented Networks", RFC 2513, February 1699 1999. 1701 [11] Aboba, B., Lidyard, D., "The Accounting Data Interchange Format 1702 (ADIF)", Internet draft (work in progress), draft-ietf-roamops- 1703 actng-05.txt, November 1998. 1705 [12] Fajman, R., "An Extensible Message Format for Message Disposition 1706 Notifications", RFC 2298, March 1998. 1708 [13] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 1709 2015, October 1996. 1711 [14] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting 1712 of Mail System Administrative Messages", RFC 1892, January 1996. 1714 [15] Galvin, J., et al. "Security Multiparts for MIME: Multi- 1715 part/Signed and Multipart/Encrypted", RFC 1847, October 1995. 1717 [16] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1718 1995. 1720 [17] Harding, T., Drummond, R., Shih, C., "MIME-based Secure EDI", 1721 Internet draft (work in progress), draft-ietf-ediint- 1722 as1-11.txt, September 1999. 1724 [18] Harding, T., Drummond, R., Shih, C., "Requirements for Inter- 1725 operable Internet EDI", Internet draft (work in progress), 1726 draft-ietf-ediint-req-08.txt, September 1999. 1728 [19] Borenstein, N., Freed, N, "MIME (Multipurpose Internet Mail 1729 Extensions) Part One: Mechanisms for Specifying and Describing 1730 the Format of Internet Message Bodies", RFC 1521, December 1993. 1732 [20] Klyne, G., "Timely Delivery for Facsimile Using Internet Mail", 1733 Internet draft (work in progress), draft-ietf-fax-timely- 1734 delivery-00.txt, October 1999. 1736 [21] Johnson, H. T., Kaplan, R. S., Relevance Lost: The Rise and Fall of 1737 Management Accounting, Harvard Business School Press, Boston, 1738 Massachusetts, 1987. 1740 [22] Horngren, C. T., Foster, G., Cost Accounting: A Managerial 1741 Emphasis. Prentice Hall, Englewood Cliffs, New Jersey, 1991. 1743 [23] Kaplan, R. S., Atkinson, Anthony A., Advanced Management 1744 Accounting, Prentice Hall, Englewood Cliffs, New Jersey, 1989. 1746 [24] Cooper, R., Kaplan, R. S., The Design of Cost Management Systems. 1747 Prentice Hall, Englewood Cliffs, New Jersey, 1991. 1749 [25] Rigney, C., Willens, S., Calhoun, P., "RADIUS Extensions", draft- 1750 ietf-radius-ext-05.txt, Internet Draft (work in progress), December 1751 1999. 1753 [26] Carrel, D., Grant, L., "The TACACS+ Protocol Version 1.78", 1754 Internet draft (work in progress), draft-grant-tacacs-02.txt, 1755 January 1997. 1757 [27] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 1758 Describing SNMP Management Frameworks", RFC 2571, April 1999. 1760 [28] Rose, M., and K. McCloghrie, "Structure and Identification of 1761 Management Information for TCP/IP-based Internets", RFC 1155, May 1762 1990. 1764 [29] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 1765 March 1991. 1767 [30] M. Rose, "A Convention for Defining Traps for use with the SNMP", 1768 RFC 1215, March 1991. 1770 [31] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 1771 of Management Information for Version 2 of the Simple Network 1772 Management Protocol (SNMPv2)", RFC 1902, January 1996. 1774 [32] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 1775 Conventions for Version 2 of the Simple Network Management Protocol 1776 (SNMPv2)", RFC 1903, January 1996. 1778 [33] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance 1779 Statements for Version 2 of the Simple Network Management Protocol 1780 (SNMPv2)", RFC 1904, January 1996. 1782 [34] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1783 Management Protocol", RFC 1157, May 1990. 1785 [35] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1786 "Introduction to Community-based SNMPv2", RFC 1901, January 1996. 1788 [36] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport 1789 Mappings for Version 2 of the Simple Network Management Protocol 1790 (SNMPv2)", RFC 1906, January 1996. 1792 [37] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 1793 Processing and Dispatching for the Simple Network Management 1794 Protocol (SNMP)", RFC 2572, April 1999. 1796 [38] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 1797 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 1798 2574, April 1999. 1800 [39] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 1801 2573, April 1999. 1803 [40] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 1804 Control Model (VACM) for the Simple Network Management Protocol 1805 (SNMP)", RFC 2575, April 1999. 1807 [41] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 1808 Operations for Version 2 of the Simple Network Management Protocol 1809 (SNMPv2)", RFC 1905, January 1996. 1811 [42] Rose, M.T., The Simple Book, Second Edition, Prentice Hall, Upper 1812 Saddle River, NJ, 1996. 1814 [43] Stewart, B., "Bulk File MIB", Internet draft (work in progress), 1815 draft-stewart-bulk-file-mib-00.txt, November 1998. 1817 [44] Stewart, B., "FTP Client MIB", Internet draft (work in progress), 1818 draft-stewart-ftp-client-mib-00.txt, November 1998. 1820 [45] Brownlee, N., Blount, A., "Accounting Attributes and Record 1821 Formats", Internet draft (work in progress), draft-ietf-aaa- 1822 accounting-attributes-00.txt, January 2000. 1824 [46] Network Management Research Group Web page, http://www.ibr.cs.tu- 1825 bs.de/projects/nmrg/ 1827 [47] Schoenwaelder, J.,"SNMP-over-TCP Transport Mapping", Internet draft 1828 (work in progress), draft-irtf-nmrg-snmp-tcp-01.txt, June 1999. 1830 [48] Schoenwaelder, J.,"SNMP Payload Compression", Internet draft (work 1831 in progress), draft-irtf-nmrg-snmp-compression-00.txt, June 1999. 1833 [49] Sprenkels, R., Martin-Flatin, J.,"Bulk Transfers of MIB Data", 1834 Simple Times, http://www.simple-times.org/pub/simple- 1835 times/issues/7-1.html, March 1999. 1837 [50] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP Payload 1838 Compression Protocol (IPComp)", RFC 2393, December 1998. 1840 [51] Hornstein, K., Hardaker, W., "A Kerberos Security Model for SNMP 1841 v3", Internet draft (work in progress), draft-hornstein- 1842 snmpv3-ksm-00.txt, June 1999. 1844 [52] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, 1845 J., Trostle, J., "Public Key Cryptography for Initial 1846 Authentication in Kerberos", Internet draft (work in progress), 1847 draft-ietf-cat-kerberos-pk-init-09.txt, June 1999. 1849 [53] Tung, B., Ryutov, T., Neuman, C., Tsudik, G., Sommerfeld, B., 1850 Medvinsky, A., Hur, M., "Public Key Cryptography for Cross-Realm 1851 Authentication in Kerberos", Internet draft (work in progress), 1852 draft-ietf-cat-kerberos-pk-cross-04.txt, June 1999. 1854 [54] Thaler, D., "Get Subtree Retrieval MIB", Internet draft (work in 1855 progress), draft-irtf-nmrg-get-subtree-mib-00.txt, October 1999. 1857 11. Author's Addresses 1859 Bernard Aboba 1860 Microsoft Corporation 1861 One Microsoft Way 1862 Redmond, WA 98052 1863 USA 1865 Phone: +1 425 936 6605 1866 EMail: bernarda@microsoft.com 1868 Jari Arkko 1869 Oy LM Ericsson Ab 1870 02420 Jorvas 1871 Finland 1873 Phone: +358 40 5079256 1874 EMail: Jari.Arkko@ericsson.com 1876 David Harrington 1877 Cabletron Systems Inc. 1878 P.O.Box 5005 1879 Rochester NH 03867-5005 1880 USA 1882 Phone: +1 603 337 7357 1883 EMail: dbh@cabletron.com 1885 12. Full Copyright Statement 1887 Copyright (C) The Internet Society (2000). All Rights Reserved. 1888 This document and translations of it may be copied and furnished to 1889 others, and derivative works that comment on or otherwise explain it or 1890 assist in its implmentation may be prepared, copied, published and 1891 distributed, in whole or in part, without restriction of any kind, 1892 provided that the above copyright notice and this paragraph are included 1893 on all such copies and derivative works. However, this document itself 1894 may not be modified in any way, such as by removing the copyright notice 1895 or references to the Internet Society or other Internet organizations, 1896 except as needed for the purpose of developing Internet standards in 1897 which case the procedures for copyrights defined in the Internet 1898 Standards process must be followed, or as required to translate it into 1899 languages other than English. The limited permissions granted above are 1900 perpetual and will not be revoked by the Internet Society or its 1901 successors or assigns. This document and the information contained 1902 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1903 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1904 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1905 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1906 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1907 13. Expiration Date 1909 This memo is filed as , and expires August 1910 1, 2000.