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

[Jouni Malinen]

On Wed, Feb 24, 2016 at 11:28:25PM +0000, Nick Lowe wrote:
> The Accounting-On is useful today on receipt after an unexpected
> reboot where Stops and an Accounting-Off will not have been received
> to mop up all stale sessions that pertain to the NAS without having to
> resort to timeouts. I certainly do not feel that it should be removed
> from hostapd therefore.

OK

> The salient consideration and concern here should be that, today,
> Accounting-On and Accounting-Off are handled by all the RADIUS servers
> that use them as applying to the whole NAS.

Sure, but what is "the whole NAS"? For hostapd, there is a RADIUS client
(and that seems to be equivalent to "a NAS" in some texts) per BSS, so
the behavior of sending out Accounting-On when a BSS comes up seems to
be valid in the sense of how RADIUS is used here.. Sure, there may be
RADIUS servers that have different view of what a NAS is (anything with
the same IP address? anything with the same NAS-Identifier? something
else?).

> It is for this reason that what hostapd does today ought to change.
> 
> There is no definition of what does or should constitute a session
> identifying attribute for Accounting-On and Accounting-Off. The RADIUS
> accounting RFC doesn't go here and doesn't touch on this critical
> point. The original intention of the accounting RFC, clarified with
> its author Carl Rigney, was that it would apply to the whole NAS.
> Thus, if somebody attempts to scope/limit by adding extra attributes,
> it is incompatible behaviour with nasty unexpected side effects when
> these are handled as applying to the whole NAS.

I don't think this discussion is going to be very fruitful before there
is matching view on what "the whole NAS" is and we clearly seem to have
quite different views on that.

I have no issues in adding a configuration parameter to disable
transmission of Accounting-On/Off per BSS (i.e., one could configure one
of the BSSes to transmit these and all others not do so).

I don't think I'd like to remove attributes that can identify the BSS
since it would be possible for a RADIUS server to use such information.
Similarly, I don't think that reference counting or some other ways of
trying to automatically figure out what should work with the RADIUS
server(s) is not going to work for all cases, so I see no point in even
trying to add such complexity when a simple yes/no configuration
parameter can be used to fine-tune this to whatever the operator
believes the particular RADIUS server(s) may expect.

-- 
Jouni Malinen                                            PGP id EFC895FA