Acct-Authentic in Accounting-On and Accounting-Off forms of Accounting-Request. Valid?

[Nick Lowe]

>   No.  It says that Access-Requests *contain* a Called-Station-Id, which in turn contains a BSSID.  There's no concept of "scope".
>
>   The Called-Station-Id attribute helps to identify a unique user session.  But that's all.

A BSSID, by its very nature, scopes the authentication if present in
the Called-Station-Id along with the SSID. It's implicit that that
happens. It doesn't have to be stated explicitly anywhere therefore,
surely? It's the nature of what using the BSSID/SSID does.

>   It's not the same behaviour.

By implement the same behaviour, I meant include a Called-Station-Id
with the same format in both auth and accounting for a session.

>   Then when the AP reboots, it sends an Accounting-On message.  If a radio box reboots... RADIUS is silent on what happens.

The RADIUS spec doesn't seem to require that a reboot has happened, or
is about to happen?

>   If the AP controls 5 radios, and one radio reboots, there is *no* standard RADIUS way of dealing with that.  If the AP sends an Accounting-On packet, it's arguably wrong.  Because the AP hasn't rebooted.

Same point as above.

>   Write an RFC. :)

>   Sure.  Write a document.

Fair point, I certainly think it needs clarifying in the interests of
interoperability and uniformity, however that concludes.

>   It's probably wrong to use an Accounting-On message.  That already has existing meaning.  Instead, there should be a new Acct-Status-Type defined.  Call it something else, like "portions of a NAS have rebooted".

I guess you're right, it has traditionally been tied to a reboot of
the NAS even if not explicitly stated

>   No, it doesn't happen in Access-Request or Accounting-Request packets.  Those contain session identification attributes.  What those attributes are is unspecified, but typically things like Calling-Station-Id and Called-Station-Id.  What those attributes contain is also largely unspecified.  Their format is defined, but often not their contents.
>
>   i.e. you're giving *meaning* to those attributes.  That's nice, but there's no reason to believe your conclusions are correct.  It's RADIUS.  Very little makes sense.  Other people can (and have) come to completely different conclusions.

I only meant that this does already happen for -most- wireless NAS
vendors in the way that they use-and-include the Called-Station-Id in
Access-Request packets and Start, Interim-Update and Stop forms of
Accounting-Request packet.

>   To be honest, I'm inclined to just start writing specs and putting them up on freeradius.org.  There are dozens of things which the IETF will never standardize, but which will be useful for many vendors.

That would be seriously awesome.

Cheers,

Nick