RE: backwards compatible introduction of NEW attribute such as CUI

[Bernard Aboba <aboba@internaut.com>]

Farid Adrangi wrote:

"We are currently working on -03 version of the CUI draft.  Here is a
snippet on what we want to say about backward compatibility.

"
... Servers which do not understand the CUI attribute SHOULD silently
discard the attribute.

The NAS MAY include the CUI attribute with a null character for its data
field in the Access-Request message to indicate its support for this
attribute to the home RADIUS server.  In cases where home RADIUS server
cannot determine the NAS support for the CUI, if the CUI is required for
proper billing, the home RADIUS server MUST reject the request by sending
an Access-Reject message including an Error-Cause attribute [RFC3576] with
value 402 (decimal), "Missing Attribute".

Otherwise, the home RADIUS server MUST send both the UserName (1)
attribute and the CUI attribute, with the understanding that if the NAS
supports the CUI attribute the CUI attribute will override the identity
portion the UserName (1) attribute.  That is, the UserName(1) attribute
will be used for routing and the CUI attribute will be used for identity
purposes.
"

Before we get into developing a protocol (as suggested below) to determine
the CUI support, I would like to know why the above paragraph does not
address the backward compatibility problem."


Here are some issues with the above approach:

a. An empty CUI attribute should be used instead of an attribute with a
NUL character for the Access-Request.

b. RFC 2865 does not require servers to discard attributes they don't
understand; this is only a MAY.  So I don't think you can make discard
a SHOULD across the existing base of RADIUS servers.  That said, if the
use of CUI were restricted only to use by NASes and servers that already
support RFC 3579 and "Privacy" then such language might be more
reasonable.

c. If the RADIUS server needs information in the accounting record
why can't this be accomplished via use of the Class attribute?

d. My understanding is that the NAS is sending the empty CUI attribute in
order to signal the RADIUS Server that a CUI attribute is expected in the
Access Accept.  If this is correct, then to maintain backward
compatibility, the NAS should only signal CUI support when the
CUI is required.  For example, the NAS might only signal CUI support if
the client sends a "Privacy" NAI, and in that case (and only that case)
will the NAS treat an Accept-Accept without CUI as an Access-Reject.


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