idnits 2.17.1 draft-ietf-aaa-acct-03.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. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 118 has weird spacing: '...tion be measu...' == Line 548 has weird spacing: '...is only one a...' == Line 631 has weird spacing: '...ible to overw...' == Line 760 has weird spacing: '..., or on expir...' == Line 771 has weird spacing: '...condary serve...' == (12 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: '5' is defined on line 1918, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1922, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1925, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1928, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1934, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1949, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1955, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1958, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1962, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1966, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1974, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1978, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 1981, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 1995, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 1998, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 2002, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 2005, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 2008, but no explicit reference was found in the text == Unused Reference: '32' is defined on line 2012, but no explicit reference was found in the text == Unused Reference: '33' is defined on line 2016, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 2020, but no explicit reference was found in the text == Unused Reference: '35' is defined on line 2023, but no explicit reference was found in the text == Unused Reference: '36' is defined on line 2026, but no explicit reference was found in the text == Unused Reference: '37' is defined on line 2030, but no explicit reference was found in the text == Unused Reference: '39' is defined on line 2038, but no explicit reference was found in the text == Unused Reference: '41' is defined on line 2045, but no explicit reference was found in the text == Unused Reference: '42' is defined on line 2049, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '3') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '4') (Obsoleted by RFC 2866) ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2486 (ref. '8') (Obsoleted by RFC 4282) == Outdated reference: A later version (-08) exists of draft-ietf-roamops-actng-05 ** Obsolete normative reference: RFC 2298 (ref. '12') (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 1892 (ref. '14') (Obsoleted by RFC 3462) == Outdated reference: A later version (-17) exists of draft-ietf-ediint-as1-11 == Outdated reference: A later version (-09) exists of draft-ietf-ediint-req-08 ** Obsolete normative reference: RFC 1521 (ref. '19') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) == Outdated reference: A later version (-05) exists of draft-ietf-fax-timely-delivery-00 -- Unexpected draft version: The latest known version of draft-ietf-radius-ext is -06, but you're referring to -07. ** Obsolete normative reference: RFC 2571 (ref. '27') (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 1902 (ref. '31') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '32') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '33') (Obsoleted by RFC 2580) ** Obsolete normative reference: RFC 1906 (ref. '36') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (ref. '37') (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (ref. '38') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2573 (ref. '39') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (ref. '40') (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 1905 (ref. '41') (Obsoleted by RFC 3416) == Outdated reference: A later version (-04) exists of draft-ietf-aaa-accounting-attributes-02 == Outdated reference: A later version (-09) exists of draft-irtf-nmrg-snmp-tcp-01 == Outdated reference: A later version (-01) exists of draft-irtf-nmrg-snmp-compression-00 ** Obsolete normative reference: RFC 2393 (ref. '50') (Obsoleted by RFC 3173) == Outdated reference: A later version (-02) exists of draft-hornstein-snmpv3-ksm-00 == Outdated reference: A later version (-34) exists of draft-ietf-cat-kerberos-pk-init-09 == Outdated reference: A later version (-08) exists of draft-ietf-cat-kerberos-pk-cross-04 == Outdated reference: A later version (-01) exists of draft-irtf-nmrg-get-subtree-mib-00 == Outdated reference: A later version (-13) exists of draft-ietf-sigtran-sctp-05 Summary: 26 errors (**), 0 flaws (~~), 46 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 2 May 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 -03 draft: rewrote SNMPv3 contextName section. 55 -02 draft: added discussion of accounting proxies. Expanded discussion 56 of accounting server faults and failover. Revised section on SNMPv3 57 contextName. Revised requirements and evaluation tables. Fixed spelling 58 mistakes. 60 4. Table of Contents 62 1. Status of this Memo 1 63 2. Copyright notice 1 64 3. Abstract 1 65 4. Table of Contents 2 66 5. Introduction 3 67 5.1 Terminology 3 68 5.2 Accounting management architecture 5 69 5.3 Accounting management objectives 6 70 5.4 Intra-domain and inter-domain accounting 9 71 5.5 Accounting record production 10 72 5.6 Requirements summary 12 73 6. Scaling and reliability 13 74 6.1 Fault resilience 13 75 6.2 Resource consumption 21 76 6.3 Data collection models 24 77 7. Review of Accounting Protocols 30 78 7.1 RADIUS 30 79 7.2 TACACS+ 31 80 7.3 SNMP 31 81 8. Review of Accounting Data Transfer 40 82 8.1 SMTP 40 83 8.2 Other protocols 41 84 9. Summary 41 85 10. Acknowledgments 43 86 11. References 44 87 12. Authors' Addresses 48 88 13. Intellectual Property Statement 48 89 14. Full Copyright Statement 49 90 15. Expiration date 49 92 5. Introduction 94 The field of Accounting Management is concerned with the collection of 95 resource consumption data for the purposes of capacity and trend 96 analysis, cost allocation, auditing, and billing. This document 97 describes each of these problems, and discusses the issues involved in 98 design of modern accounting systems. 100 Since accounting applications do not have uniform security and 101 reliability requirements, it is not possible to devise a single 102 accounting protocol and set of security services that will meet all 103 needs. Thus the goal of accounting management is to provide a set of 104 tools that can be used to meet the requirements of each application. 105 This document describes the currently available tools as well as the 106 state of the art in accounting protocol design. A companion document, 107 draft-ietf-aaa-accounting-attributes-03.txt, reviews the state of the 108 art in accounting attributes and record formats. 110 5.1. Terminology 112 This document frequently uses the following terms: 114 Accounting 115 The collection of resource consumption data for the purposes 116 of capacity and trend analysis, cost allocation, auditing, and 117 billing. Accounting management requires that resource 118 consumption be measured, rated, assigned, and communicated 119 between appropriate parties. 121 Archival accounting 122 In archival accounting, the goal is to collect all accounting 123 data, to reconstruct missing entries as best as possible in 124 the event of data loss, and to archive data for a mandated 125 time period. It is "usual and customary" for these systems to 126 be engineered to be very robust against accounting data loss. 127 Legal or financial requirements frequently mandate archival 128 accounting practices, and may often dictate that data be kept 129 confidential, regardless of whether it is to be used for 130 billing purposes or not. 132 Rating The act of determining the price to be charged for use of a 133 resource. 135 Billing The act of preparing an invoice. 137 Usage sensitive billing 138 A billing process that depends on usage information to prepare 139 an invoice can be said to be usage-sensitive. In contrast, a 140 process that is independent of usage information is said to be 141 non-usage-sensitive. 143 Auditing The act of verifying the correctness of a procedure. In order 144 to be able to conduct an audit it is necessary to be able to 145 definitively determine what procedures were actually carried 146 out so as to be able to compare this to the recommended 147 process. Accomplishing this may require security services such 148 as authentication and integrity protection. 150 Cost Allocation 151 The act of allocating costs between entities. Note that cost 152 allocation and rating are fundamentally different processes. 153 In cost allocation the objective is typically to allocate a 154 known cost among several entities. In rating the objective is 155 to determine the amount to be charged for use of a resource. 156 In cost allocation, the cost per unit of resource may need to 157 be determined; in rating, this is typically a given. 159 Interim accounting 160 An interim accounting packet provides a snapshot of usage 161 during a user's session. This may be useful in the event of a 162 device reboot or other network problem that prevents the 163 reception or generation of a session summary packet or session 164 record. Interim accounting packets can always be summarized 165 without the loss of information. 167 Session record 168 A session record represents a summary of the resource 169 consumption of a user over the entire session. Accounting 170 gateways creating the session record may do so by processing 171 interim accounting events or accounting events from several 172 devices serving the same user. 174 Accounting Protocol 175 A protocol used to convey data for accounting purposes. 177 Intra-domain accounting 178 Intra-domain accounting involves the collection of information 179 on resource usage within an administrative domain, for use 180 within that domain. In intra-domain accounting, accounting 181 packets and session records typically do not cross 182 administrative boundaries. 184 Inter-domain accounting 185 Inter-domain accounting involves the collection of information 186 on resource usage within an administrative domain, for use 187 within another administrative domain. In inter-domain 188 accounting, accounting packets and session records will 189 typically cross administrative boundaries. 191 Real-time accounting 192 Real-time accounting involves the processing of information on 193 resource usage within a defined time window. Time constraints 194 are typically imposed in order to limit financial risk. 196 Accounting server 197 The accounting server receives accounting data from devices 198 and translates it into session records. The accounting server 199 may also take responsibility for the routing of session 200 records to interested parties. 202 5.2. Accounting management architecture 204 The accounting management architecture involves interactions between 205 network devices, accounting servers, and billing servers. The network 206 device collects resource consumption data in the form of accounting 207 metrics. This information is then transferred to an accounting server. 208 Typically this is accomplished via an accounting protocol, although it 209 is also possible for devices to generate their own session records. 211 The accounting server then processes the accounting data received from 212 the network device. This processing may include summarization of interim 213 accounting information, elimination of duplicate data, or generation of 214 session records. 216 The processed accounting data is then submitted to a billing server, 217 which typically handles rating and invoice generation, but may also 218 carry out auditing, cost allocation, trend analysis or capacity planning 219 functions. Session records may be batched and compressed by the 220 accounting server prior to submission to the billing server in order to 221 reduce the volume of accounting data and the bandwidth required to 222 accomplish the transfer. 224 One of the functions of the accounting server is to distinguish between 225 inter and intra-domain accounting events and to route them 226 appropriately. Intra-domain accounting events are typically routed to 227 the local billing server, while inter-domain accounting events will be 228 routed to accounting servers operating within other administrative 229 domains. While it is not required that session record formats used in 230 inter and intra-domain accounting be the same, this is desirable, since 231 it eliminates translations that would otherwise be required. 233 The diagram below illustrates the accounting management architecture: 235 +------------+ 236 | | 237 | Network | 238 | Device | 239 | | 240 +------------+ 241 | 242 Accounting | 243 Protocol | 244 | 245 V 246 +------------+ +------------+ 247 | | | | 248 | Org B | Inter-domain | Org A | 249 | Acctg. |<----------------------------->| Acctg. | 250 | Server | session records | Server | 251 | | | | 252 +------------+ +------------+ 253 | | 254 | Intra-domain | 255 Transfer | session records | 256 Protocol | | 257 | | 258 V V 259 +------------+ +------------+ 260 | | | | 261 | Org B | | Org A | 262 | Billing | | Billing | 263 | Server | | Server | 264 | | | | 265 +------------+ +------------+ 267 5.3. Accounting management objectives 269 Accounting Management involves the collection of resource consumption 270 data for the purposes of capacity and trend analysis, cost allocation, 271 auditing, billing. Each of these tasks has different requirements. 273 5.3.1. Trend analysis and capacity planning 275 In trend analysis and capacity planning, the goal is typically a 276 forecast of future usage. Since such forecasts are inherently 277 imperfect, high reliability is typically not required, and moderate 278 packet loss may be tolerable. 280 In certain cases, it may be desirable to use statistical sampling 281 techniques to reduce data collection requirements while still providing 282 the forecast with the desired statistical accuracy. Such a sampling 283 process may tolerate high packet loss as long as bias is not introduced. 285 The security requirements for trend analysis and capacity planning 286 depend on the circumstances of data collection and the sensitivity of 287 the data. Additional security services may be required when data is 288 being transferred between administrative domains. For example, when 289 information is being collected and analyzed within the same 290 administrative domain, integrity protection and authentication may be 291 used in order to guard against collection of invalid data. In inter- 292 domain applications confidentiality may be desirable to guard against 293 snooping by third parties. 295 5.3.2. Billing 297 When accounting data is used for billing purposes, the requirements 298 depend on whether the billing process is usage-sensitive or not. 300 5.3.2.1. Non-usage sensitive billing 302 Since by definition, non-usage-sensitive billing does not require usage 303 information, in theory all accounting data can be lost without affecting 304 the billing process. Of course this would also affect other tasks such 305 as trend analysis or auditing, so that such wholesale data loss would 306 still be unacceptable. 308 5.3.2.2. Usage-sensitive billing 310 Since usage-sensitive billing processes depend on usage information, 311 packet loss may translate directly to revenue loss. As a result, the 312 billing process may need to meet requirements arising from financial 313 reporting standards, or legal requirements, and therefore an archival 314 accounting approach may be required. 316 Usage-sensitive systems may also have additional requirements relating 317 to processing delay. Today credit risk is commonly managed by 318 computerized fraud detection systems that are designed to detect unusual 319 activity. While efficiency concerns might otherwise dictate batched 320 transmission of accounting data, where it is desirable to minimize 321 financial risk, a different approach may be required. 323 Since financial exposure increases with processing delay, it may be 324 necessary to transmit each event individually or to minimize batch size, 325 to require application layer acknowledgment before providing service, or 326 even to utilize quality of service techniques to minimize queuing 327 delays. 329 The degree of financial exposure is application-dependent. For dial-up 330 Internet access from a local provider, charges are typically low and 331 therefore the risk of loss is small. However, in the case of dial-up 332 roaming or voice over IP, time-based charges may be substantial and 333 therefore the risk of fraud is larger. In such situations it is highly 334 desirable to quickly detect unusual account activity, and it may be 335 desirable for authorization to depend on ability to pay. In situations 336 where valuable resources can be reserved, or where charges can be high, 337 very large bills may be rung up quickly, and processing may need to be 338 completed within a defined time window in order to limit exposure. 340 Since in usage-sensitive systems, accounting data translates into 341 revenue, the security and reliability requirements are greater. Due to 342 financial and legal requirements such systems need to be able to survive 343 an audit. Thus security services such as authentication, integrity and 344 replay protection are frequently required and confidentiality and data 345 object integrity may also be desirable. 347 5.3.3. Auditing 349 With enterprise networking expenditures on the rise, interest in 350 auditing is increasing. Auditing, which is the act of verifying the 351 correctness of a procedure, commonly relies on accounting data. Auditing 352 tasks include verifying the correctness of an invoice submitted by a 353 service provider, or verifying conformance to usage policy, service 354 level agreements, or security guidelines. 356 To permit a credible audit, the auditing data collection process must be 357 at least as reliable as the accounting process being used by the entity 358 that is being audited. Similarly, security policies for the audit should 359 be at least as stringent as those used in preparation of the original 360 invoice. Due to financial and legal requirements, archival accounting 361 practices are frequently required in this application. 363 Where auditing procedures are used to verify conformance to usage or 364 security policies, security services may be desired. This typically will 365 include authentication, integrity and replay protection as well as 366 confidentiality and data object integrity. In order to permit response 367 to security incidents in progress, auditing applications frequently are 368 built to operate with low processing delay. 370 5.3.4. Cost allocation 372 The application of cost allocation and billback methods by enterprise 373 customers is not yet widespread. However, with the convergence of 374 telephony and data communications, there is increasing interest in 375 applying cost allocation and billback procedures to networking costs, as 376 is now commonly practiced with telecommunications costs. 378 Cost allocation models, including traditional costing mechanisms 379 described in [21]-[23] and activity-based costing techniques described 380 in [24] are typically based on detailed analysis of usage data, and as a 381 result they are almost always usage-sensitive. Whether these techniques 382 are applied to allocation of costs between partners in a venture or to 383 allocation of costs between departments in a single firm, cost 384 allocation models often have profound behavioral and financial impacts. 385 As a result, systems developed for this purposes are typically as 386 concerned with reliable data collection and security as are billing 387 applications. Due to financial and legal requirements, archival 388 accounting practices are frequently required in this application. 390 5.4. Intra-domain and inter-domain accounting 392 Much of the initial work on accounting management has focused on intra- 393 domain accounting applications. However, with the increasing deployment 394 of services such as dial-up roaming, Internet fax, Voice and Video over 395 IP and QoS, applications requiring inter-domain accounting are becoming 396 increasingly common. 398 Inter-domain accounting differs from intra-domain accounting in several 399 important ways. Intra-domain accounting involves the collection of 400 information on resource consumption within an administrative domain, for 401 use within that domain. In intra-domain accounting, accounting packets 402 and session records typically do not cross administrative boundaries. As 403 a result, intra-domain accounting applications typically experience low 404 packet loss and involve transfer of data between trusted entities. 406 In contrast, inter-domain accounting involves the collection of 407 information on resource consumption within an administrative domain, for 408 use within another administrative domain. In inter-domain accounting, 409 accounting packets and session records will typically cross 410 administrative boundaries. As a result, inter-domain accounting 411 applications may experience substantial packet loss. In addition, the 412 entities involved in the transfers cannot be assumed to trust each 413 other. 415 Since inter-domain accounting applications involve transfers of 416 accounting data between domains, additional security measures may be 417 desirable. In addition to authentication, replay and integrity 418 protection, it may be desirable to deploy security services such as 419 confidentiality and data object integrity. In inter-domain accounting 420 each involved party also typically requires a copy of each accounting 421 event for invoice generation and auditing. 423 5.5. Accounting record production 425 Typically, a single accounting record is produced per session, or in 426 some cases, a set of interim records which can be summarized in a single 427 record for billing purposes. However, to support deployment of services 428 such as wireless access or complex billing regimes, a more sophisticated 429 approach is required. 431 It is necessary to generate several accounting records from a single 432 session when pricing changes during a session. For instance, the price 433 of a service can be higher during peak hours than off-peak. For a 434 session continuing from one tariff period to another, it becomes 435 necessary for a device to report "packets sent" during both periods. 437 Time is not the only factor requiring this approach. For instance, in 438 mobile access networks the user may roam from one place to another while 439 still being connected in the same session. If roaming causes a change in 440 the tariffs, it is necessary to account for resource consumed in the 441 first and second areas. Another example is where modifications are 442 allowed to an ongoing session. For example, it is possible that a 443 session could be re-authorized with improved QoS. This would require 444 production of accounting records at both QoS levels. 446 These examples could be addressed by using vectors or multi-dimensional 447 arrays to represent resource consumption within a single session record. 448 For example, the vector or array could describe the resource consumption 449 for each combination of factors, e.g. one data item could be the number 450 of packets during peak hour in the area of the home operator. However, 451 such an approach seems complicated and inflexible and as a result, most 452 current systems produce a set of records from one session. A session 453 identifier needs to be present in the records to permit accounting 454 systems to tie the records together. 456 In most cases, the network device will determine when multiple session 457 records are needed, as the local device is aware of factors affecting 458 local tariffs, such as QoS changes and roaming. However, future systems 459 are being designed that enable the home domain to control the generation 460 of accounting records. This is of importance in inter-domain accounting 461 or when network devices do not have tariff information. The centralized 462 control of accounting record production can be realized, for instance, 463 by having authorization servers require re-authorization at certain 464 times and requiring the production of accounting records upon each re- 465 authorization. 467 In conclusion, in some cases it is necessary to produce multiple 468 accounting records from a single session. It must be possible to do 469 this without requiring the user to start a new session or to re- 470 authenticate. The production of multiple records can be controlled 471 either by the network device or by the AAA server. The requirements for 472 timeliness, security and reliability in multiple record sessions are the 473 same as for single-record sessions. 475 5.6. Requirements summary 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | | | | 479 | Usage | Intra-domain | Inter-domain | 480 | | | | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | | Robustness vs. | Robustness vs. | 483 | | packet loss | packet loss | 484 | Capacity | | | 485 | Planning | Integrity, | Integrity, | 486 | | authentication, | authentication, | 487 | | replay protection | replay prot. | 488 | | [confidentiality] | confidentiality | 489 | | | [data object sec.]| 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Non-usage | Integrity, | Integrity, | 492 | Sensitive | authentication, | authentication, | 493 | Billing | replay protection | replay protection | 494 | | [confidentiality] | confidentiality | 495 | | | [data object sec.]| 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | | Archival | Archival | 498 | Usage | accounting | accounting | 499 | Sensitive | Integrity, | Integrity, | 500 | Billing, | authentication, | authentication, | 501 | Cost | replay protection | replay prot. | 502 | Allocation & | [confidentiality] | confidentiality | 503 | Auditing | [Bounds on | [data object sec.]| 504 | | processing delay] | [Bounds on | 505 | | | processing delay] | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | | Archival | Archival | 508 | Time | accounting | accounting | 509 | Sensitive | Integrity, | Integrity, | 510 | Billing, | authentication, | authentication, | 511 | fraud | replay protection | replay prot. | 512 | detection, | [confidentiality] | confidentiality | 513 | roaming | | [Data object | 514 | | Bounds on | security and | 515 | | processing delay | receipt support] | 516 | | | Bounds on | 517 | | | processing delay | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Key 521 [] = optional 523 6. Scaling and reliability 525 With the continuing growth of the Internet, it is important that 526 accounting management systems be scalable and reliable. This section 527 discusses the resources consumed by accounting management systems as 528 well as the scalability and reliability properties exhibited by various 529 data collection and transport models. 531 6.1. Fault resilience 533 As noted earlier, in applications such as usage-sensitive billing, cost 534 allocation and auditing, an archival approach to accounting is 535 frequently mandated, due to financial and legal requirements. Since in 536 such situations loss of accounting data can translate to revenue loss, 537 there is incentive to engineer a high degree of fault resilience. Faults 538 which may be encountered include: 540 Packet loss 541 Accounting server failures 542 Network failures 543 Device reboots 545 To date, much of the debate on accounting reliability has focused on 546 resilience against packet loss and the differences between UDP and TCP- 547 based transport. However, it should be understood that resilience 548 against packet loss is only one aspect of meeting archival accounting 549 requirements. 551 As noted in [43], "once the cable is cut you don't need more 552 retransmissions, you need a *lot* more voltage." Thus, the choice of 553 UDP or TCP transport has no impact on resilience against faults such as 554 network partition, accounting server failures or device reboots. What 555 does provide resilience against these faults is non-volatile storage. 557 The importance of non-volatile storage in design of reliable accounting 558 systems cannot be over-emphasized. Without such storage, event-driven 559 systems will lose data once the transmission timeout has been exceeded, 560 and batching designs will experience data loss once the internal memory 561 used for accounting data storage has been exceeded. Via use of non- 562 volatile storage, and internally stored interim records, most of these 563 data losses can be avoided. 565 It may even be argued that non-volatile storage is more important to 566 accounting reliability than network connectivity, since for many years 567 reliable accounting systems were implemented based solely on physical 568 storage, without any network connectivity. For example, phone usage data 569 used to be stored on paper, film, or magnetic media and carried from the 570 place of collection to a central location for bill processing. 572 6.1.1. Interim accounting 574 Interim accounting provides protection against loss of session summary 575 data by providing checkpoint information that can be used to reconstruct 576 the session record in the event that the session summary information is 577 lost. This technique may be applied to any data collection model (i.e. 578 event-driven or polling) and is supported in both RADIUS [25] and in 579 TACACS+ [26]. 581 While interim accounting can provide resilience against packet loss, 582 server failures, short-duration network failures, or device reboot, its 583 applicability is limited. Interim accounting should not be thought of 584 as a mainstream reliability improvement technique since it increases use 585 of network bandwidth in normal operation, while providing benefits only 586 in the event of a fault. 588 Since most packet loss on the Internet is due to congestion, sending 589 interim accounting data over the wire can make the problem worse by 590 increasing bandwidth usage. Therefore on-the-wire interim accounting is 591 best restricted to high-value accounting data such as information on 592 long-lived sessions. To protect against loss of data on such sessions, 593 the interim reporting interval is typically set several standard 594 deviations larger than the average session duration. This ensures that 595 most sessions will not result in generation of interim accounting events 596 and the additional bandwidth consumed by interim accounting will be 597 limited. However, as the interim accounting interval decreases toward 598 the average session time, the additional bandwidth consumed by interim 599 accounting increases markedly, and as a result, the interval must be set 600 with caution. 602 Where non-volatile storage is unavailable, interim accounting can also 603 result in excessive consumption of memory that could be better allocated 604 to storage of session data. As a result, implementors should be careful 605 to ensure that new interim accounting data overwrites previous data 606 rather than accumulating additional interim records in memory, thereby 607 worsening the buffer exhaustion problem. 609 Given the increasing popularity of non-volatile storage for use in 610 consumer devices such as digital cameras, such devices are rapidly 611 declining in price. This makes it increasingly feasible for network 612 devices to include built-in support for non-volatile storage. This can 613 be accomplished, for example, by support for compact PCMCIA cards. 615 Where non-volatile storage is available, this can be used to store 616 interim accounting data. Stored interim events are then replaced by 617 updated interim events or by session data when the session completes. 618 The session data can itself be erased once the data has been transmitted 619 and acknowledged at the application layer. This approach avoids interim 620 data being transmitted over the wire except in the case of a device 621 reboot. When a device reboots, internally stored interim records are 622 transferred to the accounting server. 624 6.1.2. Multiple record sessions 626 Generation of multiple accounting records within a session can introduce 627 scalability problems that cannot be controlled using the techniques 628 available in interim accounting. 630 For example, in the case of interim records kept in non-volatile 631 storage, it is possible to overwrite previous interim records with the 632 most recent one or summarize them to a session record. Where interim 633 updates are sent over the wire, it is possible to control bandwidth 634 usage by adjusting the interim accounting interval. 636 These measures are not applicable where multiple session records are 637 produced from a single session, since these records cannot be summarized 638 or overwritten without loss of information. As a result, multiple 639 record production can result in increased consumption of bandwidth and 640 memory. Implementors should be careful to ensure that worst-case 641 multiple record processing requirements do not exceed the capabilities 642 of their systems. 644 As an example, a tariff change at a particular time of day could, if 645 implemented carelessly, create a sudden peak in the consumption of 646 memory and bandwidth as the records need to be stored and/or 647 transported. Rather than attempting to send all of the records at once, 648 it may be desirable to keep them in non-volatile storage and send all of 649 the related records together in a batch when the session completes. It 650 may also be desirable to shape the accounting traffic flow so as to 651 reduce the peak bandwidth consumption. This can be accomplished by 652 introduction of a randomized delay interval. If the home domain can 653 also control the generation of multiple accounting records, the 654 estimation of the worst-case processing requirements can be very 655 difficult. 657 6.1.3. Packet loss 659 As packet loss is a fact of life on the Internet, accounting protocols 660 dealing with session data need to be resilient against packet loss. This 661 is particularly important in inter-domain accounting, where packets 662 often pass through Network Access Points (NAPs) where packet loss may be 663 substantial. Resilience against packet loss can be accomplished via 664 implementation of a retry mechanism on top of UDP, or use of TCP or SCTP 665 [55]. On-the-wire interim accounting provides only limited benefits in 666 mitigating the effects of packet loss. 668 UDP-based transport is frequently used in accounting applications. 669 However, this is not appropriate in all cases. Where accounting data 670 will not fit within a single UDP packet without fragmentation, use of 671 TCP or SCTP transport may be preferred to use of multiple round-trips in 672 UDP. As noted in [47] and [49], this may be an issue in the retrieval of 673 large tables. 675 In addition, in cases where congestion is likely, such as in inter- 676 domain accounting, TCP or SCTP congestion control and round-trip time 677 estimation will be very useful, optimizing throughput. In applications 678 which require maintenance of session state, such as simultaneous usage 679 control, TCP and application-layer keep alive packets or SCTP with its 680 built-in heartbeat capabilities provide a mechanism for keeping track of 681 session state. 683 When implementing UDP retransmission, there are a number of issues to 684 keep in mind: 686 Data model 687 Retry behavior 688 Congestion control 689 Timeout behavior 691 Accounting reliability can be influenced by how the data is modeled. 692 For example, it is almost always preferable to use cumulative variables 693 rather than expressing accounting data in terms of a change from a 694 previous data item. With cumulative data, the current state can be 695 recovered by a successful retrieval, even after many packets have been 696 lost. However, if the data is transmitted as a change then the state 697 will not be recovered until the next cumulative update is sent. Thus, 698 such implementations are much more vulnerable to packet loss, and should 699 be avoided wherever possible. 701 In designing a UDP retry mechanism, it is important that the retry 702 timers relate to the round-trip time, so that retransmissions will not 703 typically occur within the period in which acknowledgments may be 704 expected to arrive. Accounting bandwidth may be significant in some 705 circumstances, so that the added traffic due to unnecessary 706 retransmissions may increase congestion levels. 708 Congestion control in accounting data transfer is a somewhat 709 controversial issue. Since accounting traffic is often considered 710 mission-critical, it has been argued that congestion control is not a 711 requirement; better to let other less-critical traffic back off in 712 response to congestion. Moreover, without non-volatile storage, 713 congestive back-off in accounting applications can result in data loss 714 due to buffer exhaustion. 716 However, there are very persuasive arguments that in modern accounting 717 implementations, it is possible to implement congestion control while 718 improving throughput and maintaining high reliability. 720 In circumstances where there is sustained packet loss, there simply is 721 not sufficient capacity to maintain existing transmission rates. Thus, 722 aggregate throughput will actually improve if congestive back-off is 723 implemented. This is due to elimination of retransmissions and ability 724 to utilize techniques such as RED to desynchronize flows. In addition, 725 with QoS mechanisms such as differentiated services, it is possible to 726 mark accounting packets for preferential handling so as to provide for 727 lower packet loss if desired. Thus considerable leeway is available to 728 the network administrator in controlling the treatment of accounting 729 packets and hard coding inelastic behavior is unnecessary. Typically, 730 systems implementing non-volatile storage allow for backlogged 731 accounting data to be placed in non-volatile storage pending 732 transmission, so that buffer exhaustion resulting from congestive back- 733 off need not be a concern. 735 Since UDP is not really a transport protocol, UDP-based accounting 736 protocols such as [4] often do not prescribe timeout behavior. Thus 737 implementations may exhibit widely different behavior. For example, one 738 implementation may drop accounting data after three constant duration 739 retries to the same server, while another may implement exponential 740 back-off to a given server, then switch to another server, up to a total 741 timeout interval of twelve hours, while storing the untransmitted data 742 on non-volatile storage. The practical difference between these 743 approaches is substantial; the former approach will not satisfy archival 744 accounting requirements while the latter may. More predictable behavior 745 can be achieved via use of SCTP or TCP transport. 747 6.1.4. Accounting server faults and failover 749 In the event of a failure of the primary accounting server, it is 750 desirable for the device to failover to a secondary server. Providing 751 one or more secondary servers can remove much of the risk of accounting 752 server failure, and as a result use of secondary servers has become 753 commonplace. 755 For protocols based on TCP, it is possible for the device to maintain 756 connections to both the primary and secondary accounting servers, using 757 the secondary connection after expiration of a timer on the primary 758 connection. Alternatively, it is possible to open a connection to the 759 secondary accounting server after a timeout or loss of the primary 760 connection, or on expiration of a timer. Thus, accounting protocols 761 based on TCP are capable of responding more rapidly to connectivity 762 failures than TCP timeouts would otherwise allow, at the expense of an 763 increased risk of duplicates. 765 With SCTP, it is possible to control transport layer timeout behavior, 766 and therefore it is not necessary for the accounting application to 767 maintain its own timers. However, since SCTP is not widely available, 768 use of this transport can impose an additional implementation burden on 769 the designer. 771 For protocols using UDP, transmission to the secondary server can occur 772 after a number of retries or timer expiration. For compatibility with 773 congestion avoidance, it is advisable to incorporate techniques such as 774 round-trip-time estimation, slow start and congestive back-off. Thus 775 the accounting protocol designer utilizing UDP often is lead to re- 776 inventing techniques already existing in TCP and SCTP. As a result, the 777 use of raw UDP transport in accounting applications is not recommended. 779 With any transport it is possible for the primary and secondary 780 accounting servers to receive duplicate packets, so support for 781 duplicate elimination is required. Since accounting server failures can 782 result in data accumulation on accounting clients, use of non-volatile 783 storage can ensure against data loss due to transmission timeouts or 784 buffer exhaustion. On-the-wire interim accounting provides only limited 785 benefits in mitigating the effects of accounting server failures. 787 It is also possible for the accounting server to experience partial 788 failures. For example, a failure in the database back end could leave 789 the accounting retrieval process or thread operable while the process or 790 thread responsible for storing the data is non-functional. Similarly, it 791 is possible for the accounting application to run out of disk space, 792 making it unable to continue storing incoming session records. 794 In such cases it is desirable to distinguish between transport layer 795 acknowledgment and application layer acknowledgment. Even though both 796 acknowledgments may be sent within the same packet (such as a TCP 797 segment carrying an application layer acknowledgment along with a piggy- 798 backed ACK), the semantics are different. A transport-layer 799 acknowledgment means "I have received the data" while an application 800 layer acknowledgment means "I have accepted responsibility for the 801 data". The former typically implies only that the data has been 802 received and stored in a buffer, while the latter implies that the data 803 has been written to stable storage or suitably processed so as to guard 804 against loss. 806 In the case of partial failures, it is possible for the accounting 807 server to acknowledge receipt via transport layer acknowledgment, 808 without being capable of completing the tasks necessary to take 809 responsibility for the data, as required for an application layer 810 acknowledgment. For example, an accounting server incapable of storing 811 received data due to a back end database or disk space problem should 812 not send an application layer acknowledgment, even though the data was 813 received, so that a transport layer acknowledgment is appropriate. In 814 such cases, it is useful to be able to send an application layer error 815 message such as "Backend store unavailable" so to make it clear that the 816 accounting server is malfunctioning. 818 6.1.5. Network failures 820 Network failures may result in partial or complete loss of connectivity 821 for the accounting client. In the event of partial connectivity loss, it 822 may not be possible to reach the primary accounting server, in which 823 case switch over to the secondary accounting server is necessary. In 824 the event of a network partition, it may be necessary to store 825 accounting events in device memory or non-volatile storage until 826 connectivity can be re-established. 828 As with accounting server failures, on-the-wire interim accounting 829 provides only limited benefits in mitigating the effects of network 830 failures. 832 6.1.6. Device reboots 834 In the event of a device reboot, it is desirable to minimize the loss of 835 data on sessions in progress. Such losses may be significant even if the 836 devices themselves are very reliable, due to long-lived sessions, which 837 can comprise a significant fraction of total resource consumption. 838 Sending interim accounting data over the wire is typically implemented 839 to guard against loss of these high-value sessions. When interim 840 accounting is combined with non-volatile storage it becomes possible to 841 guard against data loss in much shorter sessions. This is possible since 842 interim accounting data need only be stored in non-volatile memory until 843 the session completes, at which time the interim data may be replaced by 844 the session record. As a result, interim accounting data need never be 845 sent over the wire, and it is possible to decrease the interim interval 846 so as to provide a very high degree of protection against data loss. 848 6.1.7. Accounting proxies 850 In order to maintain high reliability, it is important that accounting 851 proxies pass through transport and application layer acknowledgments and 852 do not store and forward accounting packets. This enables the end- 853 systems to control re-transmission behavior and utilize techniques such 854 as non-volatile storage and secondary servers to improve resilience. 856 Accounting proxies sending a transport or application layer ACK to the 857 device without receiving one from the accounting server fool the device 858 into thinking that the accounting request had been accepted by the 859 accounting server when this is not the case. As a result, the device can 860 delete the accounting packet from non-volatile storage before it has 861 been accepted by the accounting server. The leaves the accounting proxy 862 responsible for delivering accounting packets. If the accounting proxy 863 involves moving parts (e.g. a disk drive) while the devices do not, 864 overall system reliability can be reduced. 866 Store and forward accounting proxies only add value in situations where 867 the accounting subsystem is unreliable. For example, where devices do 868 not implement non-volatile storage and the accounting protocol lacks 869 transport and application layer reliability, locating the accounting 870 proxy (with its stable storage) close to the device can reduce the risk 871 of data loss. 873 However, such systems are inherently unreliable so that they can only 874 handle capacity planning or non-usage sensitive billing applications. 875 If archival accounting reliability is desired, it is necessary to 876 engineer a reliable accounting system from the start using the 877 techniques described in this document, rather than attempting to repair 878 an inherently unreliable system by adding store and forward accounting 879 proxies. 881 6.1.8. Fault resilience summary 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | | | 885 | Fault | Counter-measures | 886 | | | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | | | 889 | Packet | Retransmission based on RTT | 890 | loss | Congestion control | 891 | | Well-defined timeout behavior | 892 | | Duplicate elimination | 893 | | Interim accounting* | 894 | | Non-volatile storage | 895 | | Cumulative variables | 896 | | | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | | | 899 | Accounting | Primary-secondary servers | 900 | server & net | Duplicate elimination | 901 | failures | Interim accounting* | 902 | | Application layer ACK & error msgs. | 903 | | Non-volatile storage | 904 | | | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | | | 907 | Device | Interim accounting* | 908 | reboots | Non-volatile storage | 909 | | | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 Key 913 * = limited usefulness without non-volatile storage 915 Note: Accounting proxies are not a reliability 916 enhancement mechanism. 918 6.2. Resource consumption 920 In the process of growing to meet the needs of providers and customers, 921 accounting management systems consume a variety of resources, including: 923 Network bandwidth 924 Memory 925 Non-volatile storage 926 State on the accounting management system 927 CPU on the management system and managed devices 929 In order to understand the limits to scaling of accounting management 930 systems, we examine each of these resources in turn. 932 6.2.1. Network bandwidth 934 Accounting management systems consume network bandwidth in the 935 transferring of accounting data. The network bandwidth consumed is 936 proportional to the amount of data transferred, as well as required 937 network overhead. Since accounting data for a given event may be 100 938 octets or less, if each event is transferred individually, overhead can 939 represent a considerable proportion of total bandwidth consumption. As 940 a result, it is often desirable to transfer accounting data in batches, 941 enabling network overhead to be spread over a larger payload, and 942 enabling efficient use of compression. As noted in [48], compression 943 can be enabled in the accounting protocol, or can be done at the IP 944 layer as described in [50]. 946 6.2.2. Memory 948 In accounting systems without non-volatile storage, accounting data must 949 be stored in volatile memory during the period between when it is 950 generated and when it is transferred. The resulting memory consumption 951 will depend on retry and retransmission algorithms. Since systems 952 designed for high reliability will typically wish to retry for long 953 periods, or may store interim accounting data, the resulting memory 954 consumption can be considerable. As a result, if non-volatile storage is 955 unavailable, it may be desirable to compress accounting data awaiting 956 transmission. 958 As noted earlier, implementors of interim accounting should take care to 959 ensure against excessive memory usage by overwriting older interim 960 accounting data with newer data for the same session rather than 961 accumulating interim data in the buffer. 963 6.2.3. Non-volatile storage 965 Since accounting data stored in memory will typically be lost in the 966 event of a device reboot or a timeout, it may be desirable to provide 967 non-volatile storage for undelivered accounting data. With the costs of 968 non-volatile storage declining rapidly, network devices will be 969 increasingly capable of incorporating non-volatile storage support over 970 the next few years. 972 As described in [11], non-volatile storage may be used to store interim 973 or session records in a standard ASCII format. As with memory 974 utilization, interim accounting overwrite is desirable so as to prevent 975 excessive storage consumption. Note that the use of ASCII data 976 representation enables use of highly efficient text compression 977 algorithms that can minimize storage requirements. Such compression 978 algorithms are only typically applied to session records so as to enable 979 implementation of interim data overwrite. 981 6.2.4. State on the accounting management system 983 In order to keep track of received accounting data, accounting 984 management systems may need to keep state on managed devices or 985 concurrent sessions. Since the number of devices is typically much 986 smaller than the number of concurrent sessions, it is desirable to keep 987 only per-device state if possible. 989 6.2.5. CPU requirements 991 CPU consumption of the managed and managing nodes will be proportional 992 to the complexity of the required accounting processing. Operations such 993 as ASN.1 encoding and decoding, compression/decompression, and 994 encryption/decryption can consume considerable resources, both on 995 accounting clients and servers. 997 The effect of these operations on accounting system reliability should 998 not be under-estimated, particularly in the case of devices with 999 moderate CPU resources. In the event that devices are over-taxed by 1000 accounting tasks, it is likely that overall device reliability will 1001 suffer. 1003 6.2.6. Efficiency measures 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | | | 1007 | Resource | Efficiency measures | 1008 | | | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | | | 1011 | Network | Batching | 1012 | Bandwidth | Compression | 1013 | | | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | | | 1016 | Memory | Compression | 1017 | | Interim accounting overwrite | 1018 | | | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | | | 1021 | Non-volatile | Compression | 1022 | Storage | Interim accounting overwrite | 1023 | | | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | | | 1026 | System | Per-device state | 1027 | state | | 1028 | | | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | | | 1031 | CPU | Hardware assisted | 1032 | requirements | compression/encryption | 1033 | | | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 6.3. 1038 Data collection models 1040 Several data collection models are currently in use today for the 1041 purposes of accounting data collection. These include: 1043 Polling model 1044 Event-driven model without batching 1045 Event-driven model with batching 1046 Event-driven polling model 1048 6.3.1. Polling model 1050 In the polling model, an accounting manager will poll devices for 1051 accounting information at regular intervals. In order to ensure against 1052 loss of data, the polling interval will need to be shorter than the 1053 maximum time that accounting data can be stored on the polled device. 1054 For devices without non-volatile stage, this is typically determined by 1055 available memory; for devices with non-volatile storage the maximum 1056 polling interval is determined by the size of non-volatile storage. 1058 The polling model results in an accumulation of data within individual 1059 devices, and as a result, data is typically transferred to the 1060 accounting manager in a batch, resulting in an efficient transfer 1061 process. In terms of Accounting Manager state, polling systems scale 1062 with the number of managed devices, and system bandwidth usage scales 1063 with the amount of data transferred. 1065 Without non-volatile storage, the polling model results in loss of 1066 accounting data due to device reboots, but not due to packet loss or 1067 network failures of sufficiently short duration to be handled within 1068 available memory. This is because the Accounting Manager will continue 1069 to poll until the data is received. In situations where operational 1070 difficulties are encountered, the volume of accounting data will 1071 frequently increase so as to make data loss more likely. However, in 1072 this case the polling model will detect the problem since attempts to 1073 reach the managed devices will fail. 1075 The polling model scales poorly for implementation of shared use or 1076 roaming services, including wireless data, Internet telephony, QoS 1077 provisioning or Internet access. This is because in order to retrieve 1078 accounting data for users within a given domain, the Accounting 1079 Management station would need to periodically poll all devices in all 1080 domains, most of which would not contain any relevant data. There are 1081 also issues with processing delay, since use of a polling interval also 1082 implies an average processing delay of half the polling interval, which 1083 may be too high for accounting data that requires low processing delay. 1084 Thus the event-driven polling or the pure event-driven approach is more 1085 appropriate for shared use or roaming implementations. 1087 Per-device state is typical of polling-based network management systems, 1088 which often also carry out accounting management functions, since 1089 network management systems need to keep track of the state of network 1090 devices for operational purposes. These systems offer average processing 1091 delays equal to half the polling interval. 1093 6.3.2. Event-driven model without batching 1095 In the event-driven model, a device will contact the accounting server 1096 or manager when it is ready to transfer accounting data. Most event- 1097 driven accounting systems, such as those based on RADIUS accounting, 1098 described in [4], transfer only one accounting event per packet, which 1099 is inefficient. 1101 Without non-volatile storage, a pure event-driven model typically stores 1102 accounting events that have not yet been delivered only until the 1103 timeout interval expires. As a result this model has the smallest memory 1104 requirements. Once the timeout interval has expired, the accounting 1105 event is lost, even if the device has sufficient buffer space to 1106 continue to store it. As a result, the event-driven model is the least 1107 reliable, since accounting data loss will occur due to device reboots, 1108 sustained packet loss, or network failures of duration greater than the 1109 timeout interval. In event-driven protocols without a "keep alive" 1110 message, accounting servers cannot assume a device failure should no 1111 messages arrive for an extended period. Thus, event-driven accounting 1112 systems are typically not useful in monitoring of device health. 1114 The event-driven model is frequently used in shared use networks and 1115 roaming, since this model sends data to the recipient domains without 1116 requiring them to poll a large number of devices, most of which have no 1117 relevant data. Since the event-driven model typically does not support 1118 batching, it permits accounting records to be sent with low processing 1119 delay, enabling application of fraud prevention techniques. However, 1120 because roaming accounting events are frequently of high value, the poor 1121 reliability of this model is an issue. As a result, the event-driven 1122 polling model may be more appropriate. 1124 Per-session state is typical of event-driven systems without batching. 1125 As a result, the event-driven approach scales poorly. However, event- 1126 driven systems offer the lowest processing delay since events are 1127 processed immediately and there is no possibility of an event requiring 1128 low processing delay being caught behind a batch transfer. 1130 6.3.3. Event-driven model with batching 1132 In the event-driven model with batching, a device will contact the 1133 accounting server or manager when it is ready to transfer accounting 1134 data. The device can contact the server when a batch of a given size has 1135 been gathered, when data of a certain type is available or after a 1136 minimum time period has elapsed. Such systems can transfer more than one 1137 accounting event per packet and are thus more efficient. 1139 An event-driven system with batching will store accounting events that 1140 have not yet been delivered up to the limits of memory. As a result, 1141 accounting data loss will occur due to device reboots, but not due to 1142 packet loss or network failures of sufficiently short duration to be 1143 handled within available memory. Note that while transfer efficiency 1144 will increase with batch size, without non-volatile storage, the 1145 potential data loss from a device reboot will also increase. 1147 Where event-driven systems with batching have a keep-alive interval and 1148 run over reliable transport, the accounting server can assume that a 1149 failure has occurred if no messages are received within the keep-alive 1150 interval. Thus, such implementations can be useful in monitoring of 1151 device health. When used for this purpose the average time delay prior 1152 to failure detection is one half the keep-alive interval. 1154 Through implementation of a scheduling algorithm, event-driven systems 1155 with batching can deliver appropriate service to accounting events that 1156 require low processing delay. For example, high-value inter-domain 1157 accounting events could be sent immediately, thus enabling use of fraud- 1158 prevention techniques, while all other events would be batched. However, 1159 there is a possibility that an event requiring low processing delay will 1160 be caught behind a batch transfer in progress. Thus the maximum 1161 processing delay is proportional to the maximum batch size divided by 1162 the link speed. 1164 Event-driven systems with batching scale with the number of active 1165 devices. As a result this approach scales better than the pure event- 1166 driven approach, or even the polling approach, and is equivalent in 1167 terms of scaling to the event-driven polling approach. However, the 1168 event-driven batching approach has lower processing delay than the 1169 event-driven polling approach, since delivery of accounting data 1170 requires fewer round-trips and events requiring low processing delay can 1171 be accommodated if a scheduling algorithm is employed. 1173 6.3.4. Event-driven polling model 1175 In the event-driven polling model an accounting manager will poll the 1176 device for accounting data only when it receives an event. The 1177 accounting client can generate an event when a batch of a given size has 1178 been gathered, when data of a certain type is available or after a 1179 minimum time period has elapsed. Note that while transfer efficiency 1180 will increase with batch size, without non-volatile storage, the 1181 potential data loss from a device reboot will also increase. 1183 Without non-volatile storage, an event-driven polling model will lose 1184 data due to device reboots, but not due to packet loss, or network 1185 partitions of short-duration. Unless a minimum delivery interval is set, 1186 event-driven polling systems are not useful in monitoring of device 1187 health. 1189 The event-driven polling model can be suitable for use in roaming since 1190 it permits accounting data to be sent to the roaming partners with low 1191 processing delay. At the same time non-roaming accounting can be handled 1192 via more efficient polling techniques, thereby providing the best of 1193 both worlds. 1195 Where batching can be implemented, the state required in event-driven 1196 polling can be reduced to scale with the number of active devices. If 1197 portions of the network vary widely in usage, then this state may 1198 actually be less than that of the polling approach. Note that processing 1199 delay in this approach is higher than in event-driven accounting with 1200 batching since at least two round-trips are required to deliver data: 1201 one for the event notification, and one for the resulting poll. 1203 6.3.5. Data collection summary 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | | | | 1207 | Model | Pros | Cons | 1208 | | | | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | Polling | Per-device state | Not robust | 1211 | | Robust against | against device | 1212 | | packet loss | reboot, server | 1213 | | Batch transfers | or network | 1214 | | | failures* | 1215 | | | Polling interval | 1216 | | | determined by | 1217 | | | storage limit | 1218 | | | High processing | 1219 | | | delay | 1220 | | | Unsuitable for | 1221 | | | use in roaming | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | Event-driven, | Lowest processing | Not robust | 1224 | no batching | delay | against packet | 1225 | | Suitable for | loss, device | 1226 | | use in roaming | reboot, or | 1227 | | | network | 1228 | | | failures* | 1229 | | | Low efficiency | 1230 | | | Per-session state | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | Event-driven, | Single round-trip | Not robust | 1233 | with batching | latency | against device | 1234 | and | Batch transfers | reboot, network | 1235 | scheduling | Suitable for | failures* | 1236 | | use in roaming | | 1237 | | Per active device | | 1238 | | state | | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | Event-driven | Batch transfers | Not robust | 1241 | polling | Suitable for | against device | 1242 | | use in roaming | reboot, network | 1243 | | Per active device | failures* | 1244 | | state | Two round-trip | 1245 | | | latency | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 Key 1249 * = addressed by non-volatile storage 1251 7. Review of Accounting Protocols 1253 Accounting systems have been successfully implemented using protocols 1254 such as RADIUS, TACACS+, and SNMP. This section describes the 1255 characteristics of each of these protocols. 1257 7.1. RADIUS 1259 RADIUS accounting, described in [4], was developed as an add-on to the 1260 RADIUS authentication protocol, described in [3]. As a result, RADIUS 1261 accounting shares the event-driven approach of RADIUS authentication, 1262 without support for batching or polling. As a result, RADIUS accounting 1263 scales with the number of accounting events instead of the number of 1264 devices, and accounting transfers are inefficient. 1266 Since RADIUS accounting is based on UDP and timeout and retry parameters 1267 are not specified, implementations vary widely in their approach to 1268 reliability, with some implementations retrying until delivery or buffer 1269 exhaustion, and others losing accounting data after a few retries. Since 1270 RADIUS accounting does not provide for Application-layer acknowledgments 1271 or error messages, a RADIUS Accounting-Response is equivalent to a 1272 transport-layer acknowledgment and provides no protection against 1273 application layer malfunctions. Due to the lack of reliability, it is 1274 not possible to do simultaneous usage control based on RADIUS accounting 1275 alone. Typically another device data source is required, such as polling 1276 of a session MIB or a command-line session over telnet. 1278 RADIUS accounting implementations are vulnerable to packet loss as well 1279 as application layer failures, network failures and device reboots. 1280 These deficiencies are magnified in inter-domain accounting as is 1281 required in roaming ([1],[2]). On the other hand, the event-driven 1282 approach of RADIUS accounting is useful where low processing delay is 1283 required, such as credit risk management or fraud detection. 1285 While RADIUS accounting does provide hop-by-hop authentication and 1286 integrity protection, and IPSEC can be employed to provide hop-by-hop 1287 confidentiality, data object security is not supported, and thus systems 1288 based on RADIUS accounting are not capable of being deployed with 1289 untrusted proxies, or in situations requiring auditability, as noted in 1290 [2]. 1292 While RADIUS does not support compression, IP compression, described in 1293 [50], can be employed to provide this. While in principle extensible 1294 with the definition of new attributes, RADIUS suffers from the very 1295 small standard attribute space (256 attributes). 1297 7.2. TACACS+ 1299 TACACS+ as defined in [26] offers an accounting model with start, stop, 1300 and interim update messages. Since TACACS+ is based on TCP, 1301 implementations are typically resilient against packet loss and short- 1302 lived network partitions, and TACACS+ scales with the number of devices. 1303 Since TACACS+ runs over TCP, it offers support for both transport layer 1304 and application layer acknowledgments, and is suitable for simultaneous 1305 usage control and handling of accounting events that require moderate 1306 though not the lowest processing delay. 1308 TACACS+ provides for hop-by-hop authentication and integrity protection 1309 as well as hop-by-hop confidentiality. Data object security is not 1310 supported, and therefore systems based on TACACS+ accounting are not 1311 deployable in the presence of untrusted proxies. While TACACS+ does not 1312 support compression, IP compression, described in [50], can be employed 1313 to provide this. 1315 7.3. SNMP 1317 SNMP, described in [27]-[41], has been widely deployed in a wide variety 1318 of intra-domain accounting applications, typically using the polling 1319 data collection model. Since polling allows data to be collected on 1320 multiple accounting events simultaneously, this model results in per- 1321 device state. Since the management agent is able to retry requests when 1322 a response is not received, such systems are resilient against packet 1323 loss or even short-lived network partitions. While implementations 1324 without non-volatile storage can only store accounting events up to the 1325 limits of their memory, and thus are not robust against device reboots 1326 or network failures, when combined with non-volatile storage, they can 1327 be made highly reliable. With SMIv2 it is possible to support confirmed 1328 notifications, so as to implement an event-driven polling model or even 1329 an event-driven batching model. However, we are not aware of any SNMP- 1330 based accounting implementations built on these models. 1332 7.3.1. NMRG extensions 1334 As discussed in [49], there are a number of efficiency and latency 1335 issues that arise when using SNMP for accounting. In such applications 1336 it is often necessary for management stations to retrieve large tables. 1337 In such situations, the latency can be quite high, even with the getbulk 1338 operation. This is because the response must fit into the largest 1339 supported packet size, requiring multiple round-trips. Unless multiple 1340 threads are employed, the transfers will be serialized and the resulting 1341 latency will be a combination of multiple round-trip times, timeout and 1342 re-transmission delays and processing overhead, which may result in 1343 unacceptable performance. Since data may change during the course of 1344 multiple retrievals, it can be difficult to get a consistent snapshot. 1346 In addition, [49] notes that SNMP is inefficient for transfer of 1347 accounting data, due to lack of compression, use of BER encoding, 1348 transmission of redundant OID prefixes, and the "get bulk overshoot" 1349 problem. As described in [54] the overshoot problem occurs when using 1350 the getbulk PDU because the manager typically does not know the number 1351 of rows in the table. As a result, it must either request too many rows, 1352 retrieving unneeded data, or too few, resulting in the need for multiple 1353 getbulk requests. 1355 To address these issues, a number of changes to SNMP are now under 1356 discussion within the IRTF Network Management Research Group (NMRG), 1357 described in [46]. These include an SNMP-over-TCP transport mapping, 1358 described in [47]; SNMP payload compression, described in [48]; and the 1359 addition of a "get subtree" PDU or the subtree retrieval MIB [54]. 1360 Taken together, we will refer to these changes as the "NMRG extensions." 1362 The SNMP-over-TCP transport mapping, particularly when combined with a 1363 subtree retrieval solution, results in substantial latency reductions in 1364 table retrieval. While it is possible for SNMP to operate in polling, 1365 event-driven, event-driven batching and event-driven polling modes, the 1366 latency reduction from the SNMP-over-TCP transport mapping manifests 1367 itself primarily in the polling, event-driven polling and event-driven 1368 batching modes. 1370 While use of TCP transport provides for transport layer acknowledgment, 1371 this still leaves SNMP without the equivalent of an application layer 1372 acknowledgment for confirmed notifications. Since the Response to an 1373 Inform-Request is typically sent by the master agent, not the subagent, 1374 there is no requirement that the Response wait until the accounting 1375 application has accepted responsibility for the data and thus the 1376 Response does not correspond to an application layer acknowledgment. 1378 Reference [49] also discusses file-based storage of SNMP data, as 1379 described in [43], and the FTP MIB, described in [44]. Together these 1380 MIBs enable storage of SNMP data in non-volatile storage, and subsequent 1381 transfer via SNMP. It is noted that this approach requires 1382 implementation of additional MIBs as well as FTP, and requires separate 1383 security mechanisms such as IPSEC to provide authentication, replay and 1384 integrity protection and confidentiality for the data in transit. 1385 However, the the file-based transfer approach also has an important 1386 benefit, which is compatibility with non-volatile storage. 1388 While an SNMP over TCP transport mapping is easily implemented, it does 1389 require SNMP agents to listen on TCP ports 161 and 162. Addition of a 1390 "get subtree" PDU implies changes to every agent that the management 1391 station will interact with. However, the subtree retrieval MIB described 1392 in [54] requires no changes to the SNMP protocol or SNMP protocol engine 1393 and thus can be implemented and deployed more easily. 1395 7.3.2. SNMP v3 1397 SNMPv3 includes support for security services as well as access 1398 controls. This section describes how this functionality may be applied 1399 in intra and inter-domain accounting. 1401 In inter-domain accounting, it is necessary to control access on a per- 1402 domain basis. In order to apply domain-based access controls, it is 1403 first necessary to identify the data subset that is to have its access 1404 controlled. Several conceptual abstractions are used for identifying 1405 subsets of data in SNMP v3. These include engines, contexts, and views. 1407 7.3.2.1. Engines 1409 SNMP v3 supports the use of the contextEngineID field in order to 1410 identify the engine which provides access to the data. In traditional 1411 terms, this is the agent. contextEngineID support was added in order to 1412 improve handling of mobility as well as well as to improve SNMP proxy 1413 support. Use of contextEngineID enables improved mobility, allowing the 1414 agent on a laptop to be identified independently of the IP address where 1415 it is attached to the network. In SNMPv1 and v2, different endpoint 1416 addresses imply different agents. This is not the case with SNMPv3. 1418 contextEngineID also enables SNMP proxies to identify the data origin. 1419 While in SNMPv1 and v2, the data origin is automatically assumed to be 1420 the communications endpoint (SNMP agent), with SNMPv3 it is possible to 1421 distinguish the data origin from the communications endpoint. 1423 For example, let us assume that agent A sends a trap to manager M 1424 through agent B, who forwards it. When SNMPv3 is used, while the trap 1425 received by manager M will have a source address corresponding to agent 1426 B, contextEngineID will identify agent A as the data origin of the trap. 1427 Thus, by using contextEngineID, M can identify the data origin, no 1428 matter how many intermediate SNMP agents have forwarded it. With SNMPv1 1429 and v2, M would need to assume that the data in the trap (from A) refers 1430 to the instrumentation of the agent at the last hop (B). 1432 Note that in SNMPv3 there is only a single contextEngineID per SNMP 1433 implementation. 1435 7.3.2.2. Contexts 1437 Contexts are used to identify subsets of objects that are tied to 1438 instrumentation. These subsets are defined by the agent rather than the 1439 manager since if the manager defined them, the agent would not know how 1440 to tie the contexts to the underlying instrumentation. 1442 In SNMPv3, contextName represents a slice of the data contained within a 1443 particular engine. Contexts are defined in a dynamic table, with the 1444 names defined as read-only. The agent uses the dynamic table to tell the 1445 manager what contexts it recognizes. 1447 Contexts are commonly tied to hardware components, to logical entities 1448 related to the hardware components, or to logical services. For example, 1449 contextNames might include board5, board7, repeater1, repeater2, etc. 1451 While each context may support multiple MIB modules, each contextName is 1452 limited to one instance of a particular MIB module. Thus, if multiple 1453 instances of a MIB module are required per engine, then unique 1454 contextNames must be defined. If it only makes sense to have one 1455 instance of a MIB module in an engine, such as the USM userTable, such a 1456 MIB will typically fall into the default context "". Note that while a 1457 MIB module may allow more than one instance per engine, a given SNMPv3 1458 implementation may not support this. 1460 7.3.2.3. Views 1462 A view is a mask for a particular contextName (subset of data). The view 1463 identifies which objects are visible, by specifying OIDs of the subtrees 1464 involved. There is also a mechanism to allow wildcards in the OID 1465 specification. 1467 For example, it is possible to define a view that includes the RMON 1468 tables, and another view that includes only the SNMPv3 security related 1469 tables. Using these views, it is possible to allow access to the RMON 1470 view for users Joe and Josephine (the RMON administrators), and access 1471 to the SNMPv3 security tables for user Adam (the security policy 1472 administrator). 1474 Views can be set up with wildcards. For a table that is indexed using IP 1475 addresses, Joe can be allowed access to all RMON rows that are in the 1476 subnet 134.141.x.x, with Josephine given access to all rows for subnet 1477 134.200.x.x. However, for this to work the table must be indexed by the 1478 differentiating variable, since views filter at the OID level, not at 1479 the data level. It is therefore not possible to define a view that 1480 filters on the value of non-index data. In this example, were the IP 1481 address to have been used merely as a data item rather than an index, it 1482 would not be possible to utilize view-based access control to achieve 1483 the desired objective (delegation of administrative responsibility 1484 according to subnet). 1486 7.3.2.4. SNMPv3 security services 1488 SNMPv1 and SNMPv2 do not incorporate security services. With SNMPv3, it 1489 is possible to incorporate view-based access controls, described in 1490 [40], as well as user-based security, described in [38]. As a result, 1491 SNMPv3-based accounting implementations can provide hop-by-hop 1492 authentication, integrity and replay protection, confidentiality and 1493 access-control. SNMPv3 does not support data-object security. Merely 1494 providing security for individual MIB variables is not sufficient. In 1495 order to prevent a cut and paste attack by an untrusted proxy, it is 1496 necessary to provide integrity protection covering enough of the packet 1497 (including other MIB variables) to protect against replay. 1499 A Kerberos Security Model (KSM) for SNMPv3 is described in [51]. This 1500 approach requires storage of a key on the KDC for each device and 1501 domain, while dynamically generating a session key for conversations 1502 between domains and devices. Thus, in terms of stored keys the KSM 1503 approach scales with the sum of devices and domains, whereas in terms of 1504 dynamic session keys, it scales as the product of domains and devices. 1506 As Kerberos is extended to allow initial authentication via public key, 1507 as described in [52], and cross-realm authentication, as described in 1508 [53], the KSM inherits these capabilities. As a result, this approach 1509 may have potential to reduce or even eliminate the shared secret 1510 management problem in the long-term. However, it should also be noted 1511 that certificate-based authentication can strain the limits of UDP 1512 packet sizes supported in SNMP implementations, so that the SNMP-over- 1513 TCP transport mapping may be required to support this. 1515 An IPSEC-based security model for SNMPv3 has also been discussed. 1516 Implementation of such a security model would require the SNMPv3 engine 1517 to be able to retrieve the properties of the IPSEC security association 1518 used to protect the SNMPv3 traffic. This would include the security 1519 services invoked, as well as information relating to the other endpoint 1520 such as the authentication method and presented identity and 1521 certificate. To date such APIs have not been widely implemented, and in 1522 addition, most IPSEC implementations only support machine certificates, 1523 which may not provide the required granularity of identification. Thus, 1524 an IPSEC-based security model for SNMPv3 will probably take several 1525 years to come to fruition. 1527 7.3.3. Domain-based access control in SNMPv3 1529 Domain-based access controls are required where multiple administrative 1530 domains are involved, such as in the shared use networks and roaming 1531 associations described in [1]. Since the same device may be accessed by 1532 multiple organizations, it is often necessary to control access to 1533 accounting data according to the user's organization. This ensures that 1534 organizations may be given access to accounting data relating to their 1535 users, but not to data relating to users of other organizations. 1537 In order to be able to control access to accounting data on a per-domain 1538 basis, there are several alternatives. These include use of the domain 1539 as an index, engines, contexts and proxies. 1541 7.3.3.1. Domain as index 1543 Through use of view-based access control [40], it is possible to define 1544 multiple fine-grained views of an SNMP MIB, and to assign views to 1545 specific groups of users, such that access rights to the included data 1546 elements will depend on the identity of the user making the request. 1547 For example, all users of bigco.com which are allowed access to the 1548 device would be defined in the User-based security MIB (or other 1549 security model MIB). For simplicity in administering access control, 1550 the users can be grouped using a vacmGroupName, e.g. bigco. A view of a 1551 subset of the data objects in the MIB can be defined in the 1552 vacmViewFamilyTreeTable. A vacmAccessTable pairs groups and views. For 1553 messages received from users in the bigco group, access would only be 1554 provided to the data permitted to be viewed by bigco users, as defined 1555 in the view family tree. This requires that each domain accessing the 1556 data be given one or more separate vacmGroupNames, an appropriate 1557 ViewTable be defined, and the vacmAccessTable be configured for each 1558 group. 1560 As the number of network devices within the shared use or roaming 1561 network grows, the polling model of data collection becomes increasingly 1562 impractical since most devices will not carry data relating to the 1563 polling organization. As a result, shared-use networks or roaming 1564 associations relying on SNMP-based accounting have generally collected 1565 data for all organizations and then sorted the resulting session records 1566 for delivery to each organization. While functional, this approach will 1567 typically result in increased processing delay as the number of 1568 organizations and data records grows. 1570 This issue can be addressed in SNMPv3 through use of view-based access 1571 control and the SNMP notification tables, using the event-driven, event- 1572 driven polling or event-driven batching approaches. This permits 1573 SNMPv3-enabled devices to notify domains that have accounting data 1574 awaiting collection. 1576 However, since views filter at the OID level, not at the data level, 1577 when using views to filter by domain it is necessary to use the domain 1578 as an index. For example, a table of session data could be indexed by 1579 record number and domain, allowing a view to be defined that could 1580 restrict access to domain data to the administrators of that domain. For 1581 example, user bigco could be allowed to view data relating to users 1582 within the bigco.com domain, but user smallco would not be allowed 1583 access to this view. 1585 An advantage of using domains as an index is that this technique can be 1586 used with SNMPv1 and v2 agents as well as with v3 agents. A disadvantage 1587 is that the MIBs must be specifically designed for this purpose. Since 1588 existing MIBs rarely use the domain as an index, domain separation 1589 cannot be enabled within legacy MIBs using this technique. 1591 7.3.3.2. Engines 1593 Another approach is to use contextEngineID to differentiate between data 1594 within individual domains. This approach would only be feasible for use 1595 with SNMPv3, where contextEngineID is supported. Since this technique 1596 can work with existing MIBs it enables domain separation to be applied 1597 to MIBs not specifically designed with domain separation in mind. 1599 One way this can be implemented is to provide multiple SNMP agents on 1600 the same system, one for each domain, differentiated by contextEngineID. 1601 However, this approach is not very scalable, particularly if there are a 1602 large number of domains involved, since it would require multiple agent 1603 implementations each with their own separate data space. 1605 An alternative is to allow one engine to be known by multiple 1606 contextEngineIDs. This would require that an engine be built where the 1607 engineID MIB module is multiply-instanced with different engineID 1608 values, in different contexts. However, this was not the intent of the 1609 original authors of SNMP v3, who assumed only a single contextEngineID 1610 per agent. As a result, doing this may introduce complications. For 1611 example, the MIB module that contains the contextEngineID may explicitly 1612 require only one instance per engine. 1614 7.3.3.3. Contexts 1616 Still another approach is to use contextName to differentiate between 1617 data within individual domains. contextName offers a mechanism for 1618 demultiplexing MIB modules, just as community names did in SNMPv1. The 1619 distinction is that community was overloaded to serve multiple purposes, 1620 while contextName is not. This approach would only be feasible for use 1621 with SNMPv3, where contextName is supported. Since this technique can 1622 work with existing MIBs it enables domain separation to be applied to 1623 MIBs not specifically designed with domain separation in mind. 1625 However, since contextName was not originally designed for the purpose 1626 of domain separation, use for this purpose may be problematic. In the 1627 design of SNMP v3, contexts were intended to be used by an agent to 1628 inform a manager about the contexts known to the agent. As a result, 1629 vacmContextName is read-only and so cannot be configured directly using 1630 SNMP. Since contextName is not manager configurable, this implies that 1631 agents must dynamically create contexts. Manager-defined contexts are 1632 problematic because the agent doesn't know what objects are encompassed 1633 by such a manager-defined context. 1635 Since views filter at the OID level, not the data level, it is not 1636 possible to use VACM to handle the domain separation. Instead, the 1637 domain separation needs to be handled at the sub-agent level. For 1638 example, if the contextName is made available to the sub-agent, then it 1639 can only expose those elements of a table that correspond to the given 1640 context. For example, when a getbulk request is made with a contextName 1641 of bigco.com, then only table entries for bigco.com users would be 1642 visible. For this to work, it is necessary that the MIB not require that 1643 index entries be consecutive, so that table rows may be ommitted as 1644 needed. 1646 In order to implement the required access control within the sub-agent, 1647 this approach requires that the sub-agent APIs pass the contextName to 1648 the sub-agent. Since SNMPv2 does not support contextName, therefore 1649 would need to be rewritten even though the MIB might not require 1650 modification. As a result, agent implementations may not be 1652 7.3.3.4. Proxies 1654 Another approach is to support domain separation via use of a proxy. 1655 However, the proxy application is forbidden to provide access control at 1656 the varbind level, and is designed so that the proxy does not need to 1657 look inside the PDU of the message except to determine the 1658 contextEngineID to verify it is not destined to itself. If 1659 contextEngine == securityEngine, with other qualifications, then the 1660 message is being sent to the current engine, so it is processed locally 1661 rather than being sent to the proxy forwarder. 1663 Restrictions on use of proxies to provide access control at the varbind 1664 level also affect the ability to provide support for legacy devices. If 1665 legacy devices do not support view-based access control, then the proxy 1666 will not be able to provide this capability. 1668 Issues of legacy support also exist with the NMRG extensions. A proxy 1669 receiving a "get subtree" PDU going to a non-NMRG capable device would 1670 need to translate the "get subtree" PDU into multiple getnext or getbulk 1671 requests. This issue would also exist with the subtree retrieval MIB 1672 described in [54], since unless the legacy devices also support the 1673 subtree retrieval MIB, the proxy would encounter the "getbulk overshoot" 1674 problem. 1676 Similarly, unless a device supports the SNMP-over-TCP transport mapping, 1677 deployment of an NMRG-capable proxy will not provide much benefit, since 1678 the proxy will need to fall back to UDP-based getnext or getbulk 1679 operations. This will result in multiple round-trips and high latency 1680 and in addition the risk of inconsistent tables would remain. Existing 1681 proxies are built to support only the current standard operations so 1682 that new proxy code would be needed to support these NMRG extensions. 1684 Where the product of the number of domains and devices is large, such as 1685 in inter-domain accounting applications, the number of shared secrets 1686 can get out of hand. The localized key capability in the SNMPv3 USM 1687 allows a manager to have one central key, sharing it with many agents in 1688 a localized way while preventing the agents from getting at each other's 1689 data. This can assist in cross-domain security if deployed properly. 1691 Another solution is to implement a proxy for the purposes of shared 1692 secret reduction. In such a scheme, the domains will share a secret with 1693 the proxy, and the proxy will share a secret with each of the devices. 1694 Thus the number of shared secrets will scale with the sum of the number 1695 of devices and domains rather than the product. 1697 7.3.4. SNMP summary 1699 Given the wealth of existing accounting-related MIBs, it is likely that 1700 SNMP will remain a popular accounting protocol for the foreseeable 1701 future. Given the SNMPv3 enhancements, it is desirable for SNMP-based 1702 intra-domain accounting implementations to upgrade to SNMPv3. Such an 1703 upgrade is virtually mandatory for inter-domain applications. 1705 With SNMPv3, it is now possible to provide hop-by-hop security services. 1706 Through use of the SNMPv3 notify tables, and confirmed notifications, it 1707 is possible to implement the event-driven, event-driven polling and 1708 event-driven batching models, making it possible to notify domains of 1709 available data rather than requiring them to poll for it. This is 1710 critical in shared use or roaming implementations. 1712 In inter-domain accounting, management of SNMPv3 shared secrets can be 1713 assisted by the localized key capability or via implementation of a 1714 proxy. In the long term, alternative security models such as the 1715 Kerberos Security Model may further reduce the effort required to manage 1716 security. 1718 As noted in [49], SNMP-based accounting has limitations in terms of 1719 efficiency and latency that may make it inappropriate for use in 1720 situations requiring low processing delay or low overhead. These issues 1721 can be addressed via addition of extensions currently under discussion 1722 in the IRTF Network Management Research Group (NMRG). Compatibility 1723 with non-volatile storage can be achieved via implementation of the MIBs 1724 described in [43]-[44]. 1726 Since SNMPv3 was not designed for use in inter-domain accounting, 1727 facilities such as contextEngineID and contextName are not helpful for 1728 domain separation. As a result, the domain as index approach is 1729 recommended. While few current MIBs support the domain as an index, it 1730 may be possible to retrofit existing MIBs to support domain separation. 1732 For example, if all data is table-based, it may be possible to use 1733 AUGMENTS to add a domain-specific index to an existing table. If this 1734 is not possible, it may be necessary to collect data from devices and 1735 sort it by domain, resulting in high processing delay. 1737 In order to reduce latency and make the polling, or event-driven 1738 batching modes viable, it is necessary to support the NMRG extensions. 1739 Since SNMPv3 is not widely deployed today and the NMRG extensions are 1740 still under development, this approach is probably not feasible in the 1741 short to medium term. 1743 8. Review of Accounting Data Transfer 1745 In order for session records to be transmitted between accounting 1746 servers, a transfer protocol is required. Transfer protocols in use 1747 today include SMTP, FTP, and HTTP. For a review of accounting 1748 attributes and record formats, see [45]. 1750 8.1. SMTP 1752 To date, few accounting management systems have been built on SMTP since 1753 the implementation of a store-and-forward message system has 1754 traditionally required access to non-volatile storage which has not been 1755 widely available on network devices. However, SMTP-based 1756 implementations have many desirable characteristics, particularly with 1757 regards to security. 1759 Accounting management systems using SMTP for accounting transfer will 1760 typically support batching so that message processing overhead will be 1761 spread over multiple accounting records. As a result, these systems 1762 result in per-active device state. Since accounting systems using SMTP 1763 as a transfer mechanism have access to substantial non-volatile storage, 1764 they can generate, compress if necessary, and store accounting records 1765 until they are transferred to the collection site. As a result, 1766 accounting systems implemented using SMTP can be highly efficient and 1767 scalable. Using IPSEC, TLS or Kerberos, hop-by-hop security services 1768 such as authentication, integrity protection and confidentiality can be 1769 provided. 1771 As described in [13] and [15], data object security is available for 1772 SMTP, and in addition, the facilities described in [12] make it possible 1773 to request and receive signed receipts, which enables non-repudiation as 1774 described in [12]-[18]. As a result, accounting systems utilizing SMTP 1775 for accounting data transfer are capable of satisfying the most 1776 demanding security requirements. However, such systems are not typically 1777 capable of providing low processing delay, although this may be 1778 addressed by the enhancements described in [20]. 1780 8.2. Other protocols 1782 File transfer protocols such as FTP and HTTP have been used for transfer 1783 of accounting data. For example, Reference [9] describes a means for 1784 representing ASN.1-based accounting data for storage on archival media. 1785 Through the use of the Bulk File MIB, described in [43], accounting data 1786 from an SNMP MIB can be stored in ASN.1, bulk binary or Bulk ASCII 1787 format, and then subsequently retrieved as required using the FTP Client 1788 MIB described in [44]. 1790 Given access to sufficient non-volatile storage, accounting systems 1791 based on record formats and transfer protocols can avoid loss of data 1792 due to long-duration network partitions, server failures or device 1793 reboots. Since it is possible for the transfer to be driven from the 1794 collection site, the collector can retry transfers until successful, or 1795 with HTTP may even be able to restart partially completed transfers. As 1796 a result, file transfer-based systems can be made highly reliable, and 1797 the batching of accounting records makes possible efficient transfers 1798 and application of required security services with lessened overhead. 1800 9. Summary 1802 As noted previously in this document, accounting applications vary in 1803 their security and reliability requirements. Some uses such as capacity 1804 planning may only require authentication, integrity and replay 1805 protection, and modest reliability. Other applications such as inter- 1806 domain usage-sensitive billing may require the highest degree of 1807 security and reliability, since in these cases the transfer of 1808 accounting data will lead directly to the transfer of funds. 1810 Since accounting applications do not have uniform security and 1811 reliability requirements, it is not possible to devise a single 1812 accounting protocol and set of security services that will meet all 1813 needs. Rather, the goal of accounting management should be to provide a 1814 set of tools that can be used to construct accounting systems meeting 1815 the requirements of an individual application. 1817 As a result, it is important to analyze a given accounting application 1818 to ensure that the methods chosen meet the security and reliability 1819 requirements of the application. Based on the analysis given previously, 1820 it appears that existing protocols are capable of meeting the security 1821 and reliability requirements for intra-domain capacity planning and non- 1822 usage sensitive billing. In these applications efficient transfer of 1823 bulk data is important. In order to improve SNMP bulk data transport 1824 and reduce latency, the NMRG has proposed a TCP transport mapping as 1825 well as support for sub-tree retrieval. Both of these extensions would 1826 be welcome; in addition support for file-based storage should be 1827 investigated. For inter-domain use, existing protocols lack data object 1828 security support and extensions for inter-domain authentication are 1829 required, such as the Kerberos Security Model (KSM) for SNMPv3. 1831 For usage sensitive billing, as well as cost allocation and auditing 1832 applications, the reliability requirement are greater. Here existing 1833 protocols can only provide transport layer reliability, but do not 1834 support application layer acknowledgments required for robustness 1835 against accounting server failures. As with capacity planning and non- 1836 usage sensitive billing, efficient transfer of bulk data is important. 1837 In these applications it may also be necessary to put bounds on 1838 processing delay. This implies the need to reduce table retrieval 1839 latency, as addressed by the NMRG extensions to SNMP. Inter-domain 1840 operation requires data object security (which no existing protocol 1841 provides) as well as security model extensions (such as the KSM for 1842 SNMPv3). 1844 Where high-value sessions are involved, such as in roaming, Mobile IP, 1845 or telephony, fraud prevention may require low processing delay. To 1846 meet the latency requirements, SNMP requires support for a TCP transport 1847 mapping as well as subtree retrieval. High reliability is also 1848 required, implying the need for application layer as well as transport 1849 layer acknowledgments. SNMP does not provide this. In inter-domain use, 1850 additional security precautions such as data object security and receipt 1851 support may be required. No existing protocol can meet these 1852 requirements. A summary is given in the table on the next page. 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 | | | | 1856 | Usage | Intra-domain | Inter-domain | 1857 | | | | 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 | | | | 1860 | Capacity | SNMP v3 w/NMRG | SNMP v3 & KSM * | 1861 | Planning | RADIUS #%@ | w/NMRG | 1862 | | TACACS+ @ | | 1863 | | | | 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | | | | 1866 | Non-usage | SNMP v3 w/NMRG | SNMP v3 & KSM * | 1867 | Sensitive | RADIUS #%@ | w/NMRG | 1868 | Billing | TACACS+ @ | | 1869 | | | | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 | | | | 1872 | Usage | | | 1873 | Sensitive | | | 1874 | Billing, | SNMP v3 w/NMRG &$ |SNMP v3 & KSM *&$ | 1875 | Cost | TACACS+ &$@ | w/ NMRG | 1876 | Allocation & | | | 1877 | Auditing | | | 1878 | | | | 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 | | | | 1881 | Time | | | 1882 | Sensitive | SNMP v3 w/NMRG &$ | No existing | 1883 | Billing, | | protocol | 1884 | fraud | | | 1885 | detection, | | | 1886 | roaming | | | 1887 | | | | 1888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 Key 1891 # = lacks confidentiality support 1892 * = lacks data object security 1893 % = limited robustness against packet loss 1894 & = lacks application layer acknowledgment 1895 $ = requires non-volatile storage 1896 @ = lacks batching support 1898 10. Acknowledgments 1900 The authors would like to thank Bert Wijnen (Lucent), Jan Melen 1901 (Ericsson) and Jarmo Savolainen (Ericsson) for many useful discussions 1902 of this problem space. 1904 11. References 1906 [1] Aboba, B., Lu J., Alsop J., Ding J., and W. Wang, "Review of 1907 Roaming Implementations", RFC 2194, September 1997. 1909 [2] Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming 1910 Protocols", RFC 2477, January 1999. 1912 [3] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 1913 Authentication Dial In User Service (RADIUS)", RFC 2138, April, 1914 1997. 1916 [4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. 1918 [5] Gray, J., Reuter, A., Transaction Processing: Concepts and 1919 Techniques, Morgan Kaufmann Publishers, San Francisco, California, 1920 1993. 1922 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1923 Levels", BCP 14, RFC 2119, March 1997. 1925 [7] Crocker, D., Overrell, P., "Augmented BNF for Syntax 1926 Specifications: ABNF", RFC 2234, November 1997. 1928 [8] Aboba, B., and M. Beadles, "The Network Access Identifier", 1929 RFC 2486, January 1999. 1931 [9] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Accounting 1932 Information for ATM Networks", RFC 2512, February 1999. 1934 [10] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Managed 1935 Objects for Controlling the Collection and Storage of Accounting 1936 Information for Connection-Oriented Networks", RFC 2513, February 1937 1999. 1939 [11] Aboba, B., Lidyard, D., "The Accounting Data Interchange Format 1940 (ADIF)", Internet draft (work in progress), draft-ietf-roamops- 1941 actng-05.txt, November 1998. 1943 [12] Fajman, R., "An Extensible Message Format for Message Disposition 1944 Notifications", RFC 2298, March 1998. 1946 [13] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 1947 2015, October 1996. 1949 [14] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting 1950 of Mail System Administrative Messages", RFC 1892, January 1996. 1952 [15] Galvin, J., et al. "Security Multiparts for MIME: Multi- 1953 part/Signed and Multipart/Encrypted", RFC 1847, October 1995. 1955 [16] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1956 1995. 1958 [17] Harding, T., Drummond, R., Shih, C., "MIME-based Secure EDI", 1959 Internet draft (work in progress), draft-ietf-ediint- 1960 as1-11.txt, September 1999. 1962 [18] Harding, T., Drummond, R., Shih, C., "Requirements for Inter- 1963 operable Internet EDI", Internet draft (work in progress), 1964 draft-ietf-ediint-req-08.txt, September 1999. 1966 [19] Borenstein, N., Freed, N, "MIME (Multipurpose Internet Mail 1967 Extensions) Part One: Mechanisms for Specifying and Describing 1968 the Format of Internet Message Bodies", RFC 1521, December 1993. 1970 [20] Klyne, G., "Timely Delivery for Facsimile Using Internet Mail", 1971 Internet draft (work in progress), draft-ietf-fax-timely- 1972 delivery-00.txt, October 1999. 1974 [21] Johnson, H. T., Kaplan, R. S., Relevance Lost: The Rise and Fall of 1975 Management Accounting, Harvard Business School Press, Boston, 1976 Massachusetts, 1987. 1978 [22] Horngren, C. T., Foster, G., Cost Accounting: A Managerial 1979 Emphasis. Prentice Hall, Englewood Cliffs, New Jersey, 1991. 1981 [23] Kaplan, R. S., Atkinson, Anthony A., Advanced Management 1982 Accounting, Prentice Hall, Englewood Cliffs, New Jersey, 1989. 1984 [24] Cooper, R., Kaplan, R. S., The Design of Cost Management Systems. 1985 Prentice Hall, Englewood Cliffs, New Jersey, 1991. 1987 [25] Rigney, C., Willens, S., Calhoun, P., "RADIUS Extensions", draft- 1988 ietf-radius-ext-07.txt, Internet Draft (work in progress), February 1989 2000. 1991 [26] Carrel, D., Grant, L., "The TACACS+ Protocol Version 1.78", 1992 Internet draft (work in progress), draft-grant-tacacs-02.txt, 1993 January 1997. 1995 [27] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 1996 Describing SNMP Management Frameworks", RFC 2571, April 1999. 1998 [28] Rose, M., and K. McCloghrie, "Structure and Identification of 1999 Management Information for TCP/IP-based Internets", RFC 1155, May 2000 1990. 2002 [29] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 2003 March 1991. 2005 [30] M. Rose, "A Convention for Defining Traps for use with the SNMP", 2006 RFC 1215, March 1991. 2008 [31] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 2009 of Management Information for Version 2 of the Simple Network 2010 Management Protocol (SNMPv2)", RFC 1902, January 1996. 2012 [32] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 2013 Conventions for Version 2 of the Simple Network Management Protocol 2014 (SNMPv2)", RFC 1903, January 1996. 2016 [33] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance 2017 Statements for Version 2 of the Simple Network Management Protocol 2018 (SNMPv2)", RFC 1904, January 1996. 2020 [34] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 2021 Management Protocol", RFC 1157, May 1990. 2023 [35] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 2024 "Introduction to Community-based SNMPv2", RFC 1901, January 1996. 2026 [36] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport 2027 Mappings for Version 2 of the Simple Network Management Protocol 2028 (SNMPv2)", RFC 1906, January 1996. 2030 [37] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 2031 Processing and Dispatching for the Simple Network Management 2032 Protocol (SNMP)", RFC 2572, April 1999. 2034 [38] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 2035 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2036 2574, April 1999. 2038 [39] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2039 2573, April 1999. 2041 [40] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 2042 Control Model (VACM) for the Simple Network Management Protocol 2043 (SNMP)", RFC 2575, April 1999. 2045 [41] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 2046 Operations for Version 2 of the Simple Network Management Protocol 2047 (SNMPv2)", RFC 1905, January 1996. 2049 [42] Rose, M.T., The Simple Book, Second Edition, Prentice Hall, Upper 2050 Saddle River, NJ, 1996. 2052 [43] Stewart, B., "Bulk File MIB", Internet draft (work in progress), 2053 draft-stewart-bulk-file-mib-00.txt, November 1998. 2055 [44] Stewart, B., "FTP Client MIB", Internet draft (work in progress), 2056 draft-stewart-ftp-client-mib-00.txt, November 1998. 2058 [45] Brownlee, N., Blount, A., "Accounting Attributes and Record 2059 Formats", Internet draft (work in progress), draft-ietf-aaa- 2060 accounting-attributes-02.txt, March 2000. 2062 [46] Network Management Research Group Web page, http://www.ibr.cs.tu- 2063 bs.de/projects/nmrg/ 2065 [47] Schoenwaelder, J.,"SNMP-over-TCP Transport Mapping", Internet draft 2066 (work in progress), draft-irtf-nmrg-snmp-tcp-01.txt, June 1999. 2068 [48] Schoenwaelder, J.,"SNMP Payload Compression", Internet draft (work 2069 in progress), draft-irtf-nmrg-snmp-compression-00.txt, June 1999. 2071 [49] Sprenkels, R., Martin-Flatin, J.,"Bulk Transfers of MIB Data", 2072 Simple Times, http://www.simple-times.org/pub/simple- 2073 times/issues/7-1.html, March 1999. 2075 [50] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP Payload 2076 Compression Protocol (IPComp)", RFC 2393, December 1998. 2078 [51] Hornstein, K., Hardaker, W., "A Kerberos Security Model for SNMP 2079 v3", Internet draft (work in progress), draft-hornstein- 2080 snmpv3-ksm-00.txt, June 1999. 2082 [52] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, 2083 J., Trostle, J., "Public Key Cryptography for Initial 2084 Authentication in Kerberos", Internet draft (work in progress), 2085 draft-ietf-cat-kerberos-pk-init-09.txt, June 1999. 2087 [53] Tung, B., Ryutov, T., Neuman, C., Tsudik, G., Sommerfeld, B., 2088 Medvinsky, A., Hur, M., "Public Key Cryptography for Cross-Realm 2089 Authentication in Kerberos", Internet draft (work in progress), 2090 draft-ietf-cat-kerberos-pk-cross-04.txt, June 1999. 2092 [54] Thaler, D., "Get Subtree Retrieval MIB", Internet draft (work in 2093 progress), draft-irtf-nmrg-get-subtree-mib-00.txt, October 1999. 2095 [55] Stewart, R. R., et al., "Simple Control Transmission Protocol", 2096 Internet draft (work in progress), draft-ietf-sigtran-sctp-05.txt, 2097 January 2000. 2099 12. Author's Addresses 2101 Bernard Aboba 2102 Microsoft Corporation 2103 One Microsoft Way 2104 Redmond, WA 98052 2105 USA 2107 Phone: +1 425 936 6605 2108 EMail: bernarda@microsoft.com 2110 Jari Arkko 2111 Oy LM Ericsson Ab 2112 02420 Jorvas 2113 Finland 2115 Phone: +358 40 5079256 2116 EMail: Jari.Arkko@ericsson.com 2118 David Harrington 2119 Cabletron Systems Inc. 2120 P.O.Box 5005 2121 Rochester NH 03867-5005 2122 USA 2124 Phone: +1 603 337 7357 2125 EMail: dbh@cabletron.com 2127 13. Intellectual Property Statement 2129 The IETF takes no position regarding the validity or scope of any 2130 intellectual property or other rights that might be claimed to pertain 2131 to the implementation or use of the technology described in this 2132 document or the extent to which any license under such rights might or 2133 might not be available; neither does it represent that it has made any 2134 effort to identify any such rights. Information on the IETF's 2135 procedures with respect to rights in standards-track and standards- 2136 related documentation can be found in BCP-11. Copies of claims of 2137 rights made available for publication and any assurances of licenses to 2138 be made available, or the result of an attempt made to obtain a general 2139 license or permission for the use of such proprietary rights by 2140 implementors or users of this specification can be obtained from the 2141 IETF Secretariat. 2143 The IETF invites any interested party to bring to its attention any 2144 copyrights, patents or patent applications, or other proprietary rights 2145 which may cover technology that may be required to practice this 2146 standard. Please address the information to the IETF Executive 2147 Director. 2149 14. Full Copyright Statement 2151 Copyright (C) The Internet Society (2000). All Rights Reserved. 2152 This document and translations of it may be copied and furnished to 2153 others, and derivative works that comment on or otherwise explain it or 2154 assist in its implementation may be prepared, copied, published and 2155 distributed, in whole or in part, without restriction of any kind, 2156 provided that the above copyright notice and this paragraph are included 2157 on all such copies and derivative works. However, this document itself 2158 may not be modified in any way, such as by removing the copyright notice 2159 or references to the Internet Society or other Internet organizations, 2160 except as needed for the purpose of developing Internet standards in 2161 which case the procedures for copyrights defined in the Internet 2162 Standards process must be followed, or as required to translate it into 2163 languages other than English. The limited permissions granted above are 2164 perpetual and will not be revoked by the Internet Society or its 2165 successors or assigns. This document and the information contained 2166 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 2167 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 2168 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2169 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2170 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2172 15. Expiration Date 2174 This memo is filed as , and expires 2175 December 1, 2000.