Farid,
I think we are talking about a backwards compatibility issue here.
In this context, I do not think your below proposal of adding the words "and supported by NAS" is a good idea. It is equivalent to allow the NAS to just ignore a CUI attribute present in an ACCESS ACCEPT.
The key question is if it is acceptable to the Home-RADIUS, that the NAS accepts the user but does not support (and therefore accept) the CUI attribute - and therefore does not provide the CUI in the corresponding ACCOUNTING REQUEST messages (Start, Interim, and Stop).
I do not think that this is acceptable to the Home Network.
If it was acceptable, the Home-RADIUS would not need to send the CUI in the first place.
I beleive it is not acceptable for the Home-Radius to find out only when receiving the RADIUS Accounting Start Request Message (i.e. after the fact of admitting the user) that he does not have a chargeable-identity for the currently already ongoing usage - and therefore can not charge for that usage.
In consequence, I think some kind of CUI capability discovery procedure needs to be performed, that allows the Home-RADIUS to discover if a NAS supports CUI. In this case, the Home-RADIUS would only send the CUI when the NAS supports CUI, otherwise reject the Authentication Request in those cases where the Home RADIUS considers that a CUI is necessary.
Alternatively, potentially a large number of NASes may have to be upgraded to understand that an ACCESS ACCEPT message with a CUI attribute present MUST actually be interpreted as an ACCESS-REJECT Message if the NAS does not support copying the CUI attribute unmodified as received into all accounting requests.
Blair - I also just read your "rambling" mail to this topic: if I understand you correctly, your main point is that you need the CUI. I further understand that the CUI - if present - will be the only identity which is guaranteed to have the quality "never modified", neither by the peer nor by any intermediary.
I conclude therefore, that it is not acceptable that the NAS ignores the CUI - after all it is a serious "modification" by the NAS to just "delete" the CUI - which is what would appear to the Home-Network as effect of the NAS "ignoring" the CUI but still accepting the user.
my 2 (Euro-) Cents
Lothar
-----Ursprüngliche Nachricht-----
Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
Gesendet: Mittwoch, 13. Oktober 2004 02:07
An: Greg Weber
Cc: radiusext@ops.ietf.org; bernarda@windows.microsoft.com; david.mariblanca@ericsson.com
Betreff: RE: -01 version of Chargeable User Identity
Hi Greg,
Thanks for reviewing the draft. I see your point. Does it help if we say something like:
"
The NAS MUST include this attribute in the Accounting Requests (Start, Interim, and Stop) messages if it was included in the Access Accept message and supported by NAS. "
BR,
Farid
> -----Original Message-----
> From: Greg Weber [mailto:gdweber@cisco.com]
> Sent: Tuesday, October 12, 2004 4:40 PM
> To: Adrangi, Farid
> Cc: radiusext@ops.ietf.org; bernarda@windows.microsoft.com;
> david.mariblanca@ericsson.com
> Subject: Re: -01 version of Chargeable User Identity
>
>
>
> Hi Farid,
> A question on how -01 attempts to resolve a particular
> part of issue #14.
>
> From -00:
> The NAS or the access network AAA server MUST
> include this attribute in the Accounting Requests (Start,
> Interim, and Stop) messages if it was included in the Access
> Accept message.
>
> From #14:
> [BA] I don't understand how backward compatibility is achieved.
> How is a RADIUS server to know whether the NAS supports the CUI
> attribute?
>
> -01 adds:
> In cases where the home RADIUS server cannot determine the NAS
> support for CUI attribute, it MUST send both the UserName (1)
> attribute and 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.
>
> But the additional text does not obviate the still existing excerpt
> from the -00 draft. -01 still says that the NAS MUST send the new
> attribute if it is received and that is a compatibility problem.
>
> Greg
>
> >
> > Hi all,
> > The version -01 should appear on ID repository soon. In
> the mean time,
> > you can access the draft here :
> >
> http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char
geable-use
> r-id-01.txt.
>
> The -01 update addresses the two issues (issue 13 and 14) submitted
> against the draft by David and Bernard respectively - please see
> http://www.drizzle.com/~aboba/RADEXT/#Issue%2014 for the detailed
> descriptions of the issues.
>
>
> Bernard,
>
> Regarding two of your comments,
>
> - Made a clarification on encoded format for CUI string. But, we
> weren't sure if you were also questioning the proposed XX:YYYYYYYYYY
> format rather than just NAI or other encoding supported
by
> Username.
>
> - Diameter translation /CoA message comment, are you suggesting to
> prohibit the user of the attribute in COA/Disconnect message? Please
> note that the CUI is for identifying the user session than username.
>
> BR,
> Farid
>
> --
> 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/>