One document matched: draft-irtf-aaaarch-pol-acct-05.txt-100442.txt
Differences from 05.txt-04.txt
T. Zseby
Internet Draft S. Zander
Document: <draft-irtf-aaaarch-pol-acct-05.txt> G. Carle
Category: Experimental Fraunhofer FOKUS
August 2002
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 document describes policy-based accounting which is an approach
to provide flexibility to 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 document describes building blocks and message sequences for
policy-based accounting in the generic AAA architecture [RFC2903].
Examples are given for the usage of accounting policies in different
scenarios. Furthermore it is shown how accounting components can be
integrated into the AAA authorization framework [RFC2904]. This
document 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.
Zseby, Zander, Carle Expires February 2003 [Page 1]
Internet Draft Policy-based Accounting August 2002
Table of Contents
1. Introduction.................................................3
1.1 Motivation...................................................3
1.2 Document Scope...............................................4
2. Terminology..................................................4
3. Impact of Provider Network Characteristics on Accounting.....6
4. Business roles and relations.................................8
5. Reference Model and Building Blocks.........................11
6. Accounting Policies.........................................13
6.1 Accounting Policy Condition.................................14
6.2 Accounting Policy Action....................................15
6.3 Example for Meter Configuration.............................16
7. Accounting Services.........................................17
7.1 Integrated Accounting.......................................17
7.2 Discrete Accounting.........................................18
7.3 Intra-Domain Accounting.....................................20
7.4 Inter-Domain Accounting.....................................21
8. Accounting with different Authorization Models..............22
8.1 Agent Sequence..............................................22
8.2 Pull Sequence...............................................23
8.3 Push Sequence...............................................24
8.4 Roaming.....................................................24
9. Examples....................................................25
9.1 Printing Service Example....................................25
9.1.1Intra-Domain Accounting.....................................25
9.1.2Inter-Domain Accounting.....................................26
9.1.3User Accounting Indication..................................27
9.2 Mobile/Roaming Example......................................27
9.3 Diffserv Example............................................29
9.4 User Accounting Indication Example..........................32
10. Security Considerations.....................................33
11. References..................................................35
12. Acknowledgments.............................................36
13. Author's Addresses..........................................36
14. Full Copyright Statement....................................37
Zseby, Zander, Carle Expires February 2003 [Page 2]
Internet Draft Policy-based Accounting August 2002
1. Introduction
1.1 Motivation
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 is an
important concept 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.
Service providers have various options for service differentiation,
charging schemes and the provisioning of accounting services. The
applied charging schemes for the provided services is one
significant feature that is used by providers to distinguish
themselves from competitors. Therefore providers use different
charging schemes and may change the schemes in accordance to their
business plan. Providers also can offer different accounting
services (e.g. standard, comprehensive, etc.) in order to allow
customers/users to chose one scheme that meets the customers/users
needs. Furthermore it may be advantageous for a providers to
outsource accounting functionality to a third party. Users introduce
various traffic profiles and may have individual preferences
regarding the accounting services (like itemized invoices,
accounting indications, spending limits etc.).
One further challenge for the configuration of accounting services
are heterogeneous metering and accounting infrastructures within
provider domains. Also the usage of different accounting and
metering solutions used in different provider networks complicates
the sharing of configuration parameters (e.g. in roaming scenarios).
The configuration and dynamic adaptation of the accounting process
to the business model and specific user demands requires a flexible
configurable accounting infrastructure. The utilization of
standardized policies for the expression of conditions and related
configuration actions also allows the configuration of heterogeneous
infrastructures. For this purpose we propose to use accounting
policies to configure the accounting infrastructure and use the AAA
architecture to exchange and to deploy these policies.
Zseby, Zander, Carle Expires February 2003 [Page 3]
Internet Draft Policy-based Accounting August 2002
1.2 Document Scope
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. This document describes an architecture and mechanisms
to configure the accounting service. It proposes to use the AAA
protocol for the exchange of accounting configuration information
expressed in policies. It does not propose a specific protocol for
the accounting configuration itself. The configuration itself can be
done by existing protocols (e.g. COPS-PR, SNMP, etc.). Furthermore
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 [RFC2904].
Accounting management architectures and objectives as well as the
transport of accounting records are discussed in [RFC2975] and are
not further explained here. This document concentrates on the
configuration of the accounting architecture and measurement
devices.
The policy-based accounting architecture represented in this
document describes policy-based accounting from the perspective of a
Generic AAA Server [RFC2903]. Such a server combines into a single
entity the functions of managing accounting policy, together with
the functions of managing user-specific authentication,
authorization and service provisioning. Some service providers may
choose to implement an approach that does not combine these
functions into a single entity or protocol, in which case that
particular aspect of this architecture does not apply.
This document 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/Confirmation
Accounting indication messages are pushed from the originating
AAA Server (the server where the accounting information was
generated) to the recipient which can be a AAA Server or a
customer/user application. Accounting indications contain
accounting records which describe the resource consumption for
a service. Accounting indication messages can also contain
aggregated information for multiple services. There can be
interim and end-of-session accounting indication messages.
Interim indications are delivered in specified intervals to the
recipient during the service session while end-of-session
indications are given to the recipient at the end of the
Zseby, Zander, Carle Expires February 2003 [Page 4]
Internet Draft Policy-based Accounting August 2002
session only. Accounting indications may be acknowledged by
accounting confirmations to provide application layer
reliability.
Accounting Policy Indication/Confirmation
Accounting policy indication messages contain accounting
policies and are sent from a customer/user or a AAA server to a
another AAA server. Accounting policy indications may be
acknowledged by accounting policy confirmations to provide
application layer reliability.
Accounting Request/Answer
Accounting requests are sent by a AAA server to another AAA
server to request the current accounting information for a
particular session set (polling). The request is answered with
an accounting answer which contains the accounting records.
Accounting Policy Request/Answer
Accounting policy requests are sent by a AAA server to another
AAA server or a customer/user to request accounting policies
for a service. The request is answered by an accounting policy
answer that contains the accounting policy.
Accounting Policies
Accounting policies describes rules for generation, transport
and storage of accounting data. These rules are used for the
configuration of the accounting process.
Application Specific Module (ASM)
An ASM provides the functionalities required for the user
configuration of a service to a authenticated and authorized
user. It gets application specific information (ASI)(e.g. for
user 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 [RFC2903].
Charging Scheme
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.
Classifier
This document uses the definition of classifier as given in
[RFC2475]. Since this document assumes that meters already
include classification functions, the term classifier is only
Zseby, Zander, Carle Expires February 2003 [Page 5]
Internet Draft Policy-based Accounting August 2002
used for entities that perform additional classification (e.g.
as part of data post processing).
Meter
This document uses the definition of meter as given in
[RFC2722]. This meter definition already includes the
classification of packets. With this it differs from the
DiffServ model [RFC2475] where classifier and meter are
considered as separate entities.
Meter Reader/Collector
This document uses the definition of meter reader and collector
as given in [RFC2722].
Meter Manager
This document uses the definition of meter manager as given in
[RFC2722].
Policy, policy condition, policy action
The terms policy, policy condition and policy action are used
as defined in [RFC3198].
QoS Auditing
QoS Auditing is the process of evaluating whether a given
quality of service guarantee (e.g. thresholds for QoS
parameters given in an SLA) has been met during the service
provisioning.
Service Class
A service class specifies the handling of a service (as defined
in [RFC3198]) belonging to that class by the service provider.
A service class has some kind of identifier (e.g. name) and the
handling of the service is defined by a Service Level
Specification (SLS) as described in [RFC3198].
User Configuration
We refer to User Configuration as the process of configuring a
service for a user which has been authenticated and authorized
by the AAA architecture. Although an AAA architecture is not
directly responsible for this user-dependent configuration it
may be responsible for triggering the process.
Further definitions of service related terms (Service, Service
Subscriber, Service User, Network Provider, Service Provider,
Broker) can be found in section 4 (business roles and their
relations).
3. Impact of Provider Network Characteristics on 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:
Zseby, Zander, Carle Expires February 2003 [Page 6]
Internet Draft Policy-based Accounting August 2002
- Size and Purpose
A small ISP that deals with individual customers may charge
individual users based on single flows. Backbone operators often
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 economic 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
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 need only be done 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). It is
important for providers to agree beforehand how accounting data will
be collected and monitored, and how disputes concerning accounting
data will be resolved. In order to minimize disputes between
providers it is important for them to agree that either both will
collect accounting data, and will compare it with the other's data
at regular intervals, e.g. monthly, or both will use a single source
of accounting data, provided by one of them, or by a trusted third
party.
Zseby, Zander, Carle Expires February 2003 [Page 7]
Internet Draft Policy-based Accounting August 2002
- 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. Business roles and relations
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 (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
QoS enhancement (e.g. ARQ, FEC). A transport service might also
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
Zseby, Zander, Carle Expires February 2003 [Page 8]
Internet Draft Policy-based Accounting August 2002
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 service user is 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 she is
responsible for.
- 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 provides information services on top of
transport services provided by network providers.
- 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.
Zseby, Zander, Carle Expires February 2003 [Page 9]
Internet Draft Policy-based Accounting August 2002
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
The following examples show 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 [RFC2566]. 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 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. As an alternative the content (video) can be
Zseby, Zander, Carle Expires February 2003 [Page 10]
Internet Draft Policy-based Accounting August 2002
delivered in different qualities via different transport mechanisms
by the service provider. The service provider chooses an appropriate
network provider which provides a transport service compliant with
the conditions the service provider offers to the subscribers. In
this case the service provider can use the facilities of a broker to
get a reference to appropriate network providers.
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 data from the bottom level metering via accounting up to the
final billing process. Data aggregation is not exclusively done at
the collection layer it can also be done at the other layers. The
building blocks on the different layers are configured through the
policies shown on the left side. Higher layer policies can be
translated into lower layer policies. The configuration parameters
are extracted from the policy and passed 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 large amount of captured data
makes filtering and/or aggregation after the metering necessary. In
case of a configurable meter, the meter collects meter data only for
flows specified by metering policies.
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) flow granularity (e.g. micro flows or traffic
aggregates) (c) metered flow attributes (i.e. which data is to be
collected for a specific flow), and (d) meter accuracy (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).
Collected data can be aggregated before being passed to the
accounting layer. Metering policies define how collection and
aggregation is done.
Zseby, Zander, Carle Expires February 2003 [Page 11]
Internet Draft Policy-based Accounting August 2002
POLICY CONFIGURATION BUILDING BLOCKS
+---------------+ +-------------------------+
| |------------------>| Billing |
| Billing & | +-------------------------+
| Charging | ^ charging
| | | data
| | +-------------------------+
| |------------------>| Charging |
+---------------+ +-------------------------+
| ^ acct
V | data
+---------------+ +-------------------------+
| Accounting | | |
| |------------------>| Accounting |
+---------------+ +-------------------------+
| ^ aggr. meter
V | data
+---------------+ +-------------------------+
| |------------------>| Collection |
| Metering | | |
| | +-------------------------+
| | ^ meter
| | | data
| | +-------------------------+
| |------------------>| Metering |
+---------------+ +-------------------------+
Figure 2: Reference 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. The accounting
process is configured through accounting policies.
- Charging
Charging derives non-monetary costs for accounting data sets based
on service and customer specific tariff parameters. Different cost
metrics may be applied to the same accounting records even in
parallel. Charging policies define the tariffs and parameters which
are applied.
- Billing
Billing translates costs calculated by the Charging into monetary
units and generates a final bill for the customer. Billing policies
define among others the type (e.g. invoice, credit card), the form
Zseby, Zander, Carle Expires February 2003 [Page 12]
Internet Draft Policy-based Accounting August 2002
(e.g. itemized or not, partial anyomization, etc.) of the bill and
the time for billing (e.g. weekly, monthly, etc.).
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 can be exchanged between AAA
instances at the user or provider premises. They provide a
standardized representation of configuration information that can be
converted into the appropriate settings for different elements of
the accounting infrastructures (e.g. different meters).
As shown in Figure 2 accounting policies configure the accounting
process. Policies for the configuration of the metering and
collection process can be derived from accounting policies.
Accounting policies are not used to configure the charging or billing
process. Accounting policies reside in the AAA server (local policies)
or are received from other AAA servers (extra-domain policies) or
customers/users. Two different models of obtaining accounting
policies can be differentiated: push and pull model.
Push Model
In the push model accounting policies are pushed from another AAA
server or customer/user in order to establish the policies in the
local accounting infrastructure. The acceptance and use of pushed
policies requires special security considerations. The evaluation of
the policy should not take place without an appropriate security
check of the policy in advance. Also the evaluation of the condition
can lead to unwanted actions in the AAA server if the condition
contains critical data either intentionally (to attack the system)
or by accident. Even the evaluation of the condition can cause
problems (e.g. DoS). Therefore not only the action but also the
condition has to be checked for potential security hazards before it
is evaluated.
Pull Model
In the pull model the AAA server requests the policy from a remote
AAA server or customer/user by sending an accounting policy request.
The remote AAA server sends an accounting policy reply as an answer
that contains the appropriate policy.
Accounting policies are enforced by the network elements that are
configured in accordance with the policies. They influence the
following settings in the accounting architecture:
- meter configuration
- data collection and aggregation
- accounting record distribution and storage
Zseby, Zander, Carle Expires February 2003 [Page 13]
Internet Draft Policy-based Accounting August 2002
6.1 Accounting Policy Condition
An accounting policy consists one or more rules each having a
condition part and an action part. The condition part expresses
under which condition the policy should be enforced. The following
attributes are examples for variables in a policy condition
statement.
- customer/user ID
The customer/user ID identifies the customer or user of the service.
It can be used in a policy condition in order to select an customer
or user specific accounting configuration (as policy action). For
example it can be user-dependent whether accounting indications are
sent to the user or not.
- IP address
IP addresses specifies the devices or networks from which the
service usage takes place. The address of specific hosts or subnets
can be used to select accounting strategies specific to the customer
or a user group associated with this address. (e.g. all customers of
an ISP, all public terminals etc.).
- time of day
The time of day can be used for instance to configure the level of
detail for the accounting record, the report interval and
destination.
- service class
Service classes are defined by the provider. They describe different
levels or different kinds of services that are offered by the
provider and are usually defined based on a business model.
Customers/users select a service class. This selected class can be
used in accounting policies to define appropriate accounting
settings per class. With this it is possible for instance to provide
more detailed accounting records for higher prioritized services
than for standard services.
- accounting type
Accounting types combine multiple accounting settings under one
keyword. Like service classes, the offered accounting types are
defined by the provider in accordance to the business model. With
this providers can offer for instance different accounting types for
one service and allow the customer/user to select one. The
combination of settings under one keyword simplify the selection for
users. For instance the combination of high granular accounting
records with short report intervals under a keyword (e.g.
"comprehensive accounting") or less frequent generation of less
detailed records accessed by another keyword ("standard
accounting"). The definition of accounting types can also help in
inter-domain scenarios if providers agree on accounting types.
Zseby, Zander, Carle Expires February 2003 [Page 14]
Internet Draft Policy-based Accounting August 2002
6.2 Accounting Policy Action
The action part defines the action that takes place if the condition
is true. The action for an accounting policy is usually the
configuration of the accounting infrastructure. This can already
include settings for meters and collection entities. The following
list gives examples for parameters of the accounting infrastructure
that can be configured by an accounting policy action:
- 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
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 [RFC2924].
- 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 ensure that unauthorized
entities cannot get access to confidential data.
- report interval
The report 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.
- flow granularity
The flow granularity determines how fine grained (in coverage) the
flows in the network are measured. The granularity usually is
configured by installing specific classification rules in the meter.
It is also possible to set a specific granularity by configuring
aggregation schemes that are applied after the metering process. The
granularity can range from individual micro flows(e.g. determined by
the quintuple <src, dest, proto, src-port, dest-port>) up to coarse
granular traffic aggregates (e.g. all traffic from one network)
Zseby, Zander, Carle Expires February 2003 [Page 15]
Internet Draft Policy-based Accounting August 2002
- meter accuracy
The parameters for the meter accuracy can determine for instance how
often measurements take place at the meter, how accurate timestamps
should be, etc. Meter accuracy parameters can also be used to
configure sampling schemes.
6.3 Example for Meter Configuration
The following two examples show how accounting policies can be used
to configure different meters. 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 the meter NeTraMet [RFC2123] 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.
+------------------+
| AAA |
| |
+------------------+
| ^
Policy | | Accounting Records
V |
+------------------+
| ASM |
| |
+------------------+
| ^
| |
| config +-----------------+
| |
+-------------------------------+ |
| | Accounting | |
| V | |
| +----------------+ | |
| | Meter Manager | | | Accounting Records
| +----------------+ | |
| | | | |
| SNMP V | |
| (conf)+---------------+ | |
| | | Meter Reader |---------+
| | +---------------+ |
| | ^ |
| V | |
| +-----------+ | |
| | Meter |-----+ |
| +-----------+ SNMP(DATA) |
| |
+-------------------------------+
Figure 3: Policy based Accounting with NeTraMet
Zseby, Zander, Carle Expires February 2003 [Page 16]
Internet Draft Policy-based Accounting August 2002
If the meter NetFlow [NetFlow] is used, 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.
+------------------+
| AAA |
| |
+------------------+
| ^
Policy | | Accounting Records
V |
+------------------+
| ASM |
| |
+------------------+
| ^
| |
| config | Accounting Records
| |
+-------------------------------+
| | Accounting |
| | |
| | +---------------------+ |
| | | Flow Collector | |
| | | +------------+ | |
| | | | Classifier | | |
| | | | Aggregator | | |
| +->| +------------+ | |
| +---------------------+ |
| ^ |
| | |
| +-----------+ | |
| | Meter |-----+ |
| +-----------+ UDP (DATA) |
| |
+-------------------------------+
Figure 4: Policy based Accounting with NetFlow
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.
7.1 Integrated Accounting
In the integrated accounting model 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 specific service and might collect accounting information by
Zseby, Zander, Carle Expires February 2003 [Page 17]
Internet Draft Policy-based Accounting August 2002
directly exploiting some service specific entities. 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 user configuration of the service equipment.
Accounting policies are defined as part of the contractual
agreement. The ASM converts the instructions from the AAA server
into the appropriate user configuration including settings for the
accounting architecture.
+---------------------+
<---1--->| Generic AAA Server |<---1--->
| | ............
| Rule based engine |<----|----->: Policy :
| | 3| :..........:
+---------------------+<----|--+ ............
^ +-->: Events :
| :..........:
2
|
V
+----------------------+ ...............
| Application specific |<--3-->: Acct Policy :
| Module | :.............:
+----------------------+
^
|
5
|
V
+-------------------------------------+
| Service |
| +-----------+ +----------------+ | ..............
| | Service |<-->| Accounting/ |<--3-->: Accounting :
| | Provision | | Metering | | : Data :
| +-----------+ +----------------+ | :............:
+-------------------------------------+
Figure 5: AAA Server with Integrated Accounting
Data about the resource consumption is sent back to the AAA server
via the ASM. The accounting process within the service converts the
metered data into accounting records which are sent to the AAA
server. For generating accounting records data conversion,
aggregation and filtering of data might be performed.
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. In this
case the accounting does not have to be coupled to a specific
service. Discrete Accounting can be used for outsourcing the
accounting task. The accounting service can be provided by a general
accounting system which is able to account for different services.
Zseby, Zander, Carle Expires February 2003 [Page 18]
Internet Draft Policy-based Accounting August 2002
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. Accounting is offered just like
any other service. This means authentication and authorization might
be required prior to the accounting service provisioning.
Furthermore it is important that the involved parties agree
beforehand how the accounting service is provided, what parameters
can be set and how disputes will be resolved. After the accounting
service has been configured the AAA server can do the user
configuration of the service.
+---------------------+
<---1--->| Generic AAA Server |<---1--->
| | ............
| Rule based engine |<----|----->: Policy :
| | 3| :..........:
+---------------------+<----|--+ ............
^ ^ +-->: Events :
| | :..........:
2 2
| |
V V
+-------------+ +--------------+ ...............
| Application | | Application |<--3-->: Acct Policy :
| Specific | | Specific | :.............:
| Module | | Module |
+-------------+ +--------------+
^ ^
| |
5 5
| |
V V
+-------------+ +---------------+ ..............
| Service | | Accounting/ |<--3-->: Accounting :
| | | Metering | : Data :
+-------------+ +---------------+ :............:
Figure 6: AAA Server with Discrete Accounting
A service provider that has outsourced the accounting service has to
request this service from an accounting service provider.
The generated accounting records are send from the accounting
provider to the service provider who may make modifications to the
records before sending them to the final destination. Having such a
general accounting service might speed up the creation of new
services - especially specialized content services - in the
Internet. This separation is also beneficial to support special
accounting services (e.g. sending accounting indications to users)
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).
Zseby, Zander, Carle Expires February 2003 [Page 19]
Internet Draft Policy-based Accounting August 2002
Another option is to outsource only the metering service. The meter
service provider generates meter data and sends them to the service
provider who has requested them. The service provider then generates
accounting records based on the received meter data. A separate
accounting or metering service provider can be used to validate the
accounting data generated by a service provider. If the customer
does not trust a service provider, or in the case of a legal action,
a trusted accounting or metering provider is able to validate the
correctness of the accounting data generated by the service
provider.
7.3 Intra-Domain Accounting
In Intra-Domain accounting [RFC2975] 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.
+-------------+
| Billing |
+-------------+
^
|
+-------------+
| ASM |
+-------------+
^
| ..............
+--------------+ : Accounting :
| AAA |<--->: Policies :
+--------------+ :............:
| ^
| |
V |
+--------------+
| ASM |
+--------------+
| ^
config | | Accounting Records
V |
+------------+ +-----------|----------+
| | Service usage | +--------+-------+ |
| End System |-------------->| | Accounting | |
| | | +----------------+ |
+------------+ | |
| Service |
+----------------------+
User Provider
Figure 7: Intra-Domain Accounting
Zseby, Zander, Carle Expires February 2003 [Page 20]
Internet Draft Policy-based Accounting August 2002
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
[RFC2002] 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 as shown in the figure below.
| +-----------+
| | Billing |
| +-----------+
| ^
| |
| +-----------+
| | ASM |
| +-----------+
| ^
| |
+------------------+ 1. AccPolInd +-----------+
| |<-------------| |
| | | | |
| AAAF | 2.AccPolConf | AAAH |
| |------------->| |
| | | | |
| | 3. AccRec | |
| |------------->| |
+------------------+ | +-----------+
config | ^ | ^
| | | |
V | | V
+--------------+ | .............
| ASM | | : Acct. :
+--------------+ | : Policies :
| ^ | :...........:
| | |
| | Acct. Records |
Service V | |
+------------+ usage +-----------|----------+ |
| | | +--------+-------+ | |
| End System |------>| | Accounting | | |
| | | +----------------+ | |
+------------+ | | |
| Service | |
+----------------------+ |
User Foreign-Provider Home-Provider
Figure 8: Inter-Domain Accounting (Roaming Example)
Zseby, Zander, Carle Expires February 2003 [Page 21]
Internet Draft Policy-based Accounting August 2002
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 indication to the foreign AAA server. The indication contains
the accounting policy. Instead of sending an indication the
accounting policies could also be piggybacked onto an authorization
reply. If the foreign AAA server is able to configure devices in a
way to enforce the desired policy (e.g. the meters are capable of
metering the requested attributes) the accounting policy indication
is acknowledged. 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 of measuring 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.
8. Accounting with different Authorization Models
The AAA authorization framework [RFC2904] 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.
8.1 Agent Sequence
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 user configuration of
the service equipment (messages 2 and 3 in Figure 9). User-specific
configuration of 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).
Zseby, Zander, Carle Expires February 2003 [Page 22]
Internet Draft Policy-based Accounting August 2002
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 4 | +-------------------+ |
| User | | | ^ ^ |
| | | |2 |3 |AcctRec |
| | | V | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
+------+ | |
+-------------------------+
Figure 9: Accounting and Agent Sequence
In the agent sequence it is possible to allow the user to send
accounting policies (e.g. for accounting indications) together with
the authorization request to the AAA server. Figure 9 shows the
agent sequence authorization and accounting messages.
8.2 Pull Sequence
The configuration of the accounting infrastructure can be done
similar to the agent sequence during the user configuration 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 indications from users.
+-------------------------+
+------+ | Service Provider |
| |AccPolInd +-------------------+ |
| |.........>| AAA Server | |
| |<.........| | |
| | | +-------------------+ |
| User | | ^ | ^ |
| | | |2 |3 |AcctRec |
| | | | V | |
| | 1 | +-------------------+ |
| |-------+->| Service | |
| |<------+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Figure 10: Accounting and Pull Sequence
This can be for instance achieved by a hybrid model of agent and
pull sequence where the user sends an accounting policy indication
Zseby, Zander, Carle Expires February 2003 [Page 23]
Internet Draft Policy-based Accounting August 2002
to the AAA server in addition to the messages exchange for the pull
sequence. Figure 10 shows the pull sequence authorization and
accounting messages.
8.3 Push Sequence
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 (message 3 in Figure 11) contains information about
the accounting policies 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.
Figure 11 shows push sequence authorization and accounting messages.
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 2 | +-------------------+ |
| User | | ^ |
| | | | AcctRec |
| | | | |
| | 3 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Figure 11: Accounting and Push Sequence
8.4 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
Zseby, Zander, Carle Expires February 2003 [Page 24]
Internet Draft Policy-based Accounting August 2002
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 9.2. This
scenario requires a prior agreement between the involved providers
about the possible policies and parameters that are allowed to be
set by others.
9. Examples
The following examples illustrate the use of policy-based
accounting. Please note that also the services used in the examples
are used only for illustration purposes and their use in reality
requires different messages and parameters.
9.1 Printing Service Example
The Internet Printing Protocol (IPP) [RFC2566], 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.
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 [RFC2905].
9.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
Zseby, Zander, Carle Expires February 2003 [Page 25]
Internet Draft Policy-based Accounting August 2002
service of a network provider is used. In this case the AAA Server
of the provider controls the access to the file and the print
server. This means the AAA server enforces the accounting policies
and collects accounting data for both servers.
9.1.2 Inter-Domain Accounting
If two different organizations are involved there are two
possibilities for trust relationships as shown in [RFC2905]:
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 which is shown in Figure 12 the accounting
policies from the user arrive at the print service AAA server.
USER DOMAIN PRINT SERVICE DOMAIN FILE SERVICE DOMAIN
| |
+------+ | |
| | | |
| | | |
| | | +--------------------+ | +-------------------+
| User |---1-->| Print Service |---1-->| File Service |
| |<--2---| AAA Server |<--2---| AAA Server |
| | | +--------------------+ | +-------------------+
| | | | Print Server | | | File Server |
| | | | and Printer | | | |
+------+ | +--------------------+ | +-------------------+
1: AccPolInd, 2: AccPolConf
Figure 12: Inter-Domain Accounting and Printing Service
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 passes it to the print service. The print service generates the
final accounting record for the service session based on its 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
used for later authorization decisions based on used resources i.e.
if the customer is a company and the user is an employee.
Zseby, Zander, Carle Expires February 2003 [Page 26]
Internet Draft Policy-based Accounting August 2002
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 sent 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 could be coupled via a session ID) and
policies that define which activities a certain session is composed
of.
9.1.3 User Accounting Indication
For the printing service there are a number of possible options for
sending accounting indications to the user. Accounting indications
give the user an indication of how much resources have been used
until the time of the indication. A user can receive accounting
indications or not depending on the accounting 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
the user has no idea of the costs of the service usage. If user and
subscriber are a single entity, accounting indications would help
users to avoid exceeding their spending limit. Additionally
accounting indications give the user a hint which 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.
9.2 Mobile/Roaming Example
In this section the "Dial-in with Roaming" example from the
authorization examples [RFC2905] [RFC2002] is used to show how
accounting functions could interact with authorization functions.
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 basic configuration of the accounting
modules is 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.
Zseby, Zander, Carle Expires February 2003 [Page 27]
Internet Draft Policy-based Accounting August 2002
User | Visited ISP | Home ISP
| |
| | +-----------+ ..........
<--------------------12-------------------| Charging, |<-:charging:
| | | Billing | :policies:
| | +-----------+ :........:
| | ^
| | |
| | +-----------+
| | | ASM |
| | +-----------+
| | ^
| | |11
| | |
| +------------+ | +-------------+
| | | | | |
| | |---10---->| |
| | | | | |
Acct. Records | AAAF Server|----3---->| AAAH Server |
<-----------------| |<---4-----| |
| | | | | |
| | | | | |
| +------------+ | +-------------+
| ^ | ^ |
| | | | |
| | 5 9 |
| | | | |
| | V | |
| | +----------------+|
| | | ASM ||
| 2 | ||
| | +----------------+|
| | | ^ |
| | | | |
| | 6 8 |
| | | | |
| +------------+------+-------+ |
7 | | Service | | | |
<--------| Equipment | +----------+| |
1 | | |->|Accounting|| |
-------->| | +----------+| |
| | config | | | |
| | | +---------+ | |
| | +->| Meters | | |
| | +---------+ | |
| +---------------------------+ |
| |
Figure 13: Roaming Example
The exchange of authorization data corresponds to the example in
[RFC2905]. As an additional component we introduce an ASM between
home AAA and service equipment for the user configuration which
Zseby, Zander, Carle Expires February 2003 [Page 28]
Internet Draft Policy-based Accounting August 2002
happens after successful authorization. The extended roaming example
is shown in Figure 13. 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) user specific service parameters are given to the visited ISP's
AAA server and are forwarded to the service equipment (5) where the
user configuration is done. The user-specific 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 Y has to be generated every 30 seconds "
This accounting policy is used by the visited ISP to configure his
modules (e.g. metering, data collection).
User-dependent 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.3 Diffserv Example
This example explains how integrated accounting is configured via
policies for a Diffserv service [RFC2475] based on bandwidth brokers
[I2-BB]. The service is the transport of packets with a higher
priority and the service includes accounting and QoS auditing.
Figure 14 shows the service setup. The user issues a Service Request
(SR) for a Diffserv service to the AAA server. The request contains
a user ID and the parameter for the desired service class.
User->AAA: user-x@nw-a, service=diffserv, class=gold,
amount=2Mbit, dest= nw-b
In this example user-x is located at network A (nw-a) and requests a
gold class service for all flows from this network to the
destination network B (nw-b). After authentication and authorization
has completed successfully, the AAA server extracts the Application
Specific Information (ASI) from the request and passes them to the
ASM of the Diffserv service.
AAA->ASM: service=diffserv, class=gold, amount=2Mbit, src=nw-a
dest=nw-b
Zseby, Zander, Carle Expires February 2003 [Page 29]
Internet Draft Policy-based Accounting August 2002
The ASM takes over the task of translating the application specific
information into appropriate user configuration information for the
service equipment. For the given Diffserv example the service
equipment consists of three components: accounting equipment, the
QoS auditing equipment and the bandwidth broker architecture. The
ASM has to address all three components to set up the requested
service for the user. The translation of the ASI into configuration
information for the components can be done by evaluating service
provisioning policies. For example the ASM could have the following
service provisioning policy:
if class==gold {
set bw-request.class = gold
set accounting.type = comprehensive
set qos-audit.metric = one-way-delay
...
}
This results in sending a bandwidth request to the BB which asks for
a gold service with the given parameters. Furthermore the ASM issues
a request to the accounting equipment for comprehensive accounting
and a request to the QoS auditing equipment for a one-way-delay
measurement between the given networks.
ASM->BB: BW-request(gold, src=nw-a, dest=nw-b, amount=2Mbit)
ASM->Acct: Acct-request(comprehensive, src=nw-a)
ASM->QoS: QoS-audit-request(one-way-delay, src=nw-a, dest=nw-b)
The bandwidth broker then sets up the Diffserv infrastructure to
provide the prioritized forwarding according to the definition of a
gold class. This is done in accordance with the actual bandwidth
broker's architecture and not further considered here. For the
Accounting Configuration and the QoS Audit Control local
configuration policies exist for setting up the service.
Accounting-Policy:
if type==comprehensive {
set meter-location = access-point(nw-a)
set record type =detailed
set report interval = 120 s
set report target = 193.175.12.8
}
QoS-Measurement-Policy:
if metric==one-way-delay {
set method = passive
set timestampsize = 48 bit
set ingress-meter-location = access-point(nw-a)
set egress-meter-location = access-point(nw-b)
}
Zseby, Zander, Carle Expires February 2003 [Page 30]
Internet Draft Policy-based Accounting August 2002
In this case the local accounting policy sets the meter location to
the network access point of network A. It states that for a
comprehensive accounting a detailed record type is required with an
report interval of 120 s. The resulting records have to be sent to
the given report target. The QoS measurement policy sets the
measurement method to passive measurement. It sets the size used for
timestamp representation to 48 bit. As meter locations the meters at
the access points of network A and network B are used.
After evaluating these policies the instructions for the meter
configuration are passed down to the measurement infrastructure. In
our example the accounting configuration instructs the meter at the
first measurement point (MP1) to add a new rule with the given flow
attributes and settings for storage and reporting of results.
Acct->MI: MP1: add rule dscp=23, src=a.a.a/24, dest=b.b.b.b/24
save volume
set report interval = 120 s
set report target = 193.175.12.8
SR +-------+
User ----------------->| AAA |
+-------+
|
| ASI
V
+-------+
+-----------------| ASM |--------------+--------------+
| Policy +-------+ Policy | BW Request |
| Parameters Parameters | |
| | |
-----|----------------------------------------|--------------|-----
| Service Equipment | |
V V V
+---------------+ .............. +-----------+ +-----------+
| Accounting |<-->: Local :<-->| QoS | | Bandwidth |
| | : Policies : | Auditing | | Broker |
+---------------+ :............: +-----------+ +-----------+
| |
| Meter Instructions | Measurement Setup
V V
+--------------------------------------------------+
| Measurement |
| Infrastructure |
+--------------------------------------------------+
Figure 14: Diffserv Service Provision Setup
Zseby, Zander, Carle Expires February 2003 [Page 31]
Internet Draft Policy-based Accounting August 2002
The QoS audit control instructs two meters (at MP1 and MP2) to set
up a passive one-way-delay measurement.
QoS->MI: MP1: add rule dscp=23, src=a.a.a.a/24 dest=b.b.b.b/24,
save timestamp-48
MP2: add rule dscp=23, src=a.a.a.a/24, dest=b.b.b.b/24,
save timestamp-48
9.4 User Accounting Indication Example
This example explains how discrete accounting can be used to provide
accounting indications for the user. Accounting indications are sent
to the user in order to inform the user about the current resource
consumption. 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. Therefore the accounting here is seen as a
separate service. That means the accounting service is independent
of the main service and therefore can be applied to different
services. It might be used as an addition to an integrated
accounting that is part of the service. The authorization process
for the accounting service is out of the scope of this document and
therefore not further explained here.
Figure 15 illustrates the configuration message sequence for setting
up the accounting service. First the user sends an Accounting
Service Request (ASR) to the AAA server which includes desired
parameters for the provisioning of the accounting service (e.g.
report interval).
user->AAA: user-x@nw-a, service= accounting indications,
report interval= 60 s
The AAA server passes the Application Specific Information (ASI) to
the ASM of the accounting service after the user has been
authenticated and authorized for the service usage.
AAA->ASM: user-x@nw-a, service=accounting indications,
report interval= 60 s
The ASM generates an accounting policy based on the ASI and passes
this policy to the Accounting Configuration.
ASM->Acct: If src=a.a.a.x {
acc-indication = on
report interval = 60s
report target= a.a.a.x
}
Zseby, Zander, Carle Expires February 2003 [Page 32]
Internet Draft Policy-based Accounting August 2002
ASR +-------+
User --------------->| AAA |
+-------+
|
| ASI
V
+-------+
| ASM |
+-------+
|
-------------------------|---------------------------
Service Equipment | Accounting Policy
V
+-----------------+ ..............
| Accounting |<---->: Local Acct :
| | : Policies :
+-----------------+ :............:
|
| Meter Instructions
V
+-----------------+
| Measurement |
| Infrastructure |
+-----------------+
Figure 15: Accounting Indication Configuration
The Accounting Configuration generates meter instructions according
to the accounting policies from the ASM and local accounting
policies and passes them to the measurement infrastructure.
local Acct-Policy: if acc-indication {
record type = compact
}
Acct->MI: MP1: set report interval = 60 s
add report target = a.a.a.x
10. Security Considerations
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 introduce potential security hazards.
Zseby, Zander, Carle Expires February 2003 [Page 33]
Internet Draft Policy-based Accounting August 2002
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 of
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 accounted for, 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 may lead to erroneous bills. Furthermore it is
important that policies or accounting records are not redirected or
removed, and that forged policies or records are not inserted.
- Eavesdropping
It may be required 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. Especially if multiple services use one AAA server an
attack to the server can be worse than an attack to the service
equipment itself. 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.
- Protection of the integrity of accounting policies and 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.
- Verify correctness of generated accounting data
It must be ensured that the accounting data generated by the service
provider is correct. A provider may generate incorrect accounting
records either deliberately (i.e. forging) or unintentionally (e.g.
faulty configuration). These incorrect accounting records probably
Zseby, Zander, Carle Expires February 2003 [Page 34]
Internet Draft Policy-based Accounting August 2002
have the consequence of incorrect bills. Customers can verify the
correctness of the accounting data through their measurements and/or
through data collected by a trusted third party. A trusted third
party can be an independent accounting service provider as described
in section 7.2 or a more general entity providing an auditing
service.
- Prevention and protection against Denial of Service attacks
The AAA protocol and all building blocks should be designed and
implemented in a way as resistant as possible to denial of service
attacks. An additional strategy to defend against DoS attacks is to
add a component to the meter system that is able to detect
suspicious traffic patterns. Upon detection further actions can be
taken according to a pre-defined policy.
The prevention of these hazards has to be considered for the
protocols used for accounting policy exchange and the transportation
of accounting records. Since the security requirements for
authentication, transmission level security, data object
confidentiality and integrity are addressed in the criteria for AAA
protocol evaluation [RFC2989] 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. Real prevention of DoS
attacks is quite difficult. A selective dropping of the attackers
packets is impossible, if the malicious packets cannot be separated
from the valid customer traffic. Dropping of all packets of a
certain type may prevent authorized customers from using the service
and therefore help the attacker to achieve her goal.
11. References
[I2-BB] Internet2-QBone Bandwidth Broker,
http://www.merit.edu/working.groups/i2-qbone-bb
[NetFlow] NetFlow Services and Applications, White Paper, Cisco
Systems, 1999
[RFC2002] C. Perkins: "IP Mobility Support", Standards Track RFC
2002, October 1996
[RFC2123] N. Brownlee: "Traffic Flow Measurement: Experiences with
NeTraMet", Informational RFC 2123, March 1997
[RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W.
Weiss, "An Architecture for Differentiated Services",
Informational RFC 2475, December 1998
[RFC2566] Roger deBry, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, April 1999.
[RFC2722] N. Brownlee, C. Mills, G. Ruth, "Traffic Flow
Measurement: Architecture", Informational RFC 2722,
October 1999
[RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D.
Spence, "Generic AAA Architecture", Experimental RFC
2903, August 2000.
Zseby, Zander, Carle Expires February 2003 [Page 35]
Internet Draft Policy-based Accounting August 2002
[RFC2904] J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G.
Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence,
"AAA Authorization Framework", Informational RFC 2904,
August 2000.
[RFC2905] J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G.
Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence,
et al., "AAA Authorization Application Examples",
Informational RFC 2905, August 2000.
[RFC2924] Nevil Brownlee, Alan Blount, "Accounting Attributes and
Record Formats", Informational RFC 2924, September 2000.
[RFC2975] Bernard Aboba, Jari Arkko, David Harrington,
"Introduction to Accounting Management", Informational
RFC 2975, October 2000.
[RFC2989] Bernard Aboba, et al., "Criteria for Evaluating AAA
Protocols for Network Access", Informational RFC 2989,
November 2000.
[RFC3198] A. Westerinen, J. Schnizlein, J. Strassner, M.
Scherling, B. Quinn, S. Herzog, A. Huynh, M. Carlson, J.
Perry, S. Waldbusser: "Terminology for Policy-Based
Management", Informational RFC3198, November 2001
12. Acknowledgments
The authors would like to thank the members of the AAAARCH research
group and in particular the chairs, John Vollbrecht and Cees de Laat,
for the fruitful discussions and comments. Special thanks are to
Bernard Aboba, Nevil Brownlee and Ed Ellesson for their review and
valuable input to this document.
13. Author's Addresses
Tanja Zseby
Fraunhofer Institute for Open Communication Systems
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone: +49-30-34 63 7153
Fax: +49-30-34 53 8153
Email: zseby@fokus.fhg.de
Sebastian Zander
Fraunhofer Institute for Open Communication Systems
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone: +49-30-34 63 7287
Fax: +49-30-34 63 8287
Email: zander@fokus.fhg.de
Georg Carle
Fraunhofer Institute for Open Communication Systems
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Zseby, Zander, Carle Expires February 2003 [Page 36]
Internet Draft Policy-based Accounting August 2002
Phone: +49-30-34 63 7149
Fax: +49-30-34 63 8149
Email: carle@fokus.fhg.de
14. Full Copyright Statement
Copyright (C) The Internet Society (2002). 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.
Zseby, Zander, Carle Expires February 2003 [Page 37]
| PAFTECH AB 2003-2026 | 2026-04-22 15:30:38 |