RADIUS Accounting

The RADIUS base standards document [RADIUS2865] does not provide specifications for accounting support. Rather, RADIUS accounting is defined in a separate informational RFC [RADACC2866]. Accounting procedure is also based on a client–server model where the client (NAS) passes the user’s accounting information to the RADIUS server, which hosts the RADIUS accounting machine.

RADIUS accounting uses two messages types: Accounting Request and Accounting Response, both of which are also transported over UDP. Accounting Requests are always sent from the RADIUS client towards the RADIUS server, while Accounting Responses are generated by the RADIUS server upon receiving and processing the Accounting Requests (Figure 6.3). However, as we will see later on, in roaming scenarios proxy servers may have a hand in the Accounting Request–Response exchange.

6.3.4.1 Basic Operation

The basic operation is shown in Figure 6.4. An NAS that is capable of supporting RADIUS accounting generates an Accounting Request “Start” at the start of operation and sends it to the RADIUS accounting server. This packet specifies, among other things, the type of service being delivered, and the user that the service is being delivered to. Upon reception of a valid accounting request, the server adds an accounting record to its log and acknowledges the request by generating an Accounting Response to indicate that the packet has been received.

At the end of service delivery the client will generate an Accounting Stop packet describing the type of service that was delivered and optionally statistics such as the actual session duration, disconnect reason, or number of input and output octets. It will send this to

NAS RADIUS

server Accounting Request

Accounting Response

the RADIUS accounting server, which will send back an acknowledgement that the packet has been received. Of course, if the RADIUS accounting server is unable to successfully record, the accounting packet does not send an Accounting-Response acknowledgment to the client.

The RADIUS accounting specification introduces a number of new attributes, some of the more important of which are mentioned in Table 6.6. Note that as base RADIUS, RADIUS accounting is also an extensible protocol.

6.3.4.2 Security and Reliability of RADIUS Accounting

Think of your cellular phone bill statement when you think of RADIUS accounting. Do you like to see charges related to phone calls you never made or see entries that state your phone call was two and a half hours instead of 23 minutes? Now think of your operator for a second, even though most of us don’t want to. Does the operator like to find out that people who have been making one-hour phone calls have received bills that have not listed the charges for these calls? Now you see why reliability and security for RADIUS accounting messaging are

Client RADIUS

server Accounting Request (start)

Accounting Response (Ack for success)

Accounting Request (Interim usage data)

Accounting Request (stop, time) average Accounting Answer (Ack for receipt)

Accounting Answer (stop)

Start

Stop

Figure 6.4 Message exchange sequence during a full accounting session

Table 6.6 Examples of RADIUS Accounting Attributes Attribute name Description

Acct-Status-Type When included in an accounting request, indicates whether the corresponding request marks the beginning of the user service (start) or the end (stop) Acct-Input-Octets

Acct-Output-Octets Acct-Input-Packets Acct-Output-Packets

These attributes are used to indicate the number of incoming and outgoing octets/packets transmitted through a specific client port during a session

Acct-Session-Time Sent at the end of the session along with an accounting request to indicate how many seconds the user has received service for

Acct-Authentic May be included in an accounting request to indicate how the user was authenticated, whether by RADIUS, the NAS itself, or another remote authentication protocol

so important. How could the operators prove their case without having reliable and provable records of the user’s sessions?

Because RADIUS is transported by UDP, reliability in data transfer is not guaranteed. So it is possible that the accounting packets are lost in the network. Loss of RADIUS Accounting-Stops creates several problems as follows:

● Incomplete and incorrect billing information for metered services results in lost revenue or customer disputes that cannot be resolved.

● Some operator networks may implement a limit on the number of simultaneous sessions a user can run at any given time. If accounting packets carrying the stop indication for some previously ended sessions are not received by the server, the user will be out of luck when trying to start a new session.

RADIUS accounting RFC has taken an easy route for reliability and simply recommends that the client continues sending Accounting Requests until an acknowledgement is received. By including configurable parameters such as retransmission-intervals (back-off mechanisms) and the number of retransmissions in the NAS, and configuring those parameters more efficiently, some of those problems may be fixed. For instance, increasing the retry limit and overall time (timeout) allowed for retries improves the chances of a request getting through. Additionally, by waiting longer to retransmit, the NAS is not contributing as much to the congestion.

When it comes to security, RADIUS accounting is slightly better than the base RADIUS specification: both Accounting Requests and Accounting Responses are authenticated using an MD5 hash function and the shared secret configured between the client and the server. For the Accounting Requests, the hash function is performed as follows:

Authenticator value=MD5 (Code, ID, Length, 16 zero octets, request attributes, shared secret)

The 16-octet MD5 output is included in the Authenticator (called the Request Authenticator) field of the Accounting Request packet.

For Accounting Response packets, the value in the authenticator field (called the Response Authenticator) in the packet is calculated as follows:

Authenticator value=MD5 (Code, ID, Length, Request Authenticator, shared secret) Where the Request Authenticator is extracted from the corresponding Accounting Request packet.