[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on the Class attribute
Hi David,
David B. Nelson wrote:
Vijay Devarapalli wrote:
I had a question on the Class attribute [RFC 2865]. What should
the RADIUS server do if the Class in the Access Accept message
that it sent does not match with the Accounting Request message
that comes later?
Given that the RADIUS Accounting Server may be completely independent of
the RADIUS Server, how would a RADIUS Accounting Server, in the most
general case, be able to tell that the content of the Class attribute
had been modified? What session identifier information from other
RADIUS attributes would it use to make that determination?
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. I agree with you that if the Accounting Request goes to
a different server from the one that sent the Access Accept
message, this matching does not make sense. The use of this
attribute also may not make sense.
In the special case where the RADIUS Accounting Server is tightly
coupled with the RADIUS Server and has a priori knowledge of sessions
that the RADIUS Server has authorized, and therefore the intended value
of the Class attribute, it might be possible to take some action. In
these special cases it is not entirely clear what value exists in the
Class attribute.
I have no idea either.
Could you elaborate on a particular use case that exemplifies your
concerns?
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... 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.
Vijay
--
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/>