arkko-acctreq-00.txt

Internet DRAFT - draft-arkko-acctreq

draft-arkko-acctreq

Last Version:	draft-arkko-acctreq-00.txt	Tracker Entry
Date:	`20-Jan-2000`
Disposition:	expired

Network Working Group Jari Arkko
INTERNET-DRAFT Ericsson
Category: Standards Track
<draft-arkko-acctreq-00.txt>
6 August 1998

Requirements for Internet-Scale Accounting Management

1. Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

The distribution of this memo is unlimited. It is filed as <draft-
arkko-acctreq-00.txt>, and expires February 1, 1999. Please send
comments to the authors.

2. Abstract

Over the years, as Internet services have evolved, sophisticated
inter-domain applications such as roaming, voice over IP, Internet
fax, and QoS provisioning have arisen. This document discusses
whether accounting for these services services can be reliably and
securely accomplished using established techniques, and explores the
requirements for Internet-scale Accounting Management.

Arkko [Page 1]

INTERNET-DRAFT 6 August 1998

3. Table of Contents

1. Status of this Memo
2. Abstract
3. Table of Contents
4. Introduction
4.1 Terminology
4.2 Requirements language
5. Flexibility properties of accounting systems
6. Requirements
6.1. Flexibility
6.2. Scalability
6.3. Security
6.4. Accounting record transfer
6.5. Accounting record information
7. Analysis of current protocols
8. Conclusions
9. Acknowledgements
10. References
11. Authors' Addresses

Arkko [Page 2]

INTERNET-DRAFT 6 August 1998

4. Introduction

4.1. Terminology

This document frequently uses the following terms:

Accounting
The act of collecting information on resource usage for the
purpose of trend analysis, auditing, billing, or cost allo-
cation.

Rating The act of determining the price to be charged for use of a
resource.

Billing The act of preparing an invoice.

Auditing The act of verifying the correctness of a procedure.

Cost Allocation
The act of allocating costs between entities. Note that cost
allocation and rating are fundamentally different processes.

Interim accounting
An interim accounting packet provides a snapshot of usage
during a user's session. It is typically implemented in
order to provide for partial accounting of a user's session
in the event of a device reboot or other network problem
that prevents the reception of a session summary packet or
session record.

Session record
A session record represents a summary of the resource con-
sumption of a user over the entire session. Accounting gate-
ways creating the session record may do so by processing
interim accounting events.

Accounting Protocol
A protocol used to convey data for accounting purposes.

Intra-domain accounting
Intra-domain accounting involves the collection of informa-
tion on resource within an administrative domain, for use
within that domain. In intra-domain accounting, accounting
packets and session records typically do not cross adminis-
trative boundaries.

Arkko [Page 3]

INTERNET-DRAFT 6 August 1998

Inter-domain accounting
Inter-domain accounting involves the collection of informa-
tion on resource usage of an entity with an administrative
domain, for use within another administrative domain. In
inter-domain accounting, accounting packets and session
records will typically cross administrative boundaries.

Real-time accounting
Real-time accounting involves the processing of information
on resource usage within a defined time window. Time con-
straints are typically imposed in order to limit financial
risk.

4.2. Requirements language

In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [24].

5. Flexibility properties of accounting systems

This document is concerned with understanding how a general mechanism
can be used for the accounting management of a number of different
applications. It is therefore appropriate that we examine the poten-
tially differing requirements:

Information While there are some generally applicable information
elements in accounting (such as service name and time
information), different services typically have widely
different needs to convey information. It must be pos-
sible to extend the basic accounting mechanisms to new
application areas in a well-defined manner.

Security An intra-domain trend analysis application has very low
or non-existent security requirements; hop-by-hop
integrity support is almost certainly sufficient. In
contrast, an inter-domain billing application has very
high security requirements including data-object
integrity through proxies, confidentiality, and so on.

Data amount Many applications produce relatively small amounts of
data from each event, such as the few dozen variables
needed to describe a dial-in session with a NAS. In
contrast, some other applications may require the
inclusion of lengthy public key material and signa-
tures, or detailed descriptions of the provided ser-
vice.

Arkko [Page 4]

INTERNET-DRAFT 6 August 1998

Delay Many applications don't require immediate delivery of
accounting information, and are unwilling to pay the
price of such fast service. Other applications do
require immediate delivery. Yet other applications
insist also on fast acknowledgement of the delivery in
order to minimize the time the user has to wait before
service can be provided.

