Hi Jouni,
Respectfully ask you to reconsider.
There is very much a significant point to doing this, I definitely
feel that it is necessary and proportionate.
Yes, hostapd can be configured so that each NAS-Identifier is
different for each BSS, but nobody -ever- does this, people typically
consider the NAS as being the same thing as the RADIUS client in this
regard and use a constant value. That is what we need to correct.
Hostapd itself currently has no means to ensure that the
NAS-Identifier ends up being unique, pushing the problem elsewhere. We
shouldn't do that.
This adds negligible complexity to hostapd, stopping people from
hanging themselves if they use Accounting-On and Accounting-Off. (The
issue often presents itself as a subtle, hard to isolate bug.)
At the moment, we let people hang themselves. Not correcting this
status quo in hostapd is therefore a bad idea.
We, today, see Accounting-On and Accounting-Off nearly always being
sent on a per-BSS basis but with the same NAS-Identifier.
Therefore we either nee to:
a) Get a Subsystem-On and Subsystem-Off defined so that the
NAS-Identifier can be the same (which is likely going to take years to
sort).
-or-
b) We need to ensure that the NAS-Identifier is unique per-BSS going
forward (unless somebody goes out of their way to configure things
otherwise).
hostapd should be doing this by default for new deployments. For
compatibility purposes, older configurations that do not define
nas_identifier_use_bssid should continue to behave as today where they
have set a nas-identifier.
Hostapd currently allows no NAS-Identifier to be sent, the default
behaviour, which needs to be corrected so that this isn't possible as
it breaks RADIUS in many cases where this is missing. Using the BSSID
in that case seems the best fix.
I was thinking of something along the lines of:
if (!hostapd_config_get_radius_attr(req_attr,
RADIUS_ATTR_NAS_IDENTIFIER)) {
if (hapd->conf->nas_identifier_base) {
if (hapd->conf->nas_identifier_use_bssid == 1) {
len = os_snprintf(buf, sizeof(buf),
RADIUS_802_1X_ADDR_FORMAT ":",
MAC2STR(hapd->own_addr));
os_memcpy(&buf[len], hapd->conf->nas_identifier_base,
hapd->conf->nas_identifier_base_len);
len += hapd->conf->nas_identifier_base_len;
}
else {
os_memcpy(&buf[len], hapd->conf->nas_identifier_base,
hapd->conf->nas_identifier_base_len);
len = hapd->conf->nas_identifier_base_len;
}
}
else {
len = os_snprintf(buf, sizeof(buf), RADIUS_802_1X_ADDR_FORMAT,
MAC2STR(hapd->own_addr));
}
if (!radius_msg_add_attr(msg, RADIUS_ATTR_NAS_IDENTIFIER,
(u8 *) buf, len)) {
wpa_printf(MSG_ERROR, "Could not add NAS-Identifier");
return -1;
}
}
This code, and similar logic in one or two other places, really isn't
undue complexity.
The change to hostapd.conf is understandable, not unduly complex and
is backwards compatible.
# Optional NAS-Identifier, containing a string value used to identify the NAS
# originating RADIUS packets. This must be unique to the NAS within the
# scope of a RADIUS server. For example, a fully qualified domain name can be
# used here appended with the .
# Where nas_identifier has not been set, the BSSID will used.
# This will be of the form "00-10-A4-23-19-C0".
# When using IEEE 802.11r, nas_identifier must be set and be between 1 and
# 48 octets long.
#nas_identifier=ap.example.com
# Whether to use the BSSID in the NAS-Identifier sent in RADIUS packets.
# For example, where the nas_identifier is configured as ap.example.com, a
# value of the form "00-10-A4-23-19-C0:ap.example.com" will be used.
# Where mutiple BSSes are offered by a NAS, each BSS for which RADIUS accounting
# is occuring must be presented as being an individual NAS for Accounting-On and
# Accounting-Off to be handled correctly by a RADIUS server.
# This option has no effect where the nas_identifier has not been set.
# Where this is the case, the BSSID will always be sent.
# This will be of the form "00-10-A4-23-19-C0".
# 0 = disabled (default, for backwards compatiblity)
# 1 = enabled (best practice)
nas_identifier_use_bssid=1
Cheers,
Nick
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
