RE: Question on the Class attribute

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Vijay Devarapalli writes...

> It appears to me that RFC 2865 requires the class attribute, if
> used, to be the same in the Access Accept and the Accounting
> Request.

It requires that the RADIUS client (NAS or proxy) not change the content of
Class, and that it be passed intact in the Accounting-Request messages.
Class is a "cookie" between the RADIUS Server and the RADIUS Accounting
server, much as State is a "cookie" between the RADIUS Server (e.g.
Access-Challenge message) and the RADIUS Server (e.g. Access-Request
message).

> Our AAA server does not implement this attribute right now. We
> were asked to. I am trying to figure out what this attribute is
> about, where it is commonly used, etc...

It is used to "bind" sessions, as authorized by a RADIUS Server, to
accounting records, as logged on a RADIUS Accounting Server.

> However, it looks like the RADIUS AAA server behavior when the 
> value in the Class attribute in the Access Accept and Accounting
> Request does not match is unspecified.

That is correct, primarily because in the most general case there is no way
for the RADIUS Accounting Server to perform the "does it match" check.  It
takes the correct handling of the Class attribute by the NAS and by proxies
on faith, as that behavior is specified in RFC 2865.

There may be ways to detect broken behavior around the handling of Class
attributes by means of manual inspection of the server records.

There may be ways to automate the Class checking in the special case of a
tightly bound RADIUS Server and RADIUS Accounting Server, but that is beyond
the scope of RFC 2865 or RFC 2866.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>