Accounting-On and Accounting-Off being sent on a per-BSS basis not per-NAS

[Nick Lowe]

> Whoever (or whatever) configures hostapd already has an option of doing
> so with the nas_identifier parameter that is set for each BSS. I don't
> think hostapd should be modifying this parameter on its own (e.g., the
> proposal of adding a BSSID into this). This can have unexpected changes
> when upgrading hostapd without touching configuration. Please note that
> nas_identifier is used also for other purposes than RADIUS (mainly, FT
> key holder name).

I think that hostapd should append the BSSID to the end of the
NAS-Identifier, by default, if this is deemed a viable way forward so
that the default behaviour becomes compliant to RFC 2866.

The RFC has, after all, been amended by errata to explicitly state
that the current behaviour is not what is expected. 802.11r would be
unaffected if we use the unappended value for this.

> In general, it is a bad idea to change default behavior if there is a
> risk of it breaking something. I do not know what exactly the proposed
> new default behavior would be, but I find it difficult to see a clean
> solution for this that could automatically be determined in a manner
> that would cover all possible use cases. As such, I'd rather keep the
> current behavior as the default in the future as well.
>
> Please note that there are also devices that use multiple hostapd
> processes (one for each BSS), so the issue you describe is not going to
> disappear even if the default behavior within a single process would be
> changed.

There could be a configuration option to use standards compliant
RADIUS, disabled by default when undefined retaining the current
behaviour, but enabled by default in the default configuration.
This would ensure that there are no unexpected changes when upgrading
hostapd with an existing configuration.

If the BSSID were to be appended by default to the NAS-Identifier via
configuration going forward for new configurations, this would apply
to both single and multiprocess deployments and solve this
Accounting-On/Accounting-Off issue.

We shouldn't and it is in my view unrealistic to expect everyday
people to understand the nuance of RADIUS to configure this in a way
that avoids this problem.

I strongly agree that we need to get Subsystem-on/Subsystem-off
Acct-Status-Types defined as soon as possible.