Nick Lowe wrote:
Pragmatically, you cannot treat the Acct-Session-Id as being unique for a session in real world vendor heterogeneous environments, it is guaranteed to be unique only on a per-NAS basis and there is a theoretical risk of collision between vendors where they use a similar method of construction. I could not see any advice on its construction in the RADIUS RFCs?
The RFCs are silent on a wide variety of topics. :(
The Acct-Multi-Session-Id was meant to, and does, solve this surely?
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.
As some NASes will perform a fresh authentication and authorization exchange yet conceptually the user still has the same 'connection',
No. Every re-auth is a new connection. Always. Anything else is madness.
I have supported roaming only where an Acct-Multi-Session-Id value is present and shouted at vendors where one has been missing and not used the Class attribute for this purpose.
Acct-Multi-Session-Id has no well-defined meaning. Most NASes don't support it.
Such NASes are unfortunately broken. They don't implement the RADIUS specs correctly. Sadly... there are many, many, NASes which don't implement RADIUS.
Should we make more of a concerted effort to call them out and open support cases over this?
Absolutely. I'd like to have Wiki pages saying "vendor X product Y firmware Z is broken". But much as people complain about docs, 1/100 people will update them.
Sure! Which NASes are you aware of that support the CUI attribute?
WiMAX ones. Alan DeKok.