RE: -01 version of Chargeable User Identity

[Bernard Aboba <aboba@internaut.com>]

> As I stated it in my response to Barney's e-mail, I don't understand why
> the RADIUS server should ever reject a request because it contains a new
> attribute, not supported by the server.  In general, this should not be
> the expected behavior as it impacts the interoperability every time a
> new attribute is introduced.

There are two questions:  whether this is behavior that is commonly
implemented, and whether this is behavior that the IETF wishes to condone.
I agree that it seems like a bad idea, but of course that doesn't mean
that it isn't commonly implemented anyway.  I'd like to hear more from
RADIUS server implementers on what their implementations do.

> > In this particular case, my understanding is that the local
> > operator is
> > unwilling to provide service if the new attribute isn't
> > included, because
> > it does not feeling confident about payment.  So it seems to
> > me that an
> > Access-Reject might be the desired response.
> >
>
> I agree.  So, I think the proposal was that NAS advertises its support
> for the new attribute by sending a nul CUI.  And, the RADIUS will have
> the option to reject the request in the absence of the CUI.  Do you see
> any problem with respect to overhead resulting from the CUI
> advertisement here?

Overhead is not the issue -- the null CUI attribute will only require 2
octets.

A bigger question is the expected behavior by NAS and RADIUS server.

What is the purpose of the "null CUI" attribute in the Access-Request?  Is
this to inform the RADIUS server that the NAS supports CUI, in case the
RADIUS server supports it and wants to use it?  Or is it a statement from
the NAS that "the RADIUS server MUST support CUI or I won't provide
service."

The latter is more problematic, because the RADIUS server could send an
Access-Accept with no CUI attribute, and then wonder why the NAS never
sent an Accounting packet indicating that service started.  Or is the
intent for a non-supporting RADIUS server to send an Access-Reject?  If
so, then we need to verify that existing RADIUS servers that don't support
CUI actually behave this way.

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