On Feb 24, 2016, at 6:10 PM, Jouni Malinen <j@xxxxx> 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.
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
