Internet Engineering Task Force

The IETF is part of the Internet Society [16] and is responsible for the devel- opment and standardization of new Internet technologies. It is "a loosely self- organized group of people" who contribute to the evolution of the Internet [17]. The work of the IETF is organized in eight areas and each area consists of several working groups (WG). The areas that consider Internet accounting are the Operations and Management, and Applications areas. The working groups of interest are the Remote Authentication Dial-In User Service WG (RADIUS WG), Authentication, Authorization and Accounting WG (AAA WG), Real- time Traffic Flow Measurements WG (RTFM WG), IP Flow Information Export WG (IPFIX WG), and Internet Open Trading Protocol WG (Trade WG). These different WGs focus on one or more accounting functions, and sometimes continue the work of groups that finished their work. The following sections present the work of these WGs.

Remote Authentication Dial-In User Service (RADIUS) WG

The RADIUS WG was created in 1995. The addressed topic of this group was the communication of authentication and authorization information between a Network Access Server (NAS) and an authentication and authorization server. The WG has finished its work in 1999 and is not active anymore.

The WG had developed a protocol (RADIUS) that carries authentication, authorization, and configuration information between a NAS and a shared Authentication Server (RFC 2856, [18]). RADIUS is mostly used in combina-

tion with modem pools. The protocol collects and stores data regarding the dial-up activity (session) of a user: user identifier and duration of the session, services and protocols used, NAS and port identifiers, addresses, octets trans- ferred and cause of session’s termination [3]. Such data is used for auditing and billing purposes.

An extension of RADIUS to enable accounting has been added later (RFC 2866, [19]). The protocol has not primarily been developed for accounting purposes; therefore its support for accounting is limited.

Figure 2.3 depicts two users that request access to network resources. The NAS (RADIUS client) is a device to which users connect. The client requests the RADIUS server to provide authentication status, user profiles and authoriza- tions for the users. The server authenticates the client first and then checks the users’ identity and authorization. It returns the users’ status (connection author- ized or rejected) and configuration information to the client. Transactions between a client and server are authenticated using a shared secret key that is never sent over the network. Furthermore, user passwords included in RADIUS messages are sent encrypted to protect them.

We note that, in the view of this WG, accounting was used as a synonym for metering. A RADIUS client may generate and store metering data about the session of the users. At the beginning of a session, the client sends an "Accounting start" message to the RADIUS server. After the termination of the session, the client sends the collected data (e.g., input/output bytes and packets, duration of the session, etc.) and an "Accounting stop" message to the server. Thus, the protocol is only useful for post processing, not for real-time applica- tions.

Figure 2.3 RADIUS architecture

User User RADIUS client NAS RADIUS server PPP telnet RADIUS

STANDARDIZATIONORGANIZATIONSANDACTIVITIES

RADIUS is a widely used protocol; many vendors have included RADIUS support in their equipment (e.g., Lucent Technologies, Cisco Systems). Nowa- days, routers and NASs are more complex and can handle a large number of users. The limitations of RADIUS described in the literature ([21], [25]) makes this protocol unsuitable for such environments. The limitations are for instance, scalability and end-to-end security. Additionally, the implementa- tions of RADIUS accounting are vulnerable to packet loss, application and network failures, and device reboots [21].

Authentication, Authorization and Accounting (AAA) WG

The AAA WG was chartered in 1999. The goal of this WG is to specify an AAA protocol that suits the requirements formulated by the NASReq, Mobile IP and ROAMOPS WGs. The work of this WG received lots of interest from a large audience (large number of participants at their IETF meetings and mail- ing-list discussions). At the time of writing this thesis, the WG was still active. The contributors of the WG wrote first documents that captured the state of the art in accounting protocols and their design (RFC 2975, [21]), the accounting attributes (e.g., user name, user password, NAS IP address, NAS port) and record formats (e.g., string, address, integer, time) (RFC 2924, [22]). We note that, this WG defines accounting as "the act of collecting information on resource usage for the purpose of capacity planning, auditing, billing or cost allocation" [24]. The collected data can be used for different purposes such as billing, trend analysis, cost allocation or auditing. A study of the AAA base protocol requirements for network access resulted in [23]. In September 2003 an AAA protocol called Diameter is defined (RFC 3588, [24]). This protocol was designed such that it is applicable for several network access models. Diameter is based on the RADIUS client-server model. Diameter has back- wards compatibility with RADIUS and tries to correct its limitations [25]. The purpose of the Diameter base protocol is to provide an AAA framework for the WGs mentioned before, thus it also supports mobility and roaming. The description of the base protocol specifies the message format, transport, error reporting and security services to be used and supported by all Diameter appli- cations.

Diameter has the capability to deliver real-time accounting information. An AAA server can instruct a network device that implements Diameter to gener- ate accounting data, which in fact is metering data. The server also gives instructions on how the accounting data should be delivered (e.g., data transfer strategy and timeliness information). Several fault resilience methods were included to have a robust accounting protocol and to minimize the loss of accounting information.

We note that, the 3rd _{Generation Partnership Project (3GPP) adopted Diameter}

as an AAA protocol for 3GPP networks [26]. The details of Diameter-based charging for 3GPP are described in [27].

Real-time Traffic Flow Measurements (RTFM) WG

The RTFM WG [28] started its work in 1996. This WG focused on the meter- ing of network traffic (i.e., traffic flows) and collecting the metered data. Their three main objectives defined in their charter were (1) to review the existing work on traffic flow measurement, (2) to produce an improved traffic flow model, and (3) to develop a standard Flow Meter Management Information Base. The WG has completed its goals and stopped its activities in 1998. The results of this WG are the:

