Network Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                   Microsoft Corporation
     Category: Informational                                     Jari Arkko
     <draft-aboba-acct-00.txt>                                     Ericsson
     6 August 1998
     
     
     
                     Introduction to Accounting Management
     
     
     1.  Status of this Memo
     
     This document is an Internet-Draft.  Internet-Drafts are working docu-
     ments of the Internet Engineering Task Force (IETF),  its  areas,  and
     its  working groups.  Note that other groups may also distribute work-
     ing documents as Internet-Drafts.
     
     Internet-Drafts are draft documents valid for a maximum of six  months
     and  may  be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as  reference  mate-
     rial or to cite them other than as ``work in progress.''
     
     To  learn  the  current status of any Internet-Draft, please check the
     ``1id-abstracts.txt'' listing contained in the Internet-Drafts  Shadow
     Directories   on   ftp.ietf.org   (US  East  Coast),  nic.nordu.net
     (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
     
     The  distribution  of  this memo is unlimited.  It is filed as <draft-
     aboba-acct-00.txt>, and  expires February 1, 1999 Please send comments
     to the authors.
     
     
     2.  Abstract
     
     The field of Accounting Management is concerned with the collection of
     resource consumption data for the purposes of capacity and trend anal-
     ysis,  cost allocation, auditing, and billing. This document describes
     the problems encountered in Accounting Management, as well as some  of
     the  issues  encountered  in the design of accounting systems. It also
     reviews the state of current practice.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Aboba & Arkko                                                 [Page 1]


     INTERNET-DRAFT                                           6 August 1998
     
     
     3.  Table of Contents
     
          1.  Status of this Memo
          2.  Abstract
          3.  Table of Contents
          4.  Introduction
              4.1   Terminology
              4.2   Accounting management architecture
              4.3   Accounting management objectives
              4.4   Intra-domain and inter-domain accounting
          5.  Scaling and reliability properties of accounting systems
              5.1   Resource consumption
              5.2   Fault resilience
              5.3   Data collection models
          6.  Review of current practice
              6.1   Accounting protocols
              6.2   Accounting data transfer protocols
          7.  Acknowledgements
          8.  References
          9.  Authors' Addresses
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Aboba & Arkko                                                 [Page 2]


     INTERNET-DRAFT                                           6 August 1998
     
     
     4.  Introduction
     
     The field of Accounting Management is concerned with the collection of
     resource consumption data for the purposes of capacity and trend anal-
     ysis, cost allocation, auditing, and billing. This document  describes
     each of these problems, and discusses the issues involved in design of
     modern accounting systems.
     
     
     4.1.  Terminology
     
     This document frequently uses the following terms:
     
     Accounting
               The act of collecting information on resource usage for  the
               purpose  of trend analysis, auditing, billing, or cost allo-
               cation.
     
     Rating    The act of determining the price to be charged for use of  a
               resource.
     
     Billing   The act of preparing an invoice.
     
     Auditing  The act of verifying the correctness of a procedure.
     
     Cost Allocation
               The act of allocating costs between entities. Note that cost
               allocation and rating are fundamentally different processes.
     
     Interim accounting
               An  interim  accounting  packet provides a snapshot of usage
               during a user's session.  It  is  typically  implemented  in
               order  to provide for partial accounting of a user's session
               in the event of a device reboot  or  other  network  problem
               that  prevents  the reception of a session summary packet or
               session record.
     
     Session record
               A session record represents a summary of the  resource  con-
               sumption of a user over the entire session. Accounting gate-
               ways creating the session record may  do  so  by  processing
               interim accounting events.
     
     Accounting Protocol
               A protocol used to convey data for accounting purposes.
     
     Intra-domain accounting
               Intra-domain  accounting involves the collection of informa-
               tion on resource within an administrative  domain,  for  use
               within  that  domain. In intra-domain accounting, accounting
               packets and session records typically do not cross  adminis-
               trative boundaries.
     
     
     
     
     
     Aboba & Arkko                                                 [Page 3]


     INTERNET-DRAFT                                           6 August 1998
     
     
     Inter-domain accounting
               Inter-domain  accounting involves the collection of informa-
               tion on resource usage of an entity with  an  administrative
               domain,  for  use  within  another administrative domain. In
               inter-domain  accounting,  accounting  packets  and  session
               records will typically cross administrative boundaries.
     
     Real-time accounting
               Real-time  accounting involves the processing of information
               on resource usage within a defined time  window.  Time  con-
               straints  are  typically imposed in order to limit financial
               risk.
     
     Accounting server
               The accounting server receives accounting data from  devices
               and  translates  it  into  session  records.  The accounting
               server may also take responsibility for the routing of  ses-
               sion records to interested parties.
     
     
     4.2.  Accounting management architecture
     
     Accounting  management  requires  that accounting metrics be measured,
     rated, assigned, and communicated between appropriate parties.
     
     The accounting management architecture involves  interactions  between
     network devices, accounting servers, and billing servers.  The network
     device collects resource consumption data in the  form  of  accounting
     metrics. This information is then transferred to an accounting server.
     Typically this is accomplished via an accounting protocol, although it
     is also possible for devices to generate session records.
     
     The accounting server then processes the accounting data received from
     the network device.  This  processing  may  include  summarization  of
     interim accounting information, elimination of duplicate data, or gen-
     eration of session records.
     
     The processed accounting data is then submitted to a  billing  server,
     which  typically  handles  rating and invoice generation, but may also
     carry out auditing, cost allocation, trend analysis or capacity  plan-
     ning  functions.  Session records may be batched and compressed by the
     accounting server prior to submission to the billing server  in  order
     to  reduce the volume of accounting data and the bandwidth required to
     accomplish the transfer.
     
     One of the functions  of  the  accounting  server  is  to  distinguish
     between the inter and intra-domain accounting events and to route them
     appropriately.  Intra-domain accounting events are typically routed to
     the local billing server, while inter-domain accounting events will be
     routed to accounting servers  operating  within  other  administrative
     domains.  While it is not required that session record formats used in
     inter and intra-domain accounting  transfers  be  the  same,  this  is
     highly desirable, since this eliminates translations that would other-
     wise be required.
     
     
     
     Aboba & Arkko                                                 [Page 4]


     INTERNET-DRAFT                                           6 August 1998
     
     
     The diagram below illustrates a typical accounting architecture:
     
          +------------+
          |            |
          |   Network  |
          |   Device   |
          |            |
          |            |
          +------------+
                |
     Accounting |
     Protocol   |
                |
                |
                |
                |
                |
                V
          +------------+                               +------------+
          |            |                               |            |
          |   Org B    |      Inter-domain             |  Org A     |
          |   Acctg.   |<----------------------------->|  Acctg.    |
          |   Server   |      session records          |  Server    |
          |            |                               |            |
          |            |                               |            |
          +------------+                               +------------+
                |                                            |
                |                                            |
                |  Intra-domain                              |
                |  session records                           |
     Transfer   |                                            |
     Protocol   |                                            |
                |                                            |
                |                                            |
                V                                            V
          +------------+                               +------------+
          |            |                               |            |
          |  Org B     |                               |  Org A     |
          |  Billing   |                               |  Billing   |
          |  Server    |                               |  Server    |
          |            |                               |            |
          +------------+                               +------------+
     
     
     4.3.  Accounting management objectives
     
     Accounting Management involves the collection of resource  consumption
     data for the purposes of capacity and trend analysis, cost allocation,
     auditing, and billing. Since each of these tasks have different relia-
     bility  and  security  requirements,  it is worthwhile to discuss each
     task in detail.
     
     
     
     
     
     
     Aboba & Arkko                                                 [Page 5]


     INTERNET-DRAFT                                           6 August 1998
     
     
     4.3.1.  Trend analysis and capacity planning
     
     In trend analysis and capacity planning, the goal is typically a fore-
     cast  of  future usage. Since such forecasts are inherently imperfect,
     absolute reliability in accounting data collection  is  typically  not
     required.   As  a result moderate data loss can typically be tolerated
     in such an application.
     
     In certain cases, it may be  desirable  to  use  statistical  sampling
     techniques  to reduce data collection requirements while still provid-
     ing the forecast with the desired statistical accuracy.  Such  a  sam-
     pling  process may be insensitive even to large amounts of packet loss
     as long as bias is not introduced.
     
     The security requirements for trend  analysis  and  capacity  planning
     depend  on the circumstances of data collection and the sensitivity of
     the data.  Generally, additional security  services  may  be  required
     when  data  is  being transferred between administrative domains.  For
     example, when information is being collected and analyzed  within  the
     same  administrative  domain,  integrity protection and authentication
     may be used in order to guard against collection of invalid data.   In
     inter-domain  applications  confidentiality it may be desirable to add
     confidentiality, to guard against snooping by third parties.
     
     
     4.3.2.  Billing
     
     When accounting data is used for billing  purposes,  the  requirements
     differ  based  on  whether the billing process requires information on
     usage. A billing process that does not require  usage  information  to
     prepare an invoice can be said to be non-usage-sensitive.
     
     Since  by  definition,  non-usage-sensitive  billing  does not require
     usage information, in theory all accounting data can be  lost  without
     affecting  the  billing  process.  Of  course wholesale data loss will
     affect other tasks such as trend analysis or auditing,  so  that  this
     would still cause problems.
     
     Since  usage-sensitive  billing processes depend on usage information,
     packet loss may translate directly to revenue loss. As a  result,  the
     billing  process  may need to meet requirements arising from financial
     reporting standards, or legal requirements, and therefore an  archival
     approach  may be required. In archival accounting, the goal is to col-
     lect all accounting data, to reconstruct missing entries  as  best  as
     possible in the event of data loss, and to archive data for a mandated
     time period, which is typically seven years.
     
     Usage-sensitive systems may also have additional requirements relating
     to  processing delay. Today credit risk is commonly managed by comput-
     erized fraud detection systems that are  designed  to  detect  unusual
     activity.  While  transfer efficiency concerns might otherwise dictate
     batched transmission of accounting data, where it is desirable to min-
     imize financial risk, a different approach may be required.
     
     
     
     
     Aboba & Arkko                                                 [Page 6]


     INTERNET-DRAFT                                           6 August 1998
     
     
     Since  financial  exposure  increases with processing delay, it may be
     necessary to transmit each event individually  or  to  minimize  batch
     size,  to require positive acknowledgment before providing service, or
     even to utilize quality of  service  techniques  to  minimize  queuing
     delays.
     
     The  degree of financial exposure is application-dependent. For dialup
     Internet access from a local provider, charges are low  and  therefore
     the  risk  of loss is small. However, in the case of dialup roaming or
     voice over IP, time-based charges may be substantial and therefore the
     risk  of fraud is larger. In such situations it is highly desirable to
     quickly detect unusual account activity, and it may be  desirable  for
     authentication  to depend on ability to pay. In situations where valu-
     able resources can be reserved, or where charges  can  be  high,  very
     large bills may be rung up quickly, and therefore real-time processing
     may be required.
     
     In usage-sensitive systems, accounting data  may  result  in  monetary
     transfers,  and as a result, the security and reliability requirements
     are  greater.  Thus  security  services  such  as  authentication  and
     integrity protection are frequently used, and confidentiality and non-
     repudiation may also be desirable.
     
     
     4.3.3.  Auditing
     
     With enterprise networking  expenditures  on  the  rise,  interest  in
     auditing  is  increasing.  Auditing, which is the act of verifying the
     correctness of a procedure, commonly relies on accounting data. Audit-
     ing  tasks  include verifying correctness of an invoice submitted by a
     service provider, or verification that usage is  conforming  to  usage
     policy, service level agreements, or security guidelines.
     
     To permit a credible audit, the accounting data collection methods put
     in place must be at least as reliable as those used by  the  invoicing
     service provider. Similarly, security policies involved in auditing of
     an invoice should be at least as stringent as those used in the origi-
     nal calculation.
     
     Where  auditing  procedures are used to verify conformance to usage or
     security policies, security services may be  desired.  This  typically
     will  include  integrity  protection  and authentication of accounting
     data, as well as confidentiality and possibly data object security. In
     order  to  permit response to security incidents in progress, auditing
     applications frequently are  built  to  operate  with  low  processing
     delay.
     
     
     4.3.4.  Cost allocation
     
     The  application of cost allocation and billback methods by enterprise
     customers is not yet widespread.  However,  with  the  convergence  of
     telephony  and  data  communications,  there is increasing interest in
     applying cost allocation and billback procedures to networking  costs,
     
     
     
     Aboba & Arkko                                                 [Page 7]


     INTERNET-DRAFT                                           6 August 1998
     
     
     as is now commonly practiced with telecommunications costs.
     
     Cost  allocation  models,  including  traditional  costing  mechanisms
     described in [27]-[29] and activity-based costing techniques described
     in [30] are typically based on detailed analysis of usage data, and as
     a result they are almost always usage-sensitive. Whether cost  alloca-
     tion  models  are applied to allocation of costs between partners in a
     venture or to allocation of costs  between  departments  in  a  single
     firm, cost allocation models often have profound behavioral and finan-
     cial impacts. As a result, systems developed  for  this  purposes  are
     typically  as  concerned with reliable data collection and security as
     are billing applications.
     
     
     4.4.  Intra-domain and inter-domain accounting
     
     Much of the early work on  accounting  management  focused  on  intra-
     domain  accounting  applications. However, with the increasing deploy-
     ment of services such as dialup roaming, Internet fax, Internet  tele-
     phony  and  QoS,  applications  requiring  inter-domain accounting are
     becoming increasingly common.
     
     Intra-domain accounting differs from intra-domain accounting  in  sev-
     eral  important  ways. Intra-domain accounting involves the collection
     of  information  on  resource  consumption  within  an  administrative
     domain,  for  use  within  that  domain.  In  intra-domain accounting,
     accounting packets and session records typically do not cross adminis-
     trative  boundaries. As a result, intra-domain accounting applications
     typically experience low rates of packet loss.
     
     In contrast, inter-domain accounting involves the collection of infor-
     mation  on  resource  consumption within an administrative domain, for
     use within another administrative domain. In inter-domain  accounting,
     accounting  packets  and session records will typically cross adminis-
     trative boundaries. As a result, inter-domain accounting  applications
     may experience substantial packet loss.
     
     Since   inter-domain  accounting  applications  involve  transfers  of
     accounting data between domains, additional security measures  may  be
     desirable.  In addition to authentication and integrity protection, it
     may be desirable to deploy security services such as  confidentiality,
     replay  protection or non-repudiation. In inter-domain accounting each
     involved party also typically requires a copy of each accounting event
     for invoice generation and auditing.
     
     
     5.  Scaling and reliability characteristics of accounting systems
     
     With  the  continuing  growth  of  the  Internet, it is important that
     accounting management systems be scalable and reliable.  This  section
     discusses  the  resources consumed by accounting management systems as
     well as the scalability and reliability properties exhibited by  vari-
     ous data collection models.
     
     
     
     
     Aboba & Arkko                                                 [Page 8]


     INTERNET-DRAFT                                           6 August 1998
     
     
     5.1.  Resource consumption
     
     In  the  process  of  growing  to meet the needs of providers and cus-
     tomers, accounting management systems consume a variety of  resources,
     including:
     
        Network bandwidth
        Memory/non-volatile storage on managed devices
        State on the accounting management system
        CPU on the management system and managed devices
     
     In  order to understand the limits to scaling of accounting management
     systems, we examine each of these resources in turn.
     
     
     5.1.1.  Network bandwidth
     
     Accounting management systems consume network bandwidth in the  trans-
     ferring  of accounting data. The network bandwidth consumed is propor-
     tional to the amount of data transferred, as well as required  network
     overhead.   Since  accounting data for a given event may be 100 octets
     or less, if each event is transferred individually,  network  overhead
     can  represent  a  considerable proportion of total bandwidth consump-
     tion. As a result, it is often desirable to transfer  accounting  data
     in  batches, enabling network overhead to be spread over a larger pay-
     load, and enabling efficient use of compression.
     
     
     5.1.2.  Memory/non-volatile storage on managed devices
     
     In accounting systems without  non-volatile  memory,  accounting  data
     must  be stored in the period between when it is generated and when it
     is transferred. The resulting memory consumption will depend on  retry
     and  retransmission algorithms. Since systems designed for high relia-
     bility will typically wish to retry for long  periods,  the  resulting
     memory consumption can be considerable.
     
     Since  accounting  data stored in memory will typically be lost in the
     event of a device reboot, or a timeout, it may be desirable to provide
     non-volatile  storage  for undelivered accounting data. With the costs
     of flash RAM declining rapidly, it is likely that network devices will
     be  capable  of incorporating non-volatile storage within the next few
     years.
     
     
     5.1.3.  State on the accounting management system
     
     In order to keep track of received accounting data, accounting manage-
     ment  systems  may need to keep state on managed devices or concurrent
     sessions. Since the number of devices is typically much  smaller  than
     the  number  of concurrent sessions, it is desirable to keep only per-
     device state if possible.
     
     
     
     
     
     Aboba & Arkko                                                 [Page 9]


     INTERNET-DRAFT                                           6 August 1998
     
     
     5.1.4.  CPU requirements
     
     CPU consumption of the managed and managing nodes will be proportional
     to  the  complexity  of the required accounting processing. Operations
     such as ASN.1 encoding and  decoding,  compression/decompression,  and
     encryption/decryption  can  consume  considerable  resources,  both on
     accounting clients and servers.
     
     The effect of these operations on accounting system reliability should
     not  be under-estimated, particularly in the case of devices with mod-
     erate CPU resources. In the  event  that  devices  are  over-taxed  by
     accounting  tasks,  it  is likely that overall device reliability will
     suffer.
     
     
     5.2.  Fault resilience
     
     Given the potential importance of accounting data, it is highly desir-
     able  for  accounting  systems  to  be  resilient against a variety of
     faults, including:
     
        Packet loss
        Accounting server failures
        Network failures
        Device reboots
     
     
     This section discusses each of these failure modes in turn.
     
     
     5.2.1.  Packet loss
     
     As packet loss is a fact of life on the Internet, accounting protocols
     need  to  be  resilient  against such losses. Typically this is accom-
     plished either via implementation of a retry mechanism on top of  UDP,
     or use of TCP.
     
     
     5.2.2.  Accounting server failures
     
     In  the  event of an accounting server failure, it may not be possible
     for a device to transmit accounting data  to  its  primary  accounting
     server.   For protocols using TCP, opening of a connection to the sec-
     ondary accounting server can occur after a timeout or loss of the pri-
     mary  connection, or it can occur on expiration of a timer. For proto-
     cols using UDP, transmission to the secondary server can occur after a
     number  of retries or timer expiration. In either case, it is possible
     for the primary and secondary accounting servers to receive  the  same
     record, so that elimination of duplicates is required.
     
     
     
     
     
     
     
     
     Aboba & Arkko                                                [Page 10]


     INTERNET-DRAFT                                           6 August 1998
     
     
     5.2.3.  Network failures
     
     Network  failures may result in partial or complete loss of connectiv-
     ity for the accounting client. In the event  of  partial  connectivity
     loss,  it  may not be possible to reach the primary accounting server,
     in which case switchover to the secondary accounting server is  neces-
     sary.   In  the  event  of a network partition, it may be necessary to
     store accounting events in device memory or non-volatile storage until
     connectivity can be re-established.
     
     The  importance of non-volatile storage in design of reliable account-
     ing systems should  not  be  under-estimated.  Without  such  storage,
     event-driven  systems will lose data once the transmission timeout has
     been exceeded, and polling or event-driven batching designs will expe-
     rience  data  loss once the internal memory used for event storage has
     been exceeded. As a result, network access is not by itself a  guaran-
     tee  of reliable data transfer, and for many years reliable accounting
     systems were implemented based solely on physical storage, without any
     need  for  network  access.  For  example, phone usage data used to be
     stored on paper, film, or magnetic media and carried from the place of
     collection to a central location for bill processing.
     
     
     5.2.4.  Device reboots
     
     In  the event of a device reboot, it is desirable to minimize the loss
     of data on sessions in progress. This can be accomplished via  interim
     accounting,  with  the  interim accounting data being transferred over
     the network or kpt in non-volatile storage.
     
     
     5.3.  Data collection models
     
     Several data collection models are currently in use today for the pur-
     poses of accounting data collection. These include:
     
        Polling model
        Event-driven model
        Event-driven polling model
        Interim accounting
     
     
     5.3.1.  Polling model
     
     In  the  polling  model,  an  accounting manager will poll devices for
     accounting information  at  regular  intervals.  In  order  to  ensure
     against  loss  of  data,  the polling interval will need to be shorter
     than the maximum time that accounting data can be stored on the polled
     device.  For  devices  without  non-volatile strage, this is typically
     determined by available memory; for devices with non-volatile  storage
     the maximum polling interval is determined by the size of non-volatile
     storage.
     
     
     
     
     
     Aboba & Arkko                                                [Page 11]


     INTERNET-DRAFT                                           6 August 1998
     
     
     The polling model results in an accumulation of data within individual
     devices,  and  as  a  result,  data  is  typically  transferred to the
     accounting manager in a batch, resulting in an efficient transfer pro-
     cess. In terms of Accounting Manager state, polling systems scale with
     the number of managed devices, and system bandwidth usage scales  with
     the amount of data transferred.
     
     Without  non-volatile  storage,  the  polling model results in loss of
     accounting data due to device reboots, but not due to packet  loss  or
     network  failures  of sufficiently short duration to be handled within
     available memory. In situations  where  operational  difficulties  are
     encountered, the volume of accounting data will frequently increase so
     as to make data loss more likely. However, in this  case  the  polling
     model  will  detect  the  problem  since attempts to reach the managed
     devices will fail.
     
     Per-device state is typical of polling-based network  management  sys-
     tems,  which  often  also  carry  out accounting management functions,
     since network management systems need to keep track of  the  state  of
     network devices for operational purposes.
     
     
     5.3.2.  Event-driven model
     
     In the event-driven model, a device will contact the accounting server
     or manager when it is ready to transfer accounting data.  Most  event-
     driven accounting systems are based on RADIUS accounting, described in
     [4], and transfer only one accounting event per packet, which is inef-
     ficient.
     
     Without  non-volatile  storage,  a pure event-driven model only stores
     individual accounting events that have not yet been delivered and as a
     result  it  has the smallest memory requirements of any of the models.
     However, the event-driven model is  also  the  least  reliable,  since
     accounting  data  loss  will  occur  due  to device reboots, sustained
     packet loss, or network failures of duration greater than the  timeout
     interval.   Since accounting servers will not receive events if opera-
     tional difficulties are encountered, event-driven  accounting  systems
     are not very useful in monitoring of device health.
     
     Per-session state is typical of event-driven systems without batching,
     and as a result, a pure event-driven approach is to be  avoided  wher-
     ever possible.
     
     
     5.3.3.  Event-driven polling model
     
     In  the event-driven polling model an accounting manager will poll the
     device for accounting data only when it receives an event.  The  event
     can  occur  at regular time intervals, or when a batch of a given size
     has been gathered or both. Note that while  transfer  efficiency  will
     increase  with batch size, without non-volatile storage, the potential
     data loss from a device reboot will also increase.
     
     
     
     
     Aboba & Arkko                                                [Page 12]


     INTERNET-DRAFT                                           6 August 1998
     
     
     Without non-volatile storage, an event-driven polling model will  lose
     data  due  to device reboots, but not due to sustained packet loss, or
     network partitions  of  short-duration.   Unless  a  minimum  delivery
     interval  is set, event-driven polling systems are not useful in moni-
     toring of device health.
     
     Where batching can be implemented the state required  in  event-driven
     polling  can be reduced to scale with the number of active devices. If
     portions of the network vary widely in  usage,  then  this  state  may
     actually be less than that of the polling approach.
     
     
     5.3.4.  Interim accounting
     
     Interim  accounting is in use both in RADIUS [31] and in TACACS+ [32].
     It is typically implemented to improve accounting  system  reliability
     and  may  be  applied to either event-driven or polling systems. While
     interim accounting can in theory be used to limit  data  loss  due  to
     packet  loss,  short-duration  network failures, or device reboot, its
     applicability is limited  by  bandwidth  consumption  concerns.  As  a
     result,  interim  accounting is most typically implemented in order to
     avoid loss of long-duration sessions, and the interim interval is typ-
     ically  set larger than the average session duration.This ensures that
     most sessions will not result  in  generation  of  interim  accounting
     events  and  the  additional  bandwidth consumed by interim accounting
     will be moderate.
     
     However, as the interim accounting interval decreases toward  the  the
     average  session  time,  the  additional bandwidth consumed by interim
     accounting increases markedly, and as a result, the interval  must  be
     set  with  caution.  This  practice  is  particularly suspect since it
     increases use of network bandwidth in normal operation, while  provid-
     ing  benefits  only in the event of a fault.  ,LP Given the decreasing
     cost of non-volatile memory, it may be  preferable  to  store  interim
     accounting  data  in  non-volatile  storage. Stored interim events are
     then replaced by session data when the session completes, and the ses-
     sion  data  can  itself  be erased once the data has been transmitted.
     This approach avoids interim data being  transmitted  over  the  wire,
     except in the case of a device reboot.
     
     
     6.  Review of current practice
     
     Accounting systems have been successfully impelemented using protocols
     such as RADIUS, TACACS+, SYSLOG and SNMP. This section  describes  the
     characteristics of each of these protocols, as well as transfer proto-
     cols such as HTTP, FTP, and SMTP.
     
     
     6.1.  Accounting protocols
     
     
     
     
     
     
     
     Aboba & Arkko                                                [Page 13]


     INTERNET-DRAFT                                           6 August 1998
     
     
     6.1.1.  RADIUS
     
     RADIUS accounting, described in [4], was developed as an add-on to the
     RADIUS  authentication protocol, described in [3]. As a result, RADIUS
     accounting shares the event-driven approach of RADIUS  authentication,
     without  support for batching or polling. As a result, RADIUS account-
     ing scales with the number of accounting events instead of the  number
     of  devices,  and  accounting  transfers are inefficient. In addition,
     since RADIUS accounting is based on UDP and timeout and retry  parame-
     ters  are not specified, implementations vary widely in their approach
     to reliability, with some implementations retrying until  delivery  or
     buffer  depletion,  and  others  losing  accounting  data  after a few
     retries.
     
     As a result, many RADIUS accounting implementations are  sensitive  to
     packet  loss  or short-lived network partitions, and such deficiencies
     are magnified further when RADIUS  accounting  is  applied  in  inter-
     domain  accounting as is required in roaming, as noted in [1].  On the
     other hand, the event-driven approach of  RADIUS  accounting  is  well
     suited  to  handling of accounting events which require low processing
     delay, such as is required for credit risk management or fraud  detec-
     tion.
     
     While  RADIUS  accounting  does  provide hop-by-hop authentication and
     integrity protection, hop-by-hop confidentiality or data object  secu-
     rity  services  are  not  supported,  and thus systems based on RADIUS
     accounting are not capable of being deployed with  untrusted  proxies,
     as noted in [2].
     
     While  in  principle extensible with the definition of new attributes,
     RADIUS suffers from the  very  small  standard  attribute  space  (256
     attributes).
     
     
     6.1.2.  TACACS+
     
     TACACS+  as  defined  in  [32]  offers an accounting model with start,
     stop, and interim update messages. Since  TACACS+  is  based  on  TCP,
     implementations are typically resilient against packet loss and short-
     lived network partitions. However, given the tradeoff  between  relia-
     bility  and  delay,  TACACS+  accounting is less suited to handling of
     accounting events which require low processing delay.
     
     TACACS+ provides for hop-by-hop authentication and  integrity  protec-
     tion  as  well  as hop-by-hop confidentiality. Data object security is
     not supported, and therefore systems based on TACACS+  accounting  are
     not deployable in the presence of untrusted proxies.
     
     
     6.1.3.  SNMP
     
     SNMP-based  accounting  systems,  such as is described in [9] and [10]
     have been successfully  deployed  in  situations  where  sophisticated
     security  is  not  required  and  the  overhead  of ASN.1 encoding and
     
     
     
     Aboba & Arkko                                                [Page 14]


     INTERNET-DRAFT                                           6 August 1998
     
     
     decoding is not a concern. Since polling allows data to  be  collected
     on  multiple  accounting events simultaneously, such systems can store
     accounting data up to the limits of their memory or non-volatile stor-
     age, improving scaling properties and enabling efficient transfers.
     
     Since  the  management agent is able to retry requests when a response
     is not received, such systems are resilient  against  packet  loss  or
     even short-lived network partitions.  Although with SNMP v2 it is also
     possible to implement such systems using confirmed  notifications,  we
     are  not  aware  of any SNMP-based accounting systems that make use of
     this  facility.  With  SNMPv3,  described  in  [12]-[14],   SNMP-based
     accounting  systems will be capable of incorporating view-based access
     controls, described in [16], as well as user-based security, described
     in [15]. As a result, SNMP v3-based systems can provide for hop-by-hop
     authentication and confidentiality services, in  addition  to  access-
     control.  They  cannot  however  provide  data-object  based  security
     required for deployment with untrusted proxies.
     
     Where multiple administrative domains are involved,  such  as  in  the
     shared  use  networks described in [1], more sophisticated access con-
     trols are often required. Since in shared use networks the same device
     may  be  accessed  by multiple organizations, it is often necessary to
     control access to accounting data according to  the  user's  organiza-
     tion.  This ensures that organizations may be given access to account-
     ing data relating to their users, but not to data relating to users of
     other  organizations.  This implies that the view-based access control
     described in [16] is not sufficient, since access rights  will  depend
     not  only  on  the element being collected, but on the identity of the
     user to whom that data relates. As a result, shared-use networks rely-
     ing  on  SNMP-based  accounting  have generally collected data for all
     organizations and then sorted the resulting session records for deliv-
     ery  to  each organization. While functional, this approach will typi-
     cally result in increased processing delay.
     
     
     6.1.4.  DIAMETER
     
     DIAMETER as defined in [33] - [35] is currently not used for  account-
     ing purposes and does not have accounting messages defined.
     
     
     
     6.2.  Accounting data transfer protocols
     
     In  order  for  session  records  to be transmitted between accounting
     servers, a transfer protocol is required. Transfer  protocols  in  use
     today include SMTP, FTP, and HTTP.
     
     
     6.2.1.  SMTP-based accounting record transfer
     
     Accounting systems using SMTP as an accounting data transfer mechanism
     typically have access to substantial non-volatile storage. This allows
     them  to generate, compress if necessary, and store accounting records
     
     
     
     Aboba & Arkko                                                [Page 15]


     INTERNET-DRAFT                                           6 August 1998
     
     
     until they are transferred to the collection site.  Using  IPSEC,  TLS
     or  Kerberos,  hop-by-hop  security  services  such as authentication,
     integrity  protection  and  confidentiality  can  be   provided.    As
     described  in  [18]  and  [20],  data object security is available for
     SMTP, and in addition, the facilities described in [17] make it possi-
     ble to request and receive signed receipts, which enables non-repudia-
     tion as described in [17]-[23]. As a result, accounting  systems  uti-
     lizing SMTP for accounting data transfer are capable of satisfying the
     most demanding security rquirements.
     
     
     6.2.2.  Other transfer mechanisms
     
     HTTP and FTP have also been used for accounting data transfer.   Given
     access to sufficient non-volatile storage, accounting systems based on
     record formats and transfer protocols can avoid loss of  data  due  to
     long-duration  network partitions or in even internal faults. Since it
     is possible for the transfer to be driven from  the  collection  site,
     the  collector  can retry transfers until successful, or with HTTP may
     even be able to restart partially completed transfers.  As  a  result,
     file  transfer-based  systems  can  be  made  highly reliable, and the
     batching of accounting records makes possible efficient transfers  and
     application  of  required  security  services  with lessened overhead.
     However, such systems are not typically capable of providing low  pro-
     cessing  delay,  although  this  may  be addressed by the enhancements
     described in [26].
     
     
     7.  Acknowledgements
     
     The authors would like to thank Pat Calhoun  (Sun  Microsystems),  Jan
     Melen   (Ericsson),   Jarmo   Savolainen  (Ericsson),  and  Glen  Zorn
     (Microsoft) for many useful discussions of this problem space.
     
     
     8.  References
     
     [1]  B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang.  "Review of  Roaming
     Implementations."  RFC  2194, Microsoft, Aimnet, i-Pass Alliance, Asi-
     ainfo, Merit, September 1997.
     
     [2]  B. Aboba, G. Zorn.  "Roaming Requirements." Internet draft  (work
     in   progress),  draft-ietf-roamops-roamreq-07.txt,  Microsoft,  March
     1998.
     
     [3]  C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote  Authenti-
     cation  Dial  In  User Service (RADIUS)." RFC 2138, Livingston, Merit,
     Daydreamer, April, 1997.
     
     [4]  C. Rigney.  "RADIUS Accounting."  RFC  2139,  Livingston,  April,
     1997.
     
     [5]   J.  Gray,  A. Reuter. Transaction Processing: Concepts and Tech-
     niques, Morgan Kaufmann Publishers, San Francisco, California, 1993.
     
     
     
     Aboba & Arkko                                                [Page 16]


     INTERNET-DRAFT                                           6 August 1998
     
     
     [6] S. Bradner.  "Key words for use in RFCs  to  Indicate  Requirement
     Levels."  RFC 2119, Harvard University, March, 1997.
     
     [7]  D.  Crocker,  P.  Overrell.  "Augmented BNF for Syntax Specifica-
     tions: ABNF."  RFC 2234,  Internet  Mail  Consortium,  Demon  Internet
     Ltd., November 1997.
     
     [8]  G.  Good.   "The  LDAP Data Interchange Format (LDIF) - Technical
     Specification."  Internet draft (work in  progress),  draft-ietf-asid-
     ldif-02.txt, Netscape, July 1997.
     
     [9]  K.  McCloghrie,  J.  Heinanen, W. Greene, A. Prasad.  "Accounting
     Information for ATM Networks."  Internet  draft  (work  in  progress),
     draft-ietf-atommib-atmacct-04.txt,  Cisco  Systems,  Telecom  Finland,
     MCI, November 1996.
     
     [10] K. McCloghrie, J.  Heinanen,  W.  Greene,  A.  Prasad.   "Managed
     Objects  for  Controlling  the  Collection  and  Storage of Accounting
     Information for Connection-Oriented Networks."  Internet  draft  (work
     in  progress),  draft-ietf-atommib-acct-04.txt, Cisco Systems, Telecom
     Finland, MCI, November 1996.
     
     [11] B.  Aboba,  D.  Lidyard.   "Accounting  Data  Interchange  Format
     (ADIF)."   Internet  draft  (work  in  progress),  draft-ietf-roamops-
     actng-04.txt, Microsoft, Telco Research, March 1998.
     
     [12] D. Harrington,  R.  Presuhn,  B.  Wijnen,  "An  Architecture  for
     Describing SNMP Management Frameworks", RFC 2271, Cabletron, BMC Soft-
     ware, IBM, January 1998.
     
     [13] J. Case, D. Harrington, R. Presuhn, B. Wijnen, "Message  Process-
     ing  and  Dispatching  for  the  Simple  Network  Management  Protocol
     (SNMP)", RFC 2272, SNMP Research,  Cabletron  Systems,  BMC  Software,
     IBM, January 1998.
     
     [14]  D.  Levi, P. Meyer, B. Stewart, "SNMPv3 Applications", RFC 2273,
     SNMP Research, Secure Computing Corporation,  Cisco  Systems,  January
     1998.
     
     [15]  U.  Blumenthal,  B. Wijnen, "User-based Security Model (USM) for
     version 3 of the Simple Network  Management  Protocol  (SNMPv3)",  RFC
     2274, IBM, January 1998.
     
     [16]  B. Wijnen, R. Presuhn, K. McCloghrie, "View-based Access Control
     Modem (VACM) for the Simple Network Management Protocol  (SNMP)",  RFC
     2275, IBM, BMC Software, Cisco Systems, January 1998.
     
     [17]    R.  Fajman. "An Extensible Message Format for Message Disposi-
     tion Notifications."   Internet  draft  (work  in  progress),   draft-
     ietf- receipt-mdn-08.txt, National Institute of Health, August 1998.
     
     [18]   M.   Elkins.   "MIME  Security with Pretty Good Privacy (PGP)."
     RFC 2015, The Aerospace Corporation, October, 1996.
     
     
     
     
     Aboba & Arkko                                                [Page 17]


     INTERNET-DRAFT                                           6 August 1998
     
     
     [19] G. Vaudreuil. "The Multipart/Report Content Type for the  Report-
     ing  of  Mail System Administrative Messages." RFC 1892, Octel Network
     Services, January, 1996.
     
     [20]  J.  Galvin.,  et  al.  "Security  Multiparts  for  MIME:  Multi-
     part/Signed  and  Multipart/Encrypted."  RFC 1847, Trusted Information
     Systems, October, 1995.
     
     [21] D. Crocker. "MIME Encapsulation of EDI Objects." RFC 1767,  Bran-
     denburg Consulting, March, 1995.
     
     [22]   C.  Shih,  M.  Jansson,  R.  Drummond. "MIME-based Secure EDI."
     Internet   draft    (work     in     progress),     draft-ietf-ediint-
     as1-05.txt, Actra, LiNK, Drummond Group, July 1997.
     
     [23] C. Shih, M. Jansson, R. Drummond, L. Yarbrough. "Requirements for
     Inter-operable Internet EDI."   Internet  draft  (work  in  progress),
     draft-ietf-ediint-req-04.txt,  Actra, LiNK, Drummond Group, July 1997.
     
     [24]  S.  Bradner.  "Key words for use in RFCs to Indicate Requirement
     Levels."  RFC 2119, Harvard University, March, 1997.
     
     [25] Borenstein, N.,  Freed,  N.  "MIME  (Multipurpose  Internet  Mail
     Extensions)  Part  One:  Mechanisms  for Specifying and Describing the
     Format of Internet Message  Bodies",  RFC  1521,  Bellcore,  Innosoft,
     December 1993.
     
     [26] N. Joffe, D. Wing, L. Masinter. "SMTP Service Extension for Imme-
     diate  Delivery",  Internet  draft (work in progress), draft-ietf-fax-
     smtp-session-02.txt, Cisco Systems, Xerox, February 1997.
     
     [27] H. T. Johnson, R. S. Kaplan. Relevance Lost: The Rise and Fall of
     Management  Accounting,  Harvard  Business  School Press, Boston, Mas-
     sachusetts, 1987.
     
     [28] C. T. Horngren, G. Foster. Cost Accounting: A  Managerial  Empha-
     sis.  Prentice Hall, Englewood Cliffs, New Jersey, 1991.
     
     [29]  R.  S. Kaplan, Anthony A. Atkinson. Advanced Management Account-
     ing.  Prentice Hall, Englewood Cliffs, New Jersey, 1989.
     
     [30] R. Cooper, R. S. Kaplan. The Design of Cost  Management  Systems.
     Prentice Hall, Englewood Cliffs, New Jersey, 1991.
     
     [31]  P.  R.  Calhoun, M. A. Beadles, A. Ratcliffe. "RADIUS Accounting
     Interim  Accounting  Record  Extension",  Internet  draft   (work   in
     progress), draft-ietf-radius-acct-interim-00.txt, July 1997.
     
     [32] D. Carrel, L. Grant. "The TACACS+ Protocool Version 1.78", Inter-
     net draft (work in progress),  draft-grant-tacacs-02.txt,  Cisco  Sys-
     tems, January, 1997.
     
     [33]  P.  R.  Calhoun,  A.  Rubens. "DIAMETER Base Protocol", Internet
     draft   (work   in   progress),   draft-calhoun-diameter-01.txt,   Sun
     
     
     
     Aboba & Arkko                                                [Page 18]


     INTERNET-DRAFT                                           6 August 1998
     
     
     Microsystems, Merit Networks, March, 1998.
     
     [34]  P. R. Calhoun. "DIAMETER Resource Management Extensions", Inter-
     net draft (work in progress),  draft-calhoun-diameter-res-mgmt-00.txt,
     Sun Microsystems, March, 1998.
     
     [35]  P. R. Calhoun. "DIAMETER User Authentication Extensions", Inter-
     net draft (work in  progress),  draft-calhoun-diameter-authent-01.txt,
     Sun Microsystems, March, 1998.
     
     
     
     9.  Authors' Addresses
     
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 425-936-6605
     EMail: bernarda@microsoft.com
     
     Jari Arkko
     Oy LM Ericsson Ab
     02420 Jorvas
     Finland
     
     Phone: +358 40 5079256
     EMail: Jari.Arkko@ericsson.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Aboba & Arkko                                                [Page 19]