From: Lothar Reith [mailto:email@example.com]
Sent: Friday, October 15, 2004 2:05 AM
To: Adrangi, Farid; 'Greg Weber'
Cc: 'firstname.lastname@example.org'; 'email@example.com'; 'firstname.lastname@example.org'
Subject: AW: -01 version of Chargeable User Identity
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
Von: email@example.com [mailto:firstname.lastname@example.org]
Gesendet: Mittwoch, 13. Oktober 2004 02:07
An: Greg Weber
Cc: email@example.com; firstname.lastname@example.org; email@example.com
Betreff: RE: -01 version of Chargeable User Identity
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. "
> -----Original Message-----
> From: Greg Weber [mailto:firstname.lastname@example.org]
> Sent: Tuesday, October 12, 2004 4:40 PM
> To: Adrangi, Farid
> Cc: email@example.com; firstname.lastname@example.org;
> 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
> -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.
> > Hi all,
> > The version -01 should appear on ID repository soon. In
> the mean time,
> > you can access the draft here :
> 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.
> 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
> - 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.
> to unsubscribe send a message to email@example.com 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 firstname.lastname@example.org with the word 'unsubscribe' in a single line as the message text body.