ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation 27 February 1997 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 , and expires September 1, 1997. Please send comments to the authors. 2. Abstract This document describes the accounting problems that arise in the pro- vision of inter-provider services, such as provision of 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 3.1. Terminology This document frequently uses the following terms: Network Access Server The Network Access Server (NAS) is the device that clients dial in order to get access to the network. Aboba [Page 1] INTERNET-DRAFT 27 February 1997 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. 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. Session records gener- ated by the users of the local ISP are transferred within the local ISP's organization, usually to an internal billing server, where they are rated and processed for bill present- ment. Inter-organizational accounting event An inter-organizational accounting event is one which is generated by users from outside the local ISP's domain. In order to be compensated for these events, the local ISP must securely transfer them to an appropriate settlement agent. Billing The goal of billing is to correctly compute and promptly convey charges based on accounting data. Settlement The goal of settlement is to correctly compute and promptly convey charges based on inter-organizational accounting events. 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. 3.2. Roaming accounting requirements In the architecture described above, it is likely that the accounting gateway, internal billing servers, and settlement agent will need to handle a large flow of events. For example, if a roaming association has 10 members, each of whom have 100,000 users, and 5 percent of all transactions involve roaming, then if the users log in 20 times a month, each billing server will need to handle approximately 2 million records/month and the settlement agent will need to handle 1 million Aboba [Page 2] INTERNET-DRAFT 27 February 1997 records/month. For this reason, it is very important that the accounting record formats be compact and the transfer processes be efficient. 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. In order to address security concerns, it is desirable for an inter-organizational accounting transfer protocol to support "full service" functions such as 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. Since intra-organizational accounting events do not cross organiza- tional boundaries, "full service" accounting transfer features such as digital signing of accounting bundles and non-repudiation of receipt typically are not required, although it is highly desirable that both inter and intra-organizational accounting transfers exhibit the char- acteristics of high reliability transaction processing systems, such as atomicity, consistency, isolation and durability (ACID), as described in [5]. 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. It is desirable that accounting record formats be flexible. While the standard accounting record format must be able to encode metrics com- monly 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. 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 and audit servers, and settlement servers. In this architecture, local ISPs operating accounting gateways in order to translate between the accounting protocols used by NAS devices and routers and the roaming standard accounting record format and transfer method. Local ISP accounting gateways are also responsi- ble for summarizing checkpoint events into session records, as well as Aboba [Page 3] INTERNET-DRAFT 27 February 1997 routing accounting events. Accounting events originating on a local ISP 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 domains. 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 settlement 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 elminates translations that would oth- erwise be required. In the roaming accounting architecture, the function of the settlement agent is to compute charges owed by member organizations. While a roaming consortium may act as the settlement agent, it is also possi- ble for ISPs to settle among themselves. When the settlement agent's accounting gateway receives inter-organizational events from a local ISP's accounting gateway, it routes the events to the settlement server, in addition to sending copies to the home ISP. Copies are pro- vided in order to enable the home ISP to audit settlement agent charges, as well to bill back to the originating domain. Once received by the home ISP, the copied accounting records will be processed by the home ISP's billing and audit server, and will also typically be copied to the originating organization. Aboba [Page 4] INTERNET-DRAFT 27 February 1997 +------------+ +------------+ +------------+ | | | | | | | ISPB | | ISPA | | ISPA | | Router | | Billing & |<---------| Acctg. | | | | Audit | | Gateway | | | | Server | | | +------------+ +------------+ +------------+ | ^ | | 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 & | | Settlement | | | | Audit | | Server | | | | Server | | | +------------+ +------------+ +------------+ 5. 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], since both applications may transmit encrypted and signed entities, and request and receive 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 Aboba [Page 5] INTERNET-DRAFT 27 February 1997 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 "full service" accounting record transfers. Since Secure MIME-enabled mail servers are expected to become widely available in the next year, use of this technology will enable a "full service" accounting transfer method to be made available in relatively short order. Since it is likely that this technology will become available sooner than it would be possible for the ROAMOPS group to develop a secure accounting transfer method based on alternative secu- rity techniques (such as shared secrets), it is recommended that the group focus on use of Secure MIME as an accounting record transfer mechanism. 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 MIME-based secure EDI is used to transfer accounting record bun- dles between organizations, it is recommended that the bundles be encrypted as well as signed, and that a signed receipt be requested. Either S/MIME or PGP/MIME may be used to accomplish this. 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 messages need only be sent between entities with a pre-existing business relation- ship. As a result, it is possible to statically configure accounting gateways with the required public keys. With MIME-based secure EDI, the accounting records are transferred using S/MIME or PGP/MIME over SMTP. Since SMTP server technology is mature, it is believed that this method can satisfy durability as well as security requirements. 5.1. 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 Aboba [Page 6] INTERNET-DRAFT 27 February 1997 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 settlement server and to ISPA ISPGROUP: Settlement server processes the session record, debits ISPA account, credits ISPB account ISPA: Accounting gateway routes the session record to the local billing server and to BIGCO ISPA: Billing server processes the session record, debits BIGCO account, debits ISPGROUP account BIGCO: Accounting gateway routes the session record to the local billing server BIGCO: Billing server processes the session record, debits Fred's account, debits ISPA account. Each of these events is discussed below. 5.2. 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 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 settlement agent, checkpoint events are typically summarized into a session record. 5.3. 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 settlement agent. Therefore, the roaming accounting architecture anticipates that while ISPs will use an accounting protocol of their choice to Aboba [Page 7] INTERNET-DRAFT 27 February 1997 communicate accounting information between network devices and the accounting gateway, a standardized accounting record format and trans- fer method will be used for communication between accounting gateways. In order to allow for transmission of accounting information to the settlement agent, ISPB will summarize the accounting information relating to Fred's session in a standard session record format. 5.4. 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 settlement agent, as well as to the local biling server. In this example, the settlement 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. 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 settlement agent, ISPB will encrypt the bundle, as well as signing it, and will request a signed receipt. 5.5. 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. If SMTP is used to transmit the session record between the accounting gateway and billing server, Aboba [Page 8] INTERNET-DRAFT 27 February 1997 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. 5.6. ISPGROUP accounting gateway routes the session record to the settlement 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 settlement 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. 5.7. ISPGROUP settlement server processes the session record, debits ISPA account, credits ISPB account ISPGROUP's settlement server processes the session record, and as a result, ISPA's account is debited, and ISPB's account is credited. If SMTP is used to transmit the session record between ISPGROUP's accounting gateway and the settlement server, then the settlement 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. 5.8. 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 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. 5.9. ISPA billing server processes the session record, debits BIGCO account, debits ISPGROUP account ISPA's billing server processes the session record, and as a result, BIGCO's account is debited, and ISPGROUP's account is also 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 accounting gateway's request. Aboba [Page 9] INTERNET-DRAFT 27 February 1997 5.10. 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. 5.11. BIGCO billing server processes the session record, debits Fred's account, debits ISPA account BIGCO's billing server processes the session record, and as a result, Fred's account is debited, as is ISPA's account. 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 gateway's request. 6. Accounting record formats In order to allow for accounting record bundles between organizations, it is necessary to provide for a standard accounting record format. 6.1. NVT ASCII 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. 6.2. Binary formats 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 Aboba [Page 10] INTERNET-DRAFT 27 February 1997 vendor-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. 6.3. Example accounting metrics Examples of accounting metrics include: User Name (String; the user's ID, including prefix or suffix) NAS IP address (Integer; the IP address of the user's NAS) NAS Port (Integer; identifies the physical port on the NAS) Service Type (Integer; identifies the service provided to the user) NAS Identifier (Integer; unique identifier for the NAS) Delay Time (Integer; time client has been trying to send) Input Octets (Integer; in stop record, octets received from port) Output Octets (Integer; in stop record, octets sent to port) Session ID (Integer; unique ID identifying the session) Authentication (Integer; indicates how user was authenticated) Session Time (Integer; in stop record, seconds of received service) Input Packets (Integer; in stop record, packets received from port) Output Packets (Integer; in stop record, packets sent to port) Termination Cause (Integer; in stop record, indicates termination cause) Multi-Session ID (String; for linking of multiple related sessions) Link Count (Integer; number of links up when record was generated) NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.) 7. Acknowledgements Thanks to Glen Zorn of Microsoft for useful discussions of this prob- lem space. 8. 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. Aboba [Page 11] INTERNET-DRAFT 27 February 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. [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 (RR) Record in the DNS. " draft-ietf-roamops-dnsrr-00.txt, Microsoft, February, 1997. [17] C. Rigney, W. Willats. "RADIUS Extensions." draft-ietf-radius- Aboba [Page 12] INTERNET-DRAFT 27 February 1997 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. 9. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Aboba [Page 13]