[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: -01 version of Chargeable User Identity
Hello,
On Thu, Oct 21, 2004 at 10:51:22PM -0700, Bernard Aboba wrote:
> > I still don't understand the local (ie, NAS) problem. It's not going
> > to bill the end user directly, in any scenario that makes business sense.
> > If for no other reason, it has no billing address or credit card number,
> > just, even given CUI, joeblow@example.com. So for whom is CUI intended?
>
> Well, the original request was for the authors to explain the problem in
> their draft, and for the WG to read their explanation and opine as to
> whether the problem statement is convincing. So the authors
> really need to answer that question to the WG's satisfaction if this draft
> is to become a WG work item. The other alternative is for the WG to
> reject the submission, either for consideration as a WG work item, or for
> allocation of an attribute type under RFC 3575.
>
> Since the GSMA asked for this, we owe them an extra dollop of due diligence --
> and therefore the attempt to determine whether there are any scenarios in
> which the CUI attribute is needed.
>
> In the last few emails, I think we've established that if the local realm
> and home realm are doing business directly then the home
> realm can send Class and get what it needs and as far as I can see, there
> is no need for CUI.
>
> But what if the local server bills an intermediary? Then it can't
> necessarily be sure that the intermediary and home server are in agreement
> on what is to go into the Class attribute.
But the intermediate can add its own unique Class attribute to responses
going back from the home server to the local NAS, can it not? And then
it has all the information it needs when the accounting packet comes.
> In other words, Class could be meaningful to the home server, but not
> to the intermediary. If the intermediary and home server have
> arrangements that relate to things like simultaneous usage, then the
> intermediary may not be able to carry out those agreements without a
> meaningful username.
The intermediate proxies based on certain criteria, so I'd say it should
also be able to track sessions using those same criteria? (Modulo the
stale session problem, but CUI doesn't intend to help there).
> I accept your argument that the local server may not care about whether
> it can confirm a billable identity or not. If there is some
> kind of monthly report required, the local realm can generate that report
> based on the class attribute(s), by pre-arrangement with the home realm.
>
> > What does "assurance" mean? Does it mean that somehow the Access-Accept
> > is more trustworthy because the home server said it was joeblow@example.com
> > rather than just anony.mouse@example.com? Why does the NAS's owner care?
>
> "Assurance" means that the local server has fulfilled the terms of its
> obligation to the entity that it bills. If this is the home server, then
> I think there is no need for CUI, since echo'ing the Class attribute
> should give the home server whatever it might need.
>
> However, if the payor is an intermediary, then the Class attribute may not
> be sufficient.
Not the single class from the home server, but the intermediate can add
its own instance of Class. 2865 and 2866 say it's a 0+ attribute after all,
and ordering is to be preserved anyway.
If it doesn't trust the local NAS and server to be standards compliant,
it can prepend its own data to an existing Class using a separator; as
long as the home server sees the same Class it sent earlier, the
intermediate can pull any stunt he wants. But that's for the
administrator of the intermediate to decide.
Therefore I would say the intermediate too has all it needs to help it
with tracking things, including the ability to match unique responses
from the home server to accounting packets from the local NAS/proxy.
Kind regards,
Emile van Bergen.
--
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/>