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

[Jouni Malinen]

On Wed, Feb 24, 2016 at 09:22:29PM +0000, Nick Lowe wrote:
> hostapd is currently acting contrary to the original intent of RFC
> 2866 as it is sending Accounting-On and Accounting-Off
> Accounting-Request packets on a per-BSS basis and not on a per-NAS
> basis when accounting_init() is called from hostapd_setup_bss() and
> accounting_deinit() is called from hostapd_free_hapd_data().
> 
> I filed an errata against the RADIUS accounting RFC last year around
> APs that exhibit this behaviour as the original intent of the RFC was
> ambiguous.

How would the hostapd behavior be contrary to the original intent if the
original intent is ambiguous? In any case, whatever the original intent
may have been, it does not look like this really could have covered all
the cases that have shown up over the years with virtual interfaces,
supporting multiple networks in a single device, etc.

Please keep in mind that each BSS in hostapd has its own instance of a
RADIUS client. Each BSS can have different RADIUS server configuration
and just like a BSS is a virtual concept, a NAS could be similarly
virtual with NAS-per-BSS mapping being a possible interpretation. Each
BSS ("virtual NAS"?) can also use a different NAS-Identifier and even a
different IP address (both NAS-IP-Address and the source IP address of
the RADIUS message). As far as the current hostapd design is concerned,
there is a very clear NAS-to-BSS mapping, i.e., each BSS has its own
instance of a NAS/RADIUS client with completely independent
configuration for both the local identity (NAS-Identifier) and RADIUS
server.

> See: https://www.rfc-editor.org/errata_search.php?rfc=2866&eid=4485

> To solve this, I would suggest reference counting against RADIUS
> servers, sending Accounting-On as the first BSS comes up and
> Accounting-Off as the last BSS goes down. This must be tracked on a
> per-RADIUS server basis to be done correctly.

Wouldn't it be simpler to just stop sending Accounting-On and
Accounting-Off messages completely if they can cause issues for RADIUS
servers? The more I hear about the issues with those (like the earlier
discussion on races with Start/Stop and retransmissions), the less I see
how these would work in practice to get any good outcome. hostapd is
sending out Start/Stop messages for every session anyway.

> It is also incorrect to include a Called-Station-Id in
> Accounting-On/Accounting-Off to scope to a BSS as an Accounting-On
> cannot be sent on this basis.

Has there been any consensus check on this interpretation in a suitable
IETF group? I don't think I'd fully agree with the interpretation of a
single physical device with multiple radios (whether virtual or real)
always counting as a single NAS or that there wouldn't be a NAS per
BSS.

That said, I also realize that there are different ways of implementing
RADIUS clients for IEEE 802.11 APs. In some of the wireless switch cases
with a shared management entity, it may very well be the case that there
is a single RADIUS client (NAS?) per multiple APs and/or BSSs. However,
that does not mean that the design with a RADIUS client per BSS would be
any less viable option.

> Alan, really helpfully, put up the following about this issue:
> http://freeradius.org/rfc/acct_status_type_subsystem.html
> 
> Additionally, it does not seem correct to include a NAS-Port-Type in
> Accounting-On/Accounting-Off, nor WLAN-HESSID based on this context.
> 
> I am also incidentally curious now if the proposed Subsystem-on and
> Subsystem-Off should support nesting for layered, sub-dependent
> subsystems of a NAS.

I'm not sure I agree with the "sending one accounting packet for each
user is not scalable" part as far as IEEE 802.11 access points are
concerned. I never considered Accounting-Off (or -On) as an optimization
to avoid sending out Stop messages.

Without a much clearer definition of what a NAS, a subsystem, and a
session are (and especially when a session terminates), I'm not sure
this description would really result in much better situation.

If the proposed changes were to deprecate use of Accounting-On/Off and
add a clear description of how Subsystem-On/Off are to be used and if
there were also an example of how this maps to likely IEEE 802 use
cases, this would sound like a more useful direction to me.

-- 
Jouni Malinen                                            PGP id EFC895FA