On Sep 18, 2015, at 6:43 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
What is the expected behaviour with Class attributes in accounting when 802.1X re-authentication occurs?
Class is for linking Access-Accept to subsequent Accounting-Request packets. It is not sent in later Access-Request packets.
The clients association/connection is not terminated, so, should we expect to see a Stop and a Start for the session? With many NASes I have empirically observed that we do not see this. In my opinion, we should not.
The RFCs are unfortunately silent on this topic.
In the case that accounting for the session carries on without a Stop and a Start, should then a NAS update the value of the Class attribute(s) that it accounts with based on new value(s) returned in the Access-Accept? In my opinion, yes, it should.
The RFCs are unfortunately silent on this topic.
I am not convinced therefore that the Class attribute should ever be used as part of a unique session key therefore.
Maybe. Since you control the Class attribute, you can send back the *same* Class in the second (and later) authentications.
A unique session key redoes what the Acct-Session-Id should be doing in the first place because of NAS deficiencies.
Yes. My $0.02 is that the Acct-Session-Id should probably be sent back by the RADIUS server in the Access-Accept. That way it's under the control of software which is properly written. But that's not going to happen.
My thoughts are that the default behaviour in FreeRADIUS should always be:
&Acct-Unique-Session-Id := "%{md5:%{User-Name},%{Acct-Multi-Session-ID},%{Acct-Session-ID},%{%{NAS-IPv6-Address}:-%{NAS-IP-Address}},%{NAS-Identifier}}"
I also should have mentioned before, that the NAS-Port-Id should be dropped too in addition to the NAS-Port.
Those are there for dial-up or DSL concentrators. They're useful for some people, and need to stay in. You're free to make changes to your local config, of course. Alan DeKok.