RE: Scope of applicability for CUI

[Avi Lior <avi@bridgewatersystems.com>]

Hi Emile,

I think we agree overall.

See comments inline.

> -----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,
> 
> On Mon, Dec 20, 2004 at 10:30:35PM +0200, Jari Arkko wrote:
> 
> > Avi Lior wrote:
> > 
> > >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.
> > 
> > Agreed. This is for me the prime reason why CUI is needed.
> 
> 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.
Clients must not modify CUI whereas they can modify Class providing they
restore class in the accounting stream.
Clients that understand CUI must ensure that CUI is placed in the Accounting
Packets.  With Class this is a SHOULD.

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

> 
> Let's try to work out your example a little. A proxy AAA like iPass' 
> could refuse to forward the accept towards the NAS if it 
> doesn't receive a CUI from the home AAA, and send a reject 
> instead. Ok.

Sure.
 
> Similarly, if it wants to get (some) certainty about whether 
> it can expect to receive CUI in the subsequent accounting 
> from the NAS, it could reject all requests from NASes that 
> don't advertise their support for echoing CUI by putting a 
> dummy CUI in their access requests.

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

> Any valid value should do though, the empty value conveys no 
> special meaning here. If the attribute is present at all, the 
> NAS indicates its support for echoing CUI. A single NUL 
> character SHOULD perhaps be used by NASes, but the receiver 
> MUST not attach any meaning to it for the purpose of 
> establishing the NAS' support for CUI.

Yes.

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

> If iPass would be smart, they would only limit things it can 
> actually count without trusting the home AAA. It knows eg. 
> when it sends an access request to which home AAA, and so 
> with /some/ certainty, it knows how many sessions are open 
> for a wholesale customer (if it doesn't miss too many Stop 
> records). Let it count the total number of simulatenous 
> sessions for a wholesale customer then, instead of for a 
> particular CUI, and let the customer's AAA enforce the limits 
> for its individual end users, using any policy it wishes to use.

Yes but they also want to enforce how many simultaneouse logins Joe has. So
they need CUI when EAP is used etc.  You may think that that is not smart
;-)
 
> 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.

> Are there any scenarios where 
> CUI-as-a-vehicle-between-home-and-intemediate offers perhaps 
> some more improvement? This is not rhetorical, but a honest question.

Not sure, and I hesitate to answer in fears of getting into a long delay.
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.

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