Re: Scope of applicability for CUI

[Emile van Bergen <openradius-radextwg@e-advies.nl>]

Hi,

On Sun, Dec 19, 2004 at 09:24:33AM +0200, john.loughney@nokia.com wrote:

> > By the way, what would be the meaning of CUI for "pay as you go"
> > type of approaches, e.g., micropayments or the like over EAP?
> > There might not be any billable user identity; the only thing
> > that could be provided in those cases is some kind of a session
> > identifier so that the home AAA and the NAS can correlate their
> > accounting records.
> 
> Correct, it could provide a session identifier; or more correctly
> a temporary billable session identity.  I haven't thought of all of
> the implications.
> 
> Actually, taking a step back, if there is a billable user identity,
> which is still needed in the pay-as-you-go case, then the CUI can
> be used to track & correlate accounting records.  This would be useful
> in cases when the user connects and disconnects several times, but
> the 'session' is longer than just one of the connection times. 
> For example, if you in a hotel and fire-up WLAN in the morning, then
> in the afternoon, then in the evening.  The 'session' might be your
> entire stay.

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

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.

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