IP-Address

[Alan DeKok]

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.