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

AW: -01 version of Chargeable User Identity

Title: Nachricht
Hi Farid,
 
yes, your proposal that CUI-capable NASes SHOULD (or MUST ?) "always include a CUI-support-indication-attribute (-value) in every ACCESS-REQUEST"  would adress my concerns, but at a relatively high cost.
 
 This additional overhead may not be justifiable in all situations.
 
I would rather suggest that the Home-Radius - if he is not trusting the NAS having CUI-capability - SHOULD send an ACCESS REJECT with
-  a reject reason "CUI-support-required, with CUI support I would have accepted, please respond with a CUI-support-indication message immidiately" 
 
A CUI-capable NAS SHOULD react to such an ACCESS REJECT Message by informing the HOME RADIUS about it's CUI capability, such that subsequent authentication requests may be accepted by the Home-RADIUS with trust that the CUI will be presented in the corresponding accounting requests.
 
Infact, ideally a CUI-capable NAS SHOULD not immidiately reject the peer (supplicant), rather immidiately respond to the Home-RADIUS with a Dummy ACCESS-REQUEST including the CUI attribute to inform the HOME-RADIUS about CUI capability.
The Home-RADIUS SHOULD have queued the ACCESS-ACCEPT message just in case the untrusted NAS will respond with a CUI-capability-indication within a specific timeframe (requires a CUI-indication-response timer at the Home-RADIUS).
If that response arrives within the timer, the Home-RADIUS should send out all ACCESS-ACCEPTS queued for this "untrusted NAS" and add it to his list of trusted CUI-capable NASes.
 
A CUI-capable-NAS should - when sending the dummy-access-request - start a second timer, waiting for the ACCESS-ACCEPT associate with the original ACCESS-REQUEST.
 
This way, only the first authentication attempt from a previously CUI-capability-untrusted NAS will take a bit longer, and there is no need to burden all ACCESS-REQUESTS with the CUI attribute.
 
This would solve the backwards compatibility issue, as CUI-incapable NASes will receive an ACCESS-REJECT Message when they should reject the authentication attempt - for them it is just a new REJECT CAUSE, which should be no problem hopefully.
 
 
Lothar
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
-----Ursprüngliche Nachricht-----
Von: Adrangi, Farid [mailto:farid.adrangi@intel.com]
Gesendet: Freitag, 15. Oktober 2004 15:59
An: Reith, Lothar [HAHN:NGD:EXCH]; Greg Weber
Cc: radiusext@ops.ietf.org; bernarda@windows.microsoft.com; david.mariblanca@ericsson.com
Betreff: RE: -01 version of Chargeable User Identity

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