Hassell J. Radius / Chapter 4. RADIUS Accounting

Computers & Technology
Education & Reference
Business & Investing
Science & Math

Radius
Authors: Hassell J.
Published year: 2005
Pages: 27-29/89

<< Previous page
Table of contents
Next page >>

Chapter 4. RADIUS Accounting

ISPs often manage points of presence over several locations, most likely geographically dispersed. All of these points of presence require protection to guard against unauthorized use of the expensive network to which they allow access. Although the front line of defense may (and should) be a robust and extensible form of authentication (to verify a user's declared identity) and authorization (to provide a user with only the services to which he is entitled), much valuable information can be gleaned from data collected about users' activities on the network. Which user logged on? When did she do so? What services was he granted?

The data becomes even more useful when it is compiled to analyze a group of users. What is the average call time for a user? How much data does that user transfer? Do I, as a system administrator, need to set a time limit for a single session so as to protect limited dial-in resources? Do I have users that are abusing an on-demand connection? All of these questions can be answered using information mined from the accounting process.

RADIUS supports a full-featured accounting protocol subset, which allows it to satisfy all requirements of the AAA model. This chapter describes the design, operation, packets, and attributes that are specific and germane to RADIUS accounting.

4.1 Key Points in RADIUS Accounting

The design of accounting in RADIUS is based upon three major characteristics:

Accounting will be based on a client/server model.: The RADIUS accounting machine is the server to the RADIUS client gear, which acts as the client. The client passes the usage data to the RADIUS server for processing. The RADIUS server acknowledges successful receipt of the data. It is also possible for the RADIUS server to act as an accounting proxy, much like the similar capability in the authentication and authorization realms.
Communications between devices will be secure.: All data is passed to and from the RADIUS server and the client gear through the use of a shared secret, which is never transmitted across the wire.
RADIUS accounting will be extensible.: The format of the accounting attributes is much like those of the authentication and authorization attributes, in that most of the services offered by the implementations can be defined and qualified using AVPs. AVPs can be added and modified to an existing implementation without disrupting the functionality already in use.

4.2 Basic Operation

All communications regarding RADIUS accounting are done with an Accounting-Request packet. A client that is participating in the RADIUS accounting process will generate an Accounting Start packet, which is a specific kind of Accounting-Request packet. This packet includes information on which service has been provisioned and on the user for which these services are provided. This packet is sent to the RADIUS accounting server, which will then acknowledge receipt of the data. When the client is finished with the network services, it will send to the accounting server an Accounting Stop packet (again, a specialized Accounting-Request packet), which will include the service delivered; usage statistics such as time elapsed, amount transferred, average speed; and other details. The accounting server acknowledges receipt of the stop packet, and all is well. If the server does not or cannot handle the contents of the Accounting-Request packet, it is not allowed to send a receipt acknowledgment to the client.

In this instance, the RFC recommends that a client continue to send its packets to the accounting server when it has not received an acknowledgment that its Accounting-Request packet has been processed . In fact, in large distributed networks, it is desirable to have several accounting servers act in a round- robin fashion to handle failover and redundancy needs. An administrator can carry this mentality further and designate certain accounting servers to handle different requestsone for his dial-up users, one for his DSL customers, and yet another for ISDN connections. Additionally, the proxy functionality present in the authentication and authorization realms of RADIUS are also allowed in the accounting phase, as the accounting server may make requests of other servers to assist in the processing of Accounting-Request packets.

4.2.1 More on Proxying

RADIUS accounting proxies act in much the same way as RADIUS authentication/authorization proxies do. Consider the following process:

The RADIUS client gear sends the Accounting Start packet to the accounting server.
The receiving accounting server logs the packet. It may then add the Proxy-State attribute and accompanying details (though it is not required to do so). It updates the request authenticator and then forwards the information to a remote machine.
This remote machine logs the incoming, forwarded packet. It then does what the first server could not do (that is to say, it performs the action that was required of the proxy), retains and copies all of the Proxy-State attributes exactly as they appeared , and sends an Accounting-Response packet back to the original forwarding server.
The original forwarding server receives the acknowledgment, strips out the Proxy-State information, constructs and adds the Response Authenticator , and sends the modified acknowledgment response back to the RADIUS client gear.