Applications differ also much depending on the amount of resources
they can dedicate for the accounting tasks:

CPU resources An application such as the accounting of dial-in ses-
sions of a NAS produces relatively infrequent account-
ing events. Other applications, such as accounting the
browsing of a web page produce substantially higher
amounts of events.

Storage resources
Many existing systems have no non-volatile memory or
use memory types that don't allow constant modifica-
tions. In contrast, future systems are likely to
employ large and cheap non-volatile memories.

Code size and complexity
For a workstation size computer the support of a number
of encryption algorithms, IPSec, MIME encoding, SMTP,
TCP, and so on is relatively easy. For a smaller device
such as an embedded processor in a fax or copy machine,
phone, set top box, and so on there are much tighter
requirements on how much protocol support can be
included.

If possible, these differing requirements and constraints should still
be supported within one accounting management mechanism.

6. Requirements

6.1. Flexibility

The following flexibility requirements suggest themselves:

Extensibility The protocol MUST be extensible to new services. It
MUST be possible to define service-specific extensions
to the accounting protocol. There MUST be a possibility
to define new standard and vendor-specific attributes.

Arkko [Page 5]

INTERNET-DRAFT 6 August 1998

There MUST be a possibility to define new messages.
There MUST be a possibility to detect version differ-
ences between protocol peers, and to revert to least
common denominator behaviour.

Security It MUST be possible to use the accounting protocol both
in situations which need and tolerate only hop-by-hop
integrity protection, as well as in situations which
need full integrity and confidentiality protection for
data objects and hop-by-hop.

Data amount It MUST be possible to use the accounting protocol both
in situations in which the amount of transferred infor-
mation fits the MTU and in which it doesn't.

Delay It MUST be possible to use the accounting protocol both
when real-time transfer of information is needed and
when it is not tolerated.

Fast UDP Delivery
It MUST be possible to use the accounting protocol both
with TCP and UDP. UDP is needed when real-time require-
ments dictate that retransmission policies are speci-
fied in a different manner than what TCP allows. For
instance, when a critical service requests to send an
accounting record and expects an acknowledgement, it
may be necessary to switch to an alternate server if
the primary server does not respond to a retransmitted
packet within a second.

Storage It MUST be possible to use the accounting protocol both
in devices which have a large non-volatile memory and
which don't.

Code size It MUST be possible to have conforming accounting pro-
tocol implementations from a stripped down version
which includes nothing more than basic protocol, UDP,
IP, and MD5 to a version which includes all security
and transport protocol support.

Proxy support It MUST be possible to forward accounting protocol mes-
sages through proxies with all supported transfer mod-
els.

Arkko [Page 6]

INTERNET-DRAFT 6 August 1998

6.2. Scalability

The following scalability requirements are set:

Per-device state
It MUST be possible to implement the accounting systems
with a per-device state when real-time requirements
don't call for event-driven information transfer.

Amortize overhead
It MUST be possible to amortize the packet header and
security overhead over several accounting records when
real-time requirements don't call for event-driven
information transfer.

6.3. Security

The following security related requirements are set:

Data object integrity
Data object integrity MUST be supported even through
proxies.

Data object confidentiality
Data object confidentiality MUST be supported even
through proxies.

Hop-by-hop integrity
Hop-by-hop integrity MUST be supported.

Hop-by-hop confidentiality
Hop-by-hop confidentiality MUST be supported.

IPSec/TLS Standard Internet security mechanisms such as IPSec or
TLS MUST be supportd for hop-by-hop security protec-
tion.

Data-based access control
Access control MUST be based also on the data in the
accounting records (such as for whose customers the
data is).

Arkko [Page 7]

INTERNET-DRAFT 6 August 1998

6.4. Accounting record transfer

The following requirements are set on how the accounting protocol
allows records to be transferred.

Polling It MUST be possible to use the polling model.

Event-driven It MUST be possible to use the event-driven model.

Event-driven polling
It MUST be possible to use the event-driven polling
model.

Interim-accounting
It MUST be possible to use the interim accounting
model.

Transfer negotiation
It MUST be possible for the service device and the
accounting server to negotiate the desired transfer
model and interim accounting parameters.

6.5. Accounting record information

The following requirements are related to the information in the
accounting records transferred by the protocol:

Finite sessions
The accounting protocol MUST support the accounting of
service usage in which a session begins at a certain
time and ends at a later time.

Infinite sessions
The accounting protocol MUST support sessions of indef-
inite length. [Discussion: This requirement is set by
services which are turned on at one time such as when
you order for some web space from a server, continue
for possibly a very long time, and might but need not
be terminated later.]

