[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: -01 version of Chargeable User Identity



Title: Message
Hi Lothar,
Thanks for your comments.   RADIUS does not support a generic capability advertisement.  However in this draft,  we can say that the NAS MUST send the CUI attribute with a nul value in the Access-Request, if it supports the attribute.  This indicates the home RADIUS server whether or not the NAS support CUI.  Will this address your concern?
BR,
Farid
-----Original Message-----
From: Lothar Reith [mailto:lothar.reith@nortelnetworks.com]
Sent: Friday, October 15, 2004 2:05 AM
To: Adrangi, Farid; 'Greg Weber'
Cc: 'radiusext@ops.ietf.org'; 'bernarda@windows.microsoft.com'; 'david.mariblanca@ericsson.com'
Subject: AW: -01 version of Chargeable User Identity

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