Protecting AAA RADIUS Accounting Information

The third A of AAA – RADIUS Accounting - often does not get as much attention as Authentication and Authorization, but it is vitally important. The RADIUS server accounting session logs provide usage information for billing in commercial applications and an audit trail in all cases. Because RADIUS is transported by UDP, a datagram protocol that does not guarantee delivery, it is possible for valuable accounting information to be lost in the network. In particular, the loss of RADIUS Accounting-Stops creates several problems including:

1) Incomplete billing information for metered services resulting in lost revenue.

2) Valid users are locked out where Simultaneous Session Control is implemented because the end of their last session was not received. This results in unhappy customers and increased customer support overhead.

3) Incomplete audit trails.

These are important problems. The RAD-Series RADIUS Server cannot always know when a RADIUS Accounting-Stop has been lost in the network but there are several steps that can be taken to improve the situation.

1) Probably the first and most important thing to do is to find out where and why the RADIUS Accounting-Stops are being lost and then fix the root cause of the problem. Do you have problems with NASs crashing? Do you have infrastructure problems where the NAS loses contact with the RADIUS Server for long periods of time? Do you have network congestion problems where packets are lost? Is the machine where the RADIUS Server runs overloaded and running behind?

Check the RADIUS Server logfile to see if it is discarding accounting messages because the queue is full. If it is, then you need to address the overload by either getting a faster machine/disk or by implementing another RAD-Series RADIUS Server. If these are only momentary overloads, then another option is to increase the size of the RADIUS accounting request queue in engine.config from its default value of 2000:

global_acct_q.limit=3000

2) If the packet loss is out of your control or cannot be quickly fixed, then the next step is to configure the NASs to retransmit more effectively. In RADIUS the client is responsible for retransmitting requests for which it receives no reply. Most NASs have parameters to configure the timeout between retransmissions and the number of retransmissions to attempt.

Increasing the retry limit improves the chances of a request getting through. The overall time attempting to get the request through is also increased, giving congestion due to traffic spikes a chance to clear.

Increasing the timeout before retransmitting also increases the overall time attempting to get the request through. Additionally, it has the advantage that by waiting longer to retransmit, the NAS is not contributing as much to the congestion.

3) Configure the NASs to send RADIUS Accounting Interim-Updates. This has two advantages:

a) If the RADIUS Accounting-Stop at the end of the session is lost, then you at least have the accounting information up to the point of the last Accounting-Interim-Update.

b) If the RAD-Series RADIUS Server has received at least one Accounting-Interim-Update, but has not received one within the last 15 minutes + 15 seconds, then the server will move that session to the "suspended" state. If a session is in the suspended state, then it will not count toward the simultaneous session limit and the user should be able to reconnect.

Before enabling RADIUS Accounting-Interim-Updates, be sure to check that your accounting software can handle them correctly. Accounting-Interim-Updates report the cumulative session totals, not incremental amounts. To bill accurately, the accounting software must process only the RADIUS Accounting-Stop or the last RADIUS Accounting-Interim-Update for any given session.

Also note that enabling this RADIUS Accounting-Interim-Updates message will increase the traffic between the NASs and the RADIUS Server.

To log RADIUS Accounting-Interim-Updates, the RAD-Series RADIUS Server’s finite state machine table must be modified at state ACCTlog from:

ACCTlog:

*.*.ACCT_START REPLY Hold

*.*.ACCT_STOP LOG REPLYHold

*.*.ACCT_ALIVE REPLY Hold

to:

ACCTlog:

*.*.ACCT_START REPLY Hold

*.*.ACCT_STOP LOG REPLYHold

*.*.ACCT_ALIVE LOG REPLYHold

4) Set the Session-Timeout attribute as a reply item in the user profile. If the RADIUS Server has not received the RADIUS Accounting-Stop by the end of the Session-Timeout period, (plus a delay factor), then it will move the session to the suspended state where it will not count toward the Simultaneous Session Control Limit.

5) Configure your NAS/telco to hunt in a round robin fashion instead of filling in the first available port. If the RADIUS Server finds a new session connected to the same port, it will close out the old session. Configuring your NAS to hunt round robin insures that all of your ports get reused instead of the first ports getting most of the calls.

Session logging is a crucial aspect of managing a network. An understanding of both the limitations and capabilities of RADIUS, a good handle on network performance, and a few key NAS and RAD-Series RADIUS Server configuration parameters can put you in control of collecting this network asset.