RFC 3334
Policy-Based Accounting
Policy-Based Accounting 💖
RFC 3334 🎀 bestie, this one is an Experimental doc, not a standard, so it's basically the authors saying "here's an idea, try it, tell us what you think" 🧪✨. It's from October 2002, and the authors are T. Zseby, S. Zander, and G. Carle, all from Fraunhofer FOKUS 👑. The title block doesn't list anything it obsoletes or updates, so it's just vibing on its own 🦋.
Status of this Memo
This memo defines an Experimental Protocol for the Internet community 🧪. It's not an Internet standard of any kind, obviously 💅. The authors are asking for discussion and suggestions for improvement, so if you have thoughts, speak up 🗣️. Distribution of this memo is unlimited 🌈.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. 📜
Abstract
Okay so this doc is about policy-based accounting, which is a way to make accounting architectures way more flexible 🌸. Accounting policies describe how an accounting architecture gets configured, but in a standardized way, so everyone's speaking the same language 🗣️✨. Those policies are what actually instrument the architecture, and they can be passed between Authentication, Authorization and Accounting (AAA) entities so everyone shares config info 🔥.
The doc walks through the building blocks and message sequences for policy-based accounting in the generic AAA architecture (RFC 2903) 🧩. There are examples of using accounting policies in different scenarios, which is honestly the best part 🍓. It also shows how accounting components fit into the AAA authorization framework (RFC 2904) 💜. What it does not do is propose a language for describing accounting policies 🙈. The vibe is "just pick a suitable policy language from existing or upcoming standards" 💅.
Table of Contents ✨
1. Introduction...............................................2
1.1 Motivation.................................................2
1.2 Document Scope.............................................3
2. Terminology................................................4
3. Impact of Provider Network Characteristics on Accounting...7
4. Business roles and relations...............................8
5. Reference Model and Building Blocks.......................11
6. Accounting Policies.......................................14
6.1 Accounting Policy Condition...............................15
6.2 Accounting Policy Action..................................16
6.3 Example for Meter Configuration...........................17
7. Accounting Services.......................................19
7.1 Integrated Accounting.....................................19
7.2 Discrete Accounting.......................................21
7.3 Intra-Domain Accounting...................................22
7.4 Inter-Domain Accounting...................................23
8. Accounting with different Authorization Models............25
8.1 Agent Sequence............................................25
8.2 Pull Sequence.............................................26
8.3 Push Sequence.............................................27
8.4 Roaming...................................................28
9. Examples..................................................29
9.1 Printing Service Example..................................29
9.1.1 Intra-Domain Accounting...................................29
9.1.2 Inter-Domain Accounting...................................30
9.1.3 User Accounting Indication................................31
9.2 Mobile/Roaming Example....................................31
9.3 Diffserv Example..........................................33
9.4 User Accounting Indication Example........................37
10. Security Considerations...................................39
11. References................................................41
12. Acknowledgments...........................................42
Author's Addresses..............................................43
Full Copyright Statement........................................441. Introduction 🦋
1.1 Motivation
Okay, so even if we get way more bandwidth in the future, controlling how network resources get used is still essential 🫶. You need it for apps with special demands, and you need it to stop waste, whether that's malicious or just an accident 😭. Charging is one way to control how resources get used and shared 💰. In multi-service networks, charging can be based on what's reserved or what's actually used 📊.
Charging on reservations is a big deal, because a reservation usually stops other users from using those resources 🔒. But if charging is only based on reservation parameters, the price depends on whether the user can predict their traffic well, which is a lot to ask 🙈. Using a scheme that looks at both the reserved and the used resources helps soften that 💜. To support usage-based charging, you have to collect info about reservations and utilization, and collecting data about resource usage is what we call accounting ✨.
Service providers have lots of options for service differentiation, charging schemes, and offering accounting services 🌈. The charging schemes are a huge way providers stand out from competitors, so they keep switching them up to match their business plans 💅. Providers can also offer different accounting services, like standard or comprehensive, so customers can pick the one that fits their needs 🍓. Sometimes it also makes sense for a provider to hand accounting off to a third party 🧚. Users bring all kinds of traffic profiles, and they have their own preferences too, like itemized invoices, accounting indications, or spending limits 💖.
Configuring accounting services gets harder because provider domains often have heterogeneous metering and accounting infrastructure 😵💫. Different providers using different accounting and metering solutions also makes sharing configuration parameters a mess, especially in roaming scenarios 🙃.
Configuring and dynamically adapting the accounting process to the business model and to specific user demands needs a flexible, configurable accounting infrastructure 🔧. Standardized policies for expressing conditions and related configuration actions also let you configure heterogeneous infrastructures, which is huge 🔥. So the proposal is to use accounting policies to configure the accounting infrastructure, and to use the Authentication, Authorization and Accounting (AAA) architecture to exchange and deploy those policies 🫶✨.
1.2 Document Scope
This doc covers the structure and usage of accounting policies 🎀. It shows how the characteristics of the provider network shape the accounting requirements 🌸. It also introduces the relationships between the different roles involved in accounting, plus the building blocks an accounting architecture needs 🧩.
The doc describes an architecture and mechanisms for configuring the accounting service 👑. It proposes using the AAA protocol to exchange accounting configuration info that's expressed as policies 🗣️. It does not propose a specific protocol for the accounting configuration itself 🙈. That config can be done with existing protocols, like the Common Open Policy Service Protocol for Support of Policy Provisioning (COPS-PR), the Simple Network Management Protocol (SNMP), and others 🦋. The doc also shows how different accounting services can be provided in intra-domain and inter-domain scenarios 🌈, with examples of using accounting policies in each case. Those examples show how accounting components can be integrated into the authorization framework proposed in [RFC2904] 💜.
Accounting management architectures and objectives, plus transport of accounting records, are covered in [RFC2975], so this doc doesn't explain them further 📚. This doc is focused on configuring the accounting architecture and the measurement devices 🔧.
The policy-based accounting architecture here is written from the perspective of a Generic AAA Server [RFC2903] 🧠. That server puts managing accounting policy and managing user-specific authentication, authorization, and service provisioning all into one entity ✨. Some providers might build it differently, without combining those functions into one entity or protocol, and in that case that part of this architecture just doesn't apply 💅.
Last thing, and it's important: this doc does not propose a language for describing accounting policies. It's assumed that a suitable policy language can be picked from existing or upcoming standards 🌸.
2. Terminology ✨
okay so before we dive in, we need to agree on what these words mean, bestie 🫶 otherwise everyone's talking past each other and it's giving chaos 💀
Accounting Indication/Confirmation 📨 Accounting indication messages get pushed from the originating AAA server (the server where the accounting information was generated) to the recipient, which can be an AAA server or a customer/user application. 💌 Accounting indications hold accounting records that describe the resource consumption for a service, and they can also carry aggregated info for multiple services. There can be interim and end-of-session accounting indication messages. Interim indications get delivered at specified intervals to the recipient during the service session, while end-of-session indications only get given to the recipient at the very end of the session. Accounting indications may be acknowledged by accounting confirmations so you get application layer reliability 🔥
Accounting Policy Indication/Confirmation 📜 Accounting policy indication messages contain accounting policies and get sent from a customer/user or a AAA server to another AAA server. ✨ These may be acknowledged by accounting policy confirmations, which again gives you application layer reliability 🫶
Accounting Request/Answer 🙋♀️ Accounting requests get sent by an AAA server to another AAA server to ask for the current accounting information for a particular session set. This is called polling 🎀 The request gets answered with an accounting answer that contains the accounting records.
Accounting Policy Request/Answer 🎯 Accounting policy requests get sent by an AAA server to another AAA server or a customer/user to ask for accounting policies for a service. The request is answered by an accounting policy answer that contains the accounting policy 💅
Accounting Policies 📋 Accounting policies describe rules for generation, transport and storage of accounting data. These rules are used to configure the accounting process. It's giving organized 🧚
Application Specific Module (ASM) 🧩 An ASM provides the functionalities needed for the user configuration of a service to an 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 ASI from the message or converts information given in a generic format into the appropriate application specific format. More info on how the ASM is used can be found in [RFC2903].
Charging Schemes 💸 A charging scheme is an instruction for calculating a charge. Usually it's represented by a formula made 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 in by information from accounting data 🌈
Classifier 🗂️ This document uses the definition of classifier from [RFC2475]. Since this document assumes that meters already include classification functions, the term classifier is only used for entities that perform additional classification (e.g. as part of data post processing). 💜
Meter 📏 This document uses the definition of meter from [RFC2722]. This meter definition already includes the classification of packets. It differs from the DiffServ model [RFC2475], where classifier and meter are considered separate entities. Not the same vibe, iykyk 👀
Meter Reader/Collector 📥 This document uses the definition of meter reader and collector from [RFC2722]. ✨
Meter Manager 🧑💼 This document uses the definition of meter manager from [RFC2722]. 🌸
Policy, policy condition, policy action ⚖️ The terms policy, policy condition and policy action are used as defined in [RFC3198]. 🫶
QoS Auditing 🔍 Quality of Service (QoS) Auditing is the process of evaluating whether a given quality of service guarantee (e.g. thresholds for QoS parameters given in a Service Level Agreement - SLA) has been met during the service provisioning. Did they keep their promise? Time to check 👑
Service Class 🎟️ A service class specifies how a service (as defined in [RFC3198]) belonging to that class gets handled 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 who has been authenticated and authorized by the AAA architecture. Although an AAA architecture isn't 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). Stay tuned for that one, bestie 🧚
3. Impact of Provider Network Characteristics on Accounting
okay so there are SO many options for future service providers when it comes to realizing service differentiation and provisioning 🌈 Which means provider networks can vary a lot across several characteristics that impact accounting and charging. Let's go through them 💅
- 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 they usually charge based on traffic aggregates instead of individual flows. Different vibes, different billing 💸
- QoS provisioning technique ⚙️ Diffserv accounting requirements differ from Intserv accounting requirements (e.g. meter granularity). Not the same, not the same at all 🙃
- Service classes 🥇🥈🥉 How a network defines its service classes, and how much freedom customers get (e.g. gold/silver/bronze service vs. a free choice of individual traffic profile parameters), is important. It affects things like the flow classification within the network, and it influences which accounting functions are required 🔥
- Charging scheme 🧾 There's 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. Some charging schemes lead to zero or only a few accounting requirements, while others may be highly demanding 😭 For instance, flat rate charging schemes require no accounting infrastructure at all. Volume-based charging schemes, on the other hand, require measuring the transmitted volume, which increases the complexity for accounting. Tariffs that introduce variable prices may require providing users with accounting information regularly (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 to share accounting tasks and distribute accounting data so that, e.g., metering only needs to be done once. If so, 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's important for providers to agree beforehand on how accounting data will be collected and monitored, and how disputes concerning accounting data will be resolved. To minimize disputes between providers, it's important for them to agree that either both will collect accounting data (and 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). No drama, just receipts 🧾🫶
- 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). 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. Reuse is giving main character energy ♻️✨
4. Business roles and relations ✨
okay so bestie, before we get into the scenarios we need to talk about who's who 💅 We looked at how services are provided on today's Internet and the one coming up, and we noticed a bunch of different business roles that show up in the service usage lifecycle. This section defines the word service first, then explains each role and how they relate to each other. We use these roles in the examples later, so it's important 🫶
- Service A service is a set of capabilities offered by a provider to a customer 🎀 In this definition, the provider and the customer can each be one of the business roles we define later. There are different kinds of services we need to recognize, and they're all iconic in their own way 🦋
- 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 a certain form of communication (e.g. video conferencing or IP telephony) 📞
- Transport services are all about the provisioning of pure transportation of IP packets 🚚 At the IP layer, this may include differentiating packets (e.g. the number of packets with a certain DSCP), Intserv based reservation, or other methods for QoS enhancement (e.g. Automatic Repeat reQuest - ARQ, Forward Error Correction - FEC). A transport service might also include mechanisms on other layers for improving the transport (e.g. MPLS) ⚡
- Management services are responsible for managing resources (e.g. configuration, accounting, security) 🧚 Accounting services describe the provisioning of data about the current or previous resource reservation and usage 📊 Providers need accounting services to generate a bill, and users need them to keep an eye on their own resource usage 💜
- Service Subscriber The service subscriber is the entity that has subscribed to a service, so it has a contractual relationship with a service provider and with a network provider that supplies the underlying transport service 🤝 A service subscriber can also act as a service user. The service subscriber might have a relationship with a broker that provides service-relevant information 🌸
- Service User The service user is the entity that actually uses the service 🙋♀️ The service user can be identical to the service subscriber. In cases where the subscriber and the user are not identical, the service subscriber should be able to control the service usage for all the 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, and the services are delivered on top of that network infrastructure 🛣️ The service provider has a contractual relationship with the service subscriber and service provider (and the broker). The transport network of a network provider is probably not one global network that connects all subscribers, providers and brokers 🙈 Instead, the transport network is segmented into a number of sub-networks or domains, each controlled by a different network provider, 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 ✨ It can offer a service directly to the service subscriber/user. It can also act like a wholesaler, selling a service to another service provider (the retailer), which then re-sells the service to the service subscriber 🛍️ The service provider has contractual relationships with other service providers, subscribers, brokers and network providers. A service provider provides information services on top of the transport services offered by network providers 💖
- Broker The broker entity lets the other roles access the information it controls 🔑 The broker can give different information to different business roles, which is very main character of it 😌 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 that can provide bandwidth as required by the subscriber) 🦋 A broker can also interact with other brokers to complete their information. In this case, broker-to-broker business relationships exist 👯♀️
Figure 1 depicts the different roles and the business relations between them 🗺️
+----+
V |
+---------------+ |
| Broker |<-+
+------>| |<-----------------+
| +---------------+ |
| ^ |
| | |
| V V
| +------------------+ +---------------+
| | Service | | Service |
| | Subscriber |<------>| Provider |
| | | | |<-+
| | +--------------+ | +---------------+ |
| | | Service User | | ^ ^ |
| | +--------------+ | | +----+
| +------------------+ |
| ^ |
| | |
| V |
| +---------------+ |
+------>| Network |<-----------------+
| Provider |<-+
+---------------+ |
^ |
+----+Figure 1: Roles and business relations
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 and 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 a reseller for the file service. The file server service chooses the appropriate transport service (maybe based on user preference), so 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 it 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, and can use different transport mechanisms for the download 💻 To get the appropriate transport, the user contacts an agency (broker), which returns a reference to a network provider that provides the required transport service 🫶 As an alternative, the content (video) can be delivered in different qualities via different transport mechanisms by the service provider. The service provider chooses an appropriate network provider that 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 ✨
okay so bestie, we came up with a reference model 🧚 that shows how all the metering, accounting and charging stuff talks to each other and gets set up through policies 💅. It's Figure 2 below. On the right side there are five layers of building blocks, stacked so the data flows from the bottom metering layer, through accounting, all the way up to the final billing step 🎀. Data aggregation isn't only a collection thing, it can happen at the other layers too 🦋. The blocks get configured by the policies on the left side. Higher layer policies can be translated into lower layer policies, and the config parameters get pulled out of the policy and handed to the right building block 🫶. Here's the tea on each block:
- Metering
Meters capture data about resource consumption in the network (e.g. transmitted volume). They'll probably sit at the edges of the network 🌸. There are two kinds: static meters and configurable meters. Static meters measure all flows at a fixed granularity, without caring whether a later charging process needs that specific meter data or not 💀. Because that's a huge pile of data, filtering and/or aggregation after the metering is usually necessary. A configurable meter only collects data for flows that metering policies specify 👑.
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 can be initiated by the meter itself (push model) or by a collector entity (pull model) 🍓. Collected data can be aggregated before it gets passed to the accounting layer, and metering policies define how collection and aggregation are done ✨.
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 📊. That includes controlling data gathering (via metering), plus transport and storage of accounting data. For subsequent charging, the metered data must be associated with a user (the initiator of a flow) and a customer (service subscriber) who's responsible for payment 💖. To kick off 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 the costs calculated by 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 of the bill (e.g. itemized or not, partial anyomization, etc.) and the time for billing (e.g. weekly, monthly, etc.) 🌈.
We propose to use policies expressed in a standardized way to appropriately configure the meter, meter data collection and accounting processes 🫶.
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 give us a standardized representation of configuration information, which can be converted into the appropriate settings for different elements of the accounting infrastructure (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 they're received from other AAA servers (extra-domain policies) or customers/users. Two different models of obtaining accounting policies can be differentiated: push and pull 🦋.
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
6.1 Accounting Policy Condition
An accounting policy consists of 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 a 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 specify 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 the 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 with 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 simplifies the selection for users. An example is 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 🤝.
6.2 Accounting Policy Action 💅
okay so the action part is the bit that actually does something once the condition is true 🔥 usually it means configuring the accounting infrastructure, and that can already include settings for meters and collection entities. here are the parameters an accounting policy action can configure ✨
- accounting record type/structure the data you need depends on the charging scheme, so different accounting records should be supported 🎀 you can either define different record types, or use one flexible record made of a variable set of accounting attributes. policies can also tell neighbor providers which kind of accounting record they need so they get the right data for the charging scheme 💖 specifying the required attributes can change how different parts of the accounting architecture are set up (like which attributes get measured). you can find an overview of accounting attributes and records in [RFC2924] 📚
- accounting record destination this is where the accounting records get sent 🦋 the destination can be a charging entity, a neighbor provider, a user entity, or a specific database. in all of these cases, authentication and authorization have to be applied so that unauthorized entities can't get their hands on confidential data 🔒
- report interval the report interval says how often accounting records get generated and sent 🌸 it affects how the meters and collectors in the accounting architecture get configured ⭐
- storage time if the destination is a database or a log file, the storage time tells you how long the accounting records have to be stored 🍓
- access list the access list says who has permission to read the stored accounting records 👑 bestie, this one is all about who gets to peek 👀
- flow granularity flow granularity decides how fine grained (in coverage) the measured flows in the network are 🧚 it's usually set by installing specific classification rules in the meter. you can also set a granularity by configuring aggregation schemes that get applied after the metering process ✨ the range goes from individual micro flows (for example, ones identified by the quintuple
<src, dest, proto, src-port, dest-port>) all the way up to coarse traffic aggregates (like all traffic from one network) 🌈 - meter accuracy meter accuracy parameters can decide things like how often measurements happen at the meter, how accurate the timestamps should be, and so on 💜 they can also be used to configure sampling schemes 🎀
6.3 Example for Meter Configuration 🧚
Note: In the following examples, the use of NeTraMet or NetFlow to collect accounting information does not guarantee exact accounting data, so it is not recommended for use in situations where exact accounting data are needed. 🙈
okay the next two examples show how accounting policies can configure different meters 💖 the accounting policy gets sent from the AAA server to the ASM, and there it's converted into the right configuration information for whichever meter is being used ✨
if the meter is NeTraMet [RFC2123], the policy gets converted into a NeTraMet ruleset with the relevant flows, attributes, and reader instructions for data collection 🦋 that info goes to the NeTraMet manager, which configures the meter and meter reader to match ✨
+------------------+
| 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
if the meter is NetFlow [NetFlow], the ASM translates the meter policies into filter instructions for the flow collector 🌸 the meter itself is static, so the configuration information doesn't affect it 💅
+------------------+
| 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 (that's integrated accounting) or as its own separate service (that's discrete accounting) 🫶 the different views and how they affect the accounting architecture are covered below 💜
7.1 Integrated Accounting ✨
in the integrated accounting model, accounting is seen as part of the provisioned service 🎀 that means it's coupled with one specific service 💖 so the accounting process gets tailored to that service and might collect accounting info by directly using some service-specific entities. for example, accounting for IP telephony could use call signaling information from a SIP server 📞 the accounting architecture gets configured 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 right 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 resource consumption gets sent back to the AAA server through the ASM 🦋 the accounting process inside the service turns the metered data into accounting records and sends them to the AAA server 💫 along the way, data conversion, aggregation, and filtering might be performed to make those records 🧁
7.2 Discrete Accounting 🧾✨
okay so, the opposite of integrated accounting is when accounting gets its own separate service 💅 it doesn't have to be glued to one specific service anymore. Discrete Accounting is basically the go-to for outsourcing the accounting job 🫶 and the accounting service can come from a general accounting system that's able to handle lots of different services.
For example, a generalized meter can do accounting for web traffic, FTP traffic, and voice over IP traffic all at once 🤯 and if accounting is its own service, one provider can handle the accounting (charging and billing) for several other service providers. Accounting is offered just like any other service, so authentication and authorization might be required before the accounting service gets provisioned 🔐 It's also super important that everyone involved agrees beforehand on how the accounting service is provided, what parameters can be set, and how disputes will be resolved ⚖️ Once the accounting service is configured, the AAA server can take care of 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 that service from an accounting service provider 📬 The accounting provider sends the generated accounting records to the service provider, who may make modifications to the records before sending them to the final destination ✏️ Having a general accounting service like this might speed up the creation of new services, especially specialized content services, on the Internet 🚀 This separation is also great for supporting special accounting services (e.g. sending accounting indications to users) that aren't directly coupled to a network service 💌 And it's useful if the same set of accounting strategies can be applied to different services (e.g. different tariffs that can be used for a set of services) 🍓
Another option is to outsource only the metering service 📏 The meter service provider generates meter data and sends it to the service provider who requested it. The service provider then generates accounting records based on that received meter data. A separate accounting or metering service provider can be used to validate the accounting data generated by a service provider 🔍 So if the customer doesn't trust a service provider, or if there's a legal action going on, a trusted accounting or metering provider can check whether the accounting data generated by the service provider is correct 👑
7.3 Intra-Domain Accounting 🏠
In Intra-Domain accounting [RFC2975], the data about resource consumption gets collected in one administrative domain and used in that same domain 🏡 Accounting policies are enforced locally. Since there's no exchange of accounting data with other domains in this scenario, accounting policies don't need to be exchanged with other entities either 🙌
+-------------+
| Billing |
+-------------+
^
|
+-------------+
| ASM |
+-------------+
^
| ..............
+--------------+ : Accounting :
| AAA |<--->: Policies :
+--------------+ :............:
| ^
| |
V |
+--------------+
| ASM |
+--------------+
| ^
config | | Accounting Records
V |
+------------+ +-----------|----------+
| | Service usage | +--------+-------+ |
| End System |-------------->| | Accounting | |
| | | +----------------+ |
+------------+ | |
| Service |
+----------------------+
User ProviderFigure 7: Intra-Domain Accounting
7.4 Inter-Domain Accounting 🌍
For Inter-Domain Accounting, at least two administratively separated networks are involved in the accounting process 🤝 These can be a Home- and a Foreign-Provider in a Roaming/Mobile IP scenario [RFC2002], or a chain of providers if the service provisioning involves data transfer and/or services from different domains 🔗 In these scenarios, exchanging 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-ProviderFigure 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, so it needs accounting data from the foreign provider 💸 To tell the foreign provider which accounting record type and report frequency it wants, the home AAA server sends an accounting policy indication to the foreign AAA server, and the indication contains the accounting policy 📨 Instead of sending an indication, the accounting policies could also be piggy-backed onto an authorization reply 🎁 If the foreign AAA server can configure devices so they enforce the desired policy (e.g. the meters are capable of metering the requested attributes), the accounting policy indication gets acknowledged ✅ But if the requested policy can't be enforced, the accounting service is denied 🙅♀️ Reasons to deny enforcement of a specific accounting policy could be, e.g., that the meter isn't capable of measuring the requested attributes, that the frequency of records can't be provided, or that the home provider isn't 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 these message sequences can be done as described in the following sections 🦋
8.1 Agent Sequence ✨
Okay so the accounting policy for the authorized service can either live right next to the authorization policy or in its own separate repository 🗂️. Setting up the accounting infrastructure can happen together with the user configuration of the service equipment (messages 2 and 3 in Figure 9) 💖. Heads up though, user-specific config and accounting infra config might mean sending data to multiple entities in the network (e.g. to different routers for setting up QoS provisioning or to dedicated accounting meters) 🫶. It's a whole group project, bestie 😭.
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 4 | +-------------------+ |
| User | | | ^ ^ |
| | | |2 |3 |AcctRec |
| | | V | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
+------+ | |
+-------------------------+Figure 9: Accounting and Agent Sequence
In the agent sequence, the user is allowed to send accounting policies (e.g. for accounting indications) along with the authorization request to the AAA server 🦋. Figure 9 shows the agent sequence authorization and accounting messages.
8.2 Pull Sequence 🌸
The accounting infra can be set up in a similar way to the agent sequence, during the user configuration of the service equipment 🧚. But the pull sequence doesn't send a specific authorization request. Like, if the service equipment is a Network Access Server (NAS) and the authorization sequence just kicks off with the dial-in process, then it would need some extra 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 done, for instance, with a hybrid model of agent and pull sequence, where the user sends an accounting policy indication to the AAA server on top of the message 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 🙅♀️. There are three possibilities for setting up the accounting infrastructure here:
a) A standard fixed accounting procedure that has been assigned in advance for the specific combination of authorized user and service is used.
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 🧳
Okay, so if the provisioning of the service and the final authentication/authorization process are handled by different organizations, accounting is kinda more tied to the service provisioning process than to the authentication/authorization process 🌈. The data never has to go through the home provider's network, so the home provider has no way to collect data about resource consumption 😬. That means accounting will usually happen in the foreign provider domain (i.e. in the domain that does the service provisioning) 🌍. Still, to keep authentication, authorization and accounting all in sync (e.g. allocating user IDs to accounting records) and to get a bill produced, there needs to be a connection between the accounting process in the service provisioning domain and the deciding authentication/authorization process (e.g. at the home provider) 🫶.
One way to do this: the foreign provider gets the accounting policies from the home provider and sets up the accounting architecture to match those policies. Then the foreign provider can generate accounting records and send them back to the home provider. The home provider can then apply charging and produce a bill 💜. An example of this is given in section 9.2. This scenario needs a prior agreement between the providers about which policies and parameters are allowed to be set 📝.
9. Examples ✨
The following examples illustrate the use of policy-based accounting 🌸. Just a heads up, the services used in these examples are only there for illustration purposes, and using them in real life would take different messages and parameters 💅.
9.1 Printing Service Example ✨
okay bestie, the Internet Printing Protocol (IPP) [RFC2566] is such a cute example for accounting, especially the "print-by-reference" model 🖨️💖 It shows how authorization and accounting are linked, because the authorization is what triggers the accounting. We'll look at a few ways to do the accounting for this service and show how the model from earlier fits right in 🧚
With IPP "print-by-reference", the user asks the print service to print a particular file, but the file isn't on their computer. It's on a public server. So the print request holds a reference, like a pointer, to the document instead of the document itself 📄 The print service has to pull the file over to a file server (used for spooling) before it can print. There are two possible setups. Either the file server and the print server belong to one organization (Intra-Domain Accounting), or they belong to two different organizations (Inter-Domain Accounting). In the first case, one service provider authorizes the user for the service. In the second case, there are two different ways to set up a trust relationship between the entities involved [RFC2905] 🤝
9.1.1 Intra-Domain Accounting
okay so in the single organization case, one service provider runs the whole file and print service 🏠 The subscriber and the user can be the same entity (e.g. a private home user), or they can be different entities (e.g. a company as the subscriber and an employee as the user). The data travels over the underlying network using the transportation service of a network provider 🌐 Here, the AAA server of the provider controls access to the file server and the print server. That means the AAA server enforces the accounting policies and collects accounting data from both servers. Main character energy for that AAA server 👑
9.1.2 Inter-Domain Accounting
if two different organizations are involved, there are two possible trust relationships, as shown in [RFC2905] 🧐
- The user has an agreement with the print server, and the print server has an agreement with the file server.
- The user has agreements with both the print server and the file server.
in case 1, the user is authorized by the print service first, and then the request is forwarded to the file server 📨 The file server then authorizes the print server and decides whether the printer is allowed to access the file. This case is shown in Figure 12, and in it the accounting policies from the user end up 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 figure out which policies it can enforce locally and which ones need to be passed on to the file service AAA server 🧩 The print service is also allowed to add its own accounting policies. If the file server doesn't support the accounting policies the print server wants, the print server must notify the user's AAA server, and some policy conflict resolution has to happen 🙈 Once the file server has transferred the file to the print service, it creates an accounting record according to the accounting policy and passes it along to the print service. After printing is done, the print service makes the final accounting record for the whole service session, using its own data and the file service data. This record is what gets used for later billing 💰 The print server can also send that final record to the user's AAA server. The user's AAA server can then use it for later authorization decisions based on the resources used. For example, if the customer is a company and the user is an employee, that's useful info 🫶
in case 2, the customer's AAA server has agreements with both the file server and the print server 🌸 Here the user's AAA server sends the accounting policies to the file server and the print server. After the service is finished, both servers create accounting records for the services they delivered, and those records are used for later billing. Just like in the first case, the accounting data can be sent to the user's AAA server for later authorization decisions. The user's AAA server can also tie both accounting records together and assign them to the user. It does this using audited session information (authorization and accounting messages for a particular session could be linked with a session ID) and policies that define which activities make up a certain session 🔗✨
9.1.3 User Accounting Indication
there are a bunch of ways to send accounting indications to the user 🔔 Accounting indications show the user how many resources have been used up to the point of the indication. Whether a user gets them or not depends on the accounting policy for that user.
For Internet printing with the "print-by-reference" model, these indications would be super helpful 🥹 The file isn't on the client's site, so the user might not know the file size or how many pages will be printed. That means the user has no idea what the service is going to cost. If the user and the subscriber are the same entity, accounting indications help users avoid going over their spending limit 💸 They also give the user a hint about which resource usage caused the charges. Think of an itemized telephone bill: it doesn't just show one monthly total, it lists every call with its start time, duration, distance, and matching charge 📞
9.2 Mobile/Roaming Example 🌍
in this section, we're using the "Dial-in with Roaming" example from the authorization examples in [RFC2905] and [RFC2002] to show how accounting functions can work with authorization functions 🦋 The accounting modules (e.g. collectors and meters) are treated here as part of the service equipment, which in this example sits at the visited ISP's premises 🏢 The visited ISP probably does the basic setup of the accounting modules itself. But the visited ISP can let the home ISP influence certain parameters, like the report interval or the accounting record format. This is handy if the home provider makes the invoice, because then it needs the right accounting records to work out the prices 💅
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 matches the example in [RFC2905] 🤩 The new thing here is an ASM, which sits between the home AAA and the service equipment. It handles the user configuration that happens after successful authorization. The extended roaming example is in Figure 13. Steps (1), (2) and (3) are the authentication/authorization request being forwarded from the user, through the visited ISP's AAA server, to the home AAA server 📬 In step (4), user-specific service parameters go to the visited ISP's AAA server, and they get forwarded to the service equipment in step (5), where the user configuration gets done ⚙️ Those user-specific service parameters can also include the policies the visited ISP should use to configure its accounting infrastructure. For example, an accounting policy could say "for user X one accounting record of type Y has to be generated every 30 seconds" ⏱️ The visited ISP uses that policy to set up its modules (e.g. metering and data collection).
The ASM turns the user-dependent service parameters into the right configuration information in step (6) 🧁 Then, in step (7), the user is told that the authentication/authorization process is complete. The accounting architecture starts metering resource usage and sends metering records to the ASM in step (8) 📊 In step (9), the ASM uses that metered data to fill in the required accounting records and sends them to the visited ISP's AAA server. The visited ISP can either post-process the data or forward it straight to the home ISP in step (10) 🚀 Using this data as input, the charging and billing modules in the home provider's domain generate an invoice in step (11), using charging policies (tariff formulas). It's then sent to the user/customer in step (12) 💌
As an extra option, accounting records can also be offered to the user as an accounting indication, which is a special service. This special service needs its own separate authorization 🔐 bestie, that's the whole roaming story, and I'm obsessed 🌈
9.3. Diffserv Example ✨
okay so this example shows how integrated accounting gets set up through policies for a Diffserv service [RFC2475] that runs on bandwidth brokers [I2-BB]. 🦋 The service is the transport of packets with a higher priority, and it also includes accounting and QoS auditing. 💅 Figure 14 shows the whole setup. The user sends a Service Request (SR) for a Diffserv service to the AAA server, and the request contains a user ID plus the parameter for the class they want. 🎀
User->AAA: user-x@nw-a, service=diffserv, class=gold,
amount=2Mbit, dest= nw-bso user-x is at network A (nw-a) and wants a gold class service for all flows from that network to the destination network B (nw-b). 👑 Once authentication and authorization are done successfully, the AAA server pulls the ASI out of the request and passes it to the ASM of the Diffserv service. 🫶
AAA->ASM: service=diffserv, class=gold, amount=2Mbit, src=nw-a
dest=nw-bThe ASM is the one that translates the application specific information into proper user configuration info for the service equipment. ✨ For this Diffserv example, the service equipment has three parts: accounting equipment, QoS auditing equipment, and the bandwidth broker architecture. 😭 The ASM has to reach out to all three to set up the requested service for the user. The translation of the ASI into configuration info for those components can be done by evaluating service provisioning policies. 🧚 For instance, the ASM could have this service provisioning policy:
if class==gold {
set bw-request.class = gold
set accounting.type = comprehensive
set qos-audit.metric = one-way-delay
...
}This ends up sending a bandwidth request to the BB, asking for a gold service with the given parameters. 🔥 The ASM also sends 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 two 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 give prioritized forwarding based on the definition of a gold class. 🌈 This is done according to the actual bandwidth broker's architecture, and that isn't covered further here. 🙈 For the Accounting Configuration and the QoS Audit Control, there are local configuration policies that 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
^ indent of last two lines
}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)
}so in this case, the local accounting policy puts the meter location at the network access point of network A. 💜 For comprehensive accounting, it says a detailed record type is required, with a report interval of 120 s. The resulting records have to get sent to the given report target. ✨ The QoS measurement policy sets the measurement method to passive measurement, and sets the timestamp size to 48 bits. 🎀 The meters at the access points of network A and network B are used as the meter locations. 🦋
After these policies get evaluated, the meter configuration instructions get passed down to the measurement infrastructure. 💅 In our example, the accounting configuration tells the meter at the first measurement point (MP1) to add a new rule with the given flow attributes and the settings for storing and reporting 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
The QoS audit control tells 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-489.4. User Accounting Indication Example 🌈
okay this one is about how discrete accounting can be used to give the user accounting indications. 🧚 Accounting indications get sent to the user so they know how much of a resource they're currently using. 📊 It's a special accounting service that can be provided on top of the standard accounting the provider already does. 💅 Like any other service, an authorization should take place before the accounting indication service gets provisioned. So the accounting here is treated as its own separate service. 🦋 That means the accounting service is independent of the main service, so it can be applied to different services. It might be added on top of an integrated accounting that's part of the service. ✨ How the authorization process works for the accounting service is out of scope for this document, so we won't get into it here. 🙈
Figure 15 shows the configuration message sequence for setting up the accounting service. 🎀 First, the user sends an Accounting Service Request (ASR) to the AAA server. It includes the parameters they want for the accounting service (for example, the report interval). 💖
user->AAA: user-x@nw-a, service= accounting indications,
report interval= 60 sAfter the user has been authenticated and authorized for the service usage, the AAA server passes the ASI to the ASM of the accounting service. 🫶
AAA->ASM: user-x@nw-a, service=accounting indications,
report interval= 60 sThe ASM generates an accounting policy based on the ASI and passes that 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 :
| | : Policies :
+-----------------+ :............:
|
| Meter Instructions
V
+-----------------+
| Measurement |
| Infrastructure |
+-----------------+Figure 15: Accounting Indication Configuration
The Accounting Configuration generates meter instructions from the accounting policies coming from the ASM, plus the local accounting policies, and then 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.x10. Security Considerations 🔒✨
Okay bestie, accounting is literally how the bills get made 💸, so the temptation to save money or cheat is sky-high in this whole area. That goes for setting up the accounting architecture and for collecting the accounting data. This framework needs two kinds of data communication: exchanging accounting policies and collecting accounting records. Both of them open the door to security problems 😬.
Here are the potential security hazards:
- Forgery of accounting policies and accounting record information 🎭 Both accounting policies and accounting records can be forged. Policies hold configuration info, and if someone changes it, the accounting and metering system can end up misconfigured. That either lets traffic slip through without being counted (say, by changing a meter's classification rules) or produces bogus accounting records. Records hold resource consumption data and are the basis for billing, so changing them can lead to wrong bills. It's also super important that policies or records aren't redirected or removed, and that forged ones don't get inserted 🙅♀️.
- Eavesdropping 👀 It may be necessary to keep accounting policies and accounting records private between the parties involved 🤫.
- Denial of Service (DoS) attacks 💥 The AAA server and the accounting/metering subsystem can both be targeted. A DoS attack on the AAA server can cause it to malfunction or even break down entirely. Then it can't do proper authentication, authorization, or accounting, and the service it provides becomes unavailable or unusable 😭. Attacking the server can be worse than attacking the service equipment itself, especially if lots of services share one AAA server. An attack on the accounting/metering system causes loss of metering data and/or loss of accounting records.
These hazards lead 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. Standard encryption methods can get this done.
- Authentication of accounting data and accounting policy sources ✍️ It should be ensured that the data really comes from the original source. Digital signatures can handle source authentication.
- Protection of the integrity of accounting policies and records 🛡️ It should be ensured that nothing got changed on the way from sender to receiver. Digital signatures can also handle data authentication.
- Verify correctness of generated accounting data 🔍 It must be ensured that the accounting data the service provider generates is correct. A provider might generate incorrect records on purpose (aka forging) or by accident (like a faulty configuration). Either way, that probably means incorrect bills. Customers can check the correctness of the accounting data using their own measurements and/or data collected by a trusted third party. That trusted third party can be an independent accounting service provider, as described in section 7.2, or a more general entity that offers an auditing service 🕵️♀️.
- Prevention and protection against Denial of Service attacks 🚧 The AAA protocol and all of its building blocks should be designed and implemented to resist DoS attacks as much as possible. An extra defense is to add a component to the meter system that can spot suspicious traffic patterns. When it spots something, further actions can be taken according to a pre-defined policy.
Preventing these hazards has to be considered for the protocols used for exchanging accounting policies and for transporting accounting records. Since the security requirements for authentication, transmission-level security, data object confidentiality, and integrity are covered in the criteria for AAA protocol evaluation [RFC2989], we assume that future AAA protocol(s) will be suited for secure accounting record transfer and probably for secure accounting policy transport too. We also assume that existing or upcoming solutions for securely transporting and enforcing policies can be used. 🙏
Real prevention of DoS attacks is honestly pretty hard 😩. Selectively dropping the attacker's packets is impossible if the malicious packets can't be separated from valid customer traffic. And dropping all packets of a certain type might stop authorized customers from using the service, which just helps the attacker reach their 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] Perkins, C., "IP Mobility Support", RFC 3220, October
1996.
[RFC2123] Brownlee, N., "Traffic Flow Measurement: Experiences with
NeTraMet", RFC 2123, March 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2566] DeBry, R., "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2911, April 1999.
[RFC2722] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
Measurement: Architecture", RFC 2722, October 1999.
[RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J. and
D. Spence, "Generic AAA Architecture", RFC 2903, August
2000.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and
D. Spence, "AAA Authorization Framework", RFC 2904,
August 2000.
[RFC2905] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and
D. Spence, "AAA Authorization Application Examples", RFC
2905, August 2000.
[RFC2924] Brownlee, N. and A. Blount, "Accounting Attributes and
Record Formats", RFC 2924, September 2000.
[RFC2975] Aboba, B., Arkko, J. and D. Harrington, "Introduction to
Accounting Management", RFC 2975, October 2000.
[RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann,
P., Shiino, H., Walsh, P., Zorn, G., Dommety, G.,
Perkins, C., Patil, B., Mitton, D., Manning, S.,
Beadles, M., Chen, X., Sivalingham, S., Hameed, A.,
Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R.,
Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S. and
E. Jaques, "Criteria for Evaluating AAA Protocols for
Network Access", RFC 2989, November 2000.
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J. and S. Waldbusser, "Terminology for Policy-Based
Management", RFC 3198, November 2001.12. Acknowledgments 🫶
The authors want to thank the members of the AAAARCH research group, especially the chairs John Vollbrecht and Cees de Laat, for all the fruitful discussions and comments 💜. Special thanks go to Bernard Aboba, Nevil Brownlee, and Ed Ellesson for their review and super valuable input 🌸.
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
Phone: +49-30-34 63 7149
Fax: +49-30-34 63 8149
EMail: carle@fokus.fhg.deFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2002). All Rights Reserved.
Okay, the legal bit 🤓. This document, and translations of it, may be copied and handed out to others. You may also prepare, copy, publish, and distribute derivative works that comment on or explain it, or that help with implementing it, either in whole or in part, with no restrictions at all. The only condition is that the above copyright notice and this paragraph are included on all copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or the references to the Internet Society or other Internet organizations. The exception is when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's being translated into a language other than English 🌍.
The limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns ♾️.
This document and the information in it are 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.
Acknowledgement 💖
Funding for the RFC Editor function is currently provided by the Internet Society ✨.
📦 where this page comes from
- ietf: rfc3334 2002-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms