RE: Capabilities: Summary - refined proposal

["Avi Lior" <avi@bridgewatersystems.com>]

Alan and Emile see below: 

> -----Original Message-----
> From: Emile van Bergen [mailto:openradius-radextwg@e-advies.nl] 
> Sent: Wednesday, October 19, 2005 6:22 AM
> To: Alan DeKok
> Cc: Avi Lior; radiusext@ops.ietf.org
> Subject: Re: Capabilities: Summary - refined proposal
> 
> Alan,
> 
> On Wed, Oct 12, 2005 at 07:50:36PM -0400, Alan DeKok wrote:
> 
> >   The capability being advertised, then, isn't location, but "can 
> > handled Access-Challenge responses to PAP, CHAP, MSCHAP requests".
> > 
> >   Once an implementation supports that, any server can 
> challenge the 
> > client with "hints", as described above.  A possible workflow is:
> > 
> >   C -> S: Access-Request
> > 		User-Name = foo
> > 		User-Password = bar
> > 		Capability = yes
> >   S -> C: Access-Challenge
> > 		Require-Location = yes    
> > 		State = abcd
> >   C -> S: Access-Request
> > 		User-Name = foo
> > 		User-Password = bar
> > 		Capability = yes
> > 		location = "moe's tavern"
> > 		State = abcd
> > 
> >   That proposal removes all of the functionality advertisement from 
> > the capability exchange.  I think the potentially infinite 
> list of "I 
> > support functionality foo" is the source of the disagreement.

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 strongly encourage all of us to be mindful of sending extra messages
because in large deployements this makes a big difference.


> >   In most situations, one party or other other will care 
> about 10% of 
> > the advertised capabilities, meaning the other 90% are irrelevant.
> > And having a potentially infinite list is problematic for 
> > implementations to manage, to say nothing of IANA.

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

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

> >   Comments?  Does this match your needs?

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



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