Indivisible events
The accounting protocol MUST support the accounting of
service usage which consists of an indivisible event.
[Discussion: In theory, this could be simulated with a
start followed immediately by stop, perhaps even in the

Arkko [Page 8]

INTERNET-DRAFT 6 August 1998

same packet. However, this is clumsy for a number of
services such as ordering a pizza.]

Service naming The protocol MUST have a standard attribute which iden-
tifies the name of the provided service. [Discussion:
Should there be something to manage these names, e.g.
object identifiers?]

Service amount specification
The protocol MUST have a standard attribute which gives
the "amount" of service provided. Amount is interpreted
in an service-specific manner, but it could be the
amount of calls made, amount of pizzas delivered, and
so on. The interpretation of the amount attribute is
defined in service-specific extensions to the account-
ing protocol. It MUST be possible to represent also
real numbers and not just integers.

Service length specification
The protocol MUST have a standard attribute which gives
the "length" of the service provided. Length is inter-
preted in the same way for all services, and MUST have
at least a one second granularity.

Service parameter specification
The protocol MUST have a standard attribute which gives
parameter information about the provided service. The
interpretation of this parameter is service-specific,
and defined in service-specific extensions to the
accounting protocol. [Discussion: Introduction of this
attribute may remove many of unnecessary RFCs about
video movie name attributes, pizza name attributes, and
so on.]

Note that the amount of money used for the service is
NOT required to be within the standard attributes.

7. Analysis of current protocols

In the following table we analyze how RADIUS Accounting as defined in
[4], TACACS+ as defined in [32], SNMP v3 as defined in [12]-[16], SMTP
and EDI functionality described in [17]-[23], and DIAMETER as defined
in [33] - [35] compare. We have used the following notation in the
table:

NO The protocol does not and can not support the feature.

Arkko [Page 9]

INTERNET-DRAFT 6 August 1998

YES The protocol supports the feature.

CAN The basic protocol could support the feature, given a simple
appropriate extension such as a new attribute is defined.

+-----------------------------+--------+--------+--------+--------+--------+
| FEATURE | RADIUS | TACACS+| SNMPv3 | SMTP |DIAMETER|
+-----------------------------+--------+--------+--------+--------+--------+
|Flexibility | | | | | |
| Extensibility | NO | NO(?)| YES | YES | YES |
| Security | NO | NO | NO | YES | YES |
| Data amount | NO | YES | NO | YES | YES |
| Delay | NO | NO | YES | YES | YES |
| Fast UDP delivery | YES | YES | YES | NO | YES |
| Storage | YES | YES | YES | NO | YES |
| Code size | NO | NO | YES | NO | YES |
| Proxy support | YES | YES | YES | YES | YES |
+-----------------------------+--------+--------+--------+--------+--------+
|Scalability | | | | | |
| Per-device state | NO | NO | NO(?)| YES | CAN |
| Amortize overhead | NO | NO | NO(?)| YES | CAN |
+-----------------------------+--------+--------+--------+--------+--------+
|Security | | | | | |
| Data object integrity | NO | NO | NO | YES | YES |
| Data object confidentiality| NO | NO | NO | YES | YES |
| Hop-by-hop integrity | YES | YES | YES | YES | YES |
| Hop-by-hop confidentiality | NO | YES | YES | YES | YES |
| IPSec/TLS | CAN | CAN | CAN | YES | YES |
| Data-based access control | YES | YES | NO | YES | YES |
+-----------------------------+--------+--------+--------+--------+--------+
|Accounting record transfer | | | | | |
| Polling | NO | NO | YES | YES | CAN |
| Event-driven | YES | YES | YES | YES | YES |
| Event-driven polling | NO | NO | YES | YES | CAN |
| Interim accounting | YES | YES | CAN | YES | CAN |
| Transfer negotiation | YES | NO(?)| NO | CAN | CAN |
+-----------------------------+--------+--------+--------+--------+--------+
|Accounting record information| | | | | |
| Finite sessions | YES | YES | CAN | CAN | YES |
| Infinite sessions | CAN | CAN | CAN | CAN | CAN |
| Indivisible events | CAN | CAN | CAN | CAN | CAN |
| Service naming | CAN | CAN | CAN | CAN | CAN |
| Service amount specificatio| CAN | CAN | CAN | CAN | CAN |
| Service length specificatio| CAN | CAN | CAN | CAN | CAN |
| Service parametrization | CAN | CAN | CAN | CAN | CAN |
+-----------------------------+--------+--------+--------+--------+--------+

