ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
<draft-ietf-roamops-actng-00.txt >
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 <draft-
ietf-roamops-actng-00.txt>, 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]