• Real-time traffic flow measurement (RTFM) architecture for the Inter- net (RFC 2063, [29]);

• Meter Management Information Based (Meter MIB, RFC 2064, [30]); • Simple Ruleset Language (SRL, RFC 2723, [31]).

The RTFM architecture (i) describes the entities implementing the metering, data collecting and storing functions, (ii) defines a traffic flow (e.g., a flow can be defined by the attributes of their end-points), and (iii) how to write rules to configure a metering entity to know which data flows are of interest and which are not. The entities of the architecture are a meter, a meter reader and a manager (Figure 2.4). The meter measures the traffic flows, generates metering data and stores this data temporarily. The meter reader collects the stored data from the meter, i.e., implements the collecting and storing function. This infor- mation can be passed to an analysis application (which not part of the architec-

STANDARDIZATIONORGANIZATIONSANDACTIVITIES

ture), and can be further used for billing. The manager starts and stops the activity of the meter and downloads to the meter the rulesets (i.e., group of rules) on which the traffic metering is based. The Meter MIB is used to control the meter and store the rulesets. Traffic flows are considered bi-directional, and they can be specified at many different levels of aggregation. In general, flows are defined between endpoints: a source endpoint and destination endpoint. These endpoints can be specified between the data link and transport layers (e.g., MAC addresses, IP-addresses or Port-Numbers). The architecture speci- fies only a pull model for reading the data out of a meter.

Figure 2.4 RTFM architecture

NeTraMet (RFC 2123, [32]) is a public domain implementation of the Meter MIB. NeTraMet provides a Simple Network Management Protocol (SNMP) agent to make the metering data available to meter readers. NeTraMet can also be used for real-time network monitoring and trouble-shooting.

IP Flow Information Export (IPFIX) WG

The IPFIX WG [33] was chartered in 2001. The goal of its work is to develop a standard architecture for IP flow information export. The work of this WG consists of developing a data model that describes the flow information, and a transport protocol, which is used to transfer this information from an exporting entity (implementing the metering function) to collection entities. The infor- mation can be used as input for network management systems, billing systems, etc. This means that the WG addresses the data collection and storing account- ing function. At the time of writing this thesis, the WG was still active. This group continues the work of the RTFM WG by revising and extending the previous work, and focuses on the information transport protocol. We note that,

Meter reader

Meter Analysis applic.

Manager

Meter MIB

RTFM architecture

the exporting and collecting process term used by this WG is actually a syno- nym for the collecting and storing accounting function. Internet-drafts describe the IPFIX reference model, which allows the data collecting and storing enti- ties to collect flow information from one or more metering entities, and to provide the collected information to one or more third parties for processing. At the beginning of 2004, the work in progress of the WG considered the defi- nition of requirements for the IPFIX protocol, the flow information export architecture and data model, the evaluation of the protocol. The flow export format of NetFlow version 9 developed by Cisco Systems is selected as a basis for the IPFIX standard.

Internet Open Trading Protocol (IOTP) WG

The IOTP WG [34] was chartered in 1998 to continue the engineering work of the IOTP protocol started by the Open Trading Protocol (OTP) Consortium. The results of the IOTP WG are a framework for trading of products on the Internet (RFC 2801, [35]) and the Electronic Commerce Modelling Language (RFC 3106, [36]). The developers of this framework tried to provide an online trading model, which resembles the every day’s trading and which supports current and future mechanisms. The trading process includes the accounting for products (as defined in Section 2.1) and delivery of products. The products are delivered over other channels than the Internet, however.

In the IOTP framework the following roles are identified: customer, merchant, customer care provider (for taking care of disputes with customer), a payment system operator and a delivery provider. The protocol is optimized for the case when the customer and merchant do not have prior relations. Multiple roles can be played by a single organization (e.g., a merchant can also be a customer). If we assume that no disputes take place (so the customer care provider can be omitted), the following interactions take place (Figure 2.5). First, a customer selects the product(s) from a merchant. The accounting system of the merchant executes the accounting functions, and presents the bill to the customer. To pay the bill, the merchant offers one or more electronic payment systems provided by a payment system operator. The customer selects one system and initiates a

STANDARDIZATIONORGANIZATIONSANDACTIVITIES

payment, which is processed by the payment system. Usually, these payments have large values (e.g., above €5). After the payment, the delivery provider delivers the selected and paid product(s).

Figure 2.5 IOTP interactions

Although, IOTP is an open standard, not many merchants use it. A major reason for this is that there are no incentives to adopt this standard. One prob- lem with IOTP is the inefficient and inconvenient payment message exchange, which is tunnelled through the IOTP protocol. Another problem is that the protocol was designed completely generic and brand-independent, which made it inflexible towards existing and emerging payment systems (e.g., systems that support person-to-person payments). The generic and brand-independent char- acteristics of standards usually make them powerful, but in this case, it might be a disadvantage. Another problem emerges from the behaviour of merchants: they need payment systems to be integrated into their web shops as soon as possible within a given budget and given time constraints. Payment system developers create proprietary systems for a particular environment and customer group, and are less interested in generic standards [37]. At the time of writing, an improved version of IOTP (IOTP v2.0) was under development. The Electronic Commerce Modelling Language (ECML) defines a standard set of information fields. The aim of this standard is to ease the process of filling in various fields with customer information on the web sites of merchants. In this way, customers will be less confused by the varying web sites of merchants. For instance, the customer information needed to make payments can be filled in automatically in a standard manner for every merchant from which the customer buys content. ECML may be used with any payment system. At the time of writing, version 2 of ECML is under development.

Merchant Payment Delivery Customer operator system 1. Select product(s) 2. Accounting: present bill and 3. Pay bill 4. Deliver product(s) offer pay.systems provider