8. Conclusions

As noted above, RADIUS, TACACS+, and DIAMETER accounting are suitable
for use in low-delay applications, SMTP is well suited for applica-
tions requiring high security and efficient transfer, and implementing
non-volatile storage, and SNMP v3 is suitable for use in intra-domain

Arkko [Page 10]

INTERNET-DRAFT 6 August 1998

accounting applications without need for data object security. How-
ever, since no single protocol satisfies all the requirements, we
believe that the need for a special-purpose accounting protocol arises
in the situations that involve more than one of the following require-
ments:

- Accounting applications which require low processing delay in order
to detect security or appropriate use violations in progress, manage
credit risk or prevent fraud. In such applications, it is often
required that accounting-data be handled in an event-driven manner,
and sent in small batches.

- Accounting applications which must incorporate information from many
devices or transfer very large volumes of data. In such applications,
efficiency is very important.

- Light-weight accounting applications running on small devices.

While RADIUS and TACACS+ are in principle capable of handling the
above two requirements, the lack of data object security, extensibil-
ity, and support for large record sizes makes it hard use these proto-
cols.

The following decisions now await resolving:

- The first decision is whether to handle credit risk management,
fraud detection, and so as a part of an accounting protocol, or
whether to handle it as a part of yet to be defined resource manage-
ment protocol. Support for these tasks could be included in products
that use the DIAMETER resource management extensions [34], for
instance. If the resource management protocol is used for this purpose
then many of the requirements set in this document will apply to it.
If not, a separate protocol needs to be constructed for the accounting
part. [Discussion: The line between a resource management and account-
ing tasks is blurred in my mind - what IS the actual difference?]

- The second decision is to decide whether the support for large-
voleme or light-weight applications is important enough to warrant the
definition of a new protocol.

- The third decision is to decide whether the accounting work may
assume the universal existence of large non-volatile memories or not.

9. Acknowledgements

The authors would like to thank Pat Calhoun (Sun Microsystems), Jan
Melen (Ericsson), Jarmo Savolainen (Ericsson), and Glen Zorn
(Microsoft) for many useful discussions of this problem space.

10. References

