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

[Nick Lowe]

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.

Eg:

Called-Station-Id: 40-18-B1-AB-CD-EF:MySSID

(BSSID: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.
To reconcile/link them to the subsequent accounting on a per-session
basis, it seems necessary.

The format is defined for auth under RFC 3580:

3.20.  Called-Station-Id

   For IEEE 802.1X Authenticators, this attribute is used to store the
   bridge or Access Point MAC address in ASCII format (upper case only),
   with octet values separated by a "-".  Example: "00-10-A4-23-19-C0".
   In IEEE 802.11, where the SSID is known, it SHOULD be appended to the
   Access Point MAC address, separated from the MAC address with a ":".
   Example "00-10-A4-23-19-C0:AP1".

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

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.

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

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.

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

If you make a configuration change that requires a BSS to go up and
down, they send an Accounting-Off and Accounting-On, expected
behaviour, but currently with the same Event-Timestamp with the two
packets being sent in very quick succession.

(Previously it was just two packets in quick succession with no
Event-Timestamp or Acct-Delay-Time.)

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.

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

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.

Thanks again! :)

Cheers,

Nick