[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Deployment (Was: Re: NAI decoration: User Identity issues)

> The primary problem is that RFC 2866 did not require that unrecognized
> attributes be copied verbatim to the accounting request packets. (Or
> am I missing some text somewhere?)

No you're not missing something.  Since unrecognized attributes can be
ignored entirely, it's possible that nothing at all may happen as a result
of sending them.

> So I agree that the NAS support for a new attribute which would have
> to be copied from Access-Accept to Accounting-Request is a problem.

It's only a problem if the RADIUS server requires this behavior.  But
we've already said that from the RADIUS server point of view, there is no
distinction between Billable Identity and Class.  They provide the same
functionality.  So a RADIUS server can send *both* Class and
Billable-Identity and be ensured that at least one of these will be
understood.

> bit mask) which would enable the server to know what the NAS
> can do.

This only helps if the attribute in question is really Mandatory.  But
Billable-Identity seems like it is optional.

> it isn't clear what to _do_ in the case when the NAS does
> not support it.

It's only a problem if the attribute MUST be supported by the NAS or
service cannot be provided (such as security-critical functionality).

So far quite a few attributes in the LAN attributes document fit in this
category (such as VLAN-related attributes or IP filters).  So that
document appears dependent on the resolution of this issue.  Note that in
this particular case the "RFC Compliance" argument doesn't hold.  It's one
thing to assume that a NAS with NAS-Port-Type of 802.11 or 802 is
compliant with RFC 3580; it's another thing to assume that they're
compliant with an extension document that may only reach a fraction of the
installed base.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>