G. Carle
Internet Draft S. Zander
Document: <draft-irtf-aaaarch-pol-acct-00.txt> T. Zseby
Category: Informational GMD FOKUS
July 2000
Policy-based Accounting
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working 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 material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This draft describes policy-based accounting which is aimed at the
provisioning of flexibility for accounting architectures. Accounting
policies describe the configuration of an accounting architecture in
a standardized way. They are used to instrument the accounting
architecture and can be exchanged between AAA entities in order to
share configuration information.
This draft describes building blocks and message sequences for
policy-based accounting in AAA. Examples are given for the usage of
accounting policies in different scenarios. Furthermore it is shown
how accounting components can be integrated into the authorization
framework. This draft does not propose a language for the
description of accounting policies. It is rather assumed that a
suitable policy language can be chosen from existing or upcoming
standards.
Carle, Zander, Zseby Expires January 2001 [Page 1]
Internet Draft Policy-based Accounting July 2000
Table of Contents
1. Introduction................................................2
2. Terminology.................................................3
3. Impact of Provider Network Characteristics to Accounting....4
4. Roles and relations between roles...........................5
5. Reference Model and Building Blocks.........................8
6. Accounting Policies........................................10
7. Accounting Services........................................13
7.1 Integrated Accounting......................................14
7.2 Discrete Accounting........................................14
7.3 Intra-Domain Accounting....................................15
7.4 Inter-Domain Accounting....................................16
7.5 Accounting Indication......................................18
7.6 Integration of Accounting Services in Authorization Model..19
7.6.1 Agent Sequence.............................................19
7.6.2 Pull Sequence..............................................19
7.6.3 Push Sequence..............................................19
7.7 Roaming....................................................20
8. Examples...................................................20
8.1 Printing Service Example...................................20
8.1.1 Intra-Domain Accounting....................................21
8.1.2 Inter-Domain Accounting....................................21
8.1.3 Accounting/Charging Indication.............................22
8.2 Mobile/Roaming Example.....................................23
9. Security Considerations....................................24
10. References.................................................26
11. Acknowledgments............................................27
12. Author's Addresses.........................................27
13. Full Copyright Statement...................................28
1. Introduction
Even if we will have much more bandwidth in the future than now, the
control of network resource utilization remains essential for the
support of applications with special demands and for the prevention
of (malicious or accidental) waste of bandwidth. Charging provides a
possibility to control utilization and sharing of network resources.
Charging in multi-service networks can be done based on the reserved
or the actual used resources. Charging on reserved resources makes
sense since reservation usually precludes other users from using the
reserved resources. Nevertheless, if charging is limited to
reservation parameters only, the applied charge depends on the
ability of the user to give a good prediction of the expected
traffic characteristics. This can be extenuated by using a charging
scheme that is based on both the reserved and the used resources. In
order to support usage-based charging, the collection of information
about the resource reservation and utilization is required. The
collection of data about resource usage is called accounting.
Accounting management architectures and objectives as well as the
transport of accounting records are discussed in [2].
Carle, Zander, Zseby Expires January 2001 [Page 2]
Internet Draft Policy-based Accounting July 2000
Service providers have various options for service differentiation,
charging schemes and the provisioning of accounting services. Users
introduce various traffic profiles and may have individual
preferences regarding the accounting services (like itemized
invoices, accounting indications, spending limits etc.). In order to
support the different accounting requirements that result from these
variability an accounting architecture has to be flexible in regard
to the data collection and distribution process. To support the
configuration of such an architecture in a standardized way we
propose to use accounting policies that are exchanged between the
different entities involved in the accounting process.
This document describes the structure and usage of accounting
policies. It shows how the characteristics of the provider network
influences the requirements for accounting. The relations between
the different roles that are involved in the accounting process and
the required building blocks for an accounting architecture are
introduced.
It is shown how different accounting services can be provided in
intra- and inter-domain scenarios. Examples are given for the usage
of accounting policies in different scenarios. They show how
accounting components can be integrated into the authorization
framework proposed in [1]. This draft does not propose a language
for the description of accounting policies. It is rather assumed
that a suitable policy language can be chosen from existing or
upcoming standards.
2. Terminology
Accounting Indication
An accounting indication provides information to customers
and/or to users about currently used resources. Accounting
indication messages are accounting records that are sent to the
customers and/or users. The accounting indication information
can be either a delta in resource consumption (e.g. since the
last accounting record has been sent) or a cumulated
information for the whole resource consumption since the
service usage began. Accounting indications can also contain
aggregated information for multiple services. There can be
interim and end-of-session accounting indications. Interim
indications are delivered in specified intervals to the user
during the service session while end-of-session indications are
given to the user at the end of the session.
Charging Indication
A charging indication is similar to an accounting indication.
But instead of giving the user an indication on the resource
reservation and/or usage the charging indication gives the user
an indication on the current charge.
Charging Scheme
Carle, Zander, Zseby Expires January 2001 [Page 3]
Internet Draft Policy-based Accounting July 2000
A charging scheme is an instruction for calculating a charge.
Usually a charging scheme is represented by a formula that
consists of charging variables (e.g. volume, time, reserved
peak rate) and charging coefficients (e.g. price per time
unit). The charging variables are usually filled by information
from accounting data.
Application Specific Module (ASM)
An ASM provides the functionalities required by a specific
application for the provisioning of AAA services. It gets
application specific information (ASI)(e.g. for configuration)
from the AAA server either in a generic format or in an
application specific format encapsulated in a standard message
sent to the ASM. The ASM either extracts the application
specific information (ASI) from the message or converts
information given in a generic format into the appropriate
application specific format. Further information on how the ASM
is used can be found in [3].
3. Impact of Provider Network Characteristics to Accounting
There are many options for future service providers for the
realization of service differentiation and provisioning. Therefore
provider networks can vary with respect to several characteristics
that impact accounting and charging:
- Size and Purpose
A small ISP that deals with individual customers may charge
individual users based on single flows. Backbone operator have small
ISPs and large corporations as customers, and usually charge based
on traffic aggregates instead of individual flows.
- QoS provisioning technique
DiffServ accounting requirements differ from IntServ accounting
requirements (e.g. meter granularity).
- Service classes
The definition of service classes within a network and the degree of
freedom that customers are given (e.g. gold/silver/bronze service
vs. a free choice of individual traffic profile parameters) is
important, e.g. for the flow classification within the network, and
influences the accounting functions required.
- Charging scheme
There exists a wide variety of charging schemes using tariff
variables based on different technical and/or economical models. The
chosen charging scheme(s) influence the accounting requirements for
the provider. While some charging schemes lead to zero or only few
accounting requirements, other charging schemes may be highly
demanding. For instance flat rate charging schemes require no
accounting infrastructure at all. In contrast to this volume-based
charging schemes require the measurement of the transmitted volume
and with this increases the complexity for accounting. Tariffs that
Carle, Zander, Zseby Expires January 2001 [Page 4]
Internet Draft Policy-based Accounting July 2000
introduce variable prices may require to provide the users regularly
with accounting information (e.g. by interim accounting
indications).
- Accounting Services
Providers may offer different accounting services (e.g. accounting
indication, itemized invoice, etc.)
- Accounting agreements with other providers
Providers may have agreements with other providers in order to share
accounting tasks and distribute accounting data so that, e.g.,
metering has to be done only once. For this it may be useful if
providers can not only exchange accounting data but also information
on the configuration of accounting modules (e.g. meters).
- Exploiting Capabilities of Existing Infrastructure (meters, data
collection points)
Providers may already have functions within the network that can
provide accounting functions (e.g. MIB objects, profile meters,
proprietary accounting solutions). In order to avoid duplicated
functionality, it should be possible to use these accounting
resources. Therefore the configuration of different types of
accounting modules (e.g. meters) should be possible. A common
language to express accounting module configurations would be useful
for this purpose.
4. Roles and relations between roles
In investigating service provision in the current and forthcoming
Internet we identified different business roles which are part of
the service usage lifecycle. In this section we first define the
term service. Afterwards the different roles and their relationships
are defined. The business roles in this model are used in the later
examples.
- Service
A service is a set of capabilities offered by a provider to a
customer. In this definition provider and customer can be one of the
business roles defined later. Different kinds of services have to be
recognized.
- Information services handle the delivery of information to
the customer on top of transport services. In content-based
services the service subscriber pays for the content he gets
(e.g. for a file, an image, a video, etc.). In communication-
based services the service subscriber pays for the provisioning
of a certain form of communication (e.g. videoconferencing or
IP telephony).
- Transport services describe the provisioning of pure
transportation of IP packets. At the IP layer this may include
the differentiation of packets (e.g. number of packets with a
certain DSCP), Intserv based reservation or other methods for
Carle, Zander, Zseby Expires January 2001 [Page 5]
Internet Draft Policy-based Accounting July 2000
QoS enhancement (e.g. ARQ, FEC). A transport service may as
well include mechanisms on other layers for improving the
transport (e.g. MPLS).
- Management services are responsible for the management of
resources (e.g. configuration, accounting, security).
Accounting services describe the provisioning of data about the
current or previous resource reservation and usage. Accounting
services are needed by providers to generate a bill or by users
to monitor their resource usage.
- Service Subscriber
The service subscriber is the entity that has subscribed to a
service and thus has a contractual relationship with a service
provider and a network provider which provides the underlying
transport service. A service subscriber can also act as a service
user. The service subscriber might have a relationship with a broker
which provides service relevant information.
- Service User
The entity that uses the service. The service user can be identical
with the Service Subscriber. In cases where subscriber and user are
not identical, the service subscriber should be able to control the
service usage for all service users he or she is responsible for.
For this the sending of accounting or charging indications is
useful.
- Network Provider
A network provider is the entity that provides the underlying
network infrastructure for the service user, service subscriber,
service provider and broker. A network provider provides transport
services. The services are delivered on top of the network
infrastructure. The service provider has a contractual relationship
with service subscriber and service provider (and the broker). The
transport network of a network provider is probably not a global
network which connects all subscribers, providers and brokers. The
transport network is segmented into a number of sub-networks or
domains controlled by different network providers with business
relations existing between them. Each domain is responsible for
intra-domain management and accounting. For inter-domain management
and accounting appropriate communication interfaces between network
providers must exist.
- Service Provider
A service provider entity provides a service. A service provider can
offer a service directly to the service subscriber/user. A service
provider can also act like a wholesaler selling a service to another
service provider (retailer) which resells the service to the service
subscriber. The service provider has contractual relationships with
other service providers, subscribers, brokers and network provider.
A service provider can provide either based services or
communication based services on top of the transport network of a
network provider.
Carle, Zander, Zseby Expires January 2001 [Page 6]
Internet Draft Policy-based Accounting July 2000
- Broker
The broker entity allows the other roles to access the information
controlled by the broker. The broker can provide different
information to different business roles. For example a service
subscriber can get references to appropriate service providers
and/or network providers (e.g. a broker gives the subscriber a
reference to a network provider which can provide bandwidth as
required by the subscriber). A broker can also interact with other
brokers to complete their information. In this case broker-to-broker
business relationships exist.
Figure 1 depicts the different roles and the business relations
between them.
+----+
V |
+---------------+ |
| Broker |<-+
+------>| |<-----------------+
| +---------------+ |
| ^ |
| | |
| V V
| +------------------+ +---------------+
| | Service | | Service |
| | Subscriber |<------>| Provider |
| | | | |<-+
| | +--------------+ | +---------------+ |
| | | Service User | | ^ ^ |
| | +--------------+ | | +----+
| +------------------+ |
| ^ |
| | |
| V |
| +---------------+ |
+------>| Network |<-----------------+
| Provider |<-+
+---------------+ |
^ |
+----+
Figure 1: Roles and business relations
In the rest of this section we give a few examples on how this
business relationship model can be applied to different services.
Example 1: This example describes an Internet printing scenario
according to the "print-by-reference" model [4]. The subscriber is a
company, the users are the employees of that company. The file
server and print server belong to two different service providers.
The company subscribes to the print server service which acts as
reseller for the file service. The file server service chooses the
Carle, Zander, Zseby Expires January 2001 [Page 7]
Internet Draft Policy-based Accounting July 2000
appropriate transport service (maybe based on user preference), thus
the file server has a contract with a network provider using the
offered transport service for downloading the data from the given
location and sending them to the print server.
Example 2: A company (service subscriber) has a contract with a
video archive (service provider). An employee can download clips in
different qualities from the archive. The employee can use different
transport mechanisms for the download. For getting the appropriate
transport the user contacts an agency (broker) that returns a
reference to a network provider which provides the required
transport service.
In the second example the content (video) can be delivered in
different qualities via different transport mechanisms by the
service provider. The service provider has some contract with
appropriate network providers which provide transport according to
the conditions the service provider offers the customers/
subscribers. In this case the service provider can use the
facilities of a broker to get a reference to appropriate network
providers. But we should not assume in general that the service
provider resells the transport service to the subscriber. There are
also lots of opportunities where the subscriber would like to
individually combine a content-based service with a special
transport service.
According to the above discussion there are two approaches for
offering services in the Internet:
- Combined service provision
The service provider sells the service (e.g. some content) and the
transport of the content to the customer as a combined service.
Example: The customer orders some goods at a company and can choose
how fast it is delivered (e.g. normal or 24h delivery). The company
then uses an appropriate transport mechanism (i.e. service from a
transport company).
- Discrete service provision
The service provider sells the service on top of a transport service
which must be obtained separately from a network provider. In this
case the customer has two contractual relationships. Example: The
customer orders some goods at a company. The customer makes a
contract with a transport company and instructs the company of the
desired transport.
5. Reference Model and Building Blocks
We have developed a reference model for describing the interactions
between the different metering, accounting and charging processes
and their configuration via policies. This reference model is shown
in Figure 2. At the right side five layers show the different
building blocks. The blocks are layered according to the processing
of the accounting data from the metering via accounting up to the
Carle, Zander, Zseby Expires January 2001 [Page 8]
Internet Draft Policy-based Accounting July 2000
final billing process. The building blocks on the different layers
are configured through the policies shown on the left side. The
configuration parameters are extracted from the policy and passed
via the control plane to the corresponding building block. The tasks
of the different building blocks are as follows:
- Metering
Meters are needed for capturing data about resource consumption in
the network (e.g. transmitted volume). They will probably be placed
at the edges of the network. Two types of meters can be
distinguished: Static meters, and configurable meters. In case of
static meters all flows are measured with a fixed granularity, not
distinguishing if a subsequent charging process needs the specific
meter data or not. In most cases the huge amount of captured data
makes a filtering stage after the metering necessary. An example for
a static meter is Cisco Netflow. In case of a configurable meter,
the meter collects meter data only for flows specified by meter
configuration information. An example of a configurable meter is
NeTraMet.
For configuration of the meter process the following issues must be
addressed: (a) metering scope (whether to meter all flows or only
selected flows), (b) metered flow attributes (i.e. which data is to
be collected for a specific flow), and (c) meter granularity
(measurement intervals etc.)
- Collection
The data gathered by the meter(s) has to be collected for further
processing. Collection of meter data can be initiated by the meter
itself (push model), or by a collector entity (pull model).
- Accounting
Accounting describes the collection of data about resource
consumption. This includes the control of data gathering (via
metering), transport and storage of accounting data. For subsequent
charging, the metered data must be associated with a user that is
the initiator of a flow, and a customer (service subscriber) that is
responsible for payment. For initiation of an accounting process, a
user or foreign provider must be authenticated and authorized. These
three functions can be performed by the AAA server.
- Charging
The Charging derives costs for accounting data sets based on service
specific tariff parameters. Different cost metrics may be applied to
the same accounting records even in parallel.
- Billing
The Billing translates costs calculated by the Charging into
monetary units and generates a final bill for the customer.
Carle, Zander, Zseby Expires January 2001 [Page 9]
Internet Draft Policy-based Accounting July 2000
Policy Parameters Building Blocks
+---------------+ User specific +---------+------------------+
| |<---------------->| | Billing |
| | | | |
| Pricing | Service specific | +------------------+
| |<---------------->| | Charging |
| | | | |
+---------------+ Accounting | +------------------+
| Accounting |<---------------->| Control | Accounting |
| | | | |
+---------------+ | Plane +------------------+
| | Collection | | Collection |
| Metering |<---------------->| | |
| | | +------------------+
| | Metering | | Metering |
| |<---------------->| | |
+---------------+ +---------+------------------+
Figure 2: Reference Model
We propose to use policies expressed in a standardized way to
configure the meter, meter data collection and accounting processes
appropriately.
6. Accounting Policies
Accounting policies describe rules for generation, transport and
storage of accounting data. They are exchanged between AAA instances
at the user or provider premises. They give a standardized
representation of policies that can be converted into the
appropriate settings for different elements of the accounting
infrastructures (e.g. different meters).
An example is given below. The accounting policy is sent from the
AAA server to the ASM and there converted to the appropriate
configuration information for the used meter. If NeTraMet is used,
the policy is converted into a NeTraMet ruleset that contains the
relevant flows, attributes and reader instructions for the data
collection. This information is passed to the NeTraMet manager that
configures meter and meter reader in accordance to the given
configuration.
Carle, Zander, Zseby Expires January 2001 [Page 10]
Internet Draft Policy-based Accounting July 2000
+------------------+
| AAA |
| |
+------------------+
| ^
Policy | | Accounting Records
V |
+------------------+
| ASM |
| |
+------------------+
| ^
| |
| config +-----------------+
| |
+-------------------------------+ |
| | | |
| V | |
| +----------------+ | |
| | Meter Manager | | | Meter Records
| +----------------+ | |
| | \ | |
| SNMP \ | |
| (conf)+---------------+ | |
| | | Meter Reader |---------+
| | +---------------+ |
| | ^ |
| V | |
| +-----------+ | |
| | Meter |-----+ |
| +-----------+ SNMP(DATA) |
| |
+-------------------------------+
Figure 3: Policy based Accounting with NeTraMet
If NetFlow is used as a meter, the meter policies are translated by
the ASM into filter instructions for the flow collector. The meter
itself is static and therefore is not affected by the configuration
information.
Carle, Zander, Zseby Expires January 2001 [Page 11]
Internet Draft Policy-based Accounting July 2000
+------------------+
| AAA |
| |
+------------------+
| ^
Policy | | Accounting Records
V |
+------------------+
| ASM |
| |
+------------------+
| ^
| |
| config | Meter Records
| |
+-------------------------------+
| | Meter System |
| | |
| | +---------------------+ |
| | | Flow Collector | |
| | | +------------+ | |
| | | | Filter | | |
| | | | Aggregator | | |
| +->| +------------+ | |
| +---------------------+ |
| ^ |
| | |
| +-----------+ | |
| | Meter |-----+ |
| +-----------+ UDP (DATA) |
| |
+-------------------------------+
Figure 4: Policy based Accounting with NetFlow
The ASM can be realized as a separate component, but it could also
be integrated in the AAA server or in the meter.
The following settings can be specified by accounting policies:
- accounting record type/structure
The required accounting data depends on the charging scheme.
Therefore different accounting records should be supported. There
are two possibilities. Either different record types are defined or
a flexible record is used that consists of a variable set of
accounting attributes. Accounting policies can be used to
Carle, Zander, Zseby Expires January 2001 [Page 12]
Internet Draft Policy-based Accounting July 2000
communicate to neighbor providers which kind of accounting record is
needed to provide appropriate data for the charging scheme. The
specification of the required accounting attributes can influence
the settings of different components of the accounting architecture
(e.g. which attributes have to be measured). An overview of
accounting attributes and records can be found in [5].
- accounting record destination
The accounting record destination describes to which entities
accounting records are sent. The accounting record destination can
be a charging entity, a neighbor provider, a user entity or a
specific database. In these cases authentication and authorization
mechanisms have to be applied in order to prevent that unauthorized
entities can get access to confidential data.
- sending interval
The sending interval specifies in what time intervals accounting
records are generated and sent. This influences the configuration of
meters and collectors in the accounting architecture.
- storage time
If the accounting record destination is a database or a log file the
storage time specifies how long the accounting records have to be
stored.
- access list
The access list specifies who has the permission to read the stored
accounting records.
Accounting policies are enforced by configuring the accounting
architecture in the appropriate way. They influence the following
settings in the accounting architecture:
- Meter configuration (meter accuracy and granularity, relevant
attributes, meter intervals )
- Data collection process (from which meters data has to be
collected, how often, which post-processing has to be applied)
- accounting record distribution (when are which accounting records
sent to whom)
- accounting record storage (location, expiration time, access list)
- accounting data aggregation (when which records should be
aggregated and how aggregation is done)
7. Accounting Services
Accounting can be seen as part of the service provisioning process
(Integrated Accounting) or as a separate service (Discrete
Accounting). The different views and their impact on the accounting
architecture are described below.
Carle, Zander, Zseby Expires January 2001 [Page 13]
Internet Draft Policy-based Accounting July 2000
7.1 Integrated Accounting
In integrated accounting the accounting is seen as part of the
provisioned service. That means the accounting is coupled to a
specific service. Therefore the accounting process is tailored to
the service probably collecting the accounting information directly
exploiting some service specific entity. For example accounting for
IP telephony could use call signaling information from a SIP server.
The configuration of the accounting architecture is done as part of
the service equipment configuration. Accounting policies are defined
as part of the service provisioning agreement. The ASM converts the
instructions from the AAA server into the appropriate service
equipment configuration including settings for the accounting
architecture.
+---------------------+
<---1--->| Generic AAA Server |<---1--->
| | ............
| Rule based engine |<----|----->: Policy :
| | 3| :..........:
+---------------------+<----|--+ ............
^ +-->: Events :
| :..........:
2
|
V
+----------------------+
| Application specific |
| Module |
+----------------------+
^ ^
| |
5 5
| |
V V
+-----------+ +----------------+ ..............
| Service |<-->| Accounting/ |<--3-->: Accounting :
| | | Metering | : Data :
+-----------+ +----------------+ :............:
Figure 5: AAA Server with Integrated Accounting
Data about the resource consumption is sent back by the meter(s) to
the ASM. The ASM then converts the metered data into accounting
records which are sent to the AAA server. For generating accounting
records the ASM might perform data conversion, aggregation and
filtering of data.
7.2 Discrete Accounting
In contrast to the integrated accounting approach, accounting can
also be seen as a separate or discrete service on its own.
Carle, Zander, Zseby Expires January 2001 [Page 14]
Internet Draft Policy-based Accounting July 2000
Accounting as a separate service can be seen as some form of
outsourcing the accounting task. It can be provided by a general
accounting system which is able to account for different services.
For example a generalized meter can do accounting for web traffic,
FTP traffic and voice over IP traffic. If accounting is a separate
service one provider can do the accounting (charging and billing)
for several other service providers. This might speed up the
creation of new services in the Internet. This separation is also
beneficial for instance to support special accounting services (like
accounting indications or exchange of data between providers) that
are not directly coupled to a network service. Furthermore this
separation is useful if the same set of accounting strategies can be
applied to different services (e.g. different tariffs which can be
used for a set of services).
+---------------------+
<---1--->| Generic AAA Server |<---1--->
| | ............
| Rule based engine |<----|----->: Policy :
| | 3| :..........:
+---------------------+<----|--+ ............
^ ^ +-->: Events :
| | :..........:
2 2
| |
V V
+-------------+ +--------------+ .................
| Application | | Accounting |<---3--->: Accounting :
| Specific | | Module | : Data :
| Module | +--------------+ :...............:
+-------------+ ^
^ |
| |
5 6
| |
V V
+-------------+ +---------------+
| Service | | Accounting/ |
| | | Metering |
+-------------+ +---------------+
Figure 6: AAA Server with Discrete Accounting
7.3 Intra-Domain Accounting
In Intra-Domain accounting [2] the data about the resource
consumption is collected in one administrative domain for the usage
in that domain. Accounting policies are locally enforced. Since no
exchange of accounting data with other domains is required in this
scenario accounting policies do not need to be exchanged with other
entities.
Carle, Zander, Zseby Expires January 2001 [Page 15]
Internet Draft Policy-based Accounting July 2000
+-----------+
| Billing |
+-----------+
^ ..............
| : Accounting :
|----------->: Records :
| :............:
| ..............
+--------------+ : Accounting :
| AAA |<--->: Policies :
+--------------+ :............:
| ^
| |
V |
+--------------+
| ASM |
+--------------+
| ^
config | | Meter Records
V |
+------------+ +----------------------+
| | Service usage | +----------------+ |
| End System |-------------->| | Meter System | |
| | | +----------------+ |
+------------+ | |
| Service Equipment |
+----------------------+
User Provider
Figure 7: Intra-Domain Accounting
7.4 Inter-Domain Accounting
For Inter-Domain Accounting at least two administratively separated
networks are involved in the accounting process. These can be a
Home- and a Foreign-Provider in a Roaming/Mobile IP Scenario or a
chain of providers if service provisioning involves data transfer
and/or services from different domains. In these scenarios the
exchange of accounting policies between providers is necessary if
accounting tasks are delegated to one provider or shared among
multiple providers. The exchange of accounting policies is done by
the AAA servers. An example is given in the figure below.
Carle, Zander, Zseby Expires January 2001 [Page 16]
Internet Draft Policy-based Accounting July 2000
| +-----------+
| | Billing |
| +-----------+
| ^
| |
+------------------+ 1. AccPolReq +-----------+
| |<-------------| |
| | | | |
| AAA | 2. AccPolAck | AAA |
| |------------->| |
| | | | |
| | 3. AccRec | |
| |------------->| |
+------------------+ | +-----------+
config | ^ |
| | |
V | |
+--------------+ |
| ASM | |
+--------------+ |
| ^ |
| | |
| | Meter Records |
Service V | |
+------------+ usage +----------------------+ |
| | | +----------------+ | |
| End System |------>| | Meter System | | |
| | | +----------------+ | |
+------------+ | | |
| Service Equipment | |
+----------------------+ |
User Foreign-Provider Home-Provider
Figure 8: Inter-Domain Accounting (Roaming Example)
In this example the foreign provider takes over the collection of
accounting data. The home provider is responsible for applying a
charging scheme and sending the bill. Therefore the home provider
needs accounting data from the foreign provider. In order to
instruct the foreign provider about the desired accounting record
type and report frequency the home AAA server sends an accounting
policy request to the foreign AAA server. The request contains the
accounting policy. If the foreign AAA server is able to enforce the
desired policy (e.g. the meters are capable of metering the
requested attributes) the accounting policy request is acknowledged.
Carle, Zander, Zseby Expires January 2001 [Page 17]
Internet Draft Policy-based Accounting July 2000
In case the requested policy cannot be enforced, the accounting
service is denied. Reasons to deny the enforcement of a specific
accounting policy could be e.g. because the meter is not capable to
measure the requested attributes or the frequency of records cannot
be provided, or the home provider is not authorized to get the
requested detailed data. In this case procedures would be useful to
negotiate the smallest common denominator for the involved AAA
servers regarding the provisioning of accounting data.
7.5 Accounting Indication
Accounting indications are accounting records that are sent to the
customer and/or user in order to inform them about the resource
usage. The accounting indication is a special accounting service
that can be provided in addition to the standard accounting
performed by the provider. Like for any other service an
authorization should take place before the accounting indication
service provisioning.
USER PROVIDER
+---------------+ +----------------+
| | | |
| | 1. AccPolReq | |
| End |-------------------->| AAA |
| System | | |
| | 2. AccPolAck | |
| |<--------------------| |
| | | |
| | 3. AccRec | |
| |<--------------------| |
| | +----------------+
| | | ^
+---------------+ | |
V |
+----------------+
| ASM |
| |
+----------------+
| ^
config | |
V |
+--------------------+
| +----------------+ |
| | Meter System | |
| +----------------+ |
| |
| Service Equipment |
+--------------------+
Figure 9: Accounting Indication
In order to request an accounting indication a user or customer
sends an accounting policy request to the responsible AAA server.
Carle, Zander, Zseby Expires January 2001 [Page 18]
Internet Draft Policy-based Accounting July 2000
The request contains the preferred accounting attributes and report
interval. If the user/customer is authorized to use the accounting
indication service, the policies are enforced by instrumenting the
metering and the accounting equipment. Accounting records are then
forwarded to the user/customer.
7.6 Integration of Accounting Services in Authorization Model
[1] introduces different message sequences for authorization. The
integration of configurable accounting services for the message
sequences can be done as described in the following sections.
7.6.1 Agent Sequence
Since this scheme describes a single domain case, the accounting
policies from the provider do not need to be transported to AAA
servers in other domains. The appropriate accounting policy for the
authorized service is either stored together with the authorization
policy or in a separate repository.
The configuration of the accounting infrastructure can be done
together with the setup of the service equipment. Setting up the
service equipment and the accounting infrastructure configuration
might involve the transfer of configuration data to multiple
entities in the network (e.g. to different routers for setting up
QoS provisioning or to dedicated accounting meters)
An ASM might be needed to convert the accounting policies into the
appropriate configuration information. In the agent sequence it is
possible to allow the user to send an accounting policy request
(e.g. for accounting indications) together with the authorization
request to the AAA server.
7.6.2 Pull Sequence
The pull sequence also describes a case where service provisioning,
authorization and accounting are done in one single domain. As in
the agent sequence the accounting policies do not need to be
communicated to other domains. The configuration of the accounting
infrastructure can also be done similar to the agent sequence during
the setup of the service equipment.
Since the pull sequence does not involve the sending of a specific
authorization request (e.g. if the service equipment is a NAS and
the authorization sequence simply starts with the dial-in process)
it would need additional communication to support accounting policy
requests from users. This can be for instance achieved by a hybrid
model of agent and pull sequence where the user sends an accounting
policy request to the AAA server in addition to the messages
exchange for the pull sequence.
7.6.3 Push Sequence
Carle, Zander, Zseby Expires January 2001 [Page 19]
Internet Draft Policy-based Accounting July 2000
In the push sequence there is no direct connection between the AAA
server and the service equipment. In this sequence there are three
possibilities for setting up the accounting infrastructure:
a) A standard fixed accounting procedure is used, that has been
assigned in advance for the specific combination of authorized user
and service.
b) The ticket contains information about the accounting policy used
(e.g. different tickets for the same service with different
accounting policies).
c) The ticket acts as a kind of digital coin and no further
accounting is needed. This model also supports the anonymous usage
of a service.
7.7 Roaming
If the provisioning of the service and the final authentication/
authorization process is done by different organizations, accounting
is rather coupled to the service provisioning process than to the
authentication/authorization process. Since the data doesn't have to
traverse the home providers network, the home provider has no
possibility to collect data about the resource consumption.
Therefore accounting will usually take place in the foreign provider
domain (i.e. in the domain that does the service provisioning).
Nevertheless, in order to ensure consistency of the authentication,
authorization and accounting processes (e.g. allocation of user IDs
to accounting records) and to produce a bill a connection between
the accounting process in the service provisioning domain and the
deciding authentication/authorization process (e.g. at the home
provider) is needed.
A possibility to do this is that the foreign provider gets the
accounting policies from the home provider and sets up the
accounting architecture in accordance to the given policies. The
foreign provider generates accounting records and sends them back to
the home provider. The home provider then can apply charging and can
produce a bill. An example for this is given in section 8.2.
8. Examples
8.1 Printing Service Example
The Internet Printing Protocol (IPP) [4], and especially the "print-
by-reference" model, provides a very interesting example scenario
for accounting and the interaction between authorization and
accounting. We will describe possible solutions for the accounting
of this service and how the accounting is triggered by the
authorization. We will show how the model presented above can be
used for this example.
Carle, Zander, Zseby Expires January 2001 [Page 20]
Internet Draft Policy-based Accounting July 2000
IPP "print-by-reference" allows a user to request a print service to
print a particular file. The file to be printed is not on the client
system but rather on a public server. That is, the clients print
request can contain a reference, or pointer, to the document instead
of the actual document itself. The print service must then read the
file to a file server (used for spooling) prior to the printing.
There are two possible setups: The file and print server either
belong to a single organization (Intra-Domain Accounting) or to two
different organizations (Inter-Domain Accounting). In the first case
the user must be authorized by a single service provider for service
usage. In the second case two different possibilities for
establishing a trust relationships between the involved entities
have to be distinguished [6].
8.1.1 Intra-Domain Accounting
In the case of a single organization the file and print service is
provided by a single service provider. The service subscriber and
user role are either one entity (e.g. private home user) or
different entities (e.g. company as subscriber, employee as user).
For data transport via the underlying network the transportation
service of a network provider is used. In this case the AAA Server
of the provider controls both the file and the print server. This
means the AAA server enforces the accounting policies and collects
accounting data for both servers.
8.1.2 Inter-Domain Accounting
If two different organizations are involved there are two
possibilities for trust relationships as shown in [6]:
1. The User has an agreement with the Print Server; the print
server has an agreement with the file server.
2. The user has agreements with both print and file server.
In case 1, the user is first authorized by the print service and the
request is forwarded to the file server. The file server authorizes
the print server and determines if the printer is allowed to access
the file. In this case the accounting policies from the user arrive
at the print service AAA server. The print service AAA server has to
decide which policies can be enforced locally and which must be
passed further to the file service AAA server. The print service can
add additional accounting policies. In case the file server does not
support the desired accounting policies the print server must notify
the users AAA server and some policy conflict resolution must occur.
After the file server has transferred the file to the print service
it generates an accounting record according to the accounting policy
and gives it to the print service. The print service generates the
final accounting record for the service session based on his own and
the file service data after finishing printing. This record will be
used for the later billing process. Additionally the print server
can send the final record to the users AAA server. There it can be
Carle, Zander, Zseby Expires January 2001 [Page 21]
Internet Draft Policy-based Accounting July 2000
used for later authorization decisions based on used resources i.e.
if the customer is a company and the user is an employee.
USER DOMAIN PRINT SERVICE DOMAIN FILE SERVICE DOMAIN
| |
+------+ | |
| | | |
| | | |
| | | +--------------------+ | +-------------------+
| User |---1-->| Print Service |---1-->| File Service |
| AAA |<--2---| AAA Server |<--2---| AAA Server |
|Server| | +--------------------+ | +-------------------+
| | | | Print Server | | | File Server |
| | | | and Printer | | | |
+------+ | +--------------------+ | +-------------------+
1: AccPolReq
2: AccPolAck
Figure 10: Inter-Domain Accounting and Printing Service
In case 2, the customer AAA server has an agreement with file and
print server. In this case the users AAA server sends accounting
policies to the file and the print server. After finishing the
service both servers generate accounting records for the delivered
services which are used for later billing. As in the former case the
accounting data can be send to the user AAA server for use in later
authorization decisions. The user AAA server can tie both accounting
records together and assign them to the user using audited session
information (authorization and accounting messages for a particular
session must have the same session id) and policies which define
what activities a certain session is composed of.
8.1.3 Accounting/Charging Indication
For the printing service there are a number of possible options for
accounting and/or charging indication. Accounting and charging
indications are usually send to the service user or the service
subscriber. Charging indications give the user an indication on how
much money has been spent for the usage so far. Accounting
indications gives the user an indication on how much resources have
been used until the time of the indication. A user can receive only
accounting, only charging, both or no indication depending on the
indication policy for the user.
For Internet printing with the "print-by-reference" model such
indications would be very helpful for the user. Since the file is
not on the clients site the user might not have information on the
file size or the number of pages that will be printed. This means
Carle, Zander, Zseby Expires January 2001 [Page 22]
Internet Draft Policy-based Accounting July 2000
the user has no idea of the costs of the service usage. If user and
subscriber are a single entity charging indications would help the
user to avoid exceeding his spending limit. Additional accounting
indications give the user a hint what resource usage has caused the
charges. This can be compared to an itemized telephony bill where
not only the monetary sum per month is printed but in addition
information for every call (start time, duration, distance etc.) and
the corresponding amount of money.
8.2 Mobile/Roaming Example
User | Visited ISP | Home ISP
| |
| | +------------+ ..........
<--------------------12----------------| | Charging | :charging:
| | |and Billing | :policies:
| | +------------+ :........:
| | ^
| | |
| | 11
| | |
| +------------+ | +------------+
| | | | | |
| | |---10---->| |
| | | | | |
| AR's | AAA Server |----3---->| AAA Server |
<-----------------| |<---4-----| |
| | | | | |
| | | | | |
| +------------+ | +------------+
| ^ | ^ |
| | | | |
| | 5 9 |
| | | | |
| | V | |
| | +----------------+|
| | | ASM ||
| 2 | ||
| | +----------------+|
| | | ^ |
| | | | |
| | | | |
| | 6 8 |
| | | | |
| +------------+------+-------+ |
7 | | Service | | | |
<--------| Equipment | +---------+ | |
1 | | |->|Collector| | |
-------->| | +---------+ | |
| | config | | | |
| | | +---------+ | |
| | +->| Meters | | |
| | +---------+ | |
Carle, Zander, Zseby Expires January 2001 [Page 23]
Internet Draft Policy-based Accounting July 2000
| +---------------------------+ |
| |
Figure 11: Roaming Example
In this section the "Dial-in with Roaming" example from the
authorization examples draft [6] is used to show how accounting
functions could interact with authorization functions. It gives just
one example from a variety of possibilities. The accounting modules
(e.g. collectors and meters) are seen here as part of the service
equipment which is in this example located at the visited ISP
premises. The basis configuration of the accounting modules would be
probably done by the visited ISP itself, but the visited ISP can
allow the home ISP to influence certain parameters (like report
interval or accounting record format). This is useful if the home
provider generates the invoice and therefore needs appropriate
accounting records to calculate the prices.
The exchange of authorization data corresponds to the example in the
draft [6]. As an additional component we introduce an ASM between
home AAA and service equipment for the conversion of the service
parameters to the appropriate configuration information.
Steps (1), (2) and (3) describe the forwarding of an
authentication/authorization request from the user via the AAA sever
of the visited ISP to the home AAA server. In step (4) service
parameters are given to the visited ISP's AAA server and are
forwarded to the service equipment (5). The service parameters could
additionally include the desired policies for the configuration of
the accounting infrastructure of the visited ISP. An accounting
policy could be for instance "for user X one accounting record of
type x has to be generated all 30 seconds " This accounting policy
is used by the visited ISP to configure his modules (e.g. metering,
data collection).
Service parameters are converted by the ASM into the appropriate
configuration information (6). Then the user is informed about the
completed authentication/authorization process (7). The accounting
architecture starts metering the resource usage and sends metering
records to the ASM (8). The ASM uses the metered data to fill the
required accounting records and sends them to the visited ISP's AAA
server (9). The visited ISP can either post-process the data or
directly forward them to the home ISP (10). With this data as input
an invoice is generated by the charging and billing modules within
the home providers domain (11) by using charging policies (tariff
formulas) and then sent to the user/customer (12).
As an additional option accounting records can be offered also to
the user (accounting indication) as a special service. For this
special service a separate authorization is required.
9. Security Considerations
Carle, Zander, Zseby Expires January 2001 [Page 24]
Internet Draft Policy-based Accounting July 2000
Accounting services provide the basis for billing. Therefore the
incentives (mainly saving money) and potential for fraud is
extremely high in the field of configuration of the accounting
architecture and the collection of accounting data.
In the presented framework two types of data communications are
required, the exchange of accounting policies and the collection of
accounting records. Both communications introduces potential
security hazards. The main hazard is that users try to forge
accounting data in a way that the final bill shows a lower charge
than actually occurred. This can be done indirectly by modifying the
accounting policies or directly by altering accounting records.
The following potential security hazards can be identified:
- Forgery of accounting policies and accounting record information
Both accounting policies and accounting records can be the target
for information forgery. Accounting policies contain configuration
information. Modifying this information can lead to a mal-configured
accounting and metering system which either allows data to traverse
the accounting system undetected (without being counted) (e.g. by
changing the classification rules of a meter) or produces bogus
accounting records. Accounting records contain data about the
resource consumption and provide the basis for billing. Modifying
accounting records leads to erroneous bills. Furthermore it should
be prevented that policies or accounting records are redirected or
removed or forged policies or records are inserted.
- Eavesdropping
It might be desired to keep accounting policies and accounting
records confidential between the involved parties.
- Denial of Service (DoS) attacks
Both the AAA server and the accounting/metering subsystem can be the
target of denial of service attacks. A denial of service attack
against the AAA server may lead to malfunction and even breakdown of
the server. This means the server will not be able to provide proper
authentication, authorization and accounting functionality. The
service provided by the AAA server will become unavailable or
unusable. An attack against the accounting/metering system will
cause loss of metering data and/or loss of accounting records.
This leads to the following security requirements:
- Secrecy of accounting policies and accounting data
Unauthorized entities should not be able to read or modify
accounting policies or accounting records. This can be achieved with
standard encryption methods.
- Authentication of accounting data and accounting policy sources
It should be ensured that the data is originated by the original
source. Source-authentication can be achieved by using digital
signatures.
Carle, Zander, Zseby Expires January 2001 [Page 25]
Internet Draft Policy-based Accounting July 2000
- Protection of the integrity of accounting policies and accounting
records
It should be ensured that the data was not modified on the way from
sender to receiver. Data-authentication can also be achieved with
digital signatures.
- Prevention and protection against Denial of Service attacks
The AAA protocol and all building blocks should be designed and
implemented in a way most resistant to denial of service attacks.
Furthermore a component can be added to the meter system which is
able to detect an unusual high packet rate. Upon detection further
actions can be taken according to a defined policy.
The prevention of these hazards is one requirement for the protocols
used for accounting policy exchange and the transportation of
accounting records. Since the needed security requirements
(authentication, transmission level security, data object
confidentiality and integrity) are addressed in the criteria for AAA
protocol evaluation [7] we assume that the future AAA protocol(s)
will be suited for secure accounting record transfer and probably
also for secure accounting policy transport. Furthermore we assume
that existing or upcoming solutions for secure transportation and
enforcement of policies can be used.
10.
References
[1] John Vollbrecht, et al, "AAA Authorization Framework",
draft-irtf-aaaarch-authorization-framework-00.txt, January
2000
[2] Bernard Aboba, Jari Arkko, David Harrington, "Introduction
to Accounting Management", <draft-ietf-aaa-acct-03.txt>,
Work in Progress, 2 May 2000
[3] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence,
"Generic AAA Architecture", draft-irtf-aaaarch-generic-
01.txt, Work in Progress, March 2000
[5] Nevil Brownlee, Alan Blount, "Accounting Attributes and
Record Formats", Internet-Draft draft-ietf-aaa-accounting-
attributes-03.txt, Work in Progress, 14 April 2000
[4] Roger deBry, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, April 1999.
[6] John Vollbrecht, et al, "AAA Authorization Application
Examples", draft-irtf-aaaarch-authorization-apps-00.txt,
Work in Progress, January 2000.
[7] Bernard Aboba, et al, "Criteria for Evaluating AAA Protocols
for Network Access, draft-ietf-aaa-na-reqts-05.txt, Work in
Progress, 26 April 2000
Carle, Zander, Zseby Expires January 2001 [Page 26]
Internet Draft Policy-based Accounting July 2000
11.
Acknowledgments
The authors would like to thank the members of the AAAARCH research
group for the fruitful discussions and comments.
12.
Author's Addresses
Georg Carle
GMD FOKUS
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone: +49-30-34 63 7149
Email: carle@fokus.gmd.de
Sebastian Zander
GMD FOKUS
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone: +49-30-34 63 7287
Email: zander@fokus.gmd.de
Tanja Zseby
GMD FOKUS
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone: +49-30-34 63 7153
Email: zseby@fokus.gmd.de
Carle, Zander, Zseby Expires January 2001 [Page 27]
Internet Draft Policy-based Accounting July 2000
13.
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Carle, Zander, Zseby Expires January 2001 [Page 28]