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

[Alan DeKok]

On May 21, 2015, at 9:37 AM, Nick Lowe <nick.lowe at gmail.com> wrote:

> Thanks for the confirmation, Alan! :)
> 
> The Called-Station-Id is actually really useful as it defines the
> scope of the Accounting-On/Accounting-Off which are sent here on a
> per-BSS basis for the 802.11 NAS.

  That's a very non-standard use.  Accounting-On / Off is supposed to be for the entire NAS.  i.e. the WLAN controller / BSS.  Not for a particular SSID.

> Otherwise, I cannot see how you would properly handle the
> Accounting-On and Accounting-Off correctly as BSSes are brought up and
> down with a configuration change.

  The BSS should be the RADIUS client.

> I think it makes a lot of sense for Accounting-On and Accounting-Off
> therefore to include this in a Called-Station-Id attribute.

  Which, in the normal RADIUS model, is just the MAC address of the RADIUS client.  Which never changes.  So it's not really useful to send it.

> On the Aerohive front, all the RADIUS accounting will include an
> Event-Timestamp and Acct-Delay-Time in the forthcoming release, that
> isn't the case today.

  Wow... that's bad, but good they've fixed it.

> They have also added the Message-Authenticator AVP to non-EAP based
> Access-Request packets for the forthcoming release too. (Enabled as an
> option, disabled by default.)

  That's a good idea.

> There are a couple of other issues that I have noticed that will still
> need resolving in a subsequent release, things like the Accounting-On
> and Accounting-Off not being retried if no ACK is received.

  That's bad.

> In the beta that I am testing, they are now sending an Accounting-Off
> and Accounting-On at boot with the same Event-Timestamp in very quick
> succession. (They need to just send Accounting-On at this point
> really.)

  Accounting-Off is for when the NAS is about to reboot.  Accounting-On is for when the NAS has just booted.

> This could easily result in out of order receipt, it's UDP after all,
> or out of order handling at a RADIUS server due to threading. It's
> race prone.

  Yes.  They're better off just sending an Accounting-On message.

> I've suggested that they consider implementing the retransmission
> behaviour recommended in your excellent RFC 5080.

  Yeah... which is years old.

> I'm pretty confident they are on the case to improve things. I've been
> trying to identify and weed out issues so any others you notice it
> would be good to know about.

  They've been sending accounting "stop" packets after an Access-Reject.  Uh... no.  If the user was rejected, there's no session, and no need for a "stop" packet.

  I think I should write a "best practices" document for NAS vendors.

  Alan DeKok.