Re: Capabilities: Summary - refined proposal

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

Hi,

On Wed, Oct 19, 2005 at 12:06:58PM -0400, Avi Lior wrote:

> Alan and Emile see below: 
> 
> First of all you are advertizing but you are advertizing one capability.
> 
> But the affect of doing what you suggest is to force a challenge
> everytime.  This is problematic since we try to reduce the number of
> messages exchanged.  
> 
> Consider the prepaid case.  Here the AAA-Server will need to send
> attributes to the NAS to control the session.  Simply sending the
> prepaid attributes to the NAS could result in giving the user free
> service.  Since a NAS that does not understand the attributes will
> simply ignore them.
> 
> In the scheme proposed above the AAA-Server will always have to
> challenge for the NAS to see if it supports Prepaid.  So for the
> millions of prepaid users that attempt to login we will have to send
> millions of extra messages.
> 
> In our proposal the NAS will simply indicate right up front whether it
> supports prepaid or not.  Saving millions of messages a day.

I am not addressing prepaid here. Service limiting attributes are
another discussion. Please see my post to the 'Problem statement'
thread.

> I strongly encourage all of us to be mindful of sending extra messages
> because in large deployements this makes a big difference.

What makes you think we're not? "Won't somebody please mind the
roundtrips!" is getting, frankly, a bit repetitive.

> Yes but your proposal requires extra messaging.  And I think you are
> being over dramatic about an infitie list of implementations to manage.

My proposal is about the case where the NAS withholds information from
the initial access request, for privacy reasons. I'm talking about
GEOPRIV and related things, NOT prepaid.

In the case of GEOPRIV, and we've been at this at length, the case of
service being dependent on Location information CANNOT be implemented in
a single round trip AT ALL, because the NAS first needs to be informed
of the user's privacy policy -- in short, whether or not that NAS is
allowed to send the user's Location at all.

> > >   The above proposal should keep all of the capability 
> > exchange within 
> > > the current RADIUS data model, and won't require a new bit-array.
> 
> I don't see this.  You still need to define attributes for each
> capability.  For example,  you need to define an attribute for
> Location-Required  this is wasteful in two aspects:
> 1) It is wasteful on the attribute space (which is limited)
> 2) It is wasteful in the space required in the RADIUS messages.
> 3) And back to your IANA issue, IANA still needs to manage a potentially
> infinite number of attributes for this feature.

In my proposal, and that was the 'refinement' you were replying to,
there is no potentially infinite list of challenge cause attributes,
because that has other problems (the NAS ignoring attributes it does not
know about). See the mail you replied to.

Rather, there is a /single/ Challenge-Cause attribute with a potentially
'infinite' list of values. There are 4294967296 challenge causes
available, so I don't see the number space as a problem.

> So while it works -- I don't think this is a better apporach then what
> we have been proposing.

Alan's first attempt may not be, and it does not address mandatory
session limiting (can we please talk about that instead of including a
whole range of other issues by reference to the prepaid draft), but the
current proposal does solve GEOPRIV, in a generic way that also solves
other issues /that would already need challenges anyway/.

The best way to implement mandatory session limiting attributes is still
to be discussed, however, let's try to get agreement on the problem
statements first.

It would be a good start if you'd separate the two issues of GEOPRIV and
Prepaid. They have entirely different problem statements. I believe
Bernard suggested we get the problems clearly enumerated and defined
first, and then come up with precise, targeted solutions that are also
as generic as possible. A proposed solution may, may cover both
problems, but we're not nearly there yet.

Few seem to have joined you in blessing the original capabilities
advertising draft as a candidate for a solution that even reaches the
required level of precision and generality.

To do so is premature, and it would help if you didn't keep pounding on
it.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           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/>