Acct-Status-Type and Subsystems

This page discusses problems with standards and our recommended solutions. These recommendations do not update or modify any existing standards. However, we believe that the recommendations are generally useful to the RADIUS community.

Problem Statement

The Acct-Status-Type attribute has only a few values defined. These values do not fully match new practices in RADIUS. In particular, some wireless access points are composed of multiple subsystems. For example, an access point may have a controller that manages all network traffic, and multiple Basic Service Sets on multiple radios in physically remote locations. This design has a number of practical benefits, and causes at least one open problem with RADIUS.

The problem is that a basic service set may come online or go offline, which causes a loss of connectivity for multiple users. The NAS would like to indicate to the RADIUS server that multiple users are offline. However, sending one accounting packet for each user is not scalable.

Some implementations send an accounting packet, with Acct-Status-Type = Accounting-On, to indicate that the subsystem has rebooted. The problem is that RFC 2866 is largely silent on what constitutes a "session". The question for the RADIUS server is "which users, if any, should be marked 'offline' when receiving such a packet?"

Another common example is ISP access routers such as BNGs. A single BNG may run many VRFs for users, with a common VRF for RADIUS. Some BNGs want to signal that a VRF is available, or unavailable, and use accounting packets with Acct-Status-Type = Accounting-On for this purpose. As with the wireless example above, such a message does not necessarily carry information useful to identify sessions which should be marked offline, so the RADIUS system is left with the option to assume all sessions are now offline, or to ignore the message entirely.

Since RFC 2866 is silent on the subject of session identification attributes, there is no possible answer to this question. Every NAS and/or RADIUS server implementation is free to do something different. Such choices are bad for inter-operability.

There is an RFC Editor errata filed for this problem statement.

Recommendations

We have a number of recommendations.

1. Acct-Status-Type = Accounting-On should not be used to indicate sub-system reboot.
2. IANA should allocate two new values for Acct-Status-Type: Subsystem-On, and Subsystem-Off. These values have meaning similar to Accounting-On and Accounting-Off, except that they apply to a subystem of the NAS.
3. NASes should use these new values to indicate subsystem on/off.
4. The Called-Station-Id attribute should contain values unique to each subsystem.
5. The NAS should signal that the entire system has rebooted by using the existing Accounting-On and Accounting-Off values, with a value for Called-Station-Id that is global to the NAS, or to omit it entirely.

The last two recommendations are unfortunately imprecise, as we wish to maintain compatibility with existing systems.

While it is possible to have a more generic matching of sessions, i.e. "use anything in the accounting packet to determine which sessions match", there is a trade-off between flexibility and inter-operability. Leaving things too flexible means that it is impossible for RADIUS servers to know what a NAS will do, and therefore these new values will be useless. We therefore provide a recommendation (use Called-Station-Id), because we know it will work, and it will not be wrong. Vendors are free to add more attributes to the packet, but they should at least ensure that the Called-Station-Id attribute uniquely identifies a subsystem.

One method of implementing recommendations 4 and 5 is to put the BSSID and SSID into the Called-Station-Id attribute. When the entire NAS reboots, the Called-Station-Id attribute can be omitted entirely.