Fwd: [PATCH] Define the NAS-Port-Id RADIUS attribute.

[Nick Lowe]

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