G. Carle Internet Draft S. Zander Document: <draft-irtf-aaaarch-pol-acct-01.txt> T. Zseby Category: Informational GMD FOKUS November 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. Internet Draft Policy-based Accounting November 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 .........................9 6. Accounting Policies ........................................11 7. Accounting Services ........................................14 7.1 Integrated Accounting ......................................14 7.2 Discrete Accounting ........................................15 7.3 Intra-Domain Accounting ....................................17 7.4 Inter-Domain Accounting ....................................17 7.5 Accounting Indication ......................................19 7.6 Integration of Accounting Services in Authorization Model ..20 7.6.1 Agent Sequence .............................................20 7.6.2 Pull Sequence ..............................................20 7.6.3 Push Sequence ..............................................21 7.7 Roaming ....................................................21 8. Examples ...................................................21 8.1 Printing Service Example ...................................21 8.1.1 Intra-Domain Accounting ....................................22 8.1.2 Inter-Domain Accounting ....................................22 8.1.3 Accounting/Charging Indication .............................23 8.2 Mobile/Roaming Example .....................................24 8.3 Diffserv Example ...........................................25 8.4 Accounting Indication Example ..............................28 9. Security Considerations ....................................30 10. References .................................................31 11. Acknowledgments ............................................32 12. Author's Addresses .........................................32 13. Full Copyright Statement ...................................33 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] and not further Internet Draft Policy-based Accounting November 2000 explained here. This document concentrates on the configuration of the accounting architecture and measurement devices. 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 with 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. 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 [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 only. 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. Internet Draft Policy-based Accounting November 2000 Application Specific Module (ASM) An ASM provides the functionalities required by a specific application for the provisioning of a service. 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]. 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 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. 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. 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 Internet Draft Policy-based Accounting November 2000 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 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 Internet Draft Policy-based Accounting November 2000 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 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 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 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 Internet Draft Policy-based Accounting November 2000 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. Figure 1 depicts the different roles and the business relations between them. Internet Draft Policy-based Accounting November 2000 +----+ 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 [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 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. Internet Draft Policy-based Accounting November 2000 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 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 Internet Draft Policy-based Accounting November 2000 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. Internet Draft Policy-based Accounting November 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. Internet Draft Policy-based Accounting November 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. Internet Draft Policy-based Accounting November 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 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]. Internet Draft Policy-based Accounting November 2000 - 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. - 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. 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. 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 Internet Draft Policy-based Accounting November 2000 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 |<--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 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. 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. Internet Draft Policy-based Accounting November 2000 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 service provisioning. A service provider that has outsourced the accounting service has to request the accounting 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 customer. 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 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 | | 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 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 Internet Draft Policy-based Accounting November 2000 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 should be able to validate the correctness of the accounting data generated by the service provider. 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. +-----------+ | 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 Internet Draft Policy-based Accounting November 2000 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. | +-----------+ | | 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 Internet Draft Policy-based Accounting November 2000 requested attributes) the accounting policy request 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 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 Internet Draft Policy-based Accounting November 2000 In order to request an accounting indication a user or customer sends an accounting policy request to the responsible AAA server. 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. Internet Draft Policy-based Accounting November 2000 7.6.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 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. Internet Draft Policy-based Accounting November 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 Internet Draft Policy-based Accounting November 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 could be coupled via a 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 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 charging indications would help the user to avoid exceeding his spending limit. Additional accounting Internet Draft Policy-based Accounting November 2000 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 | | | | | +---------+ | | | +---------------------------+ | | | Figure 11: Roaming Example Internet Draft Policy-based Accounting November 2000 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. 8.3 Diffserv Example This example explains how integrated accounting is configured via policies for a Diffserv service. The service is the transport of packets with a higher priority and the service includes accounting and QoS auditing. Figure 12 shows the service setup. The user issues a Service Request (SR) for a Diffserv service to the AAA server. The Internet Draft Policy-based Accounting November 2000 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 The ASM takes over the task of translating the application specific information into appropriate 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. The translation of the ASI into configuration information for the components can be done by evaluating service provisioning policies. As 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. This is done in accordance to the used bandwidth broker architecture and not further considered here. For the Accounting Configuration and the QoS Audit Control local configuration policies exists for setting up the service. Internet Draft Policy-based Accounting November 2000 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 = 16 bit set ingress-meter-location = access-point(nw-a) set egress-meter-location = access-point(nw-b) } 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 ms. 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 16 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 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-16 MP2: add rule dscp=23, src=a.a.a.a/24, dest=b.b.b.b/24, save timestamp-16 Internet Draft Policy-based Accounting November 2000 SR +-------+ User ----------------->| AAA | +-------+ | | ASI V +-------+ +-----------------| ASM |--------------+--------------+ | Policy +-------+ Policy | BW Request | | Parameters Parameters | | | | | -----|----------------------------------------|--------------|----- | Service Equipment | | V V V +---------------+ .............. +-----------+ +-----------+ | Accounting |<-->: Local :<-->| QoS Audit | | Bandwidth | | Configuration | : Policies : | Control | | Broker | +---------------+ :............: +-----------+ +-----------+ | | | Meter Instructions | Measurement Setup V V +--------------------------------------------------+ | Measurement | | Infrastructure | +--------------------------------------------------+ Figure 12: Diffserv Service Provision Setup 8.4 Accounting Indication Example This example explains how discrete accounting can be used to provide accounting indications. Accounting indications are accounting records sent to the user in order to inform the user about the current resource consumption. 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 standard accounting that is part of the service. Like other services, an accounting service has to be authorized prior to the service provisioning. The authorization process is out of the scope of this document and therefore not further explained here. Figure 13 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 Internet Draft Policy-based Accounting November 2000 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 } ASR +-------+ User --------------->| AAA | +-------+ | | ASI V +-------+ | ASM | +-------+ | -------------------------|--------------------------- Service Equipment | Accounting Policy V +-----------------+ .............. | Accounting |<---->: Local Acct : | Configuration | : Policies : +-----------------+ :............: | | Meter Instructions V +-----------------+ | Measurement | | Infrastructure | +-----------------+ Figure 13: 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 } Internet Draft Policy-based Accounting November 2000 Acct->MI: MP1: set report interval = 60 s add report target = a.a.a.x 9. 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 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. 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 Internet Draft Policy-based Accounting November 2000 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 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. - 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 have the consequence of incorrect bills. A customer can verify the correctness of the accounting data through own 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 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] 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. Internet Draft Policy-based Accounting November 2000 [2] Bernard Aboba, Jari Arkko, David Harrington, "Introduction to Accounting Management", Informational RFC 2975, October 2000. [3] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence, "Generic AAA Architecture", Experimental RFC 2903, August 2000. [4] Roger deBry, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999. [5] Nevil Brownlee, Alan Blount, "Accounting Attributes and Record Formats", Informational RFC 2924, September 2000. [6] 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. [7] Bernard Aboba, et al, "Criteria for Evaluating AAA Protocols for Network Access, draft-ietf-aaa-na-reqts-07.txt, Work in Progress, August 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 Internet Draft Policy-based Accounting November 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.