Bernard,
I was indeed suggesting that a CUI creating RADIUS Server should keep state of trusted CUI-capable NASes, and therefore inherit the risk of an "old" NAS not presenting the provided CUI in the accounting requests. After all, it is himself or his user who probably asked for privacy protection which made the CUI necessary. The CUI creating RADIUS Server is basically a home RADIUS Server supporting roaming privacy - at least that is my point of view.
To the more general question, of the overhead potentially introduced by a "mandatory" CUI attribute I would like to comment as follows:
So far RADIUS does not support the concept of a mandatory attribute. I indeed proposed that the RADIUS server may enforce "mandatoriness" by sending a "conditional" REJECT, indicating via a Reject reason (or alternatively via the mandatory attribute being present), that this Reject is indeed a Reject which has only been sent because the sender was unsure if the receiver would interpret a certain attribute as mandatory when present in an ACCEPT message - otherwise an ACCEPT would have been sent.
When it comes to setting a precedence and more future attributes requiring to be interpreted as "mandatory" another possible solution may be to introduce a "Mandatory" attribute, and to include it into the Reject, followed by all mandatory attributes (optionally preceded by non-mandatory attributes). The NAS MAY convert such a "Conditional" REJECT into an ACCEPT if he supports all attributes following the Mandatory attribute. This would effectively convert a Reject with a Mandatory attribute into a CONDITIONAL REJECT, indicating to the NAS that a subsequent ACCESS ACCEPT with these Attributes with NUL-value present would result in an ACCESS ACCEPT.
Perhaps the NAS may even automatically convert the CONDITIONAL REJECT into an CONDITIONAL ACCEPT, if he supports the condition, without informing the RADIUS Authentication Server about it. The RADIUS Accounting Server will learn this via the Accounting Request messages.
I would be interested to hear if this could be a general method to solve the "mandatory/optional" backwards compabibility problem associated with the fact that it appears to be un-predictable if an unknown old NAS will reject or accept an Access Accept Message with a new attribute present, that he does not recognize.
On a different note:
Based on the comment, that the REJECT MESSAGE should be displayed, there are the following possibilities:
1. NAS should Diplay immidiately: "Please try again" (and should include the CUI-NUL attribute in the next Access REQUEST that may follow suit)
2. NAS should delay displaying the Reject, and wait for the response to a second ACCESS REQUEST (which he automatically produces, basically resending the previous ACCESS REQUEST but this time with a CUI NUL Attribute present).
3. NAS should autonomously convert the conditional REJECT into an ACCEPT and welcome the user as usual.
Lothar
(by the way announcing vacation till Nov 1)
-----Ursprüngliche Nachricht-----
Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
Gesendet: Mittwoch, 20. Oktober 2004 05:02
An: Greg Weber
Cc: radiusext@ops.ietf.org
Betreff: Re: -01 version of Chargeable User Identity
On Tue, 19 Oct 2004, Greg Weber wrote:
> > Overhead is not the issue -- the null CUI attribute will only
> > require 2 octets.
>
> The overhead is a potential issue if we are introducing
> a precedent that might be followed by many attributes
> in the future. The current suggestion seems to be that _every_
> Access-Request contain this advertisement (cf once per NAS which might
> be more reflective of capability).
I think your point about overhead is well taken. It's one thing to do this in a single case (CUI); it's another thing to set a precedent to be replicated again and again, on every RADIUS Access-Request.
Diameter can avoid this via capabilities negotiation (CER/CEA), but since RADIUS has no such feature, what do we do?
Are you suggesting that the RADIUS server keep state on NAS capabilities, by presumably mapping NAS-Identifer/NAS-IP-Address/NAS-IPv6-Address
attributes to various negotiated capabilities?
--
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/>