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

[Alan DeKok]

On Feb 24, 2016, at 6:10 PM, Jouni Malinen <j at w1.fi> wrote:
> How would the hostapd behavior be contrary to the original intent if the
> original intent is ambiguous?

  Perhaps "common usage" is a better description.

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

  Exactly.

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

  This is largely what most APs do today.

> 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's nice to have a "bulk delete".  It also serves as a positive signal than sessions are stopped.

  Otherwise, when user A is on port 1 and the NAS reboots... the RADIUS server has no idea *when* user A is offline.  All it knows is that some arbitrary time later, user B logs into port 1.

  When did user A log off of port 1?  Some time between the last Accounting-Request for user A, and the first Accounting-Request for user B.

>> 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?

  No.  It takes years to get any attention to a problem in RADEXT, much less WG consensus.

  All we can say is that scoping of Accounting-On is outside of the historical usage of RADIUS.

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

  It's an optimization when the NAS reboots.  The NAS now has no idea who *used* to be logged in.  The RADIUS server does.  The Accounting-On message is an indication from the NAS to the RADIUS server of "yeah... forget everything I told you about all of those users".

  It means the "false login" time I discussed above is short.  And all of the user sessions are marked "stop" within ~5min of when they actually stopped.  Which is a good thing.

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

  Exactly.  Hence the "Subsystem-On / Off".  What's a subsystem?  Uh... here's a grab bag of attributes in the accounting packet.  Sessions which have similar attributes are for the same subsystem.

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

  Suggestions are always welcome.

  Alan DeKok.