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

[Alan DeKok]

On May 21, 2015, at 11:53 AM, Nick Lowe <nick.lowe at gmail.com> wrote:
> 
> Does the RADIUS spec prohibit accounting on a per-BSS basis, which is
> the basis of how all APs offer service to clients/stations (STAs)?

  It's silent on the topic.

> RFC 3580 does specify that Access-Requests will be scoped to a
> per-BSSID/per-SSID basis via the Called-Station-Id,

  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.

> so why not
> implement the same behaviour for accounting?

  It's not the same behaviour.

> In the Aerohive model, there are no central controllers - each AP is a
> RADIUS client.

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

  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.

> Without the Called-Station-Id, there is no specificity to an
> Accounting-On or Accounting-Off and they become a blunt instrument,

  That's how RADIUS works.  Any non-standard extension is non-standard.

> and actually rather useless/meaningless. It doesn't match how APs
> actually operate so things should change.

  Write an RFC. :)

> The RADIUS accounting spec was written long before wireless NASes
> existed, but I actually think that it would make sense for all
> wireless vendors to align to this model - scoping to the BSS with the
> Called-Station-Id and sending Accounting-On and Accounting-Off on a
> per-BSS basis (which means sent on a physical AP basis, even where
> it's actually transmitted by a central controller).

  Sure.  Write a document.

  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".

> This already happens for Access-Request packets, and
> Accounting-Request packets with Start, Interim-Update and Stop with
> most vendors in this space via the Called-Station-Id.

  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.

  What you're really looking for is a RADIUS message saying "all sessions matching X have stopped.".   There is no standard RADIUS way to do that.  You must write a new specification.

  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.

  Alan DeKok.