[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: -01 version of Chargeable User Identity
> 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/>