RE: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt

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

Hi Bernard,  

> -----Original Message-----
> From: geopriv-bounces@ietf.org 
> [mailto:geopriv-bounces@ietf.org] On Behalf Of Bernard Aboba
> Sent: Saturday, August 27, 2005 6:55 AM
> To: radiusext@ops.ietf.org
> Cc: geopriv@ietf.org; Alan DeKok
> Subject: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt
> 
> > And blindly requesting for location information (as you 
> propose) I run 
> > the risk of having a rejection by getting to a NAS that does not 
> > support Challenge in the first place.
> 
> The only reason a RADIUS server will need to send an 
> Access-Challenge is if it *requires* location and it is not 
> present.  In that case, the RADIUS server cannot allow access 
> if location isn't provided.  

Not true at all!   A RADIUS server may require to get location but if it
does not that does not mean that its only action is to reject the
session.  It may still grant access but the access could be limited in
scope.

I can have a policy that states the service X may only provided at a
certain location.  I request for the location and if it is not provided
then I grant access but do not grant access to service X.

Blindly challenging the NAS -- requesting location without even knowing
whether the NAS even supports a challenge let alone location information
-- runs the risk of outright rejection of the session.

> If the RADIUS server doesn't require location, then it can 
> just request location in the Access-Accept.  If it gets it, 
> great.  If not, it is willing to live with out it. 

You mean for accounting purposes.  I am not even talking about that.
Above I am talking about needing location as part of the policy decision
function for granting access.
 
> In either case (mandatory or optional), capability 
> advertisement by the NAS is irrelevant. 

I disagree.  There is a distinct advantage of letting the RADIUS server
know whether or not the NAS supports a particular function.  Blindly
challenging should only be done in cases where the NAS does not support
a capability exchange mechanism.

 
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

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