RE: Scope of applicability for CUI

[Avi Lior <avi@bridgewatersystems.com>]

Hi Emile,


> -----Original Message-----
> From: Emile van Bergen [mailto:openradius-radextwg@e-advies.nl] 
> Sent: Tuesday, December 21, 2004 3:14 PM
> To: Avi Lior
> Cc: Jari Arkko; radiusext@ops.ietf.org
> Subject: Re: Scope of applicability for CUI
> 
> 
> 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.

In order to support one of the cases this must happen no? Your acceptance of
the scenario that Jari presented (which is really my scneario) requires this
to happen.

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

I am not going to "battle" with you on this.
 
> If the intermediate or client doesn't trust the home AAA in 
> that, it shouln't send requests there or act upon its accepts.

If the world were only that simple.
 
> 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.

See your next remark.  If you agree with that then that should be good
enough no?

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

Be as it may there are two cases that have been articulated:
-Accounting case, where Accounting needs to be mediated, concoledated at
intermediares based on userids or a handle to the user; and the last case.
 
> > 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. 

Not sure I follow what you mean.

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

But even if you made the specs as tight as you wanted. Class does not
address the mail (as acknowledged by you).
 
> 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.

Right.
 
> > > 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. 

We already say why Class doesn't work in the document.  What we should not
say is "For all 'normal" cases use Class".  

Class has a purpose and that is articulated elsewhere.  


> 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).

Sure. Sorry for the confusion.

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

Yes. But some wanted the business justification. So read the latest draft
and tell us whether you find it offensive. 
 
> 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.

Yes. Stated in the draft when we explain why Class does not work.

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

Yes I think this is covered.

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

Already mentioned in the draft.

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

That is a given. We don't need to say that.  But it is also not true.  If
you know CUI is there you could use if for tracking.  Since CUI or CUI @
home realm is going to be unique I can use it for tracking.  So we don't
want to go and tell people what they ought to do with Class.  After all
Class maynot be used for tracking in the first place.  Class is a cookie
that is the best and safest way to describe it and its use.

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

Well as I said we say what CUI is for and we say why Class doesn't work. I
don't think we need to tell people how and for what to use Class.

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