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

RE: Scope of applicability for CUI



See inline.

> Why would any intermediate proxy want to do this correlation 
> using information supplied by the home AAA?

An intermediate proxy when seeing Authentication/Authorization traffic can't
correlated it to a specific user when methods such as EAP are being used.

The only thing a intermediary can do is use class to correlate an accounting
stream with a authentication stream. But it can't correlate that to a
specific user.

So if iPass wants to limit how many times John logs in (and they do) then
they would not be able to do so when certain EAP methods are being used.

Or if iPass wants to correlate all the accounting records for John (and they
do) then they would not be able to do so when certain EAP methods are being
used.

Class will not be able to help here at all.

This is not about what is happening in the home network.  If it was then we
would agree with you. And we would not be proposing CUI.  But its not about
the home network.

 
> If it wants to group them itself, it can do so using its own 
> instances of Class (remember RFC 2865's requirement that 
> ordering among multiple instances of attributes of the same 
> type is to be preserved, that multiple instances of Class may 
> be present, and that if you added any Class attributes in 
> Accepts, that you should strip yours again before proxying 
> Accounting records to home home AAA *)?
> 
> Why would an intermediate care how a home AAA decides to 
> group sessions? The home AAA does the accept for each 
> individual session.  As long as the home AAA can match each 
> accept it sends to the subsequent accounting records /for 
> that session/ from the NAS, it can group them any way it 
> wants. CUI would be quite a convoluted way to inform 
> intermediate AAAs of such grouping.
> 
> And about billing: if an intermediate AAA doesn't trust a 
> home AAA's accepts, it shouldn't send requests there.
> 
> If an intermediate AAA wants to prove that the accounting 
> records it sent to the home AAA are legitimate, it can a the 
> one time Class generated by the home AAA, saying, this is 
> what I got from you, nobody could have generated it but you, 
> and I'm not sending you more minutes in Acct-Session-Time 
> than you've provided in your Session-Timeout, so please pay me now.

You cant make that assertion about class received by other entities down
stream.  To do that you would have to understand what is in the class
attribute. 


But nevertheless we are not looking for the "test" you propose.


> Really, at one point I was convinced that CUI had some use, 
> but each scenario I hear lately is covered by Class.
> 
> Cheers,
> 
> 
> Emile.
> 
> *) and if we have a (SHOULD/MUST) problem at the layer of 
> transferring multiple instanes of Class in an orderly 
> fashion, we shouldn't try to solve that on a different layer IMHO.
> 
> Cheers,
> 
> 
> Emile.
> 
> -- 
> E-Advies - Emile van Bergen           emile@e-advies.nl      
> tel. +31 (0)70 3906153           http://www.e-advies.nl    
> 

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