Steel Belted Radius Carrier 7.0 Administration and Configuration Guide > RADIUS Basics > Accounting

Accounting

To understand the Steel-Belted Radius Carrier accounting sequence, you need an overview of RADIUS accounting messages. Table 9 explains the conditions under which each type of message is issued, and the purpose of any RADIUS attributes that a message contains.

Table 9: Message Conditions and Attributes  

Message Conditions	Purpose of Message Attributes
The RADIUS client sends accounting data to Steel-Belted Radius Carrier using an Accounting-Request message. The RADIUS client is responsible for verifying that the server receives accounting requests. Most clients retry periodically until the server responds.	Depending on the value of the Acct-Status-Type attribute, the message type is considered to be Start, Stop, Interim-Acct, Accounting-On, or Accounting-Off.
Upon receipt of an Accounting-Request message, the server sends an Accounting-Response.	Complete the request/response cycle.
After receiving an Access-Accept from the server, the NAD completes its access negotiation with the user. The NAD then sends a Start message to the server.	Record connection data, such as username, NAD identifier, NAD port identifier, port type, and connection start time.
At intervals of approximately every six minutes, the NAD sends an Interim-Acct message to the server.	Record a snapshot of statistics regarding the connection. One message contains the current value of every statistic that this NAD is capable of recording about this type of connection.
After a connection is terminated, the NAD sends a Stop message to the server.	Record statistics regarding the connection. One message contains the final value of every statistic that this NAD is capable of recording about this type of connection.
Every time a client device comes online, whether after a crash or after an orderly shutdown, it sends an Accounting-On message to the server.	Identify the device that is going online and clear all session information.
Every time a client device experiences an orderly shutdown, before completing its shutdown sequence it sends an Accounting-Off message to the server.	Identify the device that is going offline and clear all session information.

Accounting Sequence

A NAD can issue an Accounting-Request whenever it chooses, for example upon establishing a successful connection. Each time an Accounting-Request message reaches Steel-Belted Radius Carrier, an accounting transaction begins. During this transaction, the server handles the message by examining the Acct-Status-Type and other attributes within the message, and taking the appropriate action.

Comma-Delimited Log Files

When the Steel-Belted Radius Carrier accounting log is enabled, all of the RADIUS accounting attributes that the server receives are reformatted and logged to a comma-separated value (CSV) text file, which is easily imported into spreadsheets and database programs for report generation and billing.

Proxy RADIUS Accounting

Steel-Belted Radius Carrier can relay an Accounting-Request to some other RADIUS server, which records the data according to its own, locally-configured RADIUS accounting options. (You have the option of specifying that the data also be recorded locally on the Steel-Belted Radius Carrier server.) The set of conventions for relaying packets between cooperating RADIUS servers is known as proxy RADIUS, and is defined in the RADIUS standard.

See Configuring a Proxy RADIUS Realm.

External Accounting

External accounting methods permit Steel-Belted Radius Carrier to record accounting data to external databases. Configuration files specify how Steel-Belted Radius Carrier communicates with an external database and how to insert accounting data into that database.

SQL is the only external accounting method currently supported by Steel-Belted Radius Carrier.

See SQL Accounting Overview.

Tunneled Accounting

During authentication, a user is typically identified by attributes such as User-Name (in the authentication request) and Class (in the authentication accept response). Standard RADIUS accounting requests typically include these attributes in messages flagging Start, Interim, and Stop events so that the user's identity can be recorded for accounting and auditing purposes.

When an organization uses a tunneled authentication protocol such as EAP/TTLS or EAP/PEAP, the identity of a user requesting authentication may be concealed from the NAD; the User-Name attribute carried by the outer authentication protocol is typically a non-unique value such as anonymous. As a result, the outer User-Name value included in accounting requests may not be sufficient to determine a user's identity. Class attributes provided by an authentication server cannot be included in clear-text in an outer Access-Accept message because they might contain clues about the user's identity, thereby defeating the identity-hiding feature of the tunneled protocol.

