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.
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,
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
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.
We have a number of recommendations.
Acct-Status-Type = Accounting-Onshould not be used to indicate sub-system reboot.
- IANA should allocate two new values
Subsystem-Off. These values have meaning similar to
Accounting-Off, except that they apply to a subystem of the NAS.
- NASes should use these new values to indicate subsystem on/off.
Called-Station-Idattribute should contain values unique to each subsystem.
- The NAS should signal that the entire system has rebooted by using
Accounting-Offvalues, with a value for
Called-Station-Idthat 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
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
Called-Station-Id attribute uniquely identifies a
One method of implementing recommendations 4 and 5 is to put the
BSSID and SSID into the
When the entire NAS reboots, the
attribute can be omitted entirely.