OUR SITES NetworkRADIUS FreeRADIUS Wiki

Acct-Session-Id Uniqueness

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-Session-Id and Acct-Multi-Session-Id attributes are opaque tokens generated by the NAS. They are not required to be unique. This means that in practice, many NASes re-use the values across reboots. For example, on reboot, a NAS may start using values for Acct-Session-Id at "000000", and increment them for every new user session. As RFC 2866 notes, the IDs may even wrap.

Even worse, Section 5.5 of RFC 2866 begins This attribute is a unique Accounting ID..., and then goes on to suggest that the attribute is not, in fact, unique.

We believe that such behavior is problematic, and causes real-world problems.

For example, since RADIUS is a UDP protocol, we can have the following situation. A user logs into a NAS, and is assigned Acct-Session-Id of "000000" via an accounting "start", which the RADIUS server receives and stores. The NAS reboots a short while later, and tries to send an accounting "on" packet to the server. Due to network issues, the server never receives this packet. During this time, the user reconnects, and is again assigned Acct-Session-Id with value "000000", which the RADIUS server recieves via an accounting "start".

This problem is a classic race condition. The RADIUS server has received two "start" packets, while it believes the NAS is alive. The RADIUS server is therefore required to believe that the two packets are for the same session, when in fact they are for two different sessions. When the accounting "on" is subsequently received, the RADIUS server will mark the session as offline. It should instead have marked the first session offline, and the second session as continuing.

The problem becomes worse with TLS-based EAP methods. Each user may have the same value for the "outer" User-Name attribute, e.g. "anonymous@example.com". This re-use means that sessions for multiple users may, in fact, appear to be all for one "anonymous" user. It may be possible to distinguish sessions via other attributes, such as Calling-Station-Id, but MAC addresses may be spoofed, and RFC 2866 has no guidelines for determining which attributes identify "session".

There are many other failure conditions for Acct-Session-Id re-use. All of these failure conditions result in problems for RADIUS server administrators. Sessions may be marked stopped when they are actually ongoing, sessions for multiple users may be confused,

FreeRADIUS works around this issue by creating a unique-Acct-Session-ID attribute. This attribute is used internally and in the SQL schema, but is not sent in any packet.

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

Recommendations

We have a number of recommendations.

  1. The values for Acct-Session-Id should be globally and temporally unique.
  2. The values for Acct-Multi-Session-Id should be globally and temporally unique.

    3. One method of implementing these recommendations is to create values for these attributes via a strong pseudo-random number generator. There are many such generators available for free on the net.

    As a related note, we recommend that the lengths of values for these attributes be at least eight (8) characters, and no more than sixty-four (64) characters. Any less than eight may cause ID re-use. And any more than sixty-four characters may cause inter-operatibility problems with implementations that assume that the values for Acct-Session-Id are short in length.

    The key thing to note here is that RFC 2866 treats Acct-Session-Id as a token generated by the NAS, which has no meaning for any other entity in the RADIUS system. That is, for all parties, the Acct-Session-Id contains an opaque token which can be tested for equality with other tokens. However, the value of Acct-Session-Id cannot be meaningfully split into sub-tokens.

    This recommendation is therefore compatible with all existing RADIUS systems, and requires no modifications to any system other than the NAS which generates them.