| Message ID | CAGnO3doQbbKyuS5LgQ1g+x_aPNcdJBLme8oPLFP1ggce6Yk_iw@mail.gmail.com |
|---|---|
| State | Changes Requested |
| Headers | show |
On Sat, Feb 06, 2016 at 11:54:03AM +0000, Nick Lowe wrote: > There is then a need to, subsequently, add code to actually send this > attribute in Access-Request and Accounting-Request packets, populated > with the ifname. What would be the use for NAS-Port-Id? RFC 2869 seems to imply that either NAS-Port or NAS-Port-Id would be included, but not both. There is already code to add NAS-Port.. Furthermore, NAS-Port-Id seems to be described as a fallback option if the "ports" cannot be numbered. > Correction is also needed for the NAS-Port attribute at this is > presently included with a value of 0 where the association id is not > available. Either the attribute should not be present when that occurs > (which is most of the time), or it should contain the ifindex (better) > for the virtual interface. The current implementation does not comply > with RFC 3580 by sending 0. With drivers that use hostapd for AP SME, the AID should always be known for the normal association case. For RSN pre-authentication, there is no AID and it would probably make sense to drop NAS-Port completely since that authentication is not for an immediate data connection. With drivers that implement AP SME internally, the AID may not be known to hostapd. Since this can be determined when starting the AP, all NAS-Port values from such an AP could be changed to use the ifindex of the wlan# interface or port number of the bridge if that interface is in a bridge. That said, neither of these are necessarily fixed values, i.e., they may change for each restart of hostapd.. As such, I'm not sure what value these would have for the RADIUS server. Then again, that would also apply for Association ID. I don't see how the RADIUS server would behave any differently based on the exact NAS-Port value with a NAS that is an IEEE 802.11 AP.. > We need to continue to ensure and be careful that the NAS-Port value > is consistent in Access-Request and subsequent Accounting-Request > packets. That is not the case with IEEE 802.11.. The Association ID can change for each re-association and a single EAP authentication can be shared between multiple re-associations. In other words, NAS-Port used in Accounting-Request for a specific session that uses the same Acct-Multi-Session-Id with a single authentication exchange can be different.
Forgot to copy the list in, oops. So the salient point here: if the NAS-Port and NAS-Port-Id was going to change while populated with ifindex and ifname, we would expect to see a Stop and a Start for the related session with the same Acct-Multi-Session-Id. Cheers, Nick On Sun, Feb 7, 2016 at 10:46 AM, Nick Lowe <nick.lowe@lugatech.com> wrote: > Hi Jouni, > > It is perfectly legal and good practice to send both. The 'or' > definitely does not mean one-or-the-other. > > We see the same language used with: > > "Either NAS-IP-Address or NAS-Identifier MUST be present in a RADIUS > Accounting-Request." > > Later, however, we see: > > "[Note 1] An Accounting-Request MUST contain either a NAS-IP-Address > or a NAS-Identifier (or both)." > > The or there does not mean one-or-the-other. It is poorly worded. > > There is also clarification of expected behaviour is in RFC 3580 for > NAS-Port and NAS-Port-ID. > > 3.4. NAS-Port > > For use with IEEE 802.1X the NAS-Port will contain the port number of > the bridge, if this is available. While an Access Point does not > have physical ports, a unique "association ID" is assigned to every > mobile Station upon a successful association exchange. As a result, > for an Access Point, if the association exchange has been completed > prior to authentication, the NAS-Port attribute will contain the > association ID, which is a 16-bit unsigned integer. Where IEEE > 802.1X authentication occurs prior to association, a unique NAS-Port > value may not be available. > > 3.29. NAS-Port-Id > > This attribute is used to identify the IEEE 802.1X Authenticator port > which authenticates the Supplicant. The NAS-Port-Id differs from the > NAS-Port in that it is a string of variable length whereas the NAS- > Port is a 4 octet value. > > Conceptually and abstractly, the NAS-Port should contain the > association id only when it is available. When it is not, we need to > do something sensible. > Presently, hostap will usually always send 0, which is invalid. It > makes more sense to send the ifindex rather than omit the attribute. > This allows us to distinguish sessions by virtual interface (aka VAP) > at the RADIUS server. It is useful from a compartmentalisation > perspective, and can be used when constructing a GUI to show live > sessions that are being accounted for. > > The NAS-Port-Id, again allows us to distinguish sessions by virtual > interface (aka VAP), but can contain a human readable and friendly > ifname showing the radio and virtual interface index. > For example: wifi0.1, wifi1.1 > > It is again useful from a compartmentalisation perspective, and can be > used when constructing a GUI to show live sessions that are being > accounted for - this time with that friendly name. > > The key point is that we should not change the value of the NAS-Port > attribute that is accounted with once we start sending it for an > individual session. This is because breaks many, many things at RADIUS > servers in the default configuration. > > For example: > > http://freeradius.org/radiusd/man/rlm_acct_unique.txt > > When a related session is created, however, for which we must see a > Stop and a Start and with the same Acct-Multi-Session-Id, it is > perfectly fine and usually expected for the value to be different. > > Cheers, > > Nick
diff --git a/src/radius/radius.c b/src/radius/radius.c index 266b29f..440f958 100644 --- a/src/radius/radius.c +++ b/src/radius/radius.c @@ -229,6 +229,7 @@ static const struct radius_attr_type radius_attrs[] = RADIUS_ATTR_HEXDUMP }, { RADIUS_ATTR_ACCT_INTERIM_INTERVAL, "Acct-Interim-Interval", RADIUS_ATTR_INT32 }, + { RADIUS_ATTR_NAS_PORT_ID, "NAS-Port-Id", RADIUS_ATTR_TEXT }, { RADIUS_ATTR_CHARGEABLE_USER_IDENTITY, "Chargeable-User-Identity", RADIUS_ATTR_TEXT }, { RADIUS_ATTR_NAS_IPV6_ADDRESS, "NAS-IPv6-Address", RADIUS_ATTR_IPV6 }, diff --git a/src/radius/radius.h b/src/radius/radius.h index f14de53..09b674a 100644 --- a/src/radius/radius.h +++ b/src/radius/radius.h @@ -89,6 +89,7 @@ enum { RADIUS_ATTR_USER_NAME = 1, RADIUS_ATTR_MESSAGE_AUTHENTICATOR = 80, RADIUS_ATTR_TUNNEL_PRIVATE_GROUP_ID = 81, RADIUS_ATTR_ACCT_INTERIM_INTERVAL = 85, + RADIUS_ATTR_NAS_PORT_ID = 87, RADIUS_ATTR_CHARGEABLE_USER_IDENTITY = 89, RADIUS_ATTR_NAS_IPV6_ADDRESS = 95, RADIUS_ATTR_ERROR_CAUSE = 101,
There is then a need to, subsequently, add code to actually send this attribute in Access-Request and Accounting-Request packets, populated with the ifname. Related... Correction is also needed for the NAS-Port attribute at this is presently included with a value of 0 where the association id is not available. Either the attribute should not be present when that occurs (which is most of the time), or it should contain the ifindex (better) for the virtual interface. The current implementation does not comply with RFC 3580 by sending 0. We need to continue to ensure and be careful that the NAS-Port value is consistent in Access-Request and subsequent Accounting-Request packets. --- Define the NAS-Port-Id RADIUS attribute. Signed-off-by: Nick Lowe <nick.lowe@lugatech.com> --- src/radius/radius.c | 1 + src/radius/radius.h | 1 + 2 files changed, 2 insertions(+)