idnits 2.17.1 draft-aboba-acct-02.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: ---------------------------------------------------------------------------- ** 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 37 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' Introduction to Accounting Management' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 106 has weird spacing: '...tion be measu...' == Line 882 has weird spacing: '...need to keep ...' == Line 1042 has weird spacing: '...section descr...' == Line 1179 has weird spacing: '...n-based acces...' == Line 1180 has weird spacing: '...he same devic...' == (10 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (2 October 1999) is 8966 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '24' on line 1512 looks like a reference -- Missing reference section? '43' on line 1580 looks like a reference -- Missing reference section? '25' on line 1515 looks like a reference -- Missing reference section? '26' on line 1519 looks like a reference -- Missing reference section? '47' on line 1593 looks like a reference -- Missing reference section? '49' on line 1599 looks like a reference -- Missing reference section? '4' on line 1444 looks like a reference -- Missing reference section? '48' on line 1596 looks like a reference -- Missing reference section? '50' on line 1603 looks like a reference -- Missing reference section? '11' on line 1467 looks like a reference -- Missing reference section? '45' on line 1586 looks like a reference -- Missing reference section? '3' on line 1440 looks like a reference -- Missing reference section? '1' on line 1434 looks like a reference -- Missing reference section? '2' on line 1437 looks like a reference -- Missing reference section? '46' on line 1590 looks like a reference -- Missing reference section? '44' on line 1583 looks like a reference -- Missing reference section? '40' on line 1569 looks like a reference -- Missing reference section? '38' on line 1562 looks like a reference -- Missing reference section? '51' on line 1606 looks like a reference -- Missing reference section? '52' on line 1610 looks like a reference -- Missing reference section? '53' on line 1615 looks like a reference -- Missing reference section? '13' on line 1474 looks like a reference -- Missing reference section? '15' on line 1480 looks like a reference -- Missing reference section? '12' on line 1471 looks like a reference -- Missing reference section? '20' on line 1498 looks like a reference -- Missing reference section? '9' on line 1459 looks like a reference -- Missing reference section? '5' on line 1446 looks like a reference -- Missing reference section? '6' on line 1450 looks like a reference -- Missing reference section? '7' on line 1453 looks like a reference -- Missing reference section? '8' on line 1456 looks like a reference -- Missing reference section? '10' on line 1462 looks like a reference -- Missing reference section? '14' on line 1477 looks like a reference -- Missing reference section? '16' on line 1483 looks like a reference -- Missing reference section? '17' on line 1486 looks like a reference -- Missing reference section? '18' on line 1490 looks like a reference -- Missing reference section? '19' on line 1494 looks like a reference -- Missing reference section? '21' on line 1502 looks like a reference -- Missing reference section? '22' on line 1506 looks like a reference -- Missing reference section? '23' on line 1509 looks like a reference -- Missing reference section? '27' on line 1523 looks like a reference -- Missing reference section? '28' on line 1526 looks like a reference -- Missing reference section? '29' on line 1530 looks like a reference -- Missing reference section? '30' on line 1533 looks like a reference -- Missing reference section? '31' on line 1536 looks like a reference -- Missing reference section? '32' on line 1540 looks like a reference -- Missing reference section? '33' on line 1544 looks like a reference -- Missing reference section? '34' on line 1548 looks like a reference -- Missing reference section? '35' on line 1551 looks like a reference -- Missing reference section? '36' on line 1554 looks like a reference -- Missing reference section? '37' on line 1558 looks like a reference -- Missing reference section? '39' on line 1566 looks like a reference -- Missing reference section? '41' on line 1573 looks like a reference -- Missing reference section? '42' on line 1577 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 55 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft Corporation 3 Category: Informational Jari Arkko 4 Ericsson 5 2 October 1999 7 Introduction to Accounting Management 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. Internet- 17 Drafts are draft documents valid for a maximum of six months and may be 18 updated, replaced, or obsoleted by other documents at any time. It is 19 inappropriate to use Internet-Drafts as reference material or to cite 20 them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 The distribution of this memo is unlimited. It is filed as , and expires April 1, 2000. Please send comments to 30 the authors. 32 2. Copyright Notice 34 Copyright (C) The Internet Society (1999). All Rights Reserved. 36 3. Abstract 38 The field of Accounting Management is concerned with the collection of 39 resource consumption data for the purposes of capacity and trend 40 analysis, cost allocation, auditing, and billing. This document 41 describes each of these problems, and discusses the issues involved in 42 design of modern accounting systems. 44 Since accounting applications do not have uniform security and 45 reliability requirements, it is not possible to devise a single 46 accounting protocol and set of security services that will meet all 47 needs. Thus the goal of accounting management is to provide a set of 48 tools that can be used to meet the requirements of each application. 49 This document describes the currently available tools as well as the 50 state of the art in accounting protocol design. A companion document, 51 draft-brownlee-accounting-attributes-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 Requirements summary 66 6. Scaling and reliability 67 6.1 Fault resilience 68 6.2 Resource consumption 69 6.3 Data collection models 70 7. Review of existing accounting protocols 71 7.1 Accounting protocols 72 7.2 Accounting data transfer 73 8. Summary 74 9. Acknowledgements 75 10. References 76 11. Authors' Addresses 77 12. Copyright Statement 78 13. Expiration date 80 5. Introduction 82 The field of Accounting Management is concerned with the collection of 83 resource consumption data for the purposes of capacity and trend 84 analysis, cost allocation, auditing, and billing. This document 85 describes each of these problems, and discusses the issues involved in 86 design of modern accounting systems. 88 Since accounting applications do not have uniform security and 89 reliability requirements, it is not possible to devise a single 90 accounting protocol and set of security services that will meet all 91 needs. Thus the goal of accounting management is to provide a set of 92 tools that can be used to meet the requirements of each application. 93 This document describes the currently available tools as well as the 94 state of the art in accounting protocol design. A companion document, 95 draft-brownlee-accounting-attributes-0x.txt, reviews the state of the 96 art in accounting attributes and record formats. 98 5.1. Terminology 100 This document frequently uses the following terms: 102 Accounting 103 The collection of resource consumption data for the purposes 104 of capacity and trend analysis, cost allocation, auditing, and 105 billing. Accounting management requires that resource 106 consumption be measured, rated, assigned, and communicated 107 between appropriate parties. 109 Archival accounting 110 In archival accounting, the goal is to collect all accounting 111 data, to reconstruct missing entries as best as possible in 112 the event of data loss, and to archive data for a mandated 113 time period. Legal or financial requirements frequently 114 mandate archival accounting practices, and may often dictate 115 that data be kept confidential, regardless of whether it is to 116 be used for billing purposes or not. 118 Rating The act of determining the price to be charged for use of a 119 resource. 121 Billing The act of preparing an invoice. 123 Usage sensitive billing 124 A billing process that depends on usage information to prepare 125 an invoice can be said to be usage-sensitive. In contrast, a 126 process that is independent of usage information is said to be 127 non-usage-sensitive. 129 Auditing The act of verifying the correctness of a procedure. 131 Cost Allocation 132 The act of allocating costs between entities. Note that cost 133 allocation and rating are fundamentally different processes. 134 In cost allocation the objective is typically to allocate a 135 known cost among several entities. In rating the objective is 136 to determine the amount owed. In cost allocation, the cost per 137 unit of resource may need to be determined; in rating, this is 138 typically a given. 140 Interim accounting 141 An interim accounting packet provides a snapshot of usage 142 during a user's session. It is typically implemented in order 143 to provide for partial accounting of a user's session in the 144 event of a device reboot or other network problem that 145 prevents the reception of a session summary packet or session 146 record. 148 Session record 149 A session record represents a summary of the resource 150 consumption of a user over the entire session. Accounting 151 gateways creating the session record may do so by processing 152 interim accounting events or accounting events from several 153 devices serving the same user. 155 Accounting Protocol 156 A protocol used to convey data for accounting purposes. 158 Intra-domain accounting 159 Intra-domain accounting involves the collection of information 160 on resource usage within an administrative domain, for use 161 within that domain. In intra-domain accounting, accounting 162 packets and session records typically do not cross 163 administrative boundaries. 165 Inter-domain accounting 166 Inter-domain accounting involves the collection of information 167 on resource usage within an administrative domain, for use 168 within another administrative domain. In inter-domain 169 accounting, accounting packets and session records will 170 typically cross administrative boundaries. 172 Real-time accounting 173 Real-time accounting involves the processing of information on 174 resource usage within a defined time window. Time constraints 175 are typically imposed in order to limit financial risk. 177 Accounting server 178 The accounting server receives accounting data from devices 179 and translates it into session records. The accounting server 180 may also take responsibility for the routing of session 181 records to interested parties. 183 5.2. Accounting management architecture 185 The accounting management architecture involves interactions between 186 network devices, accounting servers, and billing servers. The network 187 device collects resource consumption data in the form of accounting 188 metrics. This information is then transferred to an accounting server. 189 Typically this is accomplished via an accounting protocol, although it 190 is also possible for devices to generate their own session records. 192 The accounting server then processes the accounting data received from 193 the network device. This processing may include summarization of interim 194 accounting information, elimination of duplicate data, or generation of 195 session records. 197 The processed accounting data is then submitted to a billing server, 198 which typically handles rating and invoice generation, but may also 199 carry out auditing, cost allocation, trend analysis or capacity planning 200 functions. Session records may be batched and compressed by the 201 accounting server prior to submission to the billing server in order to 202 reduce the volume of accounting data and the bandwidth required to 203 accomplish the transfer. 205 One of the functions of the accounting server is to distinguish between 206 inter and intra-domain accounting events and to route them 207 appropriately. Intra-domain accounting events are typically routed to 208 the local billing server, while inter-domain accounting events will be 209 routed to accounting servers operating within other administrative 210 domains. While it is not required that session record formats used in 211 inter and intra-domain accounting be the same, this is desirable, since 212 it eliminates translations that would otherwise be required. 214 The diagram below illustrates the accounting management architecture: 216 +------------+ 217 | | 218 | Network | 219 | Device | 220 | | 221 +------------+ 222 | 223 Accounting | 224 Protocol | 225 | 226 V 227 +------------+ +------------+ 228 | | | | 229 | Org B | Inter-domain | Org A | 230 | Acctg. |<----------------------------->| Acctg. | 231 | Server | session records | Server | 232 | | | | 233 +------------+ +------------+ 234 | | 235 | Intra-domain | 236 Transfer | session records | 237 Protocol | | 238 | | 239 V V 240 +------------+ +------------+ 241 | | | | 242 | Org B | | Org A | 243 | Billing | | Billing | 244 | Server | | Server | 245 | | | | 246 +------------+ +------------+ 248 5.3. Accounting management objectives 250 Accounting Management involves the collection of resource consumption 251 data for the purposes of capacity and trend analysis, cost allocation, 252 auditing, and billing. Each of these tasks has different requirements. 254 5.3.1. Trend analysis and capacity planning 256 In trend analysis and capacity planning, the goal is typically a 257 forecast of future usage. Since such forecasts are inherently 258 imperfect, high reliability is typically not required, and moderate 259 packet loss may be tolerable. 261 In certain cases, it may be desirable to use statistical sampling 262 techniques to reduce data collection requirements while still providing 263 the forecast with the desired statistical accuracy. Such a sampling 264 process may tolerate high packet loss as long as bias is not introduced. 266 The security requirements for trend analysis and capacity planning 267 depend on the circumstances of data collection and the sensitivity of 268 the data. Additional security services may be required when data is 269 being transferred between administrative domains. For example, when 270 information is being collected and analyzed within the same 271 administrative domain, integrity protection and authentication may be 272 used in order to guard against collection of invalid data. In inter- 273 domain applications confidentiality may be desirable to guard against 274 snooping by third parties. 276 5.3.2. Billing 278 When accounting data is used for billing purposes, the requirements 279 depend on whether the billing process is usage-sensitive or not. 281 5.3.2.1. Non-usage sensitive billing 283 Since by definition, non-usage-sensitive billing does not require usage 284 information, in theory all accounting data can be lost without affecting 285 the billing process. Of course wholesale data loss would also affect 286 other tasks such as trend analysis or auditing, so that this would still 287 be intolerable. 289 5.3.2.2. Usage-sensitive billing 291 Since usage-sensitive billing processes depend on usage information, 292 packet loss may translate directly to revenue loss. As a result, the 293 billing process may need to meet requirements arising from financial 294 reporting standards, or legal requirements, and therefore an archival 295 accounting approach may be required. 297 Usage-sensitive systems may also have additional requirements relating 298 to processing delay. Today credit risk is commonly managed by 299 computerized fraud detection systems that are designed to detect unusual 300 activity. While efficiency concerns might otherwise dictate batched 301 transmission of accounting data, where it is desirable to minimize 302 financial risk, a different approach may be required. 304 Since financial exposure increases with processing delay, it may be 305 necessary to transmit each event individually or to minimize batch size, 306 to require positive acknowledgment before providing service, or even to 307 utilize quality of service techniques to minimize queuing delays. 309 The degree of financial exposure is application-dependent. For dialup 310 Internet access from a local provider, charges are low and therefore the 311 risk of loss is small. However, in the case of dialup roaming or voice 312 over IP, time-based charges may be substantial and therefore the risk of 313 fraud is larger. In such situations it is highly desirable to quickly 314 detect unusual account activity, and it may be desirable for 315 authorization to depend on ability to pay. In situations where valuable 316 resources can be reserved, or where charges can be high, very large 317 bills may be rung up quickly, and processing may need to be completed 318 within a defined time window in order to limit exposure. 320 Since in usage-sensitive systems, accounting data translates into 321 revenue, the security and reliability requirements are greater. Thus 322 security services such as authentication and integrity protection are 323 frequently used, and confidentiality and non-repudiation may also be 324 desirable. 326 5.3.3. Auditing 328 With enterprise networking expenditures on the rise, interest in 329 auditing is increasing. Auditing, which is the act of verifying the 330 correctness of a procedure, commonly relies on accounting data. Auditing 331 tasks include verifying correctness of an invoice submitted by a service 332 provider, or verifying conformance to usage policy, service level 333 agreements, or security guidelines. 335 To permit a credible audit, the auditing data collection process must be 336 at least as reliable as the accounting process being used by the entity 337 that is being audited. Similarly, security policies for the audit should 338 be at least as stringent as those used in preparation of the original 339 invoice. Due to financial and legal requirements, archival accounting 340 practices are frequently required in this application. 342 Where auditing procedures are used to verify conformance to usage or 343 security policies, security services may be desired. This typically will 344 include integrity protection and authentication of accounting data, as 345 well as confidentiality and possibly data object security. In order to 346 permit response to security incidents in progress, auditing applications 347 frequently are built to operate with low processing delay. 349 5.3.4. Cost allocation 351 The application of cost allocation and billback methods by enterprise 352 customers is not yet widespread. However, with the convergence of 353 telephony and data communications, there is increasing interest in 354 applying cost allocation and billback procedures to networking costs, as 355 is now commonly practiced with telecommunications costs. 357 Cost allocation models, including traditional costing mechanisms 358 described in [21]-[23] and activity-based costing techniques described 359 in [24] are typically based on detailed analysis of usage data, and as a 360 result they are almost always usage-sensitive. Whether these techniques 361 are applied to allocation of costs between partners in a venture or to 362 allocation of costs between departments in a single firm, cost 363 allocation models often have profound behavioral and financial impacts. 364 As a result, systems developed for this purposes are typically as 365 concerned with reliable data collection and security as are billing 366 applications. Due to financial and legal requirements, archival 367 accounting practices are frequently required in this application. 369 5.4. Intra-domain and inter-domain accounting 371 Much of the initial work on accounting management has focused on intra- 372 domain accounting applications. However, with the increasing deployment 373 of services such as dialup roaming, Internet fax, Internet telephony and 374 QoS, applications requiring inter-domain accounting are becoming 375 increasingly common. 377 Inter-domain accounting differs from intra-domain accounting in several 378 important ways. Intra-domain accounting involves the collection of 379 information on resource consumption within an administrative domain, for 380 use within that domain. In intra-domain accounting, accounting packets 381 and session records typically do not cross administrative boundaries. As 382 a result, intra-domain accounting applications typically experience low 383 packet loss and involve transfer of data between trusted entities. 385 In contrast, inter-domain accounting involves the collection of 386 information on resource consumption within an administrative domain, for 387 use within another administrative domain. In inter-domain accounting, 388 accounting packets and session records will typically cross 389 administrative boundaries. As a result, inter-domain accounting 390 applications may experience substantial packet loss. In addition, the 391 entitities involved in the transfers cannot be assumed to trust each 392 other. 394 Since inter-domain accounting applications involve transfers of 395 accounting data between domains, additional security measures may be 396 desirable. In addition to authentication and integrity protection, it 397 may be desirable to deploy security services such as confidentiality, 398 replay protection, data object integrity, or non-repudiation. In inter- 399 domain accounting each involved party also typically requires a copy of 400 each accounting event for invoice generation and auditing. 402 5.5. Requirements summary 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | | | | 406 | Usage | Intra-domain | Inter-domain | 407 | | | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | | | | 410 | Capacity | Robustness | Robustness | 411 | Planning | against moderate | against high | 412 | | packet loss | packet loss | 413 | | | | 414 | | Integrity, | Integrity, | 415 | | authentication, | authentication, | 416 | | replay protection | replay protection| 417 | | [confidentiality] | confidentiality | 418 | | | | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | | | 421 | Non-Usage | Robustness against | Robustness | 422 | Sensitive | packet loss not | against packet | 423 | Billing | required | loss not | 424 | | | required | 425 | | | | 426 | | Integrity, | Integrity, | 427 | | authentication, | authentication, | 428 | | replay protection | replay protection| 429 | | [confidentiality] | confidentiality | 430 | | | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | | | | 433 | | Archival | Archival | 434 | Usage | accounting | accounting | 435 | Sensitive | | | 436 | Billing, | Integrity, | Integrity, | 437 | Cost | authentication, | authentication, | 438 | Allocation & | replay protection | replay protection| 439 | Auditing | [confidentiality] | confidentiality | 440 | | | [non-repudiation]| 441 | | [Bounds on | | 442 | | processing delay] | [Bounds on | 443 | | | processing delay]| 444 | | | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Key 448 [] = optional 450 6. Scaling and reliability 452 With the continuing growth of the Internet, it is important that 453 accounting management systems be scalable and reliable. This section 454 discusses the resources consumed by accounting management systems as 455 well as the scalability and reliability properties exhibited by various 456 data collection models. 458 6.1. Fault resilience 460 As noted earlier, in applications such as usage-sensitive billing, cost 461 allocation and auditing, an archival approach to accounting is 462 frequently mandated, due to financial and legal requirements. Since in 463 such situations loss of accounting data can translate to revenue loss, 464 there is incentive to engineer a high degree of fault resilience. Faults 465 which may be encountered include: 467 Packet loss 468 Accounting server failures 469 Network failures 470 Device reboots 472 To date, much of the debate on accounting reliability has focussed on 473 resilience against packet loss and the differences between UDP and TCP- 474 based transport. However, it should be understood that resilience 475 against packet loss is only one aspect of the program required to meet 476 archival accounting requirements. 478 As noted in [43], "once the cable is cut you don't need more 479 retransmissions, you need a *lot* nore voltage." Thus, the choice of 480 UDP or TCP transport has no impact on resilience against faults such as 481 network partition, accounting server failures or device reboots. What 482 does provide resilience against these faults is non-volatile storage. 484 The importance of non-volatile storage in design of reliable accounting 485 systems cannot be over-emphasized. Without such storage, session- 486 oriented event-driven systems will lose data once the transmission 487 timeout has been exceeded, and batching designs will experience data 488 loss once the internal memory used for accounting data storage has been 489 exceeded. 491 It may even be argued that non-volatile storage is more important to 492 accounting reliability than network connectivity, since for many years 493 reliable accounting systems were implemented based solely on physical 494 storage, without any network connectivity. For example, phone usage data 495 used to be stored on paper, film, or magnetic media and carried from the 496 place of collection to a central location for bill processing. 498 6.1.1. Interim accounting 500 Interim accounting provides protection against loss of session summary 501 data by providing checkpoint information that can be used to reconstruct 502 the session record in the event that the session summary information is 503 lost. This technique may be applied to any data collection model (i.e. 504 event-driven or polling) and is supported in both RADIUS [25] and in 505 TACACS+ [26]. 507 While interim accounting can provide resilience against packet loss, 508 server failures, short-duration network failures, or device reboot, its 509 applicability is limited. Interim accounting should not be thought of 510 as a mainstream reliability improvement technique since it increases use 511 of network bandwidth in normal operation, while providing benefits only 512 in the event of a fault. 514 Since most packet loss on the Internet is due to congestion, sending 515 interim accounting data over the wire can make the problem worse by 516 increasing bandwidth usage. Therefore on-the-wire interim accounting is 517 best restricted to high-value accounting data such as information on 518 long-lived sessions. To protect against loss of data on such sessions, 519 the interim reporting interval is typically set several standard 520 deviations larger than the average session duration. This ensures that 521 most sessions will not result in generation of interim accounting events 522 and the additional bandwidth consumed by interim accounting will be 523 limited. However, as the interim accounting interval decreases toward 524 the the average session time, the additional bandwidth consumed by 525 interim accounting increases markedly, and as a result, the interval 526 must be set with caution. 528 Where non-volatile storage is unavailable, interim accounting can also 529 result in excessive consumption of memory that could be better allocated 530 to storage of session data. As a result, implementors should be careful 531 to ensure that new interim accounting data overwrites previous data 532 rather than accumulating additional interim records thereby worsening 533 the buffer exhaustion problem. 535 Given the decreasing cost of non-volatile memory, it may be preferable 536 to store interim accounting data in non-volatile storage. Stored interim 537 events are then replaced by session data when the session completes, and 538 the session data can itself be erased once the data has been 539 transmitted. This approach avoids interim data being transmitted over 540 the wire, except in the case of a device reboot. 542 6.1.2. Packet loss 544 As packet loss is a fact of life on the Internet, accounting protocols 545 dealing with session data need to be resilient against packet loss. This 546 is particularly important in inter-domain accounting, where packets 547 often pass through Network Access Points (NAPs) where packet loss may be 548 substantial. Resilience against packet loss can be accomplished via 549 implementation of a retry mechanism on top of UDP, or use of TCP. On- 550 the-wire interim accounting provides only limited benefits in mitigating 551 the effects of packet loss. 553 UDP-based transport is frequently used in accounting applications. 554 However, this is not appropriate in all cases. Where accounting data 555 will not fit within a single UDP packet without fragmentation, use of 556 TCP transport may preferred to use of multiple round-trips in UDP. As 557 noted in [47] and [49], this may be an issue in the retrieval of large 558 tables. 560 In addition, in cases where congestion is likely, such as in inter- 561 domain accounting, TCP congestion control and round-trip time estimation 562 will be very useful, optimizing throughput. In applications which 563 require maintenance of session state, such as simultaneous usage 564 control, TCP as well as application-layer keep alive packets provide a 565 mechanism for keeping track of session state. 567 When implementing UDP retransmission, there are a number of issues to 568 keep in mind: 570 Data model 571 Retry behavior 572 Congestion control 573 Timeout behavior 575 Accounting reliability can be influenced by how the data is modelled. 576 For example, it is almost always preferrable to use cumulative variables 577 rather than expressing accounting data in terms of a change from a 578 previous data item. With cumulative data, the current state can be 579 recovered by a successful retrieval, even after many packets have been 580 lost. However, if the data is transmitted as a change then the state 581 will not be recovered until the next cumulative update is sent. Thus, 582 such implementations are much more vulnerable to packet loss, and should 583 be avoided wherever possible. 585 In designing a UDP retry mechanism, it is important that the retry 586 timers relate to the round-trip time, so that retransmissions will not 587 typically occur within the period in which acknowledgements may be 588 expected to arrive. Accounting bandwidth may be significant in some 589 circumstances, so that the added traffic due to unnecessary 590 retransmissions may increase congestion levels. 592 Congestion control in accounting data transfer is a somewhat 593 controversial issue. Since accounting traffic is often considered 594 mission-critical, it has been argued that congestion control is not a 595 requirement; better to let other less-critical traffic back off in 596 response to congestion. Moreover, without non-volatile storage, 597 congestive backoff in accounting applications can result in data loss 598 due to buffer exhaustion. 600 However, there are very persuasive arguments that in modern accounting 601 implementations, it is possible to implement congestion control while 602 improving throughput and maintaining high reliability. 604 In circumstances where there is sustained packet loss, there simply is 605 not sufficient capacity to maintain existing transmission rates. Thus, 606 aggregate throughput will actually improve if congestive backoff is 607 implemented. This is due to elimination of retransmissions and ability 608 to utilize techniques such as RED to desynchronize flows. In addition, 609 with QoS mechanisms such as differentiated services, it is possible to 610 mark accounting packets for preferential handling so as to provide for 611 lower packet loss if desired. Thus considerable leeway is available to 612 the network administrator in controlling the treatment of accounting 613 packets and hard coding inelastic behavior is unnecessary. Furthermore, 614 systems implementing non-volatile storage allow for backlogged 615 accounting data to be placed in permanent storage pending transmission 616 so that buffer exhaustion resulting from congestive backoff need not be 617 a major concern. 619 Since UDP is not really a transport protocol, UDP-based accounting 620 protocols such as [4] often do not prescribe timeout behavior. Thus one 621 implementations may exhibit widely different behavior. For example, one 622 implementation may drop accounting data after 3 constant duration 623 retries to the same server, while another may implement exponential 624 backoff to a given server, then switch to another server, up to a total 625 timeout interval of 12 hours, while storing the untransmitted data on 626 non-volatile storage. The difference between these approaches is like 627 night and day. For example, the former approach will not satisfy 628 archival accounting requirements while the latter may. 630 6.1.3. Accounting server failures 632 In the event of an accounting server failure, it may not be possible for 633 a device to transmit accounting data to its primary accounting server. 634 For protocols using TCP, opening of a connection to the secondary 635 accounting server can occur after a timeout or loss of the primary 636 connection, or it can occur on expiration of a timer. For protocols 637 using UDP, transmission to the secondary server can occur after a number 638 of retries or timer expiration. In either case, it is possible for the 639 primary and secondary accounting servers to receive the same record, so 640 that elimination of duplicates is required. 642 Since accounting server failures can result in data accumulation on 643 accounting clients, use of non-volatile storage can ensure against the 644 loss of such data due to transmission timeouts or buffer exhaustion. 646 On-the-wire interim accounting provides only limited benefits in 647 mitigating the effects of accounting server failures. 649 6.1.4. Network failures 651 Network failures may result in partial or complete loss of connectivity 652 for the accounting client. In the event of partial connectivity loss, it 653 may not be possible to reach the primary accounting server, in which 654 case switchover to the secondary accounting server is necessary. In the 655 event of a network partition, it may be necessary to store accounting 656 events in device memory or non-volatile storage until connectivity can 657 be re-established. 659 As with accounting server failures, on-the-wire interim accounting 660 provides only limited benefits in mitigating the effects of network 661 failures. 663 6.1.5. Device reboots 665 In the event of a device reboot, it is desirable to minimize the loss of 666 data on sessions in progress. Such losses may be significant even if the 667 devices themselves are very reliable, due to long-lived sessions, which 668 can comprise a significant fraction of total resource consumption. 669 Sending interim accounting data over the wire is typically implemented 670 to guard against loss of these high-value sessions. When interim 671 accounting is combined with non-volatile storage it becomes possible to 672 guard against data loss in much shorter sessions. This is possible since 673 interim accounting data need only be stored in non-volatile memory until 674 the session completes, at which time the interim data may be replaced by 675 the session record. As a result, interim accounting data need never be 676 sent over the wire, and it is possible to decrease the interim interval 677 so as to provide a very high degree of protection against data loss. 679 6.1.6. Fault resilience summary 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | | | 683 | Fault | Counter-measures | 684 | | | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | | | 687 | Packet | Retransmission based on RTT | 688 | loss | Congestion control | 689 | | Well-defined timeout behavior | 690 | | Duplicate elimination | 691 | | Interim accounting* | 692 | | Non-volatile storage | 693 | | Cumulative variables 694 | 695 | | | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | | | 698 | Accounting | Primary-secondary servers | 699 | server & net | Duplicate elimination | 700 | failures | Interim accounting* | 701 | | Non-volatile storage | 702 | | | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | | | 705 | Device | Interim accounting* | 706 | reboots | Non-volatile storage | 707 | | | 708 | | | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 Key 712 * = limited usefulness without non-volatile storage 714 6.2. Resource consumption 716 In the process of growing to meet the needs of providers and customers, 717 accounting management systems consume a variety of resources, including: 719 Network bandwidth 720 Memory 721 Non-volatile storage 722 State on the accounting management system 723 CPU on the management system and managed devices 725 In order to understand the limits to scaling of accounting management 726 systems, we examine each of these resources in turn. 728 6.2.1. Network bandwidth 730 Accounting management systems consume network bandwidth in the 731 transferring of accounting data. The network bandwidth consumed is 732 proportional to the amount of data transferred, as well as required 733 network overhead. Since accounting data for a given event may be 100 734 octets or less, if each event is transferred individually, overhead can 735 represent a considerable proportion of total bandwidth consumption. As 736 a result, it is often desirable to transfer accounting data in batches, 737 enabling network overhead to be spread over a larger payload, and 738 enabling efficient use of compression. As noted in [48], compression 739 can be enabled in the accounting protocol, or can be done at the IP 740 layer as described in [50]. 742 6.2.2. Memory 744 In accounting systems without non-volatile storage, accounting data must 745 be stored in volatile memory during the period between when it is 746 generated and when it is transferred. The resulting memory consumption 747 will depend on retry and retransmission algorithms. Since systems 748 designed for high reliability will typically wish to retry for long 749 periods, or may store interim accounting data, the resulting memory 750 consumption can be considerable. As a result, if non-volatile storage is 751 unavailable, it may be desirable to compress accounting data awaiting 752 transmission. 754 As noted earlier, implementors of interim accounting should take care to 755 ensure against excessive memory usage by overwriting older interim 756 accounting data with newer data for the same session rather than 757 accumulating interim data in the buffer. 759 6.2.3. Non-volatile storage 761 Since accounting data stored in memory will typically be lost in the 762 event of a device reboot or a timeout, it may be desirable to provide 763 non-volatile storage for undelivered accounting data. With the costs of 764 flash RAM declining rapidly, it is likely that network devices will be 765 capable of incorporating non-volatile storage within the next few years. 767 As described in [11], non-volatile storage may be used to store interim 768 or session records in a standard ASCII format. As with memory 769 utilization, interim accounting overwrite is desirable so as to prevent 770 excessive storage consumption. Note that the use of ASCII data 771 representation enables use of highly efficient text compression 772 algorithms that can minimize storage requirements. Such compression 773 algorithms are only typically applied to session records so as to enable 774 implementation of interim data overwrite. 776 6.2.4. State on the accounting management system 778 In order to keep track of received accounting data, accounting 779 management systems may need to keep state on managed devices or 780 concurrent sessions. Since the number of devices is typically much 781 smaller than the number of concurrent sessions, it is desirable to keep 782 only per-device state if possible. 784 6.2.5. CPU requirements 786 CPU consumption of the managed and managing nodes will be proportional 787 to the complexity of the required accounting processing. Operations such 788 as ASN.1 encoding and decoding, compression/decompression, and 789 encryption/decryption can consume considerable resources, both on 790 accounting clients and servers. 792 The effect of these operations on accounting system reliability should 793 not be under-estimated, particularly in the case of devices with 794 moderate CPU resources. In the event that devices are over-taxed by 795 accounting tasks, it is likely that overall device reliability will 796 suffer. 798 6.2.6. Efficiency measures 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | | | 802 | Resource | Efficiency measures | 803 | | | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | | | 806 | Network | Batching | 807 | Bandwidth | Compression | 808 | | | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | | | 811 | Memory | Compression | 812 | | Interim accounting overwrite | 813 | | | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | | | 816 | Non-volatile | Compression | 817 | Storage | Interim accounting overwrite | 818 | | | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | | | 821 | System | Per-device state | 822 | state | | 823 | | | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | | | 826 | CPU | Hardware assisted | 827 | requirements | compression/encryption | 828 | | | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 6.3. Data collection models 833 Several data collection models are currently in use today for the 834 purposes of accounting data collection. These include: 836 Polling model 837 Event-driven model without batching 838 Event-driven model with batching 839 Event-driven polling model 841 6.3.1. Polling model 843 In the polling model, an accounting manager will poll devices for 844 accounting information at regular intervals. In order to ensure against 845 loss of data, the polling interval will need to be shorter than the 846 maximum time that accounting data can be stored on the polled device. 847 For devices without non-volatile stage, this is typically determined by 848 available memory; for devices with non-volatile storage the maximum 849 polling interval is determined by the size of non-volatile storage. 851 The polling model results in an accumulation of data within individual 852 devices, and as a result, data is typically transferred to the 853 accounting manager in a batch, resulting in an efficient transfer 854 process. In terms of Accounting Manager state, polling systems scale 855 with the number of managed devices, and system bandwidth usage scales 856 with the amount of data transferred. 858 Without non-volatile storage, the polling model results in loss of 859 accounting data due to device reboots, but not due to packet loss or 860 network failures of sufficiently short duration to be handled within 861 available memory. This is because the Accounting Manager will continue 862 to poll until the data is received. In situations where operational 863 difficulties are encountered, the volume of accounting data will 864 frequently increase so as to make data loss more likely. However, in 865 this case the polling model will detect the problem since attempts to 866 reach the managed devices will fail. 868 The polling model scales poorly for implementation of shared use or 869 roaming services, including wireless data, internet telephony, QoS 870 provisioning or Internet access. This is because in order to retrieve 871 accounting data for users within a given domain, the Accounting 872 Management station would need to periodically poll all devices, most of 873 which would not hold any relevant data. There are also issues with 874 latency, since use of a polling interval also implies an average latency 875 of half the polling interval, which may be too high for accounting data 876 that requires low processing delay. Thus the event-driven polling or 877 even the pure event-driven approach will be more appropriate for shared 878 use or roaming implementations. 880 Per-device state is typical of polling-based network management systems, 881 which often also carry out accounting management functions, since 882 network management systems need to keep track of the state of network 883 devices for operational purposes. These systems offer average latencies 884 equal to half the polling interval. 886 6.3.2. Event-driven model without batching 888 In the event-driven model, a device will contact the accounting server 889 or manager when it is ready to transfer accounting data. Most event- 890 driven accounting systems, such as those based on RADIUS accounting, 891 described in [4], transfer only one accounting event per packet, which 892 is inefficient. 894 Without non-volatile storage, a pure event-driven model typically stores 895 accounting events that have not yet been delivered only until the 896 timeout interval expires. As a result this model has the smallest memory 897 requirements. Once the timeout interval has expired, the accounting 898 event is lost, even if the device has sufficient buffer space to 899 continue to store it. As a result, the event-driven model is the least 900 reliable, since accounting data loss will occur due to device reboots, 901 sustained packet loss, or network failures of duration greater than the 902 timeout interval. In event-driven protocols without a "keep alive" 903 message, accounting servers cannot assume a device failure should no 904 messages arrive for an extended period. Thus, event-driven accounting 905 systems are typically not useful in monitoring of device health. 907 The event-driven model is frequently used in shared use networks and 908 roaming, since this model sends data to the recipient domains without 909 requiring them to poll a vast number of devices, most of which have no 910 relevant data. Since the event-driven model typically does not support 911 batching, it permits accounting records to be sent with low processing 912 delay, enabling application of fraud prevention techniques. However, 913 because roaming accounting events are frequently of high value, the poor 914 reliability of this model is an issue. As a result, the event-driven 915 polling model may be more appropriate. 917 Per-session state is typical of event-driven systems without batching. 918 As a result, the pure event-driven approach scales poorly. However, 919 event-driven systems offer the lowest latency since events are processed 920 immediately and there is no possibility of an event requiring low 921 latency being caught behind a batch transfer. 923 6.3.3. Event-driven model with batching 925 In the event-driven model with batching, a device will contact the 926 accounting server or manager when it is ready to transfer accounting 927 data. The device can contact the server when a batch of a given size has 928 been gathered, when data of a certain type is available or after a 929 minimum time period has elapsed. Such systems can transfer more than one 930 accounting event per packet and are thus more efficient. 932 An event-driven system with batching will store accounting events that 933 have not yet been delivered up to the limits of memory. As a result, 934 accounting data loss will occur due to device reboots, but not due to 935 packet loss or network failures of sufficiently short duration to be 936 handled within available memory. Note that while transfer efficiency 937 will increase with batch size, without non-volatile storage, the 938 potential data loss from a device reboot will also increase. 940 Where event-driven systems with batching have a keep-alive interval and 941 run over reliable transport, the accounting server can assume that a 942 failure has occurred if no messages are received within the keep-alive 943 interval. Thus, such implementations can be useful in monitoring of 944 device health. 946 Through implementation of a scheduling algorithm, event-driven systems 947 with batching can deliver appropriate service to accounting events that 948 require low latency. For example, high-value inter-domain accounting 949 events could be sent immediately, thus enabling use of fraud-prevention 950 techniques, while all other events would be batched. However, there is a 951 possibility that an event requiring low latency will be caught behind a 952 batch transfer in progress. Thus the maximum latency is proportional to 953 the maximum batch size divided by the link speed. 955 Event-driven systems with batching scale with the number of active 956 devices. As a result this approach scales better than the pure event- 957 driven approach, or even the polling approach, and is equivalent to the 958 event-driven polling approach. However, it has lower latency than the 959 event-driven polling approach, since delivery of accounting data 960 requires fewer round-trips and events requiring low latency can be 961 accomodated if a scheduling algorithm is employed. 963 6.3.4. Event-driven polling model 965 In the event-driven polling model an accounting manager will poll the 966 device for accounting data only when it receives an event. The 967 accounting client can generate an event when a batch of a given size has 968 been gathered, when data of a certain type is available or after a 969 minimum time period has elapsed. Note that while transfer efficiency 970 will increase with batch size, without non-volatile storage, the 971 potential data loss from a device reboot will also increase. 973 Without non-volatile storage, an event-driven polling model will lose 974 data due to device reboots, but not due to packet loss, or network 975 partitions of short-duration. Unless a minimum delivery interval is set, 976 event-driven polling systems are not useful in monitoring of device 977 health. 979 The event-driven polling model can be suitable for use in roaming since 980 it permits accounting data to be sent to the roaming partners with low 981 processing delay. At the same time non-roaming accounting can be handled 982 via more efficient polling techniques, thereby providing the best of 983 both worlds. 985 Where batching can be implemented, the state required in event-driven 986 polling can be reduced to scale with the number of active devices. If 987 portions of the network vary widely in usage, then this state may 988 actually be less than that of the polling approach. Note that latency in 989 this approach is higher than in event-driven accounting with batching 990 since at least two round-trips are required to deliver data: one for the 991 event notification, and one for the resulting poll. 993 6.3.5. Data collection summary 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Model | Pros | Cons | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Polling | Per-device state | Not robust | 999 | | Robust against | against device | 1000 | | packet loss | reboot, server | 1001 | | Batch transfers | or network | 1002 | | | failures* | 1003 | | | Polling interval | 1004 | | | determined by | 1005 | | | storage limit | 1006 | | | High processing | 1007 | | | delay | 1008 | | | Unsuitable for | 1009 | | | use in roaming | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Event-driven, | Lowest processing | Not robust | 1012 | no batching | delay | against packet | 1013 | | Suitable for | loss, device | 1014 | | use in roaming | reboot, or | 1015 | | | network | 1016 | | | failures* | 1017 | | | Low efficiency | 1018 | | | Per-session state| 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Event-driven, | Single round-trip | Not robust | 1021 | with batching | latency | against device | 1022 | and | Batch transfers | reboot, network | 1023 | scheduling | Suitable for | failures* | 1024 | | use in roaming | | 1025 | | Per active device | | 1026 | | state | | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | Event-driven | Batch transfers | Not robust | 1029 | polling | Suitable for | against device | 1030 | | use in roaming | reboot, network | 1031 | | Per active device | failures* | 1032 | | state | Two round-trip | 1033 | | | latency | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 Key 1037 * = addressed by non-volatile storage 1039 7. Review of existing accounting protocols 1041 Accounting systems have been successfully implemented using protocols 1042 such as RADIUS, TACACS+, and SNMP. This section describes the 1043 characteristic of each of these protocols, as well as transfer protocols 1044 such as HTTP, FTP, and SMTP. For a review of accounting attributes and 1045 record formats, see [45]. 1047 7.1. Accounting protocols 1049 7.1.1. RADIUS 1051 RADIUS accounting, described in [4], was developed as an add-on to the 1052 RADIUS authentication protocol, described in [3]. As a result, RADIUS 1053 accounting shares the event-driven approach of RADIUS authentication, 1054 without support for batching or polling. As a result, RADIUS accounting 1055 scales with the number of accounting events instead of the number of 1056 devices, and accounting transfers are inefficient. In addition, since 1057 RADIUS accounting is based on UDP and timeout and retry parameters are 1058 not specified, implementations vary widely in their approach to 1059 reliability, with some implementations retrying until delivery or buffer 1060 exhaustion, and others losing accounting data after a few retries. Due 1061 to the lack of reliability, it is not possible to do simultaneous usage 1062 control based on RADIUS accounting alone. Typically another device data 1063 source is required, such as polling of a session MIB or a command-line 1064 session over telnet. 1066 RADIUS accounting implementations are vulnerable to packet loss as well 1067 as network failures and device reboots. These deficiencies are magnified 1068 when RADIUS accounting is applied in inter-domain accounting as is 1069 required in roaming, as noted in [1] and [2]. On the other hand, the 1070 event-driven approach of RADIUS accounting is well suited to handling of 1071 accounting events which require low processing delay, such as is 1072 required for credit risk management or fraud detection. 1074 While RADIUS accounting does provide hop-by-hop authentication and 1075 integrity protection, and IPSEC can be employed to provide hop-by-hop 1076 confidentiality, data object security is not supported, and thus systems 1077 based on RADIUS accounting are not capable of being deployed with 1078 untrusted proxies, or in situations requiring non-repudiation, as noted 1079 in [2]. 1081 While RADIUS does not suppport compression, IP compression, described in 1082 [50], can be employed to provide this. While in principle extensible 1083 with the definition of new attributes, RADIUS suffers from the very 1084 small standard attribute space (256 attributes). 1086 7.1.2. TACACS+ 1088 TACACS+ as defined in [26] offers an accounting model with start, stop, 1089 and interim update messages. Since TACACS+ is based on TCP, 1090 implementations are typically resilient against packet loss and short- 1091 lived network partitions, and TACACS+ scales with the number of devices. 1092 Since TACACS+ runs over TCP, it is suitable for simultaneous usage 1093 control and handling of accounting events that require moderate though 1094 not the lowest processing delay. 1096 TACACS+ provides for hop-by-hop authentication and integrity protection 1097 as well as hop-by-hop confidentiality. Data object security is not 1098 supported, and therefore systems based on TACACS+ accounting are not 1099 deployable in the presence of untrusted proxies. TACACS+ does not 1100 support non-repudiation. While TACACS+ does not suppport compression, 1101 IP compression, described in [50], can be employed to provide this. 1103 7.1.3. SNMP 1105 7.1.3.1. SNMP overview 1107 SNMP, described in [27]-[41], has been widely deployed in a wide variety 1108 of intra-domain accounting applications, typically using the polling 1109 data collection model. Since polling allows data to be collected on 1110 multiple accounting events simultaneously, this model results in per- 1111 device state. Since the management agent is able to retry requests when 1112 a response is not received, such systems are resilient against packet 1113 loss or even short-lived network partitions. While implementations 1114 without non-volatile storage can only store accounting events up to the 1115 limits of their memory, and thus are not robust against device reboots 1116 or network failures, when combined with non-volatile storage, they can 1117 be made highly reliable. With SNMP v2 it is possible support confirmed 1118 notifications, so as to implement an event-driven polling model or even 1119 an event-driven batching model. However, we are not aware of any SNMP- 1120 based accounting implementations built on these models. 1122 7.1.3.2. NMRG extensions 1124 As discussed in [49], there are a number of efficiency and latency 1125 issues that arise when using SNMP for accounting. In such applications 1126 it is often necessary for management stations to retrieve large tables. 1127 In such situations, the latency can be quite high, even with the get- 1128 bulk operation. This is because the response must fit into the largest 1129 supported packet size, requiring multiple round-trips. Unless multiple 1130 threads are employed, the transfers will be serialized and the resulting 1131 latency will be a combination of multiple round-trip times, timeout and 1132 re-ransmission delays and processing overhead, resulting in unacceptable 1133 performance. 1135 In addition, it is noted that SNMP is inefficient for transfer of 1136 accounting data, due to lack of compression, use of BER encoding, 1137 transmission of redundant OIDs prefixes, and the "get bulk overshoot" 1138 problem. Since the data may change during the course of the retrieval, 1139 it can be difficult to get a consistent snapshot. 1141 As a result, this article recommends a number of changes to SNMP, which 1142 are now under discussion within the IRTF Network Management Research 1143 Group (NMRG), described in [46]. These include an SNMP-over-TCP 1144 transport mapping, described in [47]; SNMP payload compression, 1145 described in [48]; and addition of a "get subtree" protocol operation. 1146 Taken together, we will refer to these changes as the "NMRG extensions." 1148 Reference [49] also discusses file-based storage of SNMP data, as 1149 described in [43], and the FTP MIB, described in [44]. Together these 1150 MIBs enable storage of SNMP data in non-volatile storage, and subsequent 1151 transfer via SNMP. It is noted that this approach requires 1152 implementation of additional MIBs as well as FTP, and requires separate 1153 security mechanisms such as IPSEC to provide integrity protection and 1154 confidentiality for the data in transit. However, the the file-based 1155 transfer approach also has an important benefit, which is compatibility 1156 with non-volatile storage. 1158 While the NMRG extensions are attractive in the long-term, they 1159 represent signicant changes to SNMP and so will take quite a while to 1160 standardize and become widely available. While an SNMP over TCP 1161 transport mapping is easily implemented, it does require SNMP agents to 1162 listen on TCP ports 161 and 162. Addition of a GetSubtree PDU implies 1163 changes to every agent that the management station will interact with. 1165 7.1.3.3. SNMP v3 1167 While SNMP v1 and v2 did not incorporate security services, with SNMPv3, 1168 it is possible to incorporate view-based access controls, described in 1169 [40], as well as user-based security, described in [38]. As a result, 1170 SNMP v3-based accounting implementations can provide for hop-by-hop 1171 authentication, integrity and replay protection, confidentiality and 1172 access-control. Though data-objct security and non-repudiation are not 1173 supported in the protocol, it may be possible to support these 1174 capabilities through addition of appropriate MIB variables. 1176 SNMP v3 also includes additional functionality useful in inter-domain 1177 accounting. Where multiple administrative domains are involved, such as 1178 in the shared use networks and roaming associations described in [1], 1179 domain-based access controls are required. Since in shared use networks 1180 the same device may be accessed by multiple organizations, it is often 1181 necessary to control access to accounting data according to the user's 1182 organization. This ensures that organizations may be given access to 1183 accounting data relating to their users, but not to data relating to 1184 users of other organizations. This implies that access rights will 1185 depend not only on the view, but on the identity of the user described 1186 in the data element. Through use of the contextEngineID, it is possible 1187 to support multiple instances of an SNMP MIB, one for each accessing 1188 organization. This permits access to be controlled on a per-domain 1189 basis, using the view-based access control model described in [40]. For 1190 example, when a contextEngineID of bigco.com is used, access would only 1191 be provided to data on bigco.com users. Note that this requires that 1192 view-based access control be separately set up for each context and that 1193 each domain accessing the data be given a separate userName. Note that 1194 because use of contextEngineID does not require changes to MIBs, all 1195 existing MIBs running on SNMP v3 will inherit domain-handling 1196 capabilities. This is very attractive since few existing MIBs use the 1197 domain as an index, allowing domain data to be separated out. 1199 As the number of network devices within the shared use or roaming 1200 network grows, the polling model of data collection becomes increasingly 1201 impractical since most devices will not carry data relating to the 1202 polling organization. As a result, shared-use networks or roaming 1203 associations relying on SNMP-based accounting have generally collected 1204 data for all organizations and then sorted the resulting session records 1205 for delivery to each organization. While functional, this approach will 1206 typically result in increased processing delay as the number of 1207 organizations and data records grows. 1209 This issue can be addressed in SNMP v3 through use of contextEngineID 1210 and the SNMP notification tables, using the event-driven polling 1211 approach. This permits SNMP v3-enabled devices to notify domains that 1212 have accounting data awaiting collection. 1214 Note that while SNMP v3 has many features enhancing its suitability for 1215 shared use or roaming applications, it may be difficult to make use of 1216 these enhanced capabilities where there are still legacy devices 1217 implementing SNMP v1 or v2. In order to support legacy devices, an SNMP 1218 proxy will be required. However, since contextEngineID is only supported 1219 in SNMP v3, unless the legacy devices have implemented a MIB that 1220 separates out data for individual domains via an index, an SNMP v3 proxy 1221 receiving a request for data in a given domain cannot easily translate 1222 this into an equivalent SNMP v1 or v2 request. 1224 The same issues of legacy support exist with the NMRG extensions. A 1225 proxy receiving a "get subtree" request going to a non-NMRG 1226 capabledevices would need to translate the "get subtree" PDU into 1227 multiple getbulk requests. Similarly, unless the devices support TCP 1228 transport, deployment of an NMRG-capable proxy will not provide much 1229 benefit, since the proxy will need to fall back to UDP-based getnext or 1230 getbulk operations. This will result in multiple round-trips and high 1231 latency and the risk of inconsistent tables would remain. In addition, 1232 existing proxies are built to merely pass on operations so that new 1233 proxy code would be needed to support these translations. 1235 Where the product of the number of domains and devices is large, such as 1236 in inter-domain accounting applications, the number of shared secrets 1237 can get out of hand. The localized key capability in the SNMP v3 USM 1238 allows a manager to have one central key, sharing it with many agents in 1239 a localized way while preventing the agents from getting at each other's 1240 data. This can assist in cross-domain security if deployed properly. 1242 Another solution is to implement a proxy for the purposes of shared 1243 secret reduction. In such a scheme, the domains will share a secret with 1244 the proxy, and the proxy will share a secret with each of the devices. 1245 Thus the number of shared secrets will scale with the sum of the number 1246 of devices and domains rather than the product. 1248 A Kerberos Security Model (KSM) for SNMP v3 is described in [51]. This 1249 approach is an individual submission not yet part of any IETF WG effort. 1250 It requires storage of a key on the KDC for each device and domain, 1251 while dynamically generating a session key for conversations between 1252 domains and devices. Thus, in terms of stored keys the KSM approach 1253 scales with the sum of devices and domains, whereas in terms of dynamic 1254 session keys, it scales as the product of domains and devices. 1256 As Kerberos is extended to allow initial authentication via public key, 1257 as described in [52], and cross-realm authentication, as described in 1258 [53] the KSM will inherit these capabilities. As a result, this approach 1259 may have potential to reduce or even eliminate the shared secret 1260 management problem in the long-term. 1262 7.1.3.4. SNMP v3 Summary 1264 Given the wealth of existing accounting-related MIBs, it is likely that 1265 SNMP will remain a popular accounting protocol for the foreseeable 1266 future. Given the SNMP v3 enhancements, it is desirable for SNMP-based 1267 intra-domain accounting implementations to upgrade to SNMP v3. Such an 1268 upgrade is virtually mandatory for inter-domain applications. 1270 With SNMP v3, it is now possible to provide hop-by-hop security 1271 services. Through use of contextEngineID, it is possible for SNMP v3 to 1272 provide per-domain access controls that are backward compatible with 1273 existing MIBs. Through use of the SNMP v3 notify tables, it is possible 1274 to implement an event-driven polling model, making it possible to notify 1275 domains of available data rather than requiring them to poll for it. 1277 This is critical in shared use or roaming implementations. 1279 In inter-domain accounting, management of SNMP v3 shared secrets can be 1280 assisted by the localized key capability or via implementation of a 1281 proxy. In the long term, alternative security models such as the 1282 Kerberos Security Model may further reduce the effort required to manage 1283 security. 1285 As noted in [49], SNMP-based accounting has limitations in terms of 1286 efficiency and latency that may make it inappropriate for use in 1287 situations requiring low processing delay or low overhead. These issues 1288 can be addressed via addition of extensions currently under discussion 1289 in the IRTF Network Management Research Group (NMRG). Compatibility 1290 with non-volatile storage can be achieved via implementation of the MIBs 1291 described in [43]-[44]. 1293 Note that since few current MIBs support the domain as an index, it can 1294 be difficult for an SNMP proxy to simulate the contextEngineID 1295 capability on legacy devices. Thus where legacy devices remain it may be 1296 necessary to collect data from the devices and sort it by domain, 1297 resulting in high processing delay. Elimination of this issue would 1298 require upgrading all devices to SNMP v3, as well as implementation of 1299 the NMRG extensions. Since SNMP v3 is not widely deployed today and the 1300 NMRG extensions are still under development, this "all or nothing" 1301 approach is typically not viable in the short to medium term. 1303 7.2. Accounting data transfer 1305 In order for session records to be transmitted between accounting 1306 servers, a transfer protocol is required. Transfer protocols in use 1307 today include SMTP, FTP, and HTTP. 1309 7.2.1. SMTP-based accounting record transfer 1311 To date, few accounting management systems have been built on SMTP since 1312 the implementation of a store-and-forward message system has 1313 traditionally required access to non-volatile storage which has not been 1314 widely available on network devices. However, SMTP-based 1315 implementations have many desirable characteristics, particularly with 1316 regards to security. 1318 Accounting management systems using SMTP for accounting transfer will 1319 typically support batching so that message processing overhead will be 1320 spread over multiple accounting records. As a result, these systems 1321 result in per-active device state. Since accounting systems using SMTP 1322 as a transfer mechanism have access to substantial non-volatile storage, 1323 they can generate, compress if necessary, and store accounting records 1324 until they are transferred to the collection site. As a result, 1325 accounting systems implemented using SMTP can be highly efficient and 1326 scalable. Using IPSEC, TLS or Kerberos, hop-by-hop security services 1327 such as authentication, integrity protection and confidentiality can be 1328 provided. 1330 As described in [13] and [15], data object security is available for 1331 SMTP, and in addition, the facilities described in [12] make it possible 1332 to request and receive signed receipts, which enables non-repudiation as 1333 described in [12]-[18]. As a result, accounting systems utilizing SMTP 1334 for accounting data transfer are capable of satisfying the most 1335 demanding security requirements. However, such systems are not typically 1336 capable of providing low processing delay, although this may be 1337 addressed by the enhancements described in [20]. 1339 7.2.2. Other transfer mechanisms 1341 File transfer protocols such as FTP and HTTP have been used for transfer 1342 of accounting data. For example, Reference [9] describes a means for 1343 representing ASN.1-based accounting data for storage on archival media. 1344 Through the use of the Bulk File MIB, described in [43], accounting data 1345 from an SNMP MIB can be stored in ASN.1, bulk binary or Bulk ascii 1346 format, and then subsequently retrieved as required using the FTP Client 1347 MIB described in [44]. 1349 Given access to sufficient non-volatile storage, accounting systems 1350 based on record formats and transfer protocols can avoid loss of data 1351 due to long-duration network partitions, server failures or device 1352 reboots. Since it is possible for the transfer to be driven from the 1353 collection site, the collector can retry transfers until successful, or 1354 with HTTP may even be able to restart partially completed transfers. As 1355 a result, file transfer-based systems can be made highly reliable, and 1356 the batching of accounting records makes possible efficient transfers 1357 and application of required security services with lessened overhead. 1359 8. Summary 1361 As noted previously in this document, accounting applications vary in 1362 their security and reliability requirements. Some uses such as capacity 1363 planning may only require authentication, integrity and replay 1364 protection, and modest reliability while other applications such as 1365 inter-domain usage-sensitive billing may require the highest degree of 1366 security and reliability, since in these cases the transfer of 1367 accounting data will lead directly to the transfer of funds. 1369 Since accounting applications do not have uniform security and 1370 reliability requirements, it is not possible to devise a single 1371 accounting protocol and set of security services that will meet all 1372 needs. Rather, the goal of accounting management should be to provide a 1373 set of tools that can be used to construct accounting systems meeting 1374 the requirements of an individual application. 1376 As a result, it is important to analyze a given accounting application 1377 to ensure that the methods chosen meet the security and reliability 1378 requirements of the application. Based on the analysis given previously, 1379 it appears that existing protocols are capable of meeting the security 1380 requirements for capacity planning and non-usage sensitive billing 1381 applications. For usage sensitive billing, as well as cost allocation 1382 and auditing applications, new work is required to support file-based 1383 storage and transfer of bulk data. Where high-value sessions are 1384 involved, such as in roaming, Mobile IP, or telephony, fraud detection 1385 support may require low processing delay. Currently, no existing 1386 protocol simultaneously meets the requiremens for high security and 1387 reliability, as well as low processing delay. A summary is given below: 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | | | | 1391 | Usage | Intra-domain | Inter-domain | 1392 | | | | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | | | | 1395 | Capacity | SNMP v1, v2, v3 | SNMP v3 | 1396 | Planning or | RADIUS accounting | | 1397 | Non-Usage | TACACS+ accounting | | 1398 | Sensitive | | | 1399 | Billing | | | 1400 | | | | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | | Non-volatile | Non-volatile | 1403 | Usage | storage | storage | 1404 | Sensitive | | | 1405 | Billing, | SNMP v3 w/NMRG | SNMP v3 w/NMRG | 1406 | cost | extensions | extensions | 1407 | allocation & | TACACS+ accounting | | 1408 | auditing | | | 1409 | | | | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | | | | 1412 | | Non-volatile | Non-volatile | 1413 | | storage | storage | 1414 | | Low overhead, | Low overhead, | 1415 | Time | event driven | event driven | 1416 | Sensitive | batching | batching | 1417 | Billing, | Authenticity | Data object | 1418 | fraud | and privacy | security and | 1419 | detection, | support | receipt support | 1420 | roaming | | | 1421 | | No existing | No existing | 1422 | | protocol | protocol | 1423 | | | | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 9. Acknowledgements 1428 The authors would like to thank Bert Wijnen (IBM), Jan Melen (Ericsson) 1429 and Jarmo Savolainen (Ericsson) for many useful discussions of this 1430 problem space. 1432 10. References 1434 [1] Aboba, B., Lu J., Alsop J., Ding J., and W. Wang, "Review of 1435 Roaming Implementations", RFC 2194, September 1997. 1437 [2] Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming 1438 Protocols", RFC 2477, January 1999. 1440 [3] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 1441 Authentication Dial In User Service (RADIUS)", RFC 2138, April, 1442 1997. 1444 [4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. 1446 [5] Gray, J., Reuter, A., Transaction Processing: Concepts and 1447 Techniques, Morgan Kaufmann Publishers, San Francisco, California, 1448 1993. 1450 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1451 Levels", BCP 14, RFC 2119, March 1997. 1453 [7] Crocker, D., Overrell, P., "Augmented BNF for Syntax 1454 Specifications: ABNF", RFC 2234, November 1997. 1456 [8] Aboba, B., and M. Beadles, "The Network Access Identifier", 1457 RFC 2486, January 1999. 1459 [9] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Accounting 1460 Information for ATM Networks", RFC 2512, February 1999. 1462 [10] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Managed 1463 Objects for Controlling the Collection and Storage of Accounting 1464 Information for Connection-Oriented Networks", RFC 2513, February 1465 1999. 1467 [11] Aboba, B., Lidyard, D., "The Accounting Data Interchange Format 1468 (ADIF)", Internet draft (work in progress), draft-ietf-roamops- 1469 actng-05.txt, November 1998. 1471 [12] Fajman, R., "An Extensible Message Format for Message Disposition 1472 Notifications", RFC 2298, March 1998. 1474 [13] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 1475 2015, October 1996. 1477 [14] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting 1478 of Mail System Administrative Messages", RFC 1892, January 1996. 1480 [15] Galvin, J., et al. "Security Multiparts for MIME: Multi- 1481 part/Signed and Multipart/Encrypted", RFC 1847, October 1995. 1483 [16] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1484 1995. 1486 [17] Shih, C., Jansson, M., Drummond,R., "MIME-based Secure EDI", 1487 Internet draft (work in progress), draft-ietf-ediint- 1488 as1-09.txt, December 1998. 1490 [18] Shih, C., Jansson, M., Drummond, R., Yarbrough, L. "Requirements 1491 for Inter-operable Internet EDI", Internet draft (work in 1492 progress), draft-ietf-ediint-req-06.txt, December 1998. 1494 [19] Borenstein, N., Freed, N, "MIME (Multipurpose Internet Mail 1495 Extensions) Part One: Mechanisms for Specifying and Describing 1496 the Format of Internet Message Bodies", RFC 1521, December 1993. 1498 [20] Joffe, N., Wing, D., Masinter, L., "SMTP Service Extension for 1499 Immediate Delivery", Internet draft (work in progress), draft-ietf- 1500 fax-smtp-session-04.txt, August 1998. 1502 [21] Johnson, H. T., Kaplan, R. S., Relevance Lost: The Rise and Fall of 1503 Management Accounting, Harvard Business School Press, Boston, 1504 Massachusetts, 1987. 1506 [22] Horngren, C. T., Foster, G., Cost Accounting: A Managerial 1507 Emphasis. Prentice Hall, Englewood Cliffs, New Jersey, 1991. 1509 [23] Kaplan, R. S., Atkinson, Anthony A., Advanced Management 1510 Accounting, Prentice Hall, Englewood Cliffs, New Jersey, 1989. 1512 [24] Cooper, R., Kaplan, R. S., The Design of Cost Management Systems. 1513 Prentice Hall, Englewood Cliffs, New Jersey, 1991. 1515 [25] Rigney, C., Willens, S., Calhoun, P., "RADIUS Extensions", draft- 1516 ietf-radius-ext-03.txt, Internet Draft (work in progress), January 1517 1999. 1519 [26] Carrel, D., Grant, L., "The TACACS+ Protocol Version 1.78", 1520 Internet draft (work in progress), draft-grant-tacacs-02.txt, 1521 January 1997. 1523 [27] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 1524 Describing SNMP Management Frameworks", RFC 2571, April 1999. 1526 [28] Rose, M., and K. McCloghrie, "Structure and Identification of 1527 Management Information for TCP/IP-based Internets", RFC 1155, May 1528 1990. 1530 [29] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 1531 March 1991. 1533 [30] M. Rose, "A Convention for Defining Traps for use with the SNMP", 1534 RFC 1215, March 1991. 1536 [31] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 1537 of Management Information for Version 2 of the Simple Network 1538 Management Protocol (SNMPv2)", RFC 1902, January 1996. 1540 [32] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 1541 Conventions for Version 2 of the Simple Network Management Protocol 1542 (SNMPv2)", RFC 1903, January 1996. 1544 [33] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance 1545 Statements for Version 2 of the Simple Network Management Protocol 1546 (SNMPv2)", RFC 1904, January 1996. 1548 [34] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1549 Management Protocol", RFC 1157, May 1990. 1551 [35] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1552 "Introduction to Community-based SNMPv2", RFC 1901, January 1996. 1554 [36] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport 1555 Mappings for Version 2 of the Simple Network Management Protocol 1556 (SNMPv2)", RFC 1906, January 1996. 1558 [37] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 1559 Processing and Dispatching for the Simple Network Management 1560 Protocol (SNMP)", RFC 2572, April 1999. 1562 [38] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 1563 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 1564 2574, April 1999. 1566 [39] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 1567 2573, April 1999. 1569 [40] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 1570 Control Model (VACM) for the Simple Network Management Protocol 1571 (SNMP)", RFC 2575, April 1999. 1573 [41] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 1574 Operations for Version 2 of the Simple Network Management Protocol 1575 (SNMPv2)", RFC 1905, January 1996. 1577 [42] Rose, M.T., The Simple Book, Second Edition, Prentice Hall, Upper 1578 Saddle River, NJ, 1996. 1580 [43] Stewart, B., "Bulk File MIB", Internet draft (work in progress), 1581 draft-stewart-bulk-file-mib-00.txt, November 1998. 1583 [44] Stewart, B., "FTP Client MIB", Internet draft (work in progress), 1584 draft-stewart-ftp-client-mib-00.txt, November 1998. 1586 [45] Brownlee, N., "Accounting Attributes and Record Formats", Internet 1587 draft (work in progress), draft-brownlee-accounting- 1588 attributes-00.txt, May 1999. 1590 [46] Network Management Research Group Web page, http://www.ibr.cs.tu- 1591 bs.de/projects/nmrg/ 1593 [47] Schoenwaelder, J.,"SNMP-over-TCP Transport Mapping", Internet draft 1594 (work in progress), draft-irtf-nmrg-snmp-tcp-01.txt, June 1999. 1596 [48] Schoenwaelder, J.,"SNMP Payload Compression", Internet draft (work 1597 in progress), draft-irtf-nmrg-snmp-compression-00.txt, June 1999. 1599 [49] Sprenkels, R., Martin-Flatin, J.,"Bulk Transfers of MIB Data", 1600 Simple Times, http://www.simple-times.org/pub/simple- 1601 times/issues/7-1.html, March 1999. 1603 [50] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP Payload 1604 Compression Protocol (IPComp)", RFC 2393, December 1998. 1606 [51] Hornstein, K., Hardaker, W., "A Kerberos Security Model for SNMP 1607 v3", Internet draft (work in progress), draft-hornstein- 1608 snmpv3-ksm-00.txt, June 1999. 1610 [52] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, 1611 J., Trostle, J., "Public Key Cryptography for Initial 1612 Authentication in Kerberos", Internet draft (work in progress), 1613 draft-ietf-cat-kerberos-pk-init-09.txt, June 1999. 1615 [53] Tung, B., Ryutov, T., Neuman, C., Tsudik, G., Sommerfeld, B., 1616 Medvinsky, A., Hur, M., "Public Key Cryptography for Cross-Realm 1617 Authentication in Kerberos", Internet draft (work in progress), 1618 draft-ietf-cat-kerberos-pk-cross-04.txt, June 1999. 1620 11. Author's Addresses 1622 Bernard Aboba 1623 Microsoft Corporation 1624 One Microsoft Way 1625 Redmond, WA 98052 1627 Phone: 425-936-6605 1628 EMail: bernarda@microsoft.com 1630 Jari Arkko 1631 Oy LM Ericsson Ab 1632 02420 Jorvas 1633 Finland 1635 Phone: +358 40 5079256 1636 EMail: Jari.Arkko@ericsson.com 1638 12. Full Copyright Statement 1640 Copyright (C) The Internet Society (1999). All Rights Reserved. 1641 This document and translations of it may be copied and furnished to 1642 others, and derivative works that comment on or otherwise explain it or 1643 assist in its implmentation may be prepared, copied, published and 1644 distributed, in whole or in part, without restriction of any kind, 1645 provided that the above copyright notice and this paragraph are included 1646 on all such copies and derivative works. However, this document itself 1647 may not be modified in any way, such as by removing the copyright notice 1648 or references to the Internet Society or other Internet organizations, 1649 except as needed for the purpose of developing Internet standards in 1650 which case the procedures for copyrights defined in the Internet 1651 Standards process must be followed, or as required to translate it into 1652 languages other than English. The limited permissions granted above are 1653 perpetual and will not be revoked by the Internet Society or its 1654 successors or assigns. This document and the information contained 1655 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1656 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1657 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1658 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1659 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1661 13. Expiration Date 1663 This memo is filed as , and expires April 1, 1664 2000.