[1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming
Implementations." RFC 2194, Microsoft, Aimnet, i-Pass Alliance,

Arkko [Page 11]

INTERNET-DRAFT 6 August 1998

Asiainfo, Merit, September 1997.

[2] B. Aboba, G. Zorn. "Roaming Requirements." Internet draft (work
in progress), draft-ietf-roamops-roamreq-07.txt, Microsoft, March
1998.

[3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit,
Daydreamer, April, 1997.

[4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April,
1997.

[5] J. Gray, A. Reuter. Transaction Processing: Concepts and Tech-
niques, Morgan Kaufmann Publishers, San Francisco, California, 1993.

[6] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, Harvard University, March, 1997.

[7] D. Crocker, P. Overrell. "Augmented BNF for Syntax Specifica-
tions: ABNF." RFC 2234, Internet Mail Consortium, Demon Internet
Ltd., November 1997.

[8] G. Good. "The LDAP Data Interchange Format (LDIF) - Technical
Specification." Internet draft (work in progress), draft-ietf-asid-
ldif-02.txt, Netscape, July 1997.

[9] K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. "Accounting
Information for ATM Networks." Internet draft (work in progress),
draft-ietf-atommib-atmacct-04.txt, Cisco Systems, Telecom Finland,
MCI, November 1996.

[10] K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. "Managed
Objects for Controlling the Collection and Storage of Accounting
Information for Connection-Oriented Networks." Internet draft (work
in progress), draft-ietf-atommib-acct-04.txt, Cisco Systems, Telecom
Finland, MCI, November 1996.

[11] B. Aboba, D. Lidyard. "Accounting Data Interchange Format
(ADIF)." Internet draft (work in progress), draft-ietf-roamops-
actng-04.txt, Microsoft, Telco Research, March 1998.

[12] D. Harrington, R. Presuhn, B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2271, Cabletron, BMC Soft-
ware, IBM, January 1998.

[13] J. Case, D. Harrington, R. Presuhn, B. Wijnen, "Message Process-
ing and Dispatching for the Simple Network Management Protocol
(SNMP)", RFC 2272, SNMP Research, Cabletron Systems, BMC Software,
IBM, January 1998.

[14] D. Levi, P. Meyer, B. Stewart, "SNMPv3 Applications", RFC 2273,
SNMP Research, Secure Computing Corporation, Cisco Systems, January
1998.

Arkko [Page 12]

INTERNET-DRAFT 6 August 1998

[15] U. Blumenthal, B. Wijnen, "User-based Security Model (USM) for
version 3 of the Simple Network Management Protocol (SNMPv3)", RFC
2274, IBM, January 1998.

[16] B. Wijnen, R. Presuhn, K. McCloghrie, "View-based Access Control
Modem (VACM) for the Simple Network Management Protocol (SNMP)", RFC
2275, IBM, BMC Software, Cisco Systems, January 1998.

[17] R. Fajman. "An Extensible Message Format for Message Disposi-
tion Notifications." Internet draft (work in progress), draft-
ietf- receipt-mdn-08.txt, National Institute of Health, August 1998.

[18] M. Elkins. "MIME Security with Pretty Good Privacy (PGP)."
RFC 2015, The Aerospace Corporation, October, 1996.

[19] G. Vaudreuil. "The Multipart/Report Content Type for the Report-
ing of Mail System Administrative Messages." RFC 1892, Octel Network
Services, January, 1996.

[20] J. Galvin., et al. "Security Multiparts for MIME: Multi-
part/Signed and Multipart/Encrypted." RFC 1847, Trusted Information
Systems, October, 1995.

[21] D. Crocker. "MIME Encapsulation of EDI Objects." RFC 1767, Bran-
denburg Consulting, March, 1995.

[22] C. Shih, M. Jansson, R. Drummond. MIME-based Secure EDI."
Internet draft (work in progress), draft-ietf-ediint-
as1-05.txt, Actra, LiNK, Drummond Group, July 1997.

[23] C. Shih, M. Jansson, R. Drummond, L. Yarbrough. "Requirements for
Inter-operable Internet EDI." Internet draft (work in progress),
draft-ietf-ediint-req-04.txt, Actra, LiNK, Drummond Group, July 1997.

[24] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, Harvard University, March, 1997.

[25] Borenstein, N., Freed, N. "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing the
Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,
December 1993.

[26] N. Joffe, D. Wing, L. Masinter. "SMTP Service Extension for Imme-
diate Delivery", Internet draft (work in progress), draft-ietf-fax-
smtp-session-02.txt, Cisco Systems, Xerox, February 1997.

[27] H. T. Johnson, R. S. Kaplan. Relevance Lost: The Rise and Fall of
Management Accounting, Harvard Business School Press, Boston, Mas-
sachusetts, 1987.

[28] C. T. Horngren, G. Foster. Cost Accounting: A Managerial Empha-
sis. Prentice Hall, Englewood Cliffs, New Jersey, 1991.

[29] R. S. Kaplan, Anthony A. Atkinson. Advanced Management

Arkko [Page 13]

INTERNET-DRAFT 6 August 1998

Accounting. Prentice Hall, Englewood Cliffs, New Jersey, 1989.

[30] R. Cooper, R. S. Kaplan. The Design of Cost Management Systems.
Prentice Hall, Englewood Cliffs, New Jersey, 1991.

[31] P. R. Calhoun, M. A. Beadles, A. Ratcliffe. "RADIUS Accounting
Interim Accounting Record Extension", Internet draft (work in
progress), draft-ietf-radius-acct-interim-00.txt, July 1997.

[32] D. Carrel, L. Grant. "The TACACS+ Protocool Version 1.78", Inter-
net draft (work in progress), draft-grant-tacacs-02.txt, Cisco Sys-
tems, January, 1997.

[33] P. R. Calhoun, A. Rubens. "DIAMETER Base Protocol", Internet
draft (work in progress), draft-calhoun-diameter-01.txt, Sun Microsys-
tems, Merit Networks, March, 1998.

[34] P. R. Calhoun. "DIAMETER Resource Management Extensions", Inter-
net draft (work in progress), draft-calhoun-diameter-res-mgmt-00.txt,
Sun Microsystems, March, 1998.

[35] P. R. Calhoun. "DIAMETER User Authentication Extensions", Inter-
net draft (work in progress), draft-calhoun-diameter-authent-01.txt,
Sun Microsystems, March, 1998.

11. Authors' Addresses

Jari Arkko
Oy LM Ericsson Ab
02420 Jorvas
Finland

Phone: +358 40 5079256
EMail: Jari.Arkko@ericsson.com

Arkko [Page 14]