ROAMOPS Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                   Microsoft Corporation
     <draft-ietf-roamops-actng-02.txt >                        Dave Lidyard
     26 March 1997                               Telco Research Corporation
     
     
                       The Accounting Problem in Roaming
     
     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   ds.internic.net   (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-
     ietf-roamops-actng-02.txt>, and  expires October 1, 1997.  Please send
     comments to the authors.
     
     2.  Abstract
     
     This  document describes the accounting problems that arise in provid-
     ing dialup roaming capabilities.  These  include  issues  relating  to
     standardization  of  accounting  record  formats,  and  inter-provider
     transfers of accounting record bundles.  Work relevant to the solution
     of  these  problems  are reviewed, and recommendations are made on the
     direction of future standardization work.
     
     3.  Introduction
     
     As detailed in [2], solution of  the  accounting  problem  in  roaming
     requires several elements to be put in place:
     
        1.   A  standardized  accounting  record format must be provided in
        order to allow ISPs to communicate accounting  information  to  the
        roaming consortia as well as to each other.
     
        2.   A  mechanism  must  be  provided in order for these accounting
        records to be securely transferred to an accounting agent.
     
        3.  A mechanisms must be employed to  deter  fraud  and  allow  for
        auditing.
     
     This   document   describes   a   proposed  architecture  for  roaming
     
     
     
     Aboba & Lidyard                                               [Page 1]


     INTERNET-DRAFT                                           26 March 1997
     
     
     accounting, as well as proposing a method for the secure  transfer  of
     accounting  records.  Issues relevant to accounting record formats are
     discussed, as are security issues relevant to roaming accounting.
     
     3.1.  Terminology
     
     This document frequently uses the following terms:
     
     Network Access Server
               The Network Access Server (NAS) is the device  that  clients
               contact in order to get access to the network.
     
     Accounting
               The  goal of network accounting is to accurately measure and
               record metrics relevant to the analysis  of  usage  and  the
               billing of users and organizations.
     
     Checkpoint event
               A  checkpoint  event  is an accounting event that presents a
               snapshot of resource usage during a user's session.
     
     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
               checkpoint events.
     
     Accounting Protocol
               A  protocol used for the communication of accounting events.
     
     Full Service Accounting Protocol
               An accounting protocol that  in  addition  to  communicating
               accounting  events  provides  for  encryption and signing of
               accounting data, as well as signed  receipts.  Full  service
               accounting  protocols are desirable for use in inter-organi-
               zational accounting.
     
     Intra-organizational accounting event
               An intra-organizational accounting event  is  one  which  is
               generated by the local ISP's users.
     
     Inter-organizational accounting event
               An  inter-organizational  accounting  event  is one which is
               generated by customers of other ISP's.
     
     Accounting Gateway
               The Accounting Gateway is a server which receives accounting
               data  from  network  devices  such  as  a NASes and routers,
               translates this data into session records,  and  routes  the
               session  records  to  intra and inter-organizational billing
               servers.
     
     
     
     
     
     
     Aboba & Lidyard                                               [Page 2]


     INTERNET-DRAFT                                           26 March 1997
     
     
     4.  Overview of the roaming accounting architecture
     
     The goal of the roaming accounting architecture is to enable  ISPs  to
     be  compensated for use of the their network infrastructure by roaming
     users. The accounting architecture, which  is  shown  below,  involves
     interactions  between  network  devices  such  as  NASes  and routers,
     accounting gateways, billing servers, and accounting servers.
     
     Rather than merely proxying RADIUS accounting packets, it is envisaged
     that  roaming  consortia  members  will  employ accounting gateways in
     order to translate between the accounting protocols used by their  NAS
     devices  and  routers  and  a  standard  accounting record format used
     within the roaming consortia. It is also the duty  of  the  accounting
     gateway  to  arrange  for the transfer of accounting record bundles to
     the accounting agent.
     
     The use of accounting gateways allows ISPs not using RADIUS accounting
     to  participate in the consortia. Today there is NAS accounting proto-
     col on the standards track, and as a result, the  diversity  of  solu-
     tions employed in accounting (which include SNMP, TACACS+, RADIUS, and
     SYSLOG) is greater than that  for  authentication/authorization  where
     RADIUS  has  reached  proposed standard status and is supported by the
     majority of equipment vendors. In addition, use of  RADIUS  accounting
     proxies  cannot provide for encryption and digital signing of Account-
     ing-requests, or signed  Accounting-Responses.  Since  encryption  and
     digital  signing,  as well as signed receipts are roaming requirements
     as described in [2], an alternative approach had to be taken. This was
     to define a standard accounting record format and transfer protocol.
     
     In  addition to serving the translation function, local ISP accounting
     gateways are also responsible for summarizing checkpoint  events  into
     session  records,  as  well  as  routing  accounting events. Local ISP
     accounting events  fall  into  two  categories:   intra-organizational
     accounting  events, which are events generated by local customers; and
     inter-organizational accounting events, which are events generated  by
     customers  from  other  members  of  the roaming consortia. One of the
     functions of the accounting gateway is to distinguish between the  two
     types  of  events  and route them appropriately. For accounting events
     originating on a local ISP, intra-organizational accounting events are
     routed   to  the  local  billing  server,  while  inter-organizational
     accounting events will be routed to the accounting agent. While it  is
     not  required  that  the  accounting  record formats used in inter and
     intra-organizational accounting transfers be the same, this is  highly
     desirable,  since this eliminates translations that would otherwise be
     required.
     
     In the roaming accounting architecture, the function of the accounting
     agent  is  to  compute  charges  owed by member organizations. While a
     roaming consortium may act as the accounting agent, it is also  possi-
     ble  for  ISPs to settle among themselves. When the accounting agent's
     accounting gateway receives inter-organizational events from  a  local
     ISP's  accounting  gateway,  it  routes  the  events to the accounting
     server, and in addition may send copies to the home  ISP.  Copies  are
     provided  in  order  to  enable the home ISP to audit accounting agent
     
     
     
     Aboba & Lidyard                                               [Page 3]


     INTERNET-DRAFT                                           26 March 1997
     
     
     charges, as well to bill back to the originating domain. It should  be
     noted that it is also possible for local ISPs to send copies directly,
     rather than relying on the accounting agent for this function.
     
     Once received by the home ISP, the copied accounting records  will  be
     processed by the home ISP's billing server, and will also typically be
     copied to the originating organization.
     
          +------------+      +------------+          +------------+
          |            |      |            |          |            |
          |    ISPB    |      |  ISPA      |          |    ISPA    |
          |   Router   |      |  Billing   |<---------|   Acctg.   |
          |            |      |  Server    |          |   Gateway  |
          |            |      |            |          |            |
          +------------+      +------------+          +------------+
                |                                            ^
     Accounting |                                            |
     Protocol   |                     Inter-organizational   |
     (RADIUS,   |                       Accounting Events    |
     SNMP,      |                                            |
     Syslog,    |                                            |
     TACACS+,   |                                            |
     etc.)      |                                            |
                |                                            |
                V                                            V
          +------------+                               +------------+
          |            |                               |            |
          |    ISPB    |      Inter-organizational     |  ISPGROUP  |
          |   Acctg.   |<----------------------------->|   Acctg.   |
          |   Gateway  |\       Accounting Events      |  Gateway   |
          |            | \                             |            |
          |            |  \                            |            |
          +------------+   \                           +------------+
                ^           \                                |
                |            \ Intra-organizational          |
     Accounting |             \   Accounting Events          |
     Protocol   |              \                             |
     (RADIUS,   |               \                            |
     SNMP,      |                \                           |
     Syslog,    |                 \                          |
     TACACS+,   |                  \                         |
     etc.)      |                   \                        |
                |                    \                       V
          +------------+      +------------+           +------------+
          |            |      |            |           |            |
          |     ISPB   |      |    ISPB    |           |  ISPGROUP  |
          |     NAS    |      |  Billing   |           | Accounting |
          |            |      |   Server   |           |   Server   |
          |            |      |            |           |            |
          +------------+      +------------+           +------------+
                ^
     PPP        |
     Protocol   |
                |
     
     
     
     Aboba & Lidyard                                               [Page 4]


     INTERNET-DRAFT                                           26 March 1997
     
     
                V
          +------------+
          |            |
          |            |
          |    Fred    |
          |            |
          |            |
          +------------+
     
     5.  Location of the accounting agent
     
     In order for the local ISP's accounting gateway to be able  to  upload
     an accounting record bundle to the accounting agent, it will typically
     be necessary for there to be a  prexisting  relationship  between  the
     local  ISP  and the accounting agent. As a result, it is expected that
     the ISP's accounting gateway will be statically  configured  with  the
     domain names and addresses of its accounting agents. The configuration
     files might appear as follows:
     
     ispc.com       accounting-agent=acct.ispc.com port=25
     ispgroup1.com  accounting-agent=acct.ispgroup1.com port=25
     ispgroup2.com  accounting-agent=www.ispgroup2.com port=1649
     
     These configuration files imply that ISPB belongs to the roaming  con-
     sortia  ISPGROUP1 and ISPGROUP2, and that accounting records bound for
     these roaming consortia should be sent to the accounting agents  oper-
     ated  within  these  domains. On the other hand, ISPB sends accounting
     bundles to the ISPC accounting agent directly.
     
     In this case, the configuration file indicates that accounting bundles
     for  ISPC should be sent to the machine acct.ispc.com on port 25; that
     accounting bundles for ISPGROUP1 should be sent to  acct.ispgroup1.com
     on  port  25, and that accounting bundles for ISPGROUP2 should be sent
     to www.ispgroup2.com on port 1649.
     
     In order to provide information on the transaction endpoints  as  well
     as  all  the intermediate participants, it is desirable for accounting
     records to include the roaming relationship path, and  for  accounting
     record bundles to include the name of the accounting agent to whom the
     records are to be submitted.
     
     Where DNS REL RRs are used, the accounting gateway needs to maintain a
     cache  mapping  domains  to  roaming relationship paths and accounting
     agents. When the accounting  gateway  receives  a  RADIUS  Accounting-
     Request message (START or STOP), it will find the roaming relationship
     path and accounting agent corresponding to the NAI in the  cache,  and
     will insert this in the accounting record for the session.
     
     The  cache  is filled in as DNS REL RRs are received. Ordinarily a REL
     RR is kept in the cache until it times  out.  This  implies  that  the
     cache will typically remain constant between the time that the authen-
     tication is processed and when the accounting records are generated.
     
     
     
     
     
     Aboba & Lidyard                                               [Page 5]


     INTERNET-DRAFT                                           26 March 1997
     
     
     The possible exceptions to this behavior are when the TTL  expires  in
     mid-session  or if the accounting gateway is restarted, resulting in a
     flushing of the cache. In these cases if the REL RR has changed it  is
     possible  that the existing sessions may be accounted for incorrectly.
     To avoid this, the accounting gateway MUST NOT modify the cache  entry
     for a domain with a session in progress.
     
     6.  Accounting transfer protocol issues
     
     6.1.  Accounting transfer protocol requirements
     
     Given that large sums of money may change hands as a result of roaming
     accounting transfers, it  is  highly  desirable  that  the  accounting
     records be transferred securely and robustly. Requirements include:
     
     Security  In  order  to address security concerns, it is desirable for
               an inter-organizational accounting transfer protocol to sup-
               port  mutual  authentication;   signing of accounting record
               bundles; signed receipts for  accounting  record  transfers;
               and  encryption  of  accounting  record  bundles. Accounting
               gateways will  also  need  to  be  able  to  reliably  route
               accounting record bundles to the appropriate destinations.
     
     Durability
               Durability  implies  that  an  inter or intra-organizational
               accounting transfer protocol must be able to recover from  a
               variety  of  faults, including partially completed transfers
               and non-supported metrics.
     
     6.2.  Accounting transfer protocol recommendation
     
     The requirements  for  roaming  accounting  record  transfers  closely
     resemble  the requirements for interoperable Internet Electronic Docu-
     ment Interchange (EDI). As described in [12],  both  applications  may
     make  use of encryption and digital signatures as well as requests for
     signed receipts. Since these features are also of interest in  a  wide
     variety  of  EDI and Electronic Commerce (EC) applications, the EDIINT
     working group has been chartered to standardize  their  use  over  the
     Internet.  For  further  information  on  the  mechanisms proposed for
     secure EDI over the Internet, please consult references [6] - [12].
     
     Given the close correspondence between the work of the EDIINT  working
     group  and the requirements for roaming accounting record transfer, it
     is proposed that the ROAMOPS working group consider adoption of  MIME-
     based  Secure  EDI, as described in [11], for accounting record trans-
     fers. With MIME-based secure EDI, accounting record bundles are trans-
     ferred  using S/MIME or PGP/MIME over SMTP. Since SMTP server technol-
     ogy is mature, it is believed that this method can satisfy  durability
     as well as security requirements.
     
     Since  Secure  MIME-enabled mail servers are expected to become widely
     available, use of this technology  will  enable  rapid  deployment  of
     technology  for  secure  accounting record transfers. Given the likely
     widespread availability of Secure MIME-enabled mail technology, it  is
     
     
     
     Aboba & Lidyard                                               [Page 6]


     INTERNET-DRAFT                                           26 March 1997
     
     
     recommended  that  the  ROAMOPS working group not consider less secure
     alternatives.
     
     It should be noted that in order to make use of  the  techniques  pro-
     posed  in [11], it is not required that accounting record formats con-
     form to EDI standards such as UN/EDIFACT or EDI  X.12,  although  this
     may  be  desirable  in some circumstances.  What is required is that a
     MIME type be defined for the accounting record format.
     
     When used to implement secure inter-organizational  accounting  record
     transfers in roaming, it is recommended that accounting record bundles
     be encrypted  as  well  as  signed,  and  that  a  signed  receipt  be
     requested. It is recommended that S/MIME be used for this purpose.
     
     Since  MIME-based  secure EDI requires public key authentication tech-
     nology, a mechanism must be provided for acquiring the public  key  of
     the  participants  in  an exchange. While DNS Security can be used for
     this purpose, this is  not  required,  since  in  roaming,  accounting
     record  bundles  need only be transferred between entities with a pre-
     existing relationship. As a result, it is possible to statically  con-
     figure accounting gateways with the required public keys.
     
     7.  Accounting record format issues
     
     7.1.  Accounting record format requirements
     
     In order to allow for accounting record bundles between organizations,
     it is necessary to provide for a standard  accounting  record  format.
     Desirable qualities for an accounting record format include:
     
     Extensibility
               While  the standard accounting record format must be able to
               encode metrics commonly used by ISPs in determining a user's
               bill,  it  must also be extensible so that other metrics can
               be added in the future.  These metrics may either  be  IETF-
               standard  metrics,  or  they may be vendor-specific metrics.
               Since it is possible that the accounting record format  will
               itself evolve over time, or that multiple formats will be in
               common use, it is necessary that the type and version of the
               accounting  record be communicated as part of the accounting
               record transfer.
     
     Compactness
               Given the growth of the Internet,  today's  ISPs  process  a
               large  number of accounting records every day. Not only does
               processing of the  records  require  many  CPU  cycles,  but
               transmitting the records can consume considerable bandwidth.
               Therefore it is desirable for the accounting  record  format
               to be as compact as possible, and to contribute to efficient
               processing.
     
     
     
     
     
     
     
     Aboba & Lidyard                                               [Page 7]


     INTERNET-DRAFT                                           26 March 1997
     
     
     7.2.  ASCII vs. BINARY formats
     
     Today most accounting records are in NVT ASCII,  often  with  a  fixed
     record format. This has the advantage of being easy to read and debug,
     as well as being easy to parse. However, the use of a fixed format  is
     a  substantial liability, since new accounting metrics are continually
     emerging.
     
     In order to provide for extensibility, it is  possible  to  specify  a
     fixed  format  for the initial portion of the accounting record, while
     allowing additional metrics to be added via use of  appropriate  tags.
     In order to allow a record to extend over multiple lines, it is possi-
     ble to specify that lines beginning with one or more spaces should  be
     considered a continuation of the previous line.
     
     Most  NVT  ASCII  accounting formats now in use consume between 60 and
     140 octets per record. However, these records are highly compressible,
     often  exhibiting  compression  ratios of 3:1 or greater, so that when
     compressed accounting bundles are transmitted, space consumption of 50
     octets/record is frequently achievable.
     
     Via use of Attribute Value Pairs (AVPs), binary accounting record for-
     mats are easily engineered for extensibility, and as  a  result,  they
     are  popular  for  use  in  accounting  protocols  such  as RADIUS and
     TACACS+. Via use of a vendor field, it is possible to ensure that ven-
     dor-specific  metrics  will  not conflict with IETF-defined accounting
     metrics, and assuming that suitable  space  is  left  for  length  and
     attribute  fields,  it  is  possible  to allow for representation of a
     large number and variety of accounting metrics.
     
     Since NAS devices and routers typically  provide  accounting  data  in
     binary  format,  binary  accounting records can typically be generated
     more easily than NVT ASCII records.  Similarly,  billing  servers  can
     process these records more efficiently, since less parsing and conver-
     sion is required.
     
     Binary accounting records are also typically  more  compact  than  NVT
     ASCII  formats, although this advantage is reduced when compression is
     employed.  Although binary accounting records are typically  compress-
     ible,  they  are  typically much less compressible than equivalent NVT
     ASCII formats.
     
     7.3.  Accounting metrics
     
     Accounting in a roaming environment requires  adherence  to  standards
     which  allow  access to be measured, rated, assigned, and communicated
     between appropriate service providers.  In this  inter-provider  envi-
     ronment,  there  is  a  need for a set of controls that can be used to
     audit billing practices and to mediate billing disputes.  The  founda-
     tion  for satisfying these requirements is the content of the account-
     ing record. The goal of the accounting record is to  identify  who  is
     accessing  the network, who is providing the access service, from what
     location is access being provided, and when the accesses occur.
     
     
     
     
     Aboba & Lidyard                                               [Page 8]


     INTERNET-DRAFT                                           26 March 1997
     
     
     The identity of the user, their home ISP, and service  privileges  are
     the  key elements for authenticating, authorizing, and assigning cost.
     These components allow the local service provider to authorize service
     and  understand  to  whom accounting information should be sent. These
     same components provide the home authenticating party with the  infor-
     mation to identify the originating user, their roaming consortium, and
     the applicable service level agreements.
     
     The local ISP provides access. Since the home ISP presents the bill to
     the  customer, in most cases they will be responsible for sales taxes,
     but this may not universally be the case. It is  possible  that  there
     will  be  taxes  or  other  charges mandated by local governing bodies
     which need to be absorbed and rebilled.  As a result, it is  necessary
     for  the  identity  of  both the local and home ISP to be included, as
     well as the location of the called POP to be included in the  account-
     ing  record.  Including this information also allows roaming consortia
     to evaluate access patterns and trends in an effort to  leverage  high
     service areas for better rates and/or service.
     
     It  is  also  useful for the accounting record to include the date and
     time of access, in order to make it possible to analyze diurnal curves
     and  devise  programs oriented toward load leveling. Including session
     duration is useful as an input to the rating process as  well  as  for
     capacity  planning and fraud detection.  The type of access and access
     speed may also be relevant in rating.
     
     Suggested accounting metrics include:
     
     Session ID               Unique ID identifying the session
     Multi-Session ID         For linking of multiple related sessions
     NAI                      Network Access Identifier (NAI), the userID that is
                              presented during the authentication process.
     Peer Network Address     The IP address assigned to the user
     Home ISP                 Identity of the home ISP.
     Local ISP                The local ISP providing access.
     NAS Host Name            The name of the NAS providing access.
     NAS IP address           The IP address of the NAS providing access.
     NAS Port                 The physical port of the NAS providing access.
     Call Type                Indicates type of call, i.e. async vs. Sync ISDN, V.120, etc.
     Service Type             Type of service provided to the user
     Call Direction           Indicates inbound or outbound call
     B Channel interface name Indicates name of B channel interface
     Link Count               Number of links up when record was generated
     Local Time Zone          Time zone where access was provided.
     Start Date & Time        Session starting date and time (at source)
     Disconnect Date & Time   Session ending date and time (at source)
     Elapsed Duration         Seconds of received service
     Method of Access
     Disconnect Cause Code    The reason the call was disconnected
     Originating Number       Enables the computation of access charges in a toll area.
     Access Number            The phone number dialed to reach the local ISP.
     
     Packets Transmitted      Packets sent to port
     Packets Received         Packets received from port
     
     
     
     Aboba & Lidyard                                               [Page 9]


     INTERNET-DRAFT                                           26 March 1997
     
     
     OCTETS Transmitted       Octets sent to port
     OCTETS Received          Octets received from port
     Summary Charge           Aggregated charge of this accounting record.
     Charge detail            Entries for each type of charge and the amount used to
                              compute the summary charge. This includes access service
                              fees, usage related charges, and taxes. Other
                              charge detail may be applicable.
     Currency code            Currency in which the charges are expressed.
     Memo Data                General area for ISPs to communicate additional
                              information related to each accounting record.
     Authorization Code       Digitally signed token included to ensure legitimacy.
                              Form TBD.
     Roaming Rel. Path        The path of roaming relationships connecting the local ISP
                              to the home authentication server.
     
     7.4.  Case study
     
     Let us assume that we have a roaming user Fred, who  works  at  BIGCO.
     BIGCO  has  established  a  relationship with ISPA, who has joined the
     roaming consortia ISPGROUP. Fred now travels to another  part  of  the
     world and wishes to dial in to the network provided by ISPB.
     
     ISPB will account for Fred's resource usage, and will submit a session
     record to ISPGROUP for compensation. ISPGROUP will in turn bill  ISPA,
     who  will  bill  BIGCO.  Eventually BIGCO will pay ISPA, ISPA will pay
     ISPGROUP, and ISPGROUP will pay ISPB.  In order  for  all  parties  to
     verify  that they have been properly charged or compensated for Fred's
     session, the following events must occur:
     
        ISPB:      Network devices generate accounting data for Fred
        ISPB:      Accounting gateway generates a session record for Fred
        ISPB:      Accounting gateway routes the session record to
                   ISPGROUP and to the local billing server
        ISPB:      Billing server processes the session record,
                   credits ISPGROUP account
        ISPGROUP:  Accounting gateway routes the session record to the
                   accounting server and to ISPA
        ISPGROUP:  Accounting server processes the session record,
                   credits ISPA account, debits ISPB account
        ISPA:      Accounting gateway routes the session record to the
                   local billing server and to BIGCO
        ISPA:      Billing server processes the session record,
                   credits BIGCO account, debits ISPGROUP account
        BIGCO:     Accounting gateway routes the session record to the
                   local billing server
        BIGCO:     Billing server processes the session record,
                   credits Fred's account, credits ISPA account.
     
     Each of these events is discussed below.
     
     7.5.  ISPB network devices generate accounting data for Fred
     
     In order to keep track of network resources consumed by  Fred,  ISPB's
     accounting  gateway  will  collect accounting data produced by network
     
     
     
     Aboba & Lidyard                                              [Page 10]


     INTERNET-DRAFT                                           26 March 1997
     
     
     devices such as routers and NASes. This data may be produced  in  many
     forms,  and  may be communicated via a variety of protocols, including
     RADIUS, TACACS+, SNMP, and SYSLOG. The accounting data may  be  trans-
     mitted  from  network devices to the accounting gateway (as in RADIUS,
     TACACS+, SYSLOG, or SNMP traps), or the accounting  gateway  may  poll
     for the data (via SNMP GETs).
     
     Accounting  data  may  refer  to resources consumed over the life of a
     session, or it may be a checkpoint event. Checkpoint events  refer  to
     resource  consumption  at a specific point in time, rather than repre-
     senting a summary of resources  consumed  over  a  session.  Prior  to
     transfer  to  a  billing server or accounting agent, checkpoint events
     are typically summarized into a session record.
     
     7.6.  ISPB accounting gateway generates a session record for Fred
     
     Since there is currently no standards-track network accounting  proto-
     col,  ISP  accounting  practices  vary more widely than authentication
     practices, where RADIUS authentication is very widely deployed.  As  a
     result,  it appears difficult to standardize on an accounting protocol
     that can be used for  communication  between  ISPs  and  a  accounting
     agent. Therefore, the roaming accounting architecture anticipates that
     while ISPs will use an accounting protocol of their choice to communi-
     cate accounting information between network devices and the accounting
     gateway, a standardized accounting record format and  transfer  method
     will be used for communication between accounting gateways.
     
     In  order  to  allow for transmission of accounting information to the
     accounting agent,  ISPB  will  summarize  the  accounting  information
     relating to Fred's session in a standard session record format.
     
     7.7.   ISPB  accounting  gateway routes the session record to ISPGROUP
     and to the local billing server
     
     ISPB's accounting gateway examines Fred's session record,  and  routes
     it  to the appropriate destinations. It does this based on whether the
     accounting records refer to transactions occurring  within  the  ISP's
     organization,  or whether they refer to transactions occurring between
     organizations. In this case, since Fred is a roaming user, this is  an
     inter-organizational accounting event, and the accounting gateway will
     send session record to the accounting agent, as well as to  the  local
     biling  server.  In  this example, the accounting agent is run by ISP-
     GROUP, but it could just as easily be run by ISPA, in which  case  the
     two ISPs would settle directly.
     
     When  routing  accounting  record  bundles,  ISPB's accounting gateway
     machine will operate as an S/MIME or PGP/MIME-enabled SMTP server.  In
     order to improve efficiency, the accounting gateway will sort account-
     ing records into bundles prior to mailing them to  their  destination.
     When a suitable bundle of accounting records has been accumulated, the
     accounting gateway will initiate the transfer. In  this  case,  Fred's
     accounting record will be sent to multiple destinations.
     
     
     
     
     
     Aboba & Lidyard                                              [Page 11]


     INTERNET-DRAFT                                           26 March 1997
     
     
     While  intra-organizational  accounting  transfers  typically will not
     require signed accounting bundles or signed  receipts,  it  still  may
     prove  useful  to  request  that a receipt be generated in order to be
     able to confirm the success of the  transfer.  Use  of  receipts  will
     allow an accounting gateway to keep track of discrepancies between the
     number of accounting record bundles it believes were successfully sent
     to  the  local  billing  server, and the number of receipts collected.
     These discrepancies can be used to detect partially completed account-
     ing record transfers and to retransmit them.
     
     When  used  to  transfer an accounting record bundle to the accounting
     agent, ISPB will encrypt the bundle, as well as signing it,  and  will
     request a signed receipt.
     
     7.8.   ISPB  billing server processes the session record, credits ISP-
     GROUP account
     
     In order to allow itself to  audit  the  charges  and/or  compensation
     offered by ISPGROUP, ISPB's billing server will process Fred's session
     record and credit the ISPGROUP account (an asset).  If SMTP is used to
     transmit the session record between the accounting gateway and billing
     server, then the billing server will need to retrieve  the  accounting
     record  bundle  from  its mailbox and process it, sending a receipt in
     response to the accounting gateway's request.
     
     7.9.  ISPGROUP accounting gateway routes the  session  record  to  the
     accounting server and to ISPA
     
     Once ISPGROUP receives the signed and encrypted accounting record bun-
     dle from ISPB, it will send back a signed receipt as requested, and in
     addition  will verify the signature, decrypt the bundle, and then send
     copies to the accounting server as well as to ISPA. This  is  done  in
     order to enable ISPA to audit the bill received from ISPGROUP, as well
     as to bill back BIGCO for the charges. In transferring the  accounting
     record bundle to ISPA, ISPGROUP will encrypt it, and sign it, in addi-
     tion to requesting a receipt.
     
     7.10.  ISPGROUP accounting server processes the session record,  cred-
     its ISPA account, debits ISPB account
     
     ISPGROUP's  accounting  server  processes the session record, and as a
     result, ISPA's account (an asset) is credited, and ISPB's account  (an
     asset)  is  debited.  If  SMTP  is used to transmit the session record
     between ISPGROUP's accounting gateway and the accounting server,  then
     the accounting server will need to retrieve the accounting record bun-
     dle from its mailbox and process it, sending a receipt in response  to
     the accounting gateway's request.
     
     7.11.   ISPA accounting gateway routes the session record to the local
     billing server and to BIGCO
     
     Once ISPA has received the signed accounting record bundle  from  ISP-
     GROUP,  it  will send back a signed receipt as requested, and in addi-
     tion will verify the signature, decrypt  the  bundle,  and  then  send
     
     
     
     Aboba & Lidyard                                              [Page 12]


     INTERNET-DRAFT                                           26 March 1997
     
     
     copies  to  the local billing server as well as to BIGCO. This is done
     in order to enable BIGCO to audit the bill for Fred's usage.In  trans-
     ferring  the  accounting record bundle to BIGCO, ISPA will encrypt it,
     and sign it, in addition to requesting a receipt.
     
     7.12.  ISPA billing server processes the session record, credits BIGCO
     account, debits ISPGROUP account
     
     ISPA's  billing  server processes the session record, and as a result,
     BIGCO's account (an asset) is credited,  and  ISPGROUP's  account  (an
     asset) is debited.  If SMTP is used to send the session record between
     ISPA's accounting gateway and the billing  server,  then  the  billing
     server  will  need  to  retrieve the accounting record bundle from its
     mailbox and process it, sending a receipt in response to the  account-
     ing gateway's request.
     
     7.13.  BIGCO accounting gateway routes the session record to the local
     billing server
     
     Once BIGCO has received the signed accounting record bundle from ISPA,
     it  will send back a signed receipt as requested, and in addition will
     verify the signature, decrypt the bundle, and then forward the message
     to the local billing server.
     
     7.14.   BIGCO  billing  server  processes  the session record, credits
     Fred's account, credits ISPA account
     
     BIGCO's billing server processes the session record, and as a  result,
     Fred's account (an asset) is credited, as is ISPA's account (a liabil-
     ity). If SMTP is used to transit the session  record  between  BIGCO's
     accounting  gateway  and  the  billing server, then the billing server
     will need to retrieve the accounting record bundle  from  its  mailbox
     and  process it, sending a receipt in response to the accounting gate-
     way's request.
     
     8.  Security considerations
     
     The Secure MIME-based accounting record transfer  method  proposed  in
     this  draft  provides  for  mutual  authentication  and  encryption of
     accounting record bundles, as  well  as  for  signed  receipts.  As  a
     result, the roaming consortia may be assured that an accounting record
     bundle originated with the local ISP, and the local ISP may be assured
     that the roaming consortia has received the bundle as sent.
     
     In addition, since this document provides for accounting records to be
     provided to all parties along  the  roaming  relationship  path,  some
     degree  of  auditing  is  available. For example, in the case study an
     accounting record was generated by ISPB, and provided to  the  roaming
     consortia, as well as to ISPA, and BIGCO. Where hierarchical authenti-
     cation routing is used, the parties on the roaming  relationship  path
     will also typically have proxied the RADIUS Access-Request and Access-
     Accept packets resulting in authentication  and  authorization.  As  a
     result,  each  of  the  parties  will be able to match up the received
     accounting records with an event in their  authentication  logs.  This
     
     
     
     Aboba & Lidyard                                              [Page 13]


     INTERNET-DRAFT                                           26 March 1997
     
     
     provides for a limited degree of auditing.
     
     Where  hierarchical  authentication  routing  is  employed, having the
     accounting agent on the authentication  route  as  the  first  hop  is
     highly desirable, since this makes it more difficult for the local ISP
     to submit accounting records for fictitious sessions. If the authenti-
     cation  and accounting routes are aligned, this type of fraud requires
     cooperation of one of the intermediate proxies. In order to close  off
     this  possibility,  it  is necessary to support non-repudiation of the
     home authentication server's Access-Accept,  possibly  via  use  of  a
     signed message digest.
     
     However,  it should be noted that considerable leeway still exists for
     other fraudulent behavior by the local ISP. Since the local  ISP  must
     have  access  to any private keys used for signing by accounting gate-
     ways, as well as to shared secrets used by NAS devices, it is possible
     for  a  local  ISP  to  submit  inaccurate  accounting  records to the
     accounting agent. Such behavior will only be easily detectable in  the
     event  that  roaming  users  are making use of voluntary or compulsory
     tunneling, in which case the  tunnel  server  (presumed  to  exist  at
     BIGCO)  will generate its own accounting record, which may be compared
     to that generated by the local ISP. However, tunneling is expected  to
     represent only a small percentage of roaming use.
     
     With  respect to submission of inaccurate accounting records, it makes
     little difference whether the local ISP submits accounting records, or
     proxies  accounting  protocol  packets to the accounting agent. Either
     accounting records or accounting protocol packets may be forged by the
     local  ISP;  for  example,  an  accounting gateway could hold incoming
     RADIUS accounting packets and retransmit them later, making it  appear
     that the session was longer than it actually was.
     
     Requiring  the  NAS  to communicate directly with the accounting agent
     provides little extra security. Aside from  the  scalability  problems
     that would result from this when a shared-secret authentication scheme
     is used, the local ISP has access to all the  NAS  shared  secrets  or
     private  keys,  and  therefore has at its disposal all the information
     necessary to forge authentication and accounting packets.
     
     It should also be noted that this document does not provide  a  mecha-
     nism for resolving of disputes between BIGCO and the local ISP regard-
     ing the type of service provided. This is because  we  currently  have
     not specified a mechanism by which the local ISP can determine whether
     BIGCO's Access-Accept has arrived without being modified by an  inter-
     mediate  proxy.  As  a  result, it is possible that important security
     attributes (such as specification of compulsory tunneling  or  use  of
     EAP)  will be discarded by intermediate proxies. In this case, BIGCO's
     tunnel or EAP server logs will reflect the missing service attributes,
     and  BIGCO  may refuse to pay the local ISP for the services provided.
     Without support for non-repudiation in Access-Accepts,  such  disputes
     are not easily resolved.
     
     
     
     
     
     
     Aboba & Lidyard                                              [Page 14]


     INTERNET-DRAFT                                           26 March 1997
     
     
     9.  Appendix - A Binary Accounting Format Proposal
     
     In order to stimulate working group discussion of the binary vs. ASCII
     accounting record format issue, a preliminary proposal  for  a  binary
     accounting record format is included below. The proposed format offers
     backwards  compatiblity  with  RADIUS  attributes  while  offering  an
     extended  metric  space,  and  providing for error messages as well as
     mandatory and optional attributes.
     
     9.1.  Attribute Value Pair format
     
     The Binary Accounting Format represents accounting records as a series
     of  Attribute  Value Pairs (AVPs), similar to those described in [20].
     The AVP format is as follows:
     
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |M 0 0|    Overall Length       |         Vendor ID             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Attribute           |         Value...              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Value...                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     M = Mandatory. This bit is used to provide an  accounting  agent  with
     guidance as to how it should respond when encountering attributes that
     it does not understand.
     
     M = 0 indicates that the accounting agent may ignore the attribute.
     
     M =  1  indicates  that  the  accounting  agent  not  supporting  this
     attribute must not process the record, and should return an error.
     
     
     9.1.1.  Length
     
     The length field, indicates the number of octets in the AVP, including
     the Flags, Length, Vendor ID, Attribute, and Value fields. Given  that
     the  length  field  is 13 bits long, AVPs may have a maximum length of
     8192 octets.
     
     
     9.1.2.  Vendor ID
     
     Vendor ID is the IANA assigned "SMI Network Management Private  Enter-
     prise  Codes"  value,  encoded  in  network  byte  order. The value 0,
     reserved in this table, corresponds to IETF adopted attribute  values,
     defined  within this document. Vendors looking to implement EAF exten-
     sions can use their own Vendor ID along with private attribute  values
     in order to guarantee that they will not collide with another vendor's
     extensions.
     
     
     
     
     
     Aboba & Lidyard                                              [Page 15]


     INTERNET-DRAFT                                           26 March 1997
     
     
     9.1.3.  Attribute
     
     The attribute field,  which  is  16  bits  in  length,  indicates  the
     accounting metric encoded in the value field.
     
     
     9.1.4.  Value
     
     The  value  field  encodes  the value of the attribute indicate in the
     attribute field.
     
     
     
     9.2.  Attributes
     
     The IETF attribute space is subdivided into the following regions:
     
     Attributes            Purpose
     ----------            -------
     0   - 255             RADIUS attributes
     256 - 1023            Reserved
     
     In order to provide for the efficient operation  of  accounting  gate-
     ways,  the  first 256 attributes in EAF are reserved for use by RADIUS
     attributes.
     
     Only RADIUS attributes described in [4], [5], and [9] are  allowed  to
     use  Vendor  ID  0. Vendor-specific attributes MUST NOT use the RADIUS
     Vendor-specific attribute along with EAF Vendor ID 0, but instead MUST
     set the vendor ID field appropriately.
     
     
     9.2.1.  Global attributes
     
     The following attributes refer not to the characteristics of a partic-
     ular accounting record, but to the entire set of  records  being  pre-
     sented.   These  attributes  MUST  be included first in the accounting
     record stream, prior to the inclusion of any accounting  records.  The
     global  attributes are separated from the accounting records by an End
     of Global Attributes AVP.
     
     
     9.2.2.  Timestamp
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0 0 0|          14             |              0                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            1024               |         NTP Timestamp         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                                                               |
        /                           NTP Timestamp                       /
     
     
     
     Aboba & Lidyard                                              [Page 16]


     INTERNET-DRAFT                                           26 March 1997
     
     
        |                                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The Timestamp AVP is a 64-bit NTP timestamp used  to  identify  the
        time  at  which  the  packet was first sent. It is used as a unique
        identifier for the packet, so that if the transmission is  aborted,
        a subsequent retransmission will use the same timestamp field.
     
     
     9.2.3.  Source
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1 0 0|          >=7            |              0                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            1025               |           Source...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The  Source  AVP  is a string indicating the fully qualified domain
        name of the ISP from which the accounting data is being sent.  This
        attribute MUST be included in every accounting record bundle.
     
     
     9.2.4.  Destination
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1 0 0|          >=7            |              0                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            1026               |      Destination...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The  Destination  AVP  is  a  string indicating the fully qualified
        domain name of the accounting agent to whom the accounting data  is
        being  sent.  This  attribute  MUST be included in every accounting
        record bundle.
     
     
     
     9.2.5.  Number of Records
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0 0 0|           12            |              0                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            1027               |      Number of records        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Number of records                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     
     
     
     Aboba & Lidyard                                              [Page 17]


     INTERNET-DRAFT                                           26 March 1997
     
     
        The Number of Records AVP provides the number of  records  included
        in the accounting record bundle. This attribute is optional.
     
     
     9.2.6.  Error Reporting Email Address
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0 0 0|        >=7              |              0                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            1028               |      Admin Email Address...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The  Error  Reporting Email Address AVP provides the e-mail address
        to which error messages should be sent in  the  event  of  problems
        with  the accounting record bundle. This attribute MUST be included
        in every accounting record bundle.
     
     
     9.2.7.  Administrative Contact
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0 0 0|          >=7            |              0                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            1029               |      Admin Contact...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The Administrative Contact AVP denotes the  E-mail  address,  phone
        number,  address, etc. of the person who should be contacted in the
        event of problems with the accounting record stream. This attribute
        MUST be included in every accounting record bundle.
     
     
     9.2.8.  Accounting Gateway FQDN
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1 0 0|          >=7            |              0                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            1030               |   Accounting Gateway FQDN...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The Accounting Gateway FQDN AVP provides the fully qualified domain
        name of the accounting gateway sending the accounting  record  bun-
        dle. This AVP is optional.
     
     
     
     
     
     
     
     
     Aboba & Lidyard                                              [Page 18]


     INTERNET-DRAFT                                           26 March 1997
     
     
     9.2.9.  Accounting Gateway IP Address
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1 0 0|          12             |              0                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            1031               | Accounting Gateway IP Address |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Accounting Gateway IP Address |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The  Accounting  Gateway  IP Address AVP provides the IP address of
        the accounting gateway sending the accounting record  bundle.  This
        AVP is optional.
     
     
     9.2.10.  Attribute List
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0 0 0|          >=10           |              0                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            1032               |      Attributes...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The Attribute List AVP is used to provide the accounting agent with
        a list of all the Vendor ID/attributes included in  the  accounting
        record  bundle.  This provides a quick way for the accounting agent
        to determine whether it is capable of processing the  bundle.   Use
        of the Attribute List AVP is optional.
     
     
     9.2.11.  End of Global Attributes
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0 0 0|          6              |              0                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            2047               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The  End  of Global Attributes AVP is included in order to separate
        the global attributes from  the  accounting  records.  It  MUST  be
        included at the end of the global attributes.
     
     
     9.2.12.  Accounting record attributes
     
     The  following attributes refer to the characteristics of a particular
     accounting record.
     
     
     
     
     Aboba & Lidyard                                              [Page 19]


     INTERNET-DRAFT                                           26 March 1997
     
     
     9.2.13.  Accounting Record Separator
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1 0 0|           6             |              0                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            2048               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The Accounting Record Separator AVP is used to denote the end of an
        accounting  record.  This  attribute  MUST  be  included  for every
        accounting record.
     
     
     9.2.14.  Roaming relationship path
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1 0 0|          >=7            |              0                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            2049               | Roaming Relationship path...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The roaming relationship path AVP is a string indicating the  roam-
        ing  relationship  path by which the user was granted access to the
        network. This AVP MUST be included for roaming accounting  records.
     
     
     9.2.15.  Time zone
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1 0 0|          9              |              0                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            2050               |          Time Zone            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    Time Zone  |
        +-+-+-+-+-+-+-+-+
     
        The  Time Zone AVP is a string indicating the timezone abbreviation
        for the timestamps included in this accounting record.
     
     
     9.2.16.  Elapsed Time
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1 0 0|          10             |              0                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            2051               |        Elapsed Time           |
     
     
     
     Aboba & Lidyard                                              [Page 20]


     INTERNET-DRAFT                                           26 March 1997
     
     
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |         Elapsed Time          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The Elapsed Time AVP is binary value encoding the elapsed  time  in
        seconds  for  the  accounting event. This can be ued when start and
        stop times are not available.
     
     
     9.2.17.  Reason
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1 0 0|          >=7            |               0               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            2052               |          Reason...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The Reason AVP is a string providing information on why  the  event
        occurred.
     
     
     9.2.18.  Pages
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1 0 0|          12             |               0               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            2053               |        Pages                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Pages                              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The  Pages AVP is a binary number indicating the number of pages of
        text associated with the event.
     
     
     9.2.19.  Bandwidth reserved
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1 0 0|          12             |               0               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            2054               |        Bandwidth              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Bandwidth                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The Bandwidth reserved AVP is a binary  number  indicating  the  of
        bandwidth reserved during the event.
     
     
     
     
     Aboba & Lidyard                                              [Page 21]


     INTERNET-DRAFT                                           26 March 1997
     
     
     10.  Acknowledgements
     
     Thanks  to Glen Zorn of Microsoft for useful discussions of this prob-
     lem space.
     
     
     11.  References
     
     [1]  B. Aboba, J. Lu, J. Alsop, J. Ding.  "Review of Roaming Implemen-
     tations."  draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet, i-Pass
     Alliance, Asiainfo, January, 1997.
     
     [2]  B. Aboba, G. Zorn.  "Dialing Roaming  Requirements."  draft-ietf-
     roamops-roamreq-02.txt, Microsoft, January, 1997.
     
     [3]   C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote Authenti-
     cation Dial In User Service (RADIUS)." RFC  2058,  Livingston,  Merit,
     Daydreamer, January, 1997.
     
     [4]   C.  Rigney.  "RADIUS Accounting." RFC 2059, Livingston, January,
     1997.
     
     [5]  J. Gray, A. Reuter. Transaction Processing:  Concepts  and  Tech-
     niques, Morgan Kaufmann Publishers, San Francisco, California, 1993.
     
     [6]   R. Fajman. "An Extensible Message Format for Message Disposition
     Notifications."  draft-ietf-receipt-mdn-02.txt, National Institute  of
     Health, November, 1996.
     
     [7]  M.  Elkins.  "MIME  Security with Pretty Good Privacy (PGP)." RFC
     2015, The Aerospace Corporation, October, 1996.
     
     [8] G. Vaudreuil. "The Multipart/Report Content Type for the Reporting
     of  Mail System Administrative Messages." RFC 1892, Octel Network Ser-
     vices, January, 1996.
     
     [9] J. Galvin., et al. "Security Multiparts for MIME: Multipart/Signed
     and Multipart/Encrypted." RFC 1847, Trusted Information Systems, Octo-
     ber, 1995.
     
     [10] D. Crocker. "MIME Encapsulation of EDI Objects." RFC 1767,  Bran-
     denburg Consulting, March, 1995.
     
     [11]  M.  Jansson,  C. Shih, N. Turaj, R. Drummond. "MIME-based Secure
     EDI." draft-ietf-ediint-as1-02.txt, LiNK, Actra, Mitre Corp,  Drummond
     Group, November, 1996.
     
     [12] C. Shih, M. Jansson, R. Drummond, L. Yarbrough. "Requirements for
     Inter-operable  Internet  EDI."  draft-ietf-ediint-req-01.txt,  Actra,
     LiNK, Drummond Group, May, 1995.
     
      [13]  R.  Fielding, et al.  "Hypertext Transfer Protocol - HTTP/1.1."
     draft-ietf-http-v11-spec-07, UC Irvine, August, 1996.
     
     
     
     
     Aboba & Lidyard                                              [Page 22]


     INTERNET-DRAFT                                           26 March 1997
     
     
     [14] A. Gulbrandsen, P. Vixie.  "A DNS RR for specifying the  location
     of  services  (DNS  SRV)."  RFC 2052, Troll Technologies, Vixie Enter-
     prises, October 1996.
     
     [15] D. Eastlake, 3rd, C. W. Kaufman.  "Domain  Name  System  Security
     Extensions." Draft-ietf-dnnsec-secext-10.txt, CyberCash, Iris, August,
     1996.
     
     [16] B. Aboba. "The Roaming Relationships  (REL)  Resource  Record  in
     the DNS. " draft-ietf-roamops-dnsrr-03.txt, Microsoft, March, 1997.
     
     [17]  C.  Rigney, W. Willats.  "RADIUS Extensions." draft-ietf-radius-
     ext-00.txt, Livingston, January, 1997.
     
     [18] R. Rivest, S. Dusse.  "The  MD5  Message-Digest  Algorithm",  RFC
     1321,  MIT  Laboratory  for  Computer Science, RSA Data Security Inc.,
     April 1992.
     
     [19] S. Bradner.  "Key words for use in RFCs to  Indicate  Requirement
     Levels."  draft-bradner-key-words-02.txt,  Harvard University, August,
     1996.
     
     [20] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A.  J.
     Valencia, W. Verthein.  "Layer Two Tunneling Protocol -- L2TP." draft-
     ietf-pppext-l2tp-01.txt, Ascend Communications, December, 1996.
     
     
     
     
     12.  Authors' Addresses
     
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 206-936-6605
     EMail: bernarda@microsoft.com
     
     Dave Lidyard
     Telco Research Corporation
     616 Marriott Drive
     Nashville, TN 37214
     
     Phone: 615-231-6110
     EMail: dave@telcores.com
     
     
     
     
     
     
     
     
     
     
     
     Aboba & Lidyard                                              [Page 23]