Where supported by the Access Points, the Acct-Multi-Session-Id attribute can be used to link together the multiple related sessions of a roaming Supplicant. In such a situation, if the session context is transferred between Access Points, accounting packets MAY be sent without a corresponding authentication and authorization exchange, provided that Association has occurred. However, in such a situation it is assumed that the Acct-Multi-Session-Id is transferred between the Access Points as part of the Inter-Access Point Protocol (IAPP). How/where does RFC 3580 preclude it being used when reauthentication occurs? It just says it may be used "without a corresponding authentication and authorization exchange"? I would argue it really must stick over a reauthentication to work properly... Nick On Thu, Mar 27, 2014 at 2:12 AM, Alan DeKok <aland@deployingradius.com> wrote:
Nick Lowe wrote:
Nope. Acct-Multi-Session-Id handles IDs for multiple sessions. What does that mean? No one knows... the IETF RADIUS working group has had discussion on that topic, with no resolution.
For 802.1X purposes, it is, I thought, pretty well defined in RFC 3580... No?
The document has text. I'm not sure anyone implements it.
No. Every re-auth is a new connection. Always. Anything else is madness.
You have to correlate over these if you want to be able to limit the number of concurrent devices a user is allowed to have connected though, surely?
Each session should contain information about the device. That can be used to terminate old sessions, and move them to the new AP.
Certainly NASes that implement the Acct-Multi-Session-Id support persist that value across re-authenication whether there is an authorisation exchange or not.
RFC 3580 says that the Multi-Session-Id is used where there is no re-authentication. If there's no re-authentication, there's no authorization exchange.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html