RE: backwards compatible introduction of NEW attribute such as CUI

["Nelson, David" <dnelson@enterasys.com>]

Lothar Reith writes...

> Therefore, the "always advertise CUI" policy will have to be 
> implemented forever/until migrating to DIAMETER.
> - The same may apply to other new proposed attributes, such as 
> GeoPriv, etc etc

The requirement to advertise attribute support capabilities in this way is limited to a special class of attributes.  Attributes that may be required to be present in an Access-Request message (as "hints") in order for the RADIUS server to comply with its configured policy profile for the user, or group of users, is already covered.  If the required attributes are not present, an Access-Reject is sent.  Attributes that describe service provisioning are also covered, because NASes MUST treat an Access-Accept containing attributes describing unsupported services as an Access-Reject.  The case where explicit advertisement is required is the non-service describing attributes such as CUI.

Yes, it would be very convenient if RADIUS had the concept of "Mandatory" attributes that we find in Diameter.  That is one good reason to consider migrating to Diameter deployment.

> From the perspective of the RADIUS server, he may well need 
> absolute assurance that the NAS supports CUI, before he sends an 
> access-accept with a NAI that is insufficient for identification 
> of the user.

"Absolute assurance" is a strong term.  There is nothing that prevents malicious or defective NAS firmware from advertising support for CUI but not actually supporting it.  Therefore, the best that can be achieved in a protocol such as this is "relative assurance" based on implicit trust that the NASes your business partners, and their consortium members, are utilizing are reliable. 

> Question: Instead of allocating a new error code for every new 
> attribute, would it not be better to adopt a general approach, 
> which allows to include the missing attribute(s)in a Reject message
> with error cause 402 ?

True capabilities negotiation (e.g. as we find in PPP and similar protocols) might be a nice thing.  It is not clear to me that this enhancement is within the scope of the RADEXT charter or that there is consensus in the WG that RADIUS should be enhanced in such a substantial fashion.  Perhaps another reason to eventually migrate to Diameter?
 
> I still have some concern regarding the following "chicken and egg" 
> problem: Users will not see CUI benefits (in particular roaming-privacy)
> until a critical mass of network-access-providers adopts CUI with always 
> advertise policy.  Network-access-operators may hesitate to introduce an 
> always-advertise CUI policy before seeing any evidence that a critical 
> mass of users is requesting it.

This is true of any protocol extension.  It would be true of capabilities negotiation.  IMHO, we should only be working on extensions to RADIUS that meet a demand in the market, and will therefore achieve some reasonable level of quick deployment.  There's little reason to standardize enhancements that vendors will not implement.  :-)


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