RE: backwards compatible introduction of NEW attribute such as CU I

[Avi Lior <avi@bridgewatersystems.com>]

Bernard,

See comments inlien

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Thursday, December 16, 2004 3:29 AM
> To: Adrangi, Farid
> Cc: radiusext@ops.ietf.org
> Subject: RE: backwards compatible introduction of NEW 
> attribute such as CUI
> 
> 
> 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.

Assuming we still are going to do the advertizement part (under debate now).
2865 does not allow to send an empty string.

A String type must be 1-253 octets.

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

I agree with the first two sentences.

I don't think we want to restrict CUI to only 3579 based implementations.  
Still, that doesn't mean that CUI is designed to be implemented in all
RADIUS deployements blindly.
Operators, SDOs, will call out for CUI when they need it's supplied
functionality in their network whether or not they are using 3579.

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

This document is not addressing the needs of the home network.
Business Requirements in the proxy and visited network are driving the need
for the CUI 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.

Again we are debating the need having the advertizement. But assuming we
need advertizement then, the bussiness relationship will determine whether
the NAS sends the the CUI advetizement or not.  So when two operators have a
roaming agreement. If they determine that the CUI is needed, they will
arrange for their AAA infrastructure to support the CUI or not.  This is why
I don't think we need the advertizement.

If the home network knows that its partner needs the CUI it will deliver the
CUI in an Access Accept.  This is no different then when the home network
delivers a CISCO VSA when it knows that its partner is using a CISCO NAS and
requires the functionality provided by the VSA.




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

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