idnits 2.17.1 draft-ietf-aaa-acct-06.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. == The page length should not exceed 58 lines per page, but there was 50 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 51 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 9 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 127 has weird spacing: '...tion be measu...' == Line 587 has weird spacing: '...is only one a...' == Line 798 has weird spacing: '..., or on expir...' == Line 812 has weird spacing: '...condary serve...' == Line 1153 has weird spacing: '...need to keep ...' == (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. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '10' is defined on line 2065, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 2080, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 2086, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 2089, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 2104, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 2108, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 2111, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 2128, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 2132, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 2135, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 2138, but no explicit reference was found in the text == Unused Reference: '32' is defined on line 2142, but no explicit reference was found in the text == Unused Reference: '33' is defined on line 2146, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 2150, but no explicit reference was found in the text == Unused Reference: '35' is defined on line 2153, but no explicit reference was found in the text == Unused Reference: '36' is defined on line 2156, but no explicit reference was found in the text == Unused Reference: '37' is defined on line 2160, 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 2393 (ref. '5') (Obsoleted by RFC 3173) ** Obsolete normative reference: RFC 793 (ref. '7') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2486 (ref. '8') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2576 (ref. '11') (Obsoleted by RFC 3584) ** Obsolete normative reference: RFC 2298 (ref. '12') (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 1892 (ref. '14') (Obsoleted by RFC 3462) ** Obsolete normative reference: RFC 1521 (ref. '17') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 2570 (ref. '19') (Obsoleted by RFC 3410) == Outdated reference: A later version (-05) exists of draft-ietf-fax-timely-delivery-00 -- Unexpected draft version: The latest known version of draft-ietf-radius-ext is -06, but you're referring to -07. == Outdated reference: A later version (-13) exists of draft-ietf-sigtran-sctp-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 (-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 (-02) exists of draft-hornstein-snmpv3-ksm-00 == Outdated reference: A later version (-09) exists of draft-irtf-nmrg-snmp-tcp-03 == Outdated reference: A later version (-01) exists of draft-irtf-nmrg-snmp-compression-00 == Outdated reference: A later version (-01) exists of draft-irtf-nmrg-get-subtree-mib-00 Summary: 29 errors (**), 0 flaws (~~), 34 warnings (==), 4 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 21 June 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 RFC 2026. 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 2. Copyright Notice 31 Copyright (C) The Internet Society (2000). All Rights Reserved. 33 3. Abstract 35 The field of Accounting Management is concerned with the collection of 36 resource consumption data for the purposes of capacity and trend 37 analysis, cost allocation, auditing, and billing. This document 38 describes each of these problems, and discusses the issues involved in 39 design of modern accounting systems. 41 Since accounting applications do not have uniform security and 42 reliability requirements, it is not possible to devise a single 43 accounting protocol and set of security services that will meet all 44 needs. Thus the goal of accounting management is to provide a set of 45 tools that can be used to meet the requirements of each application. 46 This document describes the currently available tools as well as the 47 state of the art in accounting protocol design. A companion document, 48 draft-ietf-aaa-accounting-attributes-03.txt, reviews the state of the 49 art in accounting attributes and record formats. 51 3.1. History 53 -06 draft: rewrote SNMP section yet again. 54 -05 draft: rewrote SNMP section. 55 -04 draft: rewrote SNMP section, cleaned up references 56 -03 draft: rewrote SNMPv3 section. 57 -02 draft: added discussion of accounting proxies. Expanded 58 discussion of accounting server faults and failover. Revised 59 section on SNMPv3. Revised requirements and evaluation tables. 60 Fixed spelling mistakes. 62 4. Table of Contents 64 1. Status of this Memo 1 65 2. Copyright notice 1 66 3. Abstract 1 67 4. Table of Contents 2 68 5. Introduction 3 69 5.1 Requirements language 3 70 5.2 Terminology 3 71 5.3 Accounting management architecture 5 72 5.4 Accounting management objectives 7 73 5.5 Intra-domain and inter-domain accounting 10 74 5.6 Accounting record production 11 75 5.7 Requirements summary 13 76 6. Scaling and reliability 14 77 6.1 Fault resilience 14 78 6.2 Resource consumption 22 79 6.3 Data collection models 25 80 7. Review of Accounting Protocols 31 81 7.1 RADIUS 31 82 7.2 TACACS+ 32 83 7.3 SNMP 32 84 8. Review of Accounting Data Transfer 42 85 8.1 SMTP 42 86 8.2 Other protocols 43 87 9. Summary 43 88 10. Acknowledgments 46 89 11. References 46 90 12. Authors' Addresses 49 91 13. Intellectual Property Statement 50 92 14. Full Copyright Statement 51 93 15. Expiration date 51 95 5. Introduction 97 The field of Accounting Management is concerned with the collection of 98 resource consumption data for the purposes of capacity and trend 99 analysis, cost allocation, auditing, and billing. This document 100 describes each of these problems, and discusses the issues involved in 101 design of modern accounting systems. 103 Since accounting applications do not have uniform security and 104 reliability requirements, it is not possible to devise a single 105 accounting protocol and set of security services that will meet all 106 needs. Thus the goal of accounting management is to provide a set of 107 tools that can be used to meet the requirements of each application. 108 This document describes the currently available tools as well as the 109 state of the art in accounting protocol design. A companion document, 110 draft-ietf-aaa-accounting-attributes-03.txt, reviews the state of the 111 art in accounting attributes and record formats. 113 5.1. Requirements language 115 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 116 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 117 described in [6]. 119 5.2. Terminology 121 This document frequently uses the following terms: 123 Accounting 124 The collection of resource consumption data for the purposes 125 of capacity and trend analysis, cost allocation, auditing, and 126 billing. Accounting management requires that resource 127 consumption be measured, rated, assigned, and communicated 128 between appropriate parties. 130 Archival accounting 131 In archival accounting, the goal is to collect all accounting 132 data, to reconstruct missing entries as best as possible in 133 the event of data loss, and to archive data for a mandated 134 time period. It is "usual and customary" for these systems to 135 be engineered to be very robust against accounting data loss. 136 This may include provisions for transport layer as well as 137 application layer acknowledgments, use of non-volatile 138 storage, interim accounting capabilities (stored or 139 transmitted over the wire), etc. Legal or financial 140 requirements frequently mandate archival accounting practices, 141 and may often dictate that data be kept confidential, 142 regardless of whether it is to be used for billing purposes or 143 not. 145 Rating The act of determining the price to be charged for use of a 146 resource. 148 Billing The act of preparing an invoice. 150 Usage sensitive billing 151 A billing process that depends on usage information to prepare 152 an invoice can be said to be usage-sensitive. In contrast, a 153 process that is independent of usage information is said to be 154 non-usage-sensitive. 156 Auditing The act of verifying the correctness of a procedure. In order 157 to be able to conduct an audit it is necessary to be able to 158 definitively determine what procedures were actually carried 159 out so as to be able to compare this to the recommended 160 process. Accomplishing this may require security services such 161 as authentication and integrity protection. 163 Cost Allocation 164 The act of allocating costs between entities. Note that cost 165 allocation and rating are fundamentally different processes. 166 In cost allocation the objective is typically to allocate a 167 known cost among several entities. In rating the objective is 168 to determine the amount to be charged for use of a resource. 169 In cost allocation, the cost per unit of resource may need to 170 be determined; in rating, this is typically a given. 172 Interim accounting 173 Interim accounting provides a snapshot of usage during a 174 user's session. This may be useful in the event of a device 175 reboot or other network problem that prevents the reception or 176 generation of a session summary packet or session record. 177 Interim accounting records can always be summarized without 178 the loss of information. Note that interim accounting records 179 may be stored internally on the device (such as in non- 180 volatile storage) so as to survive a reboot and thus may not 181 always be transmitted over the wire. 183 Session record 184 A session record represents a summary of the resource 185 consumption of a user over the entire session. Accounting 186 gateways creating the session record may do so by processing 187 interim accounting events or accounting events from several 188 devices serving the same user. 190 Accounting Protocol 191 A protocol used to convey data for accounting purposes. 193 Intra-domain accounting 194 Intra-domain accounting involves the collection of information 195 on resource usage within an administrative domain, for use 196 within that domain. In intra-domain accounting, accounting 197 packets and session records typically do not cross 198 administrative boundaries. 200 Inter-domain accounting 201 Inter-domain accounting involves the collection of information 202 on resource usage within an administrative domain, for use 203 within another administrative domain. In inter-domain 204 accounting, accounting packets and session records will 205 typically cross administrative boundaries. 207 Real-time accounting 208 Real-time accounting involves the processing of information on 209 resource usage within a defined time window. Time constraints 210 are typically imposed in order to limit financial risk. 212 Accounting server 213 The accounting server receives accounting data from devices 214 and translates it into session records. The accounting server 215 may also take responsibility for the routing of session 216 records to interested parties. 218 5.3. Accounting management architecture 220 The accounting management architecture involves interactions between 221 network devices, accounting servers, and billing servers. The network 222 device collects resource consumption data in the form of accounting 223 metrics. This information is then transferred to an accounting server. 224 Typically this is accomplished via an accounting protocol, although it 225 is also possible for devices to generate their own session records. 227 The accounting server then processes the accounting data received from 228 the network device. This processing may include summarization of interim 229 accounting information, elimination of duplicate data, or generation of 230 session records. 232 The processed accounting data is then submitted to a billing server, 233 which typically handles rating and invoice generation, but may also 234 carry out auditing, cost allocation, trend analysis or capacity planning 235 functions. Session records may be batched and compressed by the 236 accounting server prior to submission to the billing server in order to 237 reduce the volume of accounting data and the bandwidth required to 238 accomplish the transfer. 240 One of the functions of the accounting server is to distinguish between 241 inter and intra-domain accounting events and to route them 242 appropriately. For session records containing a Network Access 243 Identifier (NAI), described in [8], the distinction can be made by 244 examining the domain portion of the NAI. If the domain portion is absent 245 or corresponds to the local domain, then the session record is treated 246 as an intra-domain accounting event. Otherwise, it is treated as an 247 inter-domain accounting event. 249 Intra-domain accounting events are typically routed to the local billing 250 server, while inter-domain accounting events will be routed to 251 accounting servers operating within other administrative domains. While 252 it is not required that session record formats used in inter and intra- 253 domain accounting be the same, this is desirable, since it eliminates 254 translations that would otherwise be required. 256 Where a proxy forwarder is employed, domain-based access controls may be 257 employed by the proxy forwarder, rather than by the devices themselves. 258 The network device will typically speak an accounting protocol to the 259 proxy forwarder, which may then either convert the accounting packets to 260 session records, or forward the accounting packets to another domain. 261 In either case, domain separation is typically achieved by having the 262 proxy forwarder sort the session records or accounting messages by 263 destination. 265 Where the accounting proxy is not trusted, it may be difficult to verify 266 that the proxy is issuing correct session records based on the 267 accounting messages it receives, since the original accounting messages 268 typically are not forwarded along with the session records. Therefore 269 where trust is an issue, the proxy typically forwards the accounting 270 packets themselves. Assuming that the accounting protocol supports data 271 object security, this allows the end-points to verify that the proxy has 272 not modified the data in transit or snooped on the packet contents. 274 The diagram below illustrates the accounting management architecture: 276 +------------+ 277 | | 278 | Network | 279 | Device | 280 | | 281 +------------+ 282 | 283 Accounting | 284 Protocol | 285 | 286 V 287 +------------+ +------------+ 288 | | | | 289 | Org B | Inter-domain session records | Org A | 290 | Acctg. |<----------------------------->| Acctg. | 291 |Proxy/Server| or accounting protocol | Server | 292 | | | | 293 +------------+ +------------+ 294 | | 295 | | 296 Transfer | Intra-domain | 297 Protocol | Session records | 298 | | 299 V V 300 +------------+ +------------+ 301 | | | | 302 | Org B | | Org A | 303 | Billing | | Billing | 304 | Server | | Server | 305 | | | | 306 +------------+ +------------+ 308 5.4. Accounting management objectives 310 Accounting Management involves the collection of resource consumption 311 data for the purposes of capacity and trend analysis, cost allocation, 312 auditing, billing. Each of these tasks has different requirements. 314 5.4.1. Trend analysis and capacity planning 316 In trend analysis and capacity planning, the goal is typically a 317 forecast of future usage. Since such forecasts are inherently 318 imperfect, high reliability is typically not required, and moderate 319 packet loss can be tolerated. Where it is possible to use statistical 320 sampling techniques to reduce data collection requirements while still 321 providing the forecast with the desired statistical accuracy, it may be 322 possible to tolerate high packet loss as long as bias is not introduced. 324 The security requirements for trend analysis and capacity planning 325 depend on the circumstances of data collection and the sensitivity of 326 the data. Additional security services may be required when data is 327 being transferred between administrative domains. For example, when 328 information is being collected and analyzed within the same 329 administrative domain, integrity protection and authentication may be 330 used in order to guard against collection of invalid data. In inter- 331 domain applications confidentiality may be desirable to guard against 332 snooping by third parties. 334 5.4.2. Billing 336 When accounting data is used for billing purposes, the requirements 337 depend on whether the billing process is usage-sensitive or not. 339 5.4.2.1. Non-usage sensitive billing 341 Since by definition, non-usage-sensitive billing does not require usage 342 information, in theory all accounting data can be lost without affecting 343 the billing process. Of course this would also affect other tasks such 344 as trend analysis or auditing, so that such wholesale data loss would 345 still be unacceptable. 347 5.4.2.2. Usage-sensitive billing 349 Since usage-sensitive billing processes depend on usage information, 350 packet loss may translate directly to revenue loss. As a result, the 351 billing process may need to conform to financial reporting and legal 352 requirements, and therefore an archival accounting approach may be 353 needed. 355 Usage-sensitive systems may also require low processing delay. Today 356 credit risk is commonly managed by computerized fraud detection systems 357 that are designed to detect unusual activity. While efficiency concerns 358 might otherwise dictate batched transmission of accounting data, where 359 there is a risk of fraud, financial exposure increases with processing 360 delay. Thus it may be advisable to transmit each event individually to 361 minimize batch size, or even to utilize quality of service techniques to 362 minimize queuing delays. In addition, it may be necessary for 363 authorization to be dependent on ability to pay. 365 Whether these techniques will be useful varies by application since the 366 degree of financial exposure is application-dependent. For dial-up 367 Internet access from a local provider, charges are typically low and 368 therefore the risk of loss is small. However, in the case of dial-up 369 roaming or voice over IP, time-based charges may be substantial and 370 therefore the risk of fraud is larger. In such situations it is highly 371 desirable to quickly detect unusual account activity, and it may be 372 desirable for authorization to depend on ability to pay. In situations 373 where valuable resources can be reserved, or where charges can be high, 374 very large bills may be rung up quickly, and processing may need to be 375 completed within a defined time window in order to limit exposure. 377 Since in usage-sensitive systems, accounting data translates into 378 revenue, the security and reliability requirements are greater. Due to 379 financial and legal requirements such systems need to be able to survive 380 an audit. Thus security services such as authentication, integrity and 381 replay protection are frequently required and confidentiality and data 382 object integrity may also be desirable. Application-layer 383 acknowledgments are also often required so as to guard against 384 accounting server failures. 386 5.4.3. Auditing 388 With enterprise networking expenditures on the rise, interest in 389 auditing is increasing. Auditing, which is the act of verifying the 390 correctness of a procedure, commonly relies on accounting data. Auditing 391 tasks include verifying the correctness of an invoice submitted by a 392 service provider, or verifying conformance to usage policy, service 393 level agreements, or security guidelines. 395 To permit a credible audit, the auditing data collection process must be 396 at least as reliable as the accounting process being used by the entity 397 that is being audited. Similarly, security policies for the audit should 398 be at least as stringent as those used in preparation of the original 399 invoice. Due to financial and legal requirements, archival accounting 400 practices are frequently required in this application. 402 Where auditing procedures are used to verify conformance to usage or 403 security policies, security services may be desired. This typically will 404 include authentication, integrity and replay protection as well as 405 confidentiality and data object integrity. In order to permit response 406 to security incidents in progress, auditing applications frequently are 407 built to operate with low processing delay. 409 5.4.4. Cost allocation 411 The application of cost allocation and billback methods by enterprise 412 customers is not yet widespread. However, with the convergence of 413 telephony and data communications, there is increasing interest in 414 applying cost allocation and billback procedures to networking costs, as 415 is now commonly practiced with telecommunications costs. 417 Cost allocation models, including traditional costing mechanisms 418 described in [21]-[23] and activity-based costing techniques described 419 in [24] are typically based on detailed analysis of usage data, and as a 420 result they are almost always usage-sensitive. Whether these techniques 421 are applied to allocation of costs between partners in a venture or to 422 allocation of costs between departments in a single firm, cost 423 allocation models often have profound behavioral and financial impacts. 424 As a result, systems developed for this purposes are typically as 425 concerned with reliable data collection and security as are billing 426 applications. Due to financial and legal requirements, archival 427 accounting practices are frequently required in this application. 429 5.5. Intra-domain and inter-domain accounting 431 Much of the initial work on accounting management has focused on intra- 432 domain accounting applications. However, with the increasing deployment 433 of services such as dial-up roaming, Internet fax, Voice and Video over 434 IP and QoS, applications requiring inter-domain accounting are becoming 435 increasingly common. 437 Inter-domain accounting differs from intra-domain accounting in several 438 important ways. Intra-domain accounting involves the collection of 439 information on resource consumption within an administrative domain, for 440 use within that domain. In intra-domain accounting, accounting packets 441 and session records typically do not cross administrative boundaries. As 442 a result, intra-domain accounting applications typically experience low 443 packet loss and involve transfer of data between trusted entities. 445 In contrast, inter-domain accounting involves the collection of 446 information on resource consumption within an administrative domain, for 447 use within another administrative domain. In inter-domain accounting, 448 accounting packets and session records will typically cross 449 administrative boundaries. As a result, inter-domain accounting 450 applications may experience substantial packet loss. In addition, the 451 entities involved in the transfers cannot be assumed to trust each 452 other. 454 Since inter-domain accounting applications involve transfers of 455 accounting data between domains, additional security measures may be 456 desirable. In addition to authentication, replay and integrity 457 protection, it may be desirable to deploy security services such as 458 confidentiality and data object integrity. In inter-domain accounting 459 each involved party also typically requires a copy of each accounting 460 event for invoice generation and auditing. 462 5.6. Accounting record production 464 Typically, a single accounting record is produced per session, or in 465 some cases, a set of interim records which can be summarized in a single 466 record for billing purposes. However, to support deployment of services 467 such as wireless access or complex billing regimes, a more sophisticated 468 approach is required. 470 It is necessary to generate several accounting records from a single 471 session when pricing changes during a session. For instance, the price 472 of a service can be higher during peak hours than off-peak. For a 473 session continuing from one tariff period to another, it becomes 474 necessary for a device to report "packets sent" during both periods. 476 Time is not the only factor requiring this approach. For instance, in 477 mobile access networks the user may roam from one place to another while 478 still being connected in the same session. If roaming causes a change in 479 the tariffs, it is necessary to account for resource consumed in the 480 first and second areas. Another example is where modifications are 481 allowed to an ongoing session. For example, it is possible that a 482 session could be re-authorized with improved QoS. This would require 483 production of accounting records at both QoS levels. 485 These examples could be addressed by using vectors or multi-dimensional 486 arrays to represent resource consumption within a single session record. 487 For example, the vector or array could describe the resource consumption 488 for each combination of factors, e.g. one data item could be the number 489 of packets during peak hour in the area of the home operator. However, 490 such an approach seems complicated and inflexible and as a result, most 491 current systems produce a set of records from one session. A session 492 identifier needs to be present in the records to permit accounting 493 systems to tie the records together. 495 In most cases, the network device will determine when multiple session 496 records are needed, as the local device is aware of factors affecting 497 local tariffs, such as QoS changes and roaming. However, future systems 498 are being designed that enable the home domain to control the generation 499 of accounting records. This is of importance in inter-domain accounting 500 or when network devices do not have tariff information. The centralized 501 control of accounting record production can be realized, for instance, 502 by having authorization servers require re-authorization at certain 503 times and requiring the production of accounting records upon each re- 504 authorization. 506 In conclusion, in some cases it is necessary to produce multiple 507 accounting records from a single session. It must be possible to do 508 this without requiring the user to start a new session or to re- 509 authenticate. The production of multiple records can be controlled 510 either by the network device or by the AAA server. The requirements for 511 timeliness, security and reliability in multiple record sessions are the 512 same as for single-record sessions. 514 5.7. Requirements summary 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | | | | 518 | Usage | Intra-domain | Inter-domain | 519 | | | | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | | Robustness vs. | Robustness vs. | 522 | | packet loss | packet loss | 523 | Capacity | | | 524 | Planning | Integrity, | Integrity, | 525 | | authentication, | authentication, | 526 | | replay protection | replay prot. | 527 | | [confidentiality] | confidentiality | 528 | | | [data object sec.]| 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Non-usage | Integrity, | Integrity, | 531 | Sensitive | authentication, | authentication, | 532 | Billing | replay protection | replay protection | 533 | | [confidentiality] | confidentiality | 534 | | | [data object sec.]| 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | | Archival | Archival | 537 | Usage | accounting | accounting | 538 | Sensitive | Integrity, | Integrity, | 539 | Billing, | authentication, | authentication, | 540 | Cost | replay protection | replay prot. | 541 | Allocation & | [confidentiality] | confidentiality | 542 | Auditing | [Bounds on | [data object sec.]| 543 | | processing delay] | [Bounds on | 544 | | | processing delay] | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | | Archival | Archival | 547 | Time | accounting | accounting | 548 | Sensitive | Integrity, | Integrity, | 549 | Billing, | authentication, | authentication, | 550 | fraud | replay protection | replay prot. | 551 | detection, | [confidentiality] | confidentiality | 552 | roaming | | [Data object | 553 | | Bounds on | security and | 554 | | processing delay | receipt support] | 555 | | | Bounds on | 556 | | | processing delay | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Key 560 [] = optional 562 6. Scaling and reliability 564 With the continuing growth of the Internet, it is important that 565 accounting management systems be scalable and reliable. This section 566 discusses the resources consumed by accounting management systems as 567 well as the scalability and reliability properties exhibited by various 568 data collection and transport models. 570 6.1. Fault resilience 572 As noted earlier, in applications such as usage-sensitive billing, cost 573 allocation and auditing, an archival approach to accounting is 574 frequently mandated, due to financial and legal requirements. Since in 575 such situations loss of accounting data can translate to revenue loss, 576 there is incentive to engineer a high degree of fault resilience. Faults 577 which may be encountered include: 579 Packet loss 580 Accounting server failures 581 Network failures 582 Device reboots 584 To date, much of the debate on accounting reliability has focused on 585 resilience against packet loss and the differences between UDP, SCTP and 586 TCP-based transport. However, it should be understood that resilience 587 against packet loss is only one aspect of meeting archival accounting 588 requirements. 590 As noted in [18], "once the cable is cut you don't need more 591 retransmissions, you need a *lot* more voltage." Thus, the choice of 592 transport has no impact on resilience against faults such as network 593 partition, accounting server failures or device reboots. What does 594 provide resilience against these faults is non-volatile storage. 596 The importance of non-volatile storage in design of reliable accounting 597 systems cannot be over-emphasized. Without non-volatile storage, event- 598 driven systems will lose data once the transmission timeout has been 599 exceeded, and batching designs will experience data loss once the 600 internal memory used for accounting data storage has been exceeded. Via 601 use of non-volatile storage, and internally stored interim records, most 602 of these data losses can be avoided. 604 It may even be argued that non-volatile storage is more important to 605 accounting reliability than network connectivity, since for many years 606 reliable accounting systems were implemented based solely on physical 607 storage, without any network connectivity. For example, phone usage data 608 used to be stored on paper, film, or magnetic media and carried from the 609 place of collection to a central location for bill processing. 611 6.1.1. Interim accounting 613 Interim accounting provides protection against loss of session summary 614 data by providing checkpoint information that can be used to reconstruct 615 the session record in the event that the session summary information is 616 lost. This technique may be applied to any data collection model (i.e. 617 event-driven or polling) and is supported in both RADIUS [25] and in 618 TACACS+. 620 While interim accounting can provide resilience against packet loss, 621 server failures, short-duration network failures, or device reboot, its 622 applicability is limited. Transmission of interim accounting data over 623 the wire should not be thought of as a mainstream reliability 624 improvement technique since it increases use of network bandwidth in 625 normal operation, while providing benefits only in the event of a fault. 627 Since most packet loss on the Internet is due to congestion, sending 628 interim accounting data over the wire can make the problem worse by 629 increasing bandwidth usage. Therefore on-the-wire interim accounting is 630 best restricted to high-value accounting data such as information on 631 long-lived sessions. To protect against loss of data on such sessions, 632 the interim reporting interval is typically set several standard 633 deviations larger than the average session duration. This ensures that 634 most sessions will not result in generation of interim accounting events 635 and the additional bandwidth consumed by interim accounting will be 636 limited. However, as the interim accounting interval decreases toward 637 the average session time, the additional bandwidth consumed by interim 638 accounting increases markedly, and as a result, the interval must be set 639 with caution. 641 Where non-volatile storage is unavailable, interim accounting can also 642 result in excessive consumption of memory that could be better allocated 643 to storage of session data. As a result, implementors should be careful 644 to ensure that new interim accounting data overwrites previous data 645 rather than accumulating additional interim records in memory, thereby 646 worsening the buffer exhaustion problem. 648 Given the increasing popularity of non-volatile storage for use in 649 consumer devices such as digital cameras, such devices are rapidly 650 declining in price. This makes it increasingly feasible for network 651 devices to include built-in support for non-volatile storage. This can 652 be accomplished, for example, by support for compact PCMCIA cards. 654 Where non-volatile storage is available, this can be used to store 655 interim accounting data. Stored interim events are then replaced by 656 updated interim events or by session data when the session completes. 657 The session data can itself be erased once the data has been transmitted 658 and acknowledged at the application layer. This approach avoids interim 659 data being transmitted over the wire except in the case of a device 660 reboot. When a device reboots, internally stored interim records are 661 transferred to the accounting server. 663 6.1.2. Multiple record sessions 665 Generation of multiple accounting records within a session can introduce 666 scalability problems that cannot be controlled using the techniques 667 available in interim accounting. 669 For example, in the case of interim records kept in non-volatile 670 storage, it is possible to overwrite previous interim records with the 671 most recent one or summarize them to a session record. Where interim 672 updates are sent over the wire, it is possible to control bandwidth 673 usage by adjusting the interim accounting interval. 675 These measures are not applicable where multiple session records are 676 produced from a single session, since these records cannot be summarized 677 or overwritten without loss of information. As a result, multiple 678 record production can result in increased consumption of bandwidth and 679 memory. Implementors should be careful to ensure that worst-case 680 multiple record processing requirements do not exceed the capabilities 681 of their systems. 683 As an example, a tariff change at a particular time of day could, if 684 implemented carelessly, create a sudden peak in the consumption of 685 memory and bandwidth as the records need to be stored and/or 686 transported. Rather than attempting to send all of the records at once, 687 it may be desirable to keep them in non-volatile storage and send all of 688 the related records together in a batch when the session completes. It 689 may also be desirable to shape the accounting traffic flow so as to 690 reduce the peak bandwidth consumption. This can be accomplished by 691 introduction of a randomized delay interval. If the home domain can 692 also control the generation of multiple accounting records, the 693 estimation of the worst-case processing requirements can be very 694 difficult. 696 6.1.3. Packet loss 698 As packet loss is a fact of life on the Internet, accounting protocols 699 dealing with session data need to be resilient against packet loss. This 700 is particularly important in inter-domain accounting, where packets 701 often pass through Network Access Points (NAPs) where packet loss may be 702 substantial. Resilience against packet loss can be accomplished via 703 implementation of a retry mechanism on top of UDP, or use of TCP [7] or 704 SCTP [26]. On-the-wire interim accounting provides only limited benefits 705 in mitigating the effects of packet loss. 707 UDP-based transport is frequently used in accounting applications. 708 However, this is not appropriate in all cases. Where accounting data 709 will not fit within a single UDP packet without fragmentation, use of 710 TCP or SCTP transport may be preferred to use of multiple round-trips in 711 UDP. As noted in [47] and [49], this may be an issue in the retrieval of 712 large tables. 714 In addition, in cases where congestion is likely, such as in inter- 715 domain accounting, TCP or SCTP congestion control and round-trip time 716 estimation will be very useful, optimizing throughput. In applications 717 which require maintenance of session state, such as simultaneous usage 718 control, TCP and application-layer keep alive packets or SCTP with its 719 built-in heartbeat capabilities provide a mechanism for keeping track of 720 session state. 722 When implementing UDP retransmission, there are a number of issues to 723 keep in mind: 725 Data model 726 Retry behavior 727 Congestion control 728 Timeout behavior 730 Accounting reliability can be influenced by how the data is modeled. 731 For example, it is almost always preferable to use cumulative variables 732 rather than expressing accounting data in terms of a change from a 733 previous data item. With cumulative data, the current state can be 734 recovered by a successful retrieval, even after many packets have been 735 lost. However, if the data is transmitted as a change then the state 736 will not be recovered until the next cumulative update is sent. Thus, 737 such implementations are much more vulnerable to packet loss, and should 738 be avoided wherever possible. 740 In designing a UDP retry mechanism, it is important that the retry 741 timers relate to the round-trip time, so that retransmissions will not 742 typically occur within the period in which acknowledgments may be 743 expected to arrive. Accounting bandwidth may be significant in some 744 circumstances, so that the added traffic due to unnecessary 745 retransmissions may increase congestion levels. 747 Congestion control in accounting data transfer is a somewhat 748 controversial issue. Since accounting traffic is often considered 749 mission-critical, it has been argued that congestion control is not a 750 requirement; better to let other less-critical traffic back off in 751 response to congestion. Moreover, without non-volatile storage, 752 congestive back-off in accounting applications can result in data loss 753 due to buffer exhaustion. 755 However, it can also be argued that in modern accounting 756 implementations, it is possible to implement congestion control while 757 improving throughput and maintaining high reliability. In circumstances 758 where there is sustained packet loss, there simply is not sufficient 759 capacity to maintain existing transmission rates. Thus, aggregate 760 throughput will actually improve if congestive back-off is implemented. 761 This is due to elimination of retransmissions and the ability to utilize 762 techniques such as RED to desynchronize flows. In addition, with QoS 763 mechanisms such as differentiated services, it is possible to mark 764 accounting packets for preferential handling so as to provide for lower 765 packet loss if desired. Thus considerable leeway is available to the 766 network administrator in controlling the treatment of accounting packets 767 and hard coding inelastic behavior is unnecessary. Typically, systems 768 implementing non-volatile storage allow for backlogged accounting data 769 to be placed in non-volatile storage pending transmission, so that 770 buffer exhaustion resulting from congestive back-off need not be a 771 concern. 773 Since UDP is not really a transport protocol, UDP-based accounting 774 protocols such as [4] often do not prescribe timeout behavior. Thus 775 implementations may exhibit widely different behavior. For example, one 776 implementation may drop accounting data after three constant duration 777 retries to the same server, while another may implement exponential 778 back-off to a given server, then switch to another server, up to a total 779 timeout interval of twelve hours, while storing the untransmitted data 780 on non-volatile storage. The practical difference between these 781 approaches is substantial; the former approach will not satisfy archival 782 accounting requirements while the latter may. More predictable behavior 783 can be achieved via use of SCTP or TCP transport. 785 6.1.4. Accounting server failover 787 In the event of a failure of the primary accounting server, it is 788 desirable for the device to failover to a secondary server. Providing 789 one or more secondary servers can remove much of the risk of accounting 790 server failure, and as a result use of secondary servers has become 791 commonplace. 793 For protocols based on TCP, it is possible for the device to maintain 794 connections to both the primary and secondary accounting servers, using 795 the secondary connection after expiration of a timer on the primary 796 connection. Alternatively, it is possible to open a connection to the 797 secondary accounting server after a timeout or loss of the primary 798 connection, or on expiration of a timer. Thus, accounting protocols 799 based on TCP are capable of responding more rapidly to connectivity 800 failures than TCP timeouts would otherwise allow, at the expense of an 801 increased risk of duplicates. 803 With SCTP, it is possible to control transport layer timeout behavior, 804 and therefore it is not necessary for the accounting application to 805 maintain its own timers. SCTP also enables multiplexing of multiple 806 connections within a single transport connection, all maintaining the 807 same congestion control state, avoiding the "head of line blocking" 808 issues that can occur with TCP. However, since SCTP is not widely 809 available, use of this transport can impose an additional implementation 810 burden on the designer. 812 For protocols using UDP, transmission to the secondary server can occur 813 after a number of retries or timer expiration. For compatibility with 814 congestion avoidance, it is advisable to incorporate techniques such as 815 round-trip-time estimation, slow start and congestive back-off. Thus 816 the accounting protocol designer utilizing UDP often is lead to re- 817 inventing techniques already existing in TCP and SCTP. As a result, the 818 use of raw UDP transport in accounting applications is not recommended. 820 With any transport it is possible for the primary and secondary 821 accounting servers to receive duplicate packets, so support for 822 duplicate elimination is required. Since accounting server failures can 823 result in data accumulation on accounting clients, use of non-volatile 824 storage can ensure against data loss due to transmission timeouts or 825 buffer exhaustion. On-the-wire interim accounting provides only limited 826 benefits in mitigating the effects of accounting server failures. 828 6.1.5. Application layer acknowledgments 830 It is possible for the accounting server to experience partial failures. 831 For example, a failure in the database back end could leave the 832 accounting retrieval process or thread operable while the process or 833 thread responsible for storing the data is non-functional. Similarly, it 834 is possible for the accounting application to run out of disk space, 835 making it unable to continue storing incoming session records. 837 In such cases it is desirable to distinguish between transport layer 838 acknowledgment and application layer acknowledgment. Even though both 839 acknowledgments may be sent within the same packet (such as a TCP 840 segment carrying an application layer acknowledgment along with a piggy- 841 backed ACK), the semantics are different. A transport-layer 842 acknowledgment means "the transport layer has taken responsibility for 843 delivering the data to the application", while an application-layer 844 acknowledgment means "the application has taken responsibility for the 845 data". 847 A common misconception is that use of TCP transport guarantees that data 848 is delivered to the application. However, as noted in RFC 793 [7]: 850 An acknowledgment by TCP does not guarantee that the data has been 851 delivered to the end user, but only that the receiving TCP has taken 852 the responsibility to do so. 854 Therefore, if receiving TCP fails after sending the ACK, the application 855 may not receive the data. Similarly, if the application fails prior to 856 committing the data to stable storage, the data may be lost. In order 857 for a sending application to be sure that the data it sent was received 858 by the receiving application, either a graceful close of the TCP 859 connection or an application-layer acknowledgment is required. In order 860 to protect against data loss, it is necessary that the application-layer 861 acknowledgment imply that the data has been written to stable storage or 862 suitably processed so as to guard against loss. 864 In the case of partial failures, it is possible for the transport layer 865 to acknowledge receipt via transport layer acknowledgment, without 866 having delivered the data to the application. Similarly, the application 867 may not complete the tasks necessary to take responsibility for the 868 data. 870 For example, an accounting server may receive data from the transport 871 layer but be incapable of storing it data due to a back end database 872 problem or disk fault. In this case it should not send an application 873 layer acknowledgment, even though a a transport layer acknowledgment is 874 appropriate. Rather, an application layer error message should be sent 875 indicating the source of the problem, such as "Backend store 876 unavailable". 878 Thus application-layer acknowledgment capability requires not only the 879 ability to acknowledge when the application has taken responsibility for 880 the data, but also the ability to indicate when the application has not 881 taken responsibility for the data, and why. 883 6.1.6. Network failures 885 Network failures may result in partial or complete loss of connectivity 886 for the accounting client. In the event of partial connectivity loss, it 887 may not be possible to reach the primary accounting server, in which 888 case switch over to the secondary accounting server is necessary. In 889 the event of a network partition, it may be necessary to store 890 accounting events in device memory or non-volatile storage until 891 connectivity can be re-established. 893 As with accounting server failures, on-the-wire interim accounting 894 provides only limited benefits in mitigating the effects of network 895 failures. 897 6.1.7. Device reboots 899 In the event of a device reboot, it is desirable to minimize the loss of 900 data on sessions in progress. Such losses may be significant even if the 901 devices themselves are very reliable, due to long-lived sessions, which 902 can comprise a significant fraction of total resource consumption. To 903 guard against loss of these high-value sessions, interim accounting data 904 is typically transmitted over the wire. When interim accounting in-place 905 is combined with non-volatile storage it becomes possible to guard 906 against data loss in much shorter sessions. This is possible since 907 interim accounting data need only be stored in non-volatile memory until 908 the session completes, at which time the interim data may be replaced by 909 the session record. As a result, interim accounting data need never be 910 sent over the wire, and it is possible to decrease the interim interval 911 so as to provide a very high degree of protection against data loss. 913 6.1.8. Accounting proxies 915 In order to maintain high reliability, it is important that accounting 916 proxies pass through transport and application layer acknowledgments and 917 do not store and forward accounting packets. This enables the end- 918 systems to control re-transmission behavior and utilize techniques such 919 as non-volatile storage and secondary servers to improve resilience. 921 Accounting proxies sending a transport or application layer ACK to the 922 device without receiving one from the accounting server fool the device 923 into thinking that the accounting request had been accepted by the 924 accounting server when this is not the case. As a result, the device can 925 delete the accounting packet from non-volatile storage before it has 926 been accepted by the accounting server. The leaves the accounting proxy 927 responsible for delivering accounting packets. If the accounting proxy 928 involves moving parts (e.g. a disk drive) while the devices do not, 929 overall system reliability can be reduced. 931 Store and forward accounting proxies only add value in situations where 932 the accounting subsystem is unreliable. For example, where devices do 933 not implement non-volatile storage and the accounting protocol lacks 934 transport and application layer reliability, locating the accounting 935 proxy (with its stable storage) close to the device can reduce the risk 936 of data loss. 938 However, such systems are inherently unreliable so that they are only 939 appropriate for use in capacity planning or non-usage sensitive billing 940 applications. If archival accounting reliability is desired, it is 941 necessary to engineer a reliable accounting system from the start using 942 the techniques described in this document, rather than attempting to 943 patch an inherently unreliable system by adding store and forward 944 accounting proxies. 946 6.1.9. Fault resilience summary 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | | | 950 | Fault | Counter-measures | 951 | | | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | | | 954 | Packet | Retransmission based on RTT | 955 | loss | Congestion control | 956 | | Well-defined timeout behavior | 957 | | Duplicate elimination | 958 | | Interim accounting* | 959 | | Non-volatile storage | 960 | | Cumulative variables | 961 | | | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | | | 964 | Accounting | Primary-secondary servers | 965 | server & net | Duplicate elimination | 966 | failures | Interim accounting* | 967 | | Application layer ACK & error msgs. | 968 | | Non-volatile storage | 969 | | | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | | | 972 | Device | Interim accounting* | 973 | reboots | Non-volatile storage | 974 | | | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 Key 978 * = limited usefulness without non-volatile storage 980 Note: Accounting proxies are not a reliability 981 enhancement mechanism. 983 6.2. Resource consumption 985 In the process of growing to meet the needs of providers and customers, 986 accounting management systems consume a variety of resources, including: 988 Network bandwidth 989 Memory 990 Non-volatile storage 991 State on the accounting management system 992 CPU on the management system and managed devices 994 In order to understand the limits to scaling, we examine each of these 995 resources in turn. 997 6.2.1. Network bandwidth 999 Accounting management systems consume network bandwidth in transferring 1000 accounting data. The network bandwidth consumed is proportional to the 1001 amount of data transferred, as well as required network overhead. Since 1002 accounting data for a given event may be 100 octets or less, if each 1003 event is transferred individually, overhead can represent a considerable 1004 proportion of total bandwidth consumption. As a result, it is often 1005 desirable to transfer accounting data in batches, enabling network 1006 overhead to be spread over a larger payload, and enabling efficient use 1007 of compression. As noted in [48], compression can be enabled in the 1008 accounting protocol, or can be done at the IP layer as described in [5]. 1010 6.2.2. Memory 1012 In accounting systems without non-volatile storage, accounting data must 1013 be stored in volatile memory during the period between when it is 1014 generated and when it is transferred. The resulting memory consumption 1015 will depend on retry and retransmission algorithms. Since systems 1016 designed for high reliability will typically wish to retry for long 1017 periods, or may store interim accounting data, the resulting memory 1018 consumption can be considerable. As a result, if non-volatile storage is 1019 unavailable, it may be desirable to compress accounting data awaiting 1020 transmission. 1022 As noted earlier, implementors of interim accounting should take care to 1023 ensure against excessive memory usage by overwriting older interim 1024 accounting data with newer data for the same session rather than 1025 accumulating interim data in the buffer. 1027 6.2.3. Non-volatile storage 1029 Since accounting data stored in memory will typically be lost in the 1030 event of a device reboot or a timeout, it may be desirable to provide 1031 non-volatile storage for undelivered accounting data. With the costs of 1032 non-volatile storage declining rapidly, network devices will be 1033 increasingly capable of incorporating non-volatile storage support over 1034 the next few years. 1036 Non-volatile storage may be used to store interim or session records. As 1037 with memory utilization, interim accounting overwrite is desirable so as 1038 to prevent excessive storage consumption. Note that the use of ASCII 1039 data representation enables use of highly efficient text compression 1040 algorithms that can minimize storage requirements. Such compression 1041 algorithms are only typically applied to session records so as to enable 1042 implementation of interim data overwrite. 1044 6.2.4. State on the accounting management system 1046 In order to keep track of received accounting data, accounting 1047 management systems may need to keep state on managed devices or 1048 concurrent sessions. Since the number of devices is typically much 1049 smaller than the number of concurrent sessions, it is desirable to keep 1050 only per-device state if possible. 1052 6.2.5. CPU requirements 1054 CPU consumption of the managed and managing nodes will be proportional 1055 to the complexity of the required accounting processing. Operations such 1056 as ASN.1 encoding and decoding, compression/decompression, and 1057 encryption/decryption can consume considerable resources, both on 1058 accounting clients and servers. 1060 The effect of these operations on accounting system reliability should 1061 not be under-estimated, particularly in the case of devices with 1062 moderate CPU resources. In the event that devices are over-taxed by 1063 accounting tasks, it is likely that overall device reliability will 1064 suffer. 1066 6.2.6. Efficiency measures 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | | | 1070 | Resource | Efficiency measures | 1071 | | | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | | | 1074 | Network | Batching | 1075 | Bandwidth | Compression | 1076 | | | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | | | 1079 | Memory | Compression | 1080 | | Interim accounting overwrite | 1081 | | | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | | | 1084 | Non-volatile | Compression | 1085 | Storage | Interim accounting overwrite | 1086 | | | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | | | 1089 | System | Per-device state | 1090 | state | | 1091 | | | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | | | 1094 | CPU | Hardware assisted | 1095 | requirements | compression/encryption | 1096 | | | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 6.3. 1101 Data collection models 1103 Several data collection models are currently in use today for the 1104 purposes of accounting data collection. These include: 1106 Polling model 1107 Event-driven model without batching 1108 Event-driven model with batching 1109 Event-driven polling model 1111 6.3.1. Polling model 1113 In the polling model, an accounting manager will poll devices for 1114 accounting information at regular intervals. In order to ensure against 1115 loss of data, the polling interval will need to be shorter than the 1116 maximum time that accounting data can be stored on the polled device. 1117 For devices without non-volatile stage, this is typically determined by 1118 available memory; for devices with non-volatile storage the maximum 1119 polling interval is determined by the size of non-volatile storage. 1121 The polling model results in an accumulation of data within individual 1122 devices, and as a result, data is typically transferred to the 1123 accounting manager in a batch, resulting in an efficient transfer 1124 process. In terms of Accounting Manager state, polling systems scale 1125 with the number of managed devices, and system bandwidth usage scales 1126 with the amount of data transferred. 1128 Without non-volatile storage, the polling model results in loss of 1129 accounting data due to device reboots, but not due to packet loss or 1130 network failures of sufficiently short duration to be handled within 1131 available memory. This is because the Accounting Manager will continue 1132 to poll until the data is received. In situations where operational 1133 difficulties are encountered, the volume of accounting data will 1134 frequently increase so as to make data loss more likely. However, in 1135 this case the polling model will detect the problem since attempts to 1136 reach the managed devices will fail. 1138 The polling model scales poorly for implementation of shared use or 1139 roaming services, including wireless data, Internet telephony, QoS 1140 provisioning or Internet access. This is because in order to retrieve 1141 accounting data for users within a given domain, the Accounting 1142 Management station would need to periodically poll all devices in all 1143 domains, most of which would not contain any relevant data. There are 1144 also issues with processing delay, since use of a polling interval also 1145 implies an average processing delay of half the polling interval. This 1146 may be too high for accounting data that requires low processing delay. 1147 Thus the event-driven polling or the pure event-driven approach is more 1148 appropriate for usage sensitive billing applications such as shared use 1149 or roaming implementations. 1151 Per-device state is typical of polling-based network management systems, 1152 which often also carry out accounting management functions, since 1153 network management systems need to keep track of the state of network 1154 devices for operational purposes. These systems offer average processing 1155 delays equal to half the polling interval. 1157 6.3.2. Event-driven model without batching 1159 In the event-driven model, a device will contact the accounting server 1160 or manager when it is ready to transfer accounting data. Most event- 1161 driven accounting systems, such as those based on RADIUS accounting, 1162 described in [4], transfer only one accounting event per packet, which 1163 is inefficient. 1165 Without non-volatile storage, a pure event-driven model typically stores 1166 accounting events that have not yet been delivered only until the 1167 timeout interval expires. As a result this model has the smallest memory 1168 requirements. Once the timeout interval has expired, the accounting 1169 event is lost, even if the device has sufficient buffer space to 1170 continue to store it. As a result, the event-driven model is the least 1171 reliable, since accounting data loss will occur due to device reboots, 1172 sustained packet loss, or network failures of duration greater than the 1173 timeout interval. In event-driven protocols without a "keep alive" 1174 message, accounting servers cannot assume a device failure should no 1175 messages arrive for an extended period. Thus, event-driven accounting 1176 systems are typically not useful in monitoring of device health. 1178 The event-driven model is frequently used in shared use networks and 1179 roaming, since this model sends data to the recipient domains without 1180 requiring them to poll a large number of devices, most of which have no 1181 relevant data. Since the event-driven model typically does not support 1182 batching, it permits accounting records to be sent with low processing 1183 delay, enabling application of fraud prevention techniques. However, 1184 because roaming accounting events are frequently of high value, the poor 1185 reliability of this model is an issue. As a result, the event-driven 1186 polling model may be more appropriate. 1188 Per-session state is typical of event-driven systems without batching. 1189 As a result, the event-driven approach scales poorly. However, event- 1190 driven systems offer the lowest processing delay since events are 1191 processed immediately and there is no possibility of an event requiring 1192 low processing delay being caught behind a batch transfer. 1194 6.3.3. Event-driven model with batching 1196 In the event-driven model with batching, a device will contact the 1197 accounting server or manager when it is ready to transfer accounting 1198 data. The device can contact the server when a batch of a given size has 1199 been gathered, when data of a certain type is available or after a 1200 minimum time period has elapsed. Such systems can transfer more than one 1201 accounting event per packet and are thus more efficient. 1203 An event-driven system with batching will store accounting events that 1204 have not yet been delivered up to the limits of memory. As a result, 1205 accounting data loss will occur due to device reboots, but not due to 1206 packet loss or network failures of sufficiently short duration to be 1207 handled within available memory. Note that while transfer efficiency 1208 will increase with batch size, without non-volatile storage, the 1209 potential data loss from a device reboot will also increase. 1211 Where event-driven systems with batching have a keep-alive interval and 1212 run over reliable transport, the accounting server can assume that a 1213 failure has occurred if no messages are received within the keep-alive 1214 interval. Thus, such implementations can be useful in monitoring of 1215 device health. When used for this purpose the average time delay prior 1216 to failure detection is one half the keep-alive interval. 1218 Through implementation of a scheduling algorithm, event-driven systems 1219 with batching can deliver appropriate service to accounting events that 1220 require low processing delay. For example, high-value inter-domain 1221 accounting events could be sent immediately, thus enabling use of fraud- 1222 prevention techniques, while all other events would be batched. However, 1223 there is a possibility that an event requiring low processing delay will 1224 be caught behind a batch transfer in progress. Thus the maximum 1225 processing delay is proportional to the maximum batch size divided by 1226 the link speed. 1228 Event-driven systems with batching scale with the number of active 1229 devices. As a result this approach scales better than the pure event- 1230 driven approach, or even the polling approach, and is equivalent in 1231 terms of scaling to the event-driven polling approach. However, the 1232 event-driven batching approach has lower processing delay than the 1233 event-driven polling approach, since delivery of accounting data 1234 requires fewer round-trips and events requiring low processing delay can 1235 be accommodated if a scheduling algorithm is employed. 1237 6.3.4. Event-driven polling model 1239 In the event-driven polling model an accounting manager will poll the 1240 device for accounting data only when it receives an event. The 1241 accounting client can generate an event when a batch of a given size has 1242 been gathered, when data of a certain type is available or after a 1243 minimum time period has elapsed. Note that while transfer efficiency 1244 will increase with batch size, without non-volatile storage, the 1245 potential data loss from a device reboot will also increase. 1247 Without non-volatile storage, an event-driven polling model will lose 1248 data due to device reboots, but not due to packet loss, or network 1249 partitions of short-duration. Unless a minimum delivery interval is set, 1250 event-driven polling systems are not useful in monitoring of device 1251 health. 1253 The event-driven polling model can be suitable for use in roaming since 1254 it permits accounting data to be sent to the roaming partners with low 1255 processing delay. At the same time non-roaming accounting can be handled 1256 via more efficient polling techniques, thereby providing the best of 1257 both worlds. 1259 Where batching can be implemented, the state required in event-driven 1260 polling can be reduced to scale with the number of active devices. If 1261 portions of the network vary widely in usage, then this state may 1262 actually be less than that of the polling approach. Note that processing 1263 delay in this approach is higher than in event-driven accounting with 1264 batching since at least two round-trips are required to deliver data: 1265 one for the event notification, and one for the resulting poll. 1267 6.3.5. Data collection summary 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | | | | 1271 | Model | Pros | Cons | 1272 | | | | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | Polling | Per-device state | Not robust | 1275 | | Robust against | against device | 1276 | | packet loss | reboot, server | 1277 | | Batch transfers | or network | 1278 | | | failures* | 1279 | | | Polling interval | 1280 | | | determined by | 1281 | | | storage limit | 1282 | | | High processing | 1283 | | | delay | 1284 | | | Unsuitable for | 1285 | | | use in roaming | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Event-driven, | Lowest processing | Not robust | 1288 | no batching | delay | against packet | 1289 | | Suitable for | loss, device | 1290 | | use in roaming | reboot, or | 1291 | | | network | 1292 | | | failures* | 1293 | | | Low efficiency | 1294 | | | Per-session state | 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | Event-driven, | Single round-trip | Not robust | 1297 | with batching | latency | against device | 1298 | and | Batch transfers | reboot, network | 1299 | scheduling | Suitable for | failures* | 1300 | | use in roaming | | 1301 | | Per active device | | 1302 | | state | | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Event-driven | Batch transfers | Not robust | 1305 | polling | Suitable for | against device | 1306 | | use in roaming | reboot, network | 1307 | | Per active device | failures* | 1308 | | state | Two round-trip | 1309 | | | latency | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 Key 1313 * = addressed by non-volatile storage 1315 7. Review of Accounting Protocols 1317 Accounting systems have been successfully implemented using protocols 1318 such as RADIUS, TACACS+, and SNMP. This section describes the 1319 characteristics of each of these protocols. 1321 7.1. RADIUS 1323 RADIUS accounting, described in [4], was developed as an add-on to the 1324 RADIUS authentication protocol, described in [3]. As a result, RADIUS 1325 accounting shares the event-driven approach of RADIUS authentication, 1326 without support for batching or polling. As a result, RADIUS accounting 1327 scales with the number of accounting events instead of the number of 1328 devices, and accounting transfers are inefficient. 1330 Since RADIUS accounting is based on UDP and timeout and retry parameters 1331 are not specified, implementations vary widely in their approach to 1332 reliability, with some implementations retrying until delivery or buffer 1333 exhaustion, and others losing accounting data after a few retries. Since 1334 RADIUS accounting does not provide for application-layer acknowledgments 1335 or error messages, a RADIUS Accounting-Response is equivalent to a 1336 transport-layer acknowledgment and provides no protection against 1337 application layer malfunctions. Due to the lack of reliability, it is 1338 not possible to do simultaneous usage control based on RADIUS accounting 1339 alone. Typically another device data source is required, such as polling 1340 of a session MIB or a command-line session over telnet. 1342 RADIUS accounting implementations are vulnerable to packet loss as well 1343 as application layer failures, network failures and device reboots. 1344 These deficiencies are magnified in inter-domain accounting as is 1345 required in roaming ([1],[2]). On the other hand, the event-driven 1346 approach of RADIUS accounting is useful where low processing delay is 1347 required, such as credit risk management or fraud detection. 1349 While RADIUS accounting does provide hop-by-hop authentication and 1350 integrity protection, and IPSEC can be employed to provide hop-by-hop 1351 confidentiality, data object security is not supported, and thus systems 1352 based on RADIUS accounting are not capable of being deployed with 1353 untrusted proxies, or in situations requiring auditability, as noted in 1354 [2]. 1356 While RADIUS does not support compression, IP compression, described in 1357 [5], can be employed to provide this. While in principle extensible 1358 with the definition of new attributes, RADIUS suffers from the very 1359 small standard attribute space (256 attributes). 1361 7.2. TACACS+ 1363 TACACS+ offers an accounting model with start, stop, and interim update 1364 messages. Since TACACS+ is based on TCP, implementations are typically 1365 resilient against packet loss and short-lived network partitions, and 1366 TACACS+ scales with the number of devices. Since TACACS+ runs over TCP, 1367 it offers support for both transport layer and application layer 1368 acknowledgments, and is suitable for simultaneous usage control and 1369 handling of accounting events that require moderate though not the 1370 lowest processing delay. 1372 TACACS+ provides for hop-by-hop authentication and integrity protection 1373 as well as hop-by-hop confidentiality. Data object security is not 1374 supported, and therefore systems based on TACACS+ accounting are not 1375 deployable in the presence of untrusted proxies. While TACACS+ does not 1376 support compression, IP compression, described in [5], can be employed 1377 to provide this. 1379 7.3. SNMP 1381 SNMP, described in [19],[27]-[41], has been widely deployed in a wide 1382 variety of intra-domain accounting applications, typically using the 1383 polling data collection model. Polling allows data to be collected on 1384 multiple accounting events simultaneously, resulting in per- device 1385 state. Management applications are able to retry requests when a 1386 response is not received, providing resiliency against packet loss or 1387 even short-lived network partitions. Implementations without non- 1388 volatile storage are not robust against device reboots or network 1389 failures, but when combined with non-volatile storage they can be made 1390 highly reliable. 1392 SMIv1, the data modeling language of SNMPv1, has traps to permit trap- 1393 directed polling, but the traps are not acknowledged, and lost traps can 1394 lead to a loss of data. SMIv2, used by SNMPv2c and SNMPv3, has Inform 1395 Requests which are acknowledged notifications. This makes it possible to 1396 implement a more reliable event-driven polling model or event-driven 1397 batching model. However, we are not aware of any SNMP-based accounting 1398 implementations currently built on the use of Informs. 1400 7.3.1. Security services 1402 SNMPv1 and SNMPv2c support per-packet authentication and read-only and 1403 read-write access profiles, via the community string. This clear-text 1404 password approach provides only trivial authentication, and no per- 1405 packet integrity checks, replay protection or confidentiality. View- 1406 based access control [40] can be supported using the snmpCommunityMIB, 1407 defined in [11], and SNMPv1 or SNMPv2c messages. The updated SNMP 1408 architecture [rfc2571] supports per-packet hop-by-hop authentication, 1409 integrity and replay protection, confidentiality and access control. 1411 The SNMP User Security Model (USM) [38] uses shared secrets, and when 1412 the product of the number of domains and devices is large, such as in 1413 inter-domain accounting applications, the number of shared secrets can 1414 get out of hand. The localized key capability in USM allows a manager 1415 to have one central key, sharing it with many SNMP entities in a 1416 localized way while preventing the other entities from getting at each 1417 other's data. This can assist in cross-domain security if deployed 1418 properly. 1420 SNMPv3 does not support end-to-end data object integrity and 1421 confidentiality; SNMP proxy entities decrypt and re-encrypt the data 1422 they forward. In the presence of an untrusted proxy entity, this would 1423 be inadequate. 1425 7.3.2. Application layer acknowledgments 1427 SNMP uses application-layer acknowledgment to indicate that data has 1428 been processed. SNMP Responses to get, get-next, or get-bulk requests 1429 return the requested data, or an error code indicating the nature of the 1430 error encountered. 1432 A noError SNMP Response to a SET command indicates that the requested 1433 assignments were made by the application. SNMP SETs are atomic; the 1434 command either succeeds or fails. An error-response indicates that the 1435 entity received the request, but did not succeed in executing it. 1437 Notifications do not use acknowledgements to indicate that data has been 1438 processed. The Inform notification returns an acknowledgement of 1439 receipt, but not of processing, by design. Since the updated SNMP 1440 architecture treats entities as peers with varying levels of 1441 functionality, it is possible to use SETs in either direction between 1442 cooperating entities to achieve processing acknowledgements. 1444 There are eighteen SNMP error codes. The design of SNMP makes service- 1445 specific error codes unnecessary and undesirable. 1447 7.3.3. Proxy forwarders 1449 In the accounting management architecture, proxy forwarders play an 1450 important role, forwarding intra and inter-domain accounting events to 1451 the correct destinations. The proxy forwarder may also play a role in a 1452 polling or event-driven polling architecture. 1454 The functionality of an SNMP Proxy Forwarder is defined in [39]. For 1455 example, the network devices may be configured to send notifications for 1456 all domains to the Proxy Forwarder, and the devices may be configured to 1457 allow the Proxy Forwarder to access all MIB data. 1459 The use of proxy forwarders may reduce the number of shared secrets 1460 required for inter-domain accounting. With Proxy Forwarders, the domains 1461 could share a secret with the Proxy Forwarder, and in turn, the Proxy 1462 Forwarder could share a secret with each of the devices. Thus the 1463 number of shared secrets will scale with the sum of the number of 1464 devices and domains rather than the product. 1466 The engine of an SNMP Proxy Forwarder does not look inside the PDU of 1467 the message except to determine to which SNMP engine the PDU should be 1468 forwarded or which local SNMP application should process the PDU. The 1469 SNMP Proxy Forwarder does not modify the varbind values; it does not 1470 modify the varbind list except to translate between SNMP versions; and 1471 it does not provide any varbind level access control. 1473 7.3.4. Domain-based access controls in SNMP 1475 Domain-based access controls are required where multiple administrative 1476 domains are involved, such as in the shared use networks and roaming 1477 associations described in [1]. Since the same device may be accessed by 1478 multiple organizations, it is often necessary to control access to 1479 accounting data according to the user's organization. This ensures that 1480 organizations may be given access to accounting data relating to their 1481 users, but not to data relating to users of other organizations. 1483 In order to apply domain-based access controls, in inter-domain 1484 accounting, it is first necessary to identify the data subset that is to 1485 have its access controlled. Several conceptual abstractions are used for 1486 identifying subsets of data in SNMP. These include engines, contexts, 1487 and views. This section describes how this functionality may be applied 1488 in intra and inter-domain accounting. 1490 7.3.4.1. Engines 1492 The new SNMP architecture, described in [27], added the concept of an 1493 SNMP engine to improve mobility support and to identify which data 1494 source is being referenced. The engine is the portion of an SNMP entity 1495 that constructs messages, provides security functions, and maps to the 1496 transport layer. Traditional agents and traditional managers each 1497 contain an SNMP engine. engineID allows an SNMP engine to be uniquely 1498 identified, independent of the address where it is attached to the 1499 network. 1501 A securityEngineID field in a message identifies the engine which 1502 provides access to the security credentials contained in the message 1503 header. A contextEngineID field in a message identifies the engine which 1504 provides access to the data contained in the PDU. 1506 The SNMPv3 message format explicitly passes both. In SNMPv1 and SNMPv2c, 1507 the data origin is typically assumed to be the communications endpoint 1508 (SNMP agent). SNMPv1 and SNMPv2c messages contain a community name; the 1509 community name and the source address can be mapped to an engineID via 1510 the snmpCommunityTable, described in [11]. 1512 7.3.4.2. Contexts 1514 Contexts are used to identify subsets of objects, within the scope of an 1515 engine, that are tied to instrumentation. A contextName refers to a 1516 particular subset within an engine. 1518 Contexts are commonly tied to hardware components, to logical entities 1519 related to the hardware components, or to logical services. For example, 1520 contextNames might include board5, board7, repeater1, repeater2, etc. 1522 An SNMP agent populates a read-only dynamic table to tell the manager 1523 what contexts it recognizes. Typically contexts are defined by the agent 1524 rather than the manager since if the manager defined them, the agent 1525 would not know how to tie the contexts to the underlying 1526 instrumentation. It is possible that MIB modules could be defined to 1527 allow a manager to assign contextNames to a logical subset of 1528 instrumentation. 1530 While each context may support instances of multiple MIB modules, each 1531 contextName is limited to one instance of a particular MIB module. If 1532 multiple instances of a MIB module are required per engine, then unique 1533 contextNames must be defined (e.g. repeater1, repeater2). The default 1534 context "" is used for engines which only support single instances of 1535 MIB modules, and it is used for MIB modules where it only makes sense to 1536 have one instance of that MIB module in an engine and that instance must 1537 be easy to locate, such as the system MIB or the security MIBs. 1539 SNMPv3 messages contain contextNames which are limited to the scope of 1540 the contextEngineID in the message. SNMPv1 and SNMPv2c messages contain 1541 communities which can be mapped to contextNames within the local engine, 1542 or can be mapped to contextNames within other engines via the 1543 snmpCommunityTable, described in [11]. 1545 7.3.4.3. Views 1547 Views are defined in the View-based Access Control Model. A view is a 1548 mask which is used to determine access to the managed objects in a 1549 particular context. The view identifies which objects are visible, by 1550 specifying OIDs of the subtrees included and excluded. There is also a 1551 mechanism to allow wildcards in the OID specification. 1553 For example, it is possible to define a view that includes RMON tables, 1554 and another view that includes only the SNMPv3 security related tables. 1555 Using these views, it is possible to allow access to the RMON view for 1556 users Joe and Josephine (the RMON administrators), and access to the 1557 SNMPv3 security tables for user Adam (the SNMP security Administrator). 1559 Views can be set up with wildcards. For a table that is indexed using IP 1560 addresses, Joe can be allowed access to all rows in given RMON tables 1561 (e.g. the RMON hostTable) that are in the subnet 10.2.x.x, while 1562 Josephine is given access to all rows for subnet 10.200.x.x. 1564 Views filter at the name level (OIDs), not at the value level, so 1565 defining views based on the values of non-index data is not supported. 1566 In this example, were the IP address to have been used merely as a data 1567 item rather than an index, it would not be possible to utilize view- 1568 based access control to achieve the desired objective (delegation of 1569 administrative responsibility according to subnet). 1571 View-based access control is independent of message version. It can be 1572 utilized by entities using SNMPv1, SNMPv2c, or SNMPv3 message formats. 1574 7.3.5. Inter-domain access-control alternatives 1576 As the number of network devices within the shared use or roaming 1577 network grows, the polling model of data collection becomes increasingly 1578 impractical since most devices will not carry data relating to the 1579 polling organization. As a result, shared-use networks or roaming 1580 associations relying on SNMP-based accounting have generally collected 1581 data for all organizations and then sorted the resulting session records 1582 for delivery to each organization. While functional, this approach will 1583 typically result in increased processing delay as the number of 1584 organizations and data records grows. 1586 This issue can be addressed in SNMP using the event-driven, event- 1587 driven polling or event-driven batching approaches. Traps and Informs 1588 permit SNMP-enabled devices to notify domains that have accounting data 1589 awaiting collection. SNMP Applications [39] defines a standard module 1590 for managing notifications. 1592 To use the event-driven approaches, the device must be able to determine 1593 when information is available for a domain. Domain-specific data can be 1594 differentiated at the SNMP agent level through the use of the domain as 1595 an index, and the separation of data into domain-specific contexts. 1597 7.3.5.1. Domain as index 1599 View-based access control [40] allows multiple fine-grained views of an 1600 SNMP MIB to be assigned to specific groups of users, such that access 1601 rights to the included data elements depend on the identity of the user 1602 making the request. 1604 For example, all users of bigco.com which are allowed access to the 1605 device would be defined in the User-based security MIB module (or other 1606 security model MIB module). For simplicity in administering access 1607 control, the users can be grouped using a vacmGroupName, e.g. bigco. A 1608 view of a subset of the data objects in the MIB can be defined in the 1609 vacmViewFamilyTreeTable. A vacmAccessTable pairs groups and views. For 1610 messages received from users in the bigco group, access would only be 1611 provided to the data permitted to be viewed by bigco users, as defined 1612 in the view family tree. This requires that each domain accessing the 1613 data be given one or more separate vacmGroupNames, an appropriate 1614 ViewTable be defined, and the vacmAccessTable be configured for each 1615 group. 1617 Views filter at the name (OID) level, not at the data (value) level. 1618 When using views to filter by domain it is necessary to use the domain 1619 as an index. Standard view-based access control is not designed to 1620 filter based on the values on non-indexed fields. 1622 For example, a table of session data could be indexed by record number 1623 and domain, allowing a view to be defined that could restrict access to 1624 bigco data to the administrators of the bigco domain. 1626 An advantage of using domains as an index is that this technique can be 1627 used with SNMPv1 and SNMPv2c agents as well as with SNMPv3 agents. A 1628 disadvantage is that the MIB modules must be specifically designed for 1629 this purpose. Since existing MIB modules rarely use the domain as an 1630 index, domain separation cannot be enabled within legacy MIB modules 1631 using this technique. 1633 SNMP does support a RowPointer convention that could be used to define a 1634 new table, indexed by domain, which holds tuples between the domain and 1635 existing rows of data. This would introduce issues of synchronization 1636 between tables. 1638 7.3.5.2. Contexts 1640 ContextNames can be used to differentiate multiple instances of a MIB 1641 module within an engine. 1643 Individual domains, such as bigco.com, could be mapped to logical 1644 contexts, such as a bigco context. The agent would need to create and 1645 recognize new contexts and to know which instrumentation is associated 1646 with the logical context. The agent needs to collect accounting data by 1647 domain and make the data accessible via distinct contexts, so that 1648 access control can be applied to the context to prevent disclosure of 1649 sensitive information to the wrong domain. The VACM access control views 1650 are applied relative to the context, so an operation can be permitted or 1651 denied a user based on the context which contains the data. 1653 Domain separation is handled by using contextName to differentiate 1654 multiple virtual tables. For example, if accounting data has been 1655 collected on users with the bigco.com and smallco.com domains, then a 1656 separate virtual instance of the accounting session record table would 1657 exist for each domain, and each domain would have a corresponding 1658 contextName. When a get-bulk request is made with a contextName of 1659 bigco, then data from the virtual table in the bigco context, i.e. 1660 corresponding to the bigco.com domain, would be returned. 1662 There are a number of design approaches to creating new contexts and 1663 associating the contexts with appropriate instrumentation, most notably 1664 a sub-agent approach and a manager-configured MIB approach. 1666 AgentX [51], which standardizes a registration protocol between sub- 1667 agents and master agents to simplify SNMP agent implementation, allows 1668 for the creation and recognition of new contextNames when a subagent 1669 registers to provide support for a particular MIB subtree range. The 1670 sub-agent knows how to support a particular functionality, e.g. 1671 instrumentation exposed via a range of MIB objects. Based on values 1672 detected in the data, such as source=bigco.com, the sub-agent could 1673 determine that a new domain needed to be tracked and create the 1674 appropriate context for the collection of the data, plus the appropriate 1675 access control entries. The determination could be table-driven, using 1676 MIB configuration. 1678 A manager-driven approach could use a MIB module to predefine 1679 contextNames corresponding to the domains of interest, and to indicate 1680 which objects should be collected, how to differentiate to which domain 1681 the data should be applied based on a specified condition, and what 1682 access control rules apply to the context. 1684 Either technique could associate existing MIB modules to domain-specific 1685 contexts, so domain separation can be applied to MIB modules not 1686 specifically designed with domain separation in mind. Legacy agents 1687 would not be designed to do this, so they would need to be updated to 1688 support inter-domain separation and VACM access control. 1690 The use of contextNames for inter-domain separation represents new 1691 territory, so careful consideration would be needed in designing the MIB 1692 modules and applications to provide domain to context and context to 1693 instrumentation mappings, and to ensure that security is not weakened. 1695 7.3.6. Outstanding issues 1697 There are issues that arise when using SNMP for transfer of bulk data, 1698 including issues of latency, network overhead, and table retrieval, as 1699 discussed in [49]. 1701 In accounting applications, management stations often must retrieve 1702 large tables. Latency can be high, even with the get-bulk operation, 1703 because the response must fit into the largest supported packet size, 1704 requiring multiple round-trips. Transfers may be serialized and the 1705 resulting latency will be a combination of multiple round-trip times, 1706 possible timeout and re-transmission delays and processing overhead, 1707 which may result in unacceptable performance. Since data may change 1708 during the course of multiple retrievals, it can be difficult to get a 1709 consistent snapshot. 1711 For bulk transfers, SNMP network overhead can be high due to the lack of 1712 compression, inefficiency of BER encoding, the transmission of 1713 redundant OID prefixes, and the "get-bulk overshoot problem". In bulk 1714 transfer of a table, the OIDs transferred are redundant: all OID 1715 prefixes up to the column number are identical, as are the instance 1716 identifier postfixes of all entries of a single table row. Thus it may 1717 be possible to reduce this redundancy by compressing the OIDs, or by not 1718 transferring an OID with each variable. 1720 The "get-bulk overshoot problem", described in reference [50], occurs 1721 when using the get-bulk PDU. The problem is that the manager typically 1722 does not know the number of rows in the table. As a result, it must 1723 either request too many rows, retrieving unneeded data, or too few, 1724 resulting in the need for multiple get-bulk requests. Note that the 1725 "get-bulk overshoot" problem may be preventable on the agent side. 1726 Reference [41] states that an agent can terminate the get-bulk because 1727 of "local constraints" (see items 1 and 3 on pages 15/16 of [41]). This 1728 could be interpreted to mean that it is possible to stop at the end of a 1729 table. 1731 7.3.6.1. Ongoing research 1733 To address issues of latency and efficiency, the Network Management 1734 Research Group (NMRG) was formed within the Internet Research Task Force 1735 (IRTF). Since the NMRG work is research and is not on the standards 1736 track, it should be understood that the NMRG proposals may never be 1737 standardized, or may change substantially during the standardization 1738 process. As a result, these proposals represent works in progress and 1739 are not readily available for use. 1741 The proposals under discussion in the IRTF Network Management Research 1742 Group (NMRG) are described in [46]. These include an SNMP-over-TCP 1743 transport mapping, described in [47]; SNMP payload compression, 1744 described in [48]; and the addition of a "get subtree" PDU or the 1745 subtree retrieval MIB [50]. 1747 The SNMP-over-TCP transport mapping may result in substantial latency 1748 reductions in table retrieval. The latency reduction of an SNMP-over-TCP 1749 transport mapping will likely manifest itself primarily in the polling, 1750 event-driven polling and event-driven batching modes. 1752 Payload compression methods include compression of the IP packet, as 1753 described in [5] or compression of the SNMP payload, described in [48]. 1755 Proposed improvements to table retrieval include a subtree retrieval MIB 1756 and the addition of a get-subtree PDU. The subtree retrieval MIB [50] 1757 requires no changes to the SNMP protocol or SNMP protocol engine, so it 1758 can be implemented and deployed more easily than a change to the 1759 protocol. The addition of a get-subtree PDU implies changes to the 1760 protocol and to the engines of all SNMP entities which would support it. 1761 Since it may be possible to address the "get-bulk overshoot problem" 1762 without changes to the SNMP protocol, the necessity of this modification 1763 is controversial. 1765 Reference [49] also discusses file-based storage of SNMP data, and use 1766 of an FTP MIB, to enable storage of SNMP data in non-volatile storage, 1767 and subsequent bulk transfer via FTP. This approach would require 1768 implementation of additional MIB modules as well as FTP, and requires 1769 separate security mechanisms such as IPSEC to provide authentication, 1770 replay, integrity protection and confidentiality for the data in 1771 transit. The file-based transfer approach has an important benefit - 1772 compatibility with non-volatile storage. 1774 Issues of legacy support exist with the NMRG proposals. Devices which do 1775 not implement the new functionality would need to be accommodated. This 1776 is especially problematic for proxy forwarders, which may need to act as 1777 translators between new and legacy entities. In these situations, the 1778 overhead of translation may offset the benefits of the new technologies. 1780 7.3.6.2. On-going security extension research 1782 In order to simplify key management and enable use of certificate-based 1783 security in SNMPv3, a Kerberos Security Model (KSM) for SNMPv3 has been 1784 proposed in [44]. This draft is not on the standards track, and 1785 therefore is not yet readily available for use. 1787 Use of Kerberos with SNMPv3 requires storage of a key on the KDC for 1788 each device and domain, while dynamically generating a session key for 1789 conversations between domains and devices. In terms of stored keys, the 1790 KSM approach scales with the sum of devices and domains; in terms of 1791 dynamic session keys, it scales as the product of domains and devices. 1793 As Kerberos is extended to allow initial authentication via public key, 1794 as described in [42], and cross-realm authentication, as described in 1795 [43], the KSM inherits these capabilities. As a result, this approach 1796 may have potential to reduce or even eliminate the shared secret 1797 management problem. However, it should also be noted that certificate- 1798 based authentication can strain the limits of UDP packet sizes supported 1799 in SNMP implementations, so that alternate transport mappings may be 1800 required to support this. 1802 An IPSEC-based security model for SNMPv3 has been discussed. 1803 Implementation of such a security model would require the SNMPv3 engine 1804 to be able to retrieve the properties of the IPSEC security association 1805 used to protect the SNMPv3 traffic. This would include the security 1806 services invoked, as well as information relating to the other endpoint, 1807 such as the authentication method and presented identity and 1808 certificate. To date such APIs have not been widely implemented, and in 1809 addition, most IPSEC implementations only support machine certificates, 1810 which may not provide the required granularity of identification. Thus, 1811 an IPSEC-based security model for SNMPv3 would probably take several 1812 years to come to fruition. 1814 7.3.7. SNMP summary 1816 Given the wealth of existing accounting-related MIB modules, it is 1817 likely that SNMP will remain a popular accounting protocol for the 1818 foreseeable future. 1820 Support for notifications makes it possible to implement the event- 1821 driven, event-driven polling and event-driven batching models. This 1822 makes it possible to notify domains of available data rather than 1823 requiring them to poll for it, which is critical in shared use networks 1824 and roaming. 1826 Given the SNMPv3 security enhancements, it is desirable for SNMP-based 1827 intra-domain accounting implementations to upgrade to SNMPv3. Such an 1828 upgrade is virtually mandatory for inter-domain applications. 1830 In inter-domain accounting, the burden of managing SNMPv3 shared secrets 1831 can be reduced via the localized key capability or via implementation of 1832 a Proxy Forwarder. In the long term, alternative security models such as 1833 the Kerberos Security Model may further reduce the effort required to 1834 manage security and enable streamlined inter-domain operation. 1836 SNMP-based accounting has limitations in terms of efficiency and latency 1837 that may make it inappropriate for use in situations requiring low 1838 processing delay or low overhead. This includes usage sensitive billing 1839 applications where fraud detection may be required. These issues can be 1840 addressed via proposals under discussion in the IRTF Network Management 1841 Research Group (NMRG). The experimental SNMP over TCP transport mapping 1842 may prove helpful at reducing latency. Depending on the volume of data, 1843 some form of compression may also be worth considering. However, since 1844 these proposals are still in the research stage, and are not on the 1845 standards track, these capabilities are not readily available, and the 1846 specifications could change considerably before they reach their final 1847 form. 1849 SNMP supports separation of accounting data by domain, using either of 1850 two general approaches with the VACM access control model. The domain as 1851 index approach can be used if the desired MIB module supports domain 1852 indexing, or it can implemented using an additional table. The domain- 1853 context approach can be used in agents which support dynamic logical 1854 contexts and a domain-to-context and context-to-instrumentation mapping 1855 mechanism. Either approach can be supported using SNMPv1, SNMPv2c, or 1856 SNMPv3 messages, by utilizing the snmpCommunitytable [11] to provide a 1857 community-to-context mapping. 1859 8. Review of Accounting Data Transfer 1861 In order for session records to be transmitted between accounting 1862 servers, a transfer protocol is required. Transfer protocols in use 1863 today include SMTP, FTP, and HTTP. For a review of accounting 1864 attributes and record formats, see [45]. 1866 Reference [49] contains a discussion of alternative encodings for SMI 1867 data types, as well as alternative protocols for transmission of 1868 accounting data. For example, [49] describes how MIME tags and XML DTDs 1869 may be used for encoding of SNMP messages or SMI data types. This 1870 enables data from SNMP MIBs to be transported using any protocol that 1871 can encapsulate MIME or XML, including SMTP and HTTP. 1873 8.1. SMTP 1875 To date, few accounting management systems have been built on SMTP since 1876 the implementation of a store-and-forward message system has 1877 traditionally required access to non-volatile storage which has not been 1878 widely available on network devices. However, SMTP-based 1879 implementations have many desirable characteristics, particularly with 1880 regards to security. 1882 Accounting management systems using SMTP for accounting transfer will 1883 typically support batching so that message processing overhead will be 1884 spread over multiple accounting records. As a result, these systems 1885 result in per-active device state. Since accounting systems using SMTP 1886 as a transfer mechanism have access to substantial non-volatile storage, 1887 they can generate, compress if necessary, and store accounting records 1888 until they are transferred to the collection site. As a result, 1889 accounting systems implemented using SMTP can be highly efficient and 1890 scalable. Using IPSEC, TLS or Kerberos, hop-by-hop security services 1891 such as authentication, integrity protection and confidentiality can be 1892 provided. 1894 As described in [13] and [15], data object security is available for 1895 SMTP, and in addition, the facilities described in [12] make it possible 1896 to request and receive signed receipts, which enables non-repudiation as 1897 described in [12]-[17]. As a result, accounting systems utilizing SMTP 1898 for accounting data transfer are capable of satisfying the most 1899 demanding security requirements. However, such systems are not typically 1900 capable of providing low processing delay, although this may be 1901 addressed by the enhancements described in [20]. 1903 8.2. Other protocols 1905 File transfer protocols such as FTP and HTTP have been used for transfer 1906 of accounting data. For example, Reference [9] describes a means for 1907 representing ASN.1-based accounting data for storage on archival media. 1908 Through the use of the Bulk File MIB, accounting data from an SNMP MIB 1909 can be stored in ASN.1, bulk binary or Bulk ASCII format, and then 1910 subsequently retrieved as required using the FTP Client MIB. 1912 Given access to sufficient non-volatile storage, accounting systems 1913 based on record formats and transfer protocols can avoid loss of data 1914 due to long-duration network partitions, server failures or device 1915 reboots. Since it is possible for the transfer to be driven from the 1916 collection site, the collector can retry transfers until successful, or 1917 with HTTP may even be able to restart partially completed transfers. As 1918 a result, file transfer-based systems can be made highly reliable, and 1919 the batching of accounting records makes possible efficient transfers 1920 and application of required security services with lessened overhead. 1922 9. Summary 1924 As noted previously in this document, accounting applications vary in 1925 their security and reliability requirements. Some uses such as capacity 1926 planning may only require authentication, integrity and replay 1927 protection, and modest reliability. Other applications such as inter- 1928 domain usage-sensitive billing may require the highest degree of 1929 security and reliability, since in these cases the transfer of 1930 accounting data will lead directly to the transfer of funds. 1932 Since accounting applications do not have uniform security and 1933 reliability requirements, it is not possible to devise a single 1934 accounting protocol and set of security services that will meet all 1935 needs. Rather, the goal of accounting management should be to provide a 1936 set of tools that can be used to construct accounting systems meeting 1937 the requirements of an individual application. As a result, it is 1938 important to analyze a given accounting application to ensure that the 1939 methods chosen meet the security and reliability requirements of the 1940 application. 1942 Based on an analysis of the requirements, it appears that existing 1943 deployed protocols are capable of meeting the requirements for intra- 1944 domain capacity planning and non-usage sensitive billing. In these 1945 applications efficient transfer of bulk data is useful although not 1946 critical. Thus, it is possible to use SNMPv3 to satisfy these 1947 requirements, without the NMRG extensions. These include TCP transport 1948 mapping, sub-tree retrieval, and OID compression. 1950 In inter-domain capacity planning and non-usage sensitive billing, the 1951 security and reliability requirements are greater. As a result, no 1952 existing deployed protocol satisfies the requirements. For example, 1953 existing protocols lack data object security support and extensions to 1954 improve scalability of inter-domain authentication are needed, such as 1955 the Kerberos Security Model (KSM) for SNMPv3. 1957 For usage sensitive billing, as well as cost allocation and auditing 1958 applications, the reliability requirement are greater. Here transport 1959 layer reliability is required to provide robustness against packet loss, 1960 as well as application layer acknowledgments to provide robustness 1961 against accounting server failures. SNMP operations with the exception 1962 of InforRequest provide application layer acknowledgments, and the TCP 1963 transport mapping proposed by NMRG provides robustness against packet 1964 loss. Inter-domain operation can benefit from data object security 1965 (which no existing protocol provides) as well as inter-domain security 1966 model enhancements (such as the KSM). 1968 Where high-value sessions are involved, such as in roaming, Mobile IP, 1969 or telephony, it may be necessary to put bounds on processing delay. 1970 This implies the need to reduce latency. As a result, the NMRG 1971 extensions are required in time sensitive billing applications, 1972 including TCP transport mapping, get-subtree capabilities and OID 1973 compression. High reliability is also required in this application, 1974 implying the need for application layer as well as transport layer 1975 acknowledgments. SNMPv3 with the NMRG extensions and security 1976 scalability improvements such as the KSM can satisfy the requirements in 1977 intra-domain use. 1979 However, in inter-domain use, additional security precautions such as 1980 data object security and receipt support are required. No existing 1981 protocol can meet these requirements. A summary is given in the table 1982 on the next page. 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 | | | | 1986 | Usage | Intra-domain | Inter-domain | 1987 | | | | 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 | | | | 1990 | Capacity | SNMPv3 & | SNMPv3 &<* | 1991 | Planning | RADIUS #%@ | | 1992 | | TACACS+ @ | | 1993 | | | | 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | | | | 1996 | Non-usage | SNMPv3 & | SNMPv3 &<* | 1997 | Sensitive | RADIUS #%@ | | 1998 | Billing | TACACS+ @ | | 1999 | | | | 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 | | | | 2002 | Usage | | | 2003 | Sensitive | | | 2004 | Billing, | SNMPv3 &>$ | SNMPv3 &<>*$ | 2005 | Cost | TACACS+ &$@ | | 2006 | Allocation & | | | 2007 | Auditing | | | 2008 | | | | 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 | | | | 2011 | Time | | | 2012 | Sensitive | SNMPv3 &>$ | No existing | 2013 | Billing, | | protocol | 2014 | fraud | | | 2015 | detection, | | | 2016 | roaming | | | 2017 | | | | 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 Key 2021 # = lacks confidentiality support 2022 * = lacks data object security 2023 % = limited robustness against packet loss 2024 & = lacks application layer acknowledgment (e.g. SNMP InformRequest) 2025 $ = requires non-volatile storage 2026 @ = lacks batching support 2027 < = lacks certificate support (KSM, work in progress) 2028 > = lacks support for large packet sizes (TCP transport mapping, experimental) 2030 10. Acknowledgments 2032 The authors would like to thank Bert Wijnen (Lucent), Keith McCloghrie 2033 (Cisco Systems), Jan Melen (Ericsson) and Jarmo Savolainen (Ericsson) 2034 for useful discussions of this problem space. 2036 11. References 2038 [1] Aboba, B., Lu J., Alsop J., Ding J., and W. Wang, "Review of 2039 Roaming Implementations", RFC 2194, September 1997. 2041 [2] Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming 2042 Protocols", RFC 2477, January 1999. 2044 [3] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 2045 Authentication Dial In User Service (RADIUS)", RFC 2138, April, 2046 1997. 2048 [4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. 2050 [5] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP Payload 2051 Compression Protocol (IPComp)", RFC 2393, December 1998. 2053 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2054 Levels", BCP 14, RFC 2119, March 1997. 2056 [7] Information Sciences Institute, "Transmission Control Protocol", 2057 RFC 793, September 1981. 2059 [8] Aboba, B., and M. Beadles, "The Network Access Identifier", 2060 RFC 2486, January 1999. 2062 [9] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Accounting 2063 Information for ATM Networks", RFC 2512, February 1999. 2065 [10] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Managed 2066 Objects for Controlling the Collection and Storage of Accounting 2067 Information for Connection-Oriented Networks", RFC 2513, February 2068 1999. 2070 [11] Frye, R., Levi, D., Routhier, S., Wijnen, B., "Coexistence between 2071 Version 1, Version 2, and Version 3 of the Internet-standard 2072 Management Framework", RFC 2576, March 2000. 2074 [12] Fajman, R., "An Extensible Message Format for Message Disposition 2075 Notifications", RFC 2298, March 1998. 2077 [13] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2078 2015, October 1996. 2080 [14] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting 2081 of Mail System Administrative Messages", RFC 1892, January 1996. 2083 [15] Galvin, J., et al. "Security Multiparts for MIME: Multi- 2084 part/Signed and Multipart/Encrypted", RFC 1847, October 1995. 2086 [16] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 2087 1995. 2089 [17] Borenstein, N., Freed, N, "MIME (Multipurpose Internet Mail 2090 Extensions) Part One: Mechanisms for Specifying and Describing 2091 the Format of Internet Message Bodies", RFC 1521, December 1993. 2093 [18] Rose, M.T., The Simple Book, Second Edition, Prentice Hall, Upper 2094 Saddle River, NJ, 1996. 2096 [19] Case, J., Mundy, R., Partain, D., Stewart, B., "Introduction to 2097 Version 3 of the Internet-standard Network Management Framework", 2098 RFC 2570, April 1999. 2100 [20] Klyne, G., "Timely Delivery for Facsimile Using Internet Mail", 2101 Internet draft (work in progress), draft-ietf-fax-timely- 2102 delivery-00.txt, October 1999. 2104 [21] Johnson, H. T., Kaplan, R. S., Relevance Lost: The Rise and Fall of 2105 Management Accounting, Harvard Business School Press, Boston, 2106 Massachusetts, 1987. 2108 [22] Horngren, C. T., Foster, G., Cost Accounting: A Managerial 2109 Emphasis. Prentice Hall, Englewood Cliffs, New Jersey, 1991. 2111 [23] Kaplan, R. S., Atkinson, Anthony A., Advanced Management 2112 Accounting, Prentice Hall, Englewood Cliffs, New Jersey, 1989. 2114 [24] Cooper, R., Kaplan, R. S., The Design of Cost Management Systems. 2115 Prentice Hall, Englewood Cliffs, New Jersey, 1991. 2117 [25] Rigney, C., Willens, S., Calhoun, P., "RADIUS Extensions", draft- 2118 ietf-radius-ext-07.txt, Internet Draft (work in progress), February 2119 2000. 2121 [26] Stewart, R. R., et al., "Simple Control Transmission Protocol", 2122 Internet draft (work in progress), draft-ietf-sigtran-sctp-05.txt, 2123 January 2000. 2125 [27] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 2126 Describing SNMP Management Frameworks", RFC 2571, April 1999. 2128 [28] Rose, M., and K. McCloghrie, "Structure and Identification of 2129 Management Information for TCP/IP-based Internets", RFC 1155, May 2130 1990. 2132 [29] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 2133 March 1991. 2135 [30] M. Rose, "A Convention for Defining Traps for use with the SNMP", 2136 RFC 1215, March 1991. 2138 [31] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 2139 of Management Information for Version 2 of the Simple Network 2140 Management Protocol (SNMPv2)", RFC 1902, January 1996. 2142 [32] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 2143 Conventions for Version 2 of the Simple Network Management Protocol 2144 (SNMPv2)", RFC 1903, January 1996. 2146 [33] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance 2147 Statements for Version 2 of the Simple Network Management Protocol 2148 (SNMPv2)", RFC 1904, January 1996. 2150 [34] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 2151 Management Protocol", RFC 1157, May 1990. 2153 [35] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 2154 "Introduction to Community-based SNMPv2", RFC 1901, January 1996. 2156 [36] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport 2157 Mappings for Version 2 of the Simple Network Management Protocol 2158 (SNMPv2)", RFC 1906, January 1996. 2160 [37] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 2161 Processing and Dispatching for the Simple Network Management 2162 Protocol (SNMP)", RFC 2572, April 1999. 2164 [38] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 2165 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2166 2574, April 1999. 2168 [39] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2169 2573, April 1999. 2171 [40] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 2172 Control Model (VACM) for the Simple Network Management Protocol 2173 (SNMP)", RFC 2575, April 1999. 2175 [41] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 2176 Operations for Version 2 of the Simple Network Management Protocol 2177 (SNMPv2)", RFC 1905, January 1996. 2179 [42] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, 2180 J., Trostle, J., "Public Key Cryptography for Initial 2181 Authentication in Kerberos", Internet draft (work in progress), 2182 draft-ietf-cat-kerberos-pk-init-09.txt, June 1999. 2184 [43] Tung, B., Ryutov, T., Neuman, C., Tsudik, G., Sommerfeld, B., 2185 Medvinsky, A., Hur, M., "Public Key Cryptography for Cross-Realm 2186 Authentication in Kerberos", Internet draft (work in progress), 2187 draft-ietf-cat-kerberos-pk-cross-04.txt, June 1999. 2189 [44] Hornstein, K., Hardaker, W., "A Kerberos Security Model for 2190 SNMPv3", Internet draft (work in progress), draft-hornstein- 2191 snmpv3-ksm-00.txt, June 1999. 2193 [45] Brownlee, N., Blount, A., "Accounting Attributes and Record 2194 Formats", Internet draft (work in progress), draft-ietf-aaa- 2195 accounting-attributes-04.txt, June 2000. 2197 [46] Network Management Research Group Web page, http://www.ibr.cs.tu- 2198 bs.de/projects/nmrg/ 2200 [47] Schoenwaelder, J.,"SNMP-over-TCP Transport Mapping", Internet draft 2201 (work in progress), draft-irtf-nmrg-snmp-tcp-03.txt, April 2000. 2203 [48] Schoenwaelder, J.,"SNMP Payload Compression", Internet draft (work 2204 in progress), draft-irtf-nmrg-snmp-compression-00.txt, June 1999. 2206 [49] Sprenkels, R., Martin-Flatin, J.,"Bulk Transfers of MIB Data", 2207 Simple Times, http://www.simple-times.org/pub/simple- 2208 times/issues/7-1.html, March 1999. 2210 [50] Thaler, D., "Get Subtree Retrieval MIB", Internet draft (work in 2211 progress), draft-irtf-nmrg-get-subtree-mib-00.txt, October 1999. 2213 [51] Daniele, M., Wijnen, B., Ellison, M., Francisco, D., "Agent 2214 Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000. 2216 12. Author's Addresses 2218 Bernard Aboba 2219 Microsoft Corporation 2220 One Microsoft Way 2221 Redmond, WA 98052 2222 USA 2224 Phone: +1 425 936 6605 2225 EMail: bernarda@microsoft.com 2227 Jari Arkko 2228 Oy LM Ericsson Ab 2229 02420 Jorvas 2230 Finland 2232 Phone: +358 40 5079256 2233 EMail: Jari.Arkko@ericsson.com 2235 David Harrington 2236 Cabletron Systems Inc. 2237 P.O.Box 5005 2238 Rochester NH 03867-5005 2239 USA 2241 Phone: +1 603 337 7357 2242 EMail: dbh@cabletron.com 2244 13. Intellectual Property Statement 2246 The IETF takes no position regarding the validity or scope of any 2247 intellectual property or other rights that might be claimed to pertain 2248 to the implementation or use of the technology described in this 2249 document or the extent to which any license under such rights might or 2250 might not be available; neither does it represent that it has made any 2251 effort to identify any such rights. Information on the IETF's 2252 procedures with respect to rights in standards-track and standards- 2253 related documentation can be found in BCP-11. Copies of claims of 2254 rights made available for publication and any assurances of licenses to 2255 be made available, or the result of an attempt made to obtain a general 2256 license or permission for the use of such proprietary rights by 2257 implementors or users of this specification can be obtained from the 2258 IETF Secretariat. 2260 The IETF invites any interested party to bring to its attention any 2261 copyrights, patents or patent applications, or other proprietary rights 2262 which may cover technology that may be required to practice this 2263 standard. Please address the information to the IETF Executive 2264 Director. 2266 14. Full Copyright Statement 2268 Copyright (C) The Internet Society (2000). All Rights Reserved. 2269 This document and translations of it may be copied and furnished to 2270 others, and derivative works that comment on or otherwise explain it or 2271 assist in its implementation may be prepared, copied, published and 2272 distributed, in whole or in part, without restriction of any kind, 2273 provided that the above copyright notice and this paragraph are included 2274 on all such copies and derivative works. However, this document itself 2275 may not be modified in any way, such as by removing the copyright notice 2276 or references to the Internet Society or other Internet organizations, 2277 except as needed for the purpose of developing Internet standards in 2278 which case the procedures for copyrights defined in the Internet 2279 Standards process must be followed, or as required to translate it into 2280 languages other than English. The limited permissions granted above are 2281 perpetual and will not be revoked by the Internet Society or its 2282 successors or assigns. This document and the information contained 2283 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 2284 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 2285 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2286 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2287 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2289 15. Expiration Date 2291 This memo is filed as , and expires January 2292 1, 2001.