Tunneled accounting allows Steel-Belted Radius Carrier to pass user identity information to accounting processes without exposing user identities to a NAD that should not see them. When tunneled accounting is enabled, RADIUS attributes are encrypted and encapsulated in a Class attribute. If the information for a Class attribute exceeds the attribute payload size (253 octets), Steel-Belted Radius Carrier returns more than one Class attribute for a user.

The tunneled accounting transaction sequence is:

1. The Steel-Belted Radius Carrier server acting as the tunnel endpoint for EAP/TTLS or EAP/PEAP encrypts a user's inner User-Name and Class attributes when it authenticates the user.
2. The server returns the encrypted information to the NAD encapsulated in a Class attribute in the outer Access-Accept message. The NAD associates this encapsulated identity attribute with the user, and echoes the encapsulated identity attribute whenever it generates an accounting request for the user.
3. When Steel-Belted Radius Carrier receives an accounting request from a network access device, it scans the request for an encapsulated identity attribute.
4. If Steel-Belted Radius Carrier finds an encapsulated identity attribute, it de-encapsulates and decrypts the attributes to reconstitute the original inner User-Name and Class attributes.
5. Steel-Belted Radius Carrier substitutes the decrypted attributes for the ones returned from the NAD.
6. Steel-Belted Radius Carrier processes the accounting request locally or forwards the accounting request through the proxy to its intended target.

To implement tunneled accounting, you must configure the classmap.ini file to specify how attributes should be presented, and you must configure the spi.ini file to specify the keys that are used to encrypt and decrypt users' identity information. The classmap.ini file and the spi.ini file are described in the Steel-Belted Radius Carrier Reference Guide.

For an overview of how EAP/TTLS and EAP/PEAP work, refer to About the Extensible Authentication Protocol.

Directed Accounting

The directed accounting feature allows you to map an incoming accounting request to one or more accounting methods, based on routing information found in the request packet. Among the options available with directed accounting is that of establishing an accounting log file that is distinct from the Steel-Belted Radius Carrier accounting log file in the server directory, and that contains entries from only those accounting requests that were specifically directed to the realm.

See Configuring a Directed Realm.

Accounting Spooling

Accounting spooling can improve both proxy accounting performance and reliability. When spooling is enabled for a realm, Steel-Belted Radius Carrier immediately acknowledges all accounting requests for that realm to the NAD. Meanwhile, it spools accounting requests to a file while a separate thread unspools requests and sends them to the server responsible for the realm. If the server is unavailable, Steel-Belted Radius Carrier retries at regular intervals until the proxy target acknowledges the request. Even if Steel-Belted Radius Carrier restarts, all spooled requests are preserved until they are completed.

Account spooling offers the following benefits:

• The NAD always gets an immediate ACK (acknowledgement response) for accounting requests.
• Accounting data is never lost if it is sent to a Steel-Belted Radius Carrier server with spooling enabled.

A separate and independent spooler is maintained for each realm for which proxy spooling is configured. When an accounting request is received for a realm implementing proxy spooling, it is written to a file in the target directory and a request is prepared, followed by an acknowledgement returned to the client. The file is then read by the unspooling thread and the prepared request proxied.

Targets, fast-fail, round-robin, and other extended proxy features operate normally, but unspooling continues to retry sending a request until it is successfully acknowledged. Since each spooler is independent, one unresponsive realm does not affect the delivery of spooled requests to other realms.

The Acct-Delay-Time attribute in a request is updated or added as necessary if there is a delay between the spooling and the forwarding of the request.

When the spool file's rollover interval expires or the file size exceeds the rollover size limit, the current spool file is closed for writing and a new one created. Files are named in the format, yyyymmdd_hhmm_ssss.psf, where yyyy is the year, mm is the month, dd is the day, hh is the hour, mm is the minute, and ssss is a sequence number. The configuration of the rollover settings enables spooling to be optimized according to the characteristics of the operating environment.

When Steel-Belted Radius Carrier is shut down, unspooling continues for the configured ShutdownDelay time until all spooled packets are sent. If the destination server is down at the time of shutdown, however, unspooling terminates immediately. After startup, unspooling continues from the beginning of the oldest spool file.