Re: Scope of applicability for CUI

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

Hi,

On Tue, Dec 21, 2004 at 10:56:43AM -0500, Avi Lior wrote:

> I think we agree overall.

Indeed.

> See comments inline.

Same here.

> > -----Original Message-----
> > From: Emile van Bergen [mailto:openradius-radextwg@e-advies.nl] 
> > Sent: Monday, December 20, 2004 5:36 PM
> > To: Jari Arkko
> > Cc: Avi Lior; radiusext@ops.ietf.org
> > Subject: Re: Scope of applicability for CUI
> > 
> > 
> > Hi,
> > 
> > Ok, I understand that. But then it seems to me that CUI could 
> > get the exact same semantics of Class, with the exception 
> > that there may only be one instance present.
> 
> Hmmmmm....When explaining CUI to some folks I must admit that I said it was
> "Like Class but different".  The differences are what matter though.
> 
> Yes there is only one instance. But that is the least of the differences.
> Unlike Class, CUI is supposed to be interpreted by the client.  In so far
> that the client knows the CUI is assertion by the Home Network that this is
> a handle to a subscriber.

I still fail to see how the fact that the home network not only accepts
the user but has also associated the login with a 'subscriber' is
in any way interesting to any intermediate or the client.

The policies applied by the home AAA should be irrelevant to anyone
else, as long as 'accept' means that it's willing to accept the bill for
the session.

If the intermediate or client doesn't trust the home AAA in that, it
shouln't send requests there or act upon its accepts.

I fail to see how the fact that the home AAA has succeeded in
associating the login with anything is relevant to anyone else in the
chain.

The only use I can see for that is as was suggested by Jari, to
outsource the counting of sessions per 'user' (as defined by the home
AAA) from the home AAA to an intermediate or the client. In circumstances 
where the home AAA wishes to provide the key for the counter, CUI 
addresses that need.

> Clients must not modify CUI whereas they can modify Class providing they
> restore class in the accounting stream.

Right, this is in line with 'only one instance', so that the whole chain
sees the same thing, defined by the home AAA. 

> Clients that understand CUI must ensure that CUI is placed in the Accounting
> Packets.  With Class this is a SHOULD.

And a shame that SHOULD is. I know that the process would be difficult,
and that a MUST there wouldn't provide the other features CUI has over
Class, but as I said earlier, for new applications I'd always favour
tightening requirements like that to already implemented practice
(echoing Class is nothing new), than working around the problem by
creating a new application specific attribute.

It's not uncommon for roaming brokers to demand stricter conformance in
areas where that is required.

But it's a moot point here because of the other properties of CUI.

> > And I think to avoid the confusion, it should be made more 
> > clear then that CUI is only a communications device from a 
> > home AAA (at the time of accept) to a proxy AAA (at the time 
> > of accept and when accounting, via the NAS); for all 'normal' 
> > cases, Class should be used.
> 
> No I disagree strongly with that direction.  Class should not even enter
> this picture. It's role is to allow the issuer of the Class attribute to
> correlate accounting records for its own purpose.
> 
> I think people understand the purpose of class. We just explained in the
> document why we couldn't use class. But I feel that even that should not be
> present in the document.

I disagree. The document should do its utmost to explain when CUI offers
anything above Class. Class is more generic, and in most cases, more
flexible as every hop in the chain can do its own tracking using an
extra instance or by modifying the value. 

CUI is only more useful if you want to communicate one identifier,
defined by the home network, to the other parties in the chain.

> > An empty CUI as advertisement violates RFC2865 though, which 
> > says that empty string attributes MUST NOT be sent [p. 24]. 
> 
> I agree so we send a NULL.  Good point though, many people don't get that.  

Ah, the second L gave me some confusion. I associated it with SQL.
I think the ASCII mnemonic for the \0 character is NUL (one L).

> > I still think it's a bit weird for an intermediate to enforce 
> > a limit (on simultaneous use, no less) based on data supplied 
> > by the home AAA, instead of the home AAA enforcing that limit 
> > itself. With the use of CUI as in your example, iPass needs 
> > to  trust the home AAA that it doesn't simply generate a 
> > random CUI for every single authentication to thwart such a limit.
> 
> Absolutely.

[snip]

> > No need for trust, and no need for CUI; this actually seems a 
> > better solution for your scenario.
> 
> In the case where they are counting ports per ISP you are right. But that is
> not the scenario we are trying to solve.

[snip]

> CUI solves a problem that we know and understand today. It can be used for
> other purposes I am sure.  That is why we are very insistant that we don't
> tie its use specifically to EAP and 2486bis.

And the specific problem being solved is the client or intermediate's
ability to count ports per 'user' as defined by the home AAA? To allow
the home AAA to say, if you see this guy/CUI already logged in (and the
client knows with certainty whether or not it is), please ignore my
accept -- if the home AAA and the client owner have established such a
policy together?

In that case I think it's a good idea. However, I think it would be
valuable if we leave it as generic as that (ie. a device for the home
AAA to communicate a value at accept time to the other parties at accept
and accounting time), and allow any application that the chain may agree
on. Whether that's limiting or counting simultaneous use, fraud
prevention, or whatever.

And I also think that we shouldn't try to hide the fact that Class can
also solve a lot of the scenarios. It should be /very/ clear what the
differences and limitations are of each, eg.:

	Class can be used by a home AAA and any intermediate to
	provide itself, and itself only, with a cookie set at accept
	time and received at accounting time.

	CUI can be used by a home AAA to provide a value to the client
	and each intermediate, set at accept time and received at
	accounting time. It can be used at accounting time, and when
	receiving an accept, in deciding whether or not to honour it.

	The other properties of CUI follow from that: only one instance,
	and no modifications allowed.

	Because intermediates cannot add their own CUI, it cannot be
	used by intermediates to implement their own tracking schemes.
	In such cases they need Class, not CUI.

The advertising business is really a separate issue; considering Class'
SHOULD, it would also benefit from that.

At any rate, a document describing CUI that ignores Class, will waste a
lot of users' time on trying to use it when they should use class, and
vice versa.The differences are subtle, but important, and therefore they
should be discussed together.

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