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

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

 Hi Bernard,

Please see inline.

> -----Original Message-----
> From: geopriv-bounces@ietf.org 
> [mailto:geopriv-bounces@ietf.org] On Behalf Of Bernard Aboba
> Sent: Friday, August 26, 2005 8:43 PM
> To: radiusext@ops.ietf.org; geopriv@ietf.org
> Subject: [Geopriv] Re: Review of draft-ietf-geopriv-radius-lo-04.txt
> 
> In thinking about the problem of capabilities negotiation 
> within the RADIUS-GEOPRIV document, it is not clear to me 
> that it is necessary for a NAS to advertise location support. 
> 
> Instead, the NAS can be set by default not to send location 
> attributes unless the server asks for them.  The problem then 
> reduces to how the server communicates its needs to the NAS. 
> 
> There are several cases of interest: 
> 
> 1) The RADIUS server REQUIRES the NAS to provide location in 
> the Access-Request (e.g. it implements location-based access control).
> In this case the RADIUS server can send an Access-Reject with 
> an Error-Cause attribute with a value of "Location Required". 
> Alternatively if the authentication mechanism (e.g. EAP) 
> supports Access-Challenges, the RADIUS server can place a 
> "Send location" attribute in the Challenge.  On receiving 
> either of these indications, the NAS includes location 
> attributes in the Access-Request. 
> Note that the server's decision is not influenced by whether 
> the client has advertised location support, only by the 
> inclusion of location attributes in the Access-Request.

Access Reject case is grossly inefficient requiring the
re-authentication and is simply not acceptable in many deployement and
in particular in mobile deployements where authentication is resouce
intensive.

The Challenge Option is better but we will benefit in efficiency if the
home network knew whether or not the NAS supported the feature in the
first place.  After all, if you required location information, why would
you challenge a NAS that couldn't deliver the information?


> 2) The RADIUS server does not require location in the 
> Access-Request, but would like location attributes to be 
> included in Accounting packets, if available.  In this case, 
> the RADIUS server sends an Access-Accept including a "Send 
> location" attribute, perhaps specifying more details on how 
> location should be provided (e.g. Accounting-Stop only, 
> interim records, civil/geographic, etc.).

This would work but if the authentication is predicated on whether or
not I could have location in the accounting stream, then your scheme
would not work right?
 
> Since the RADIUS server does not require location attributes, 
> a legacy NAS can ignore the "send location" attribute with no 
> ill effects.  This is how legacy NAS implementations behave, 
> and the "Issues and Fixes" document indicates that this is in 
> fact the correct behavior.
> If the NAS does understand the "send location" attribute then 
> it will send location in the Accounting packets as requested.
> 
> Am I missing something, or is the problem really this simple? 

I think advertizement as described in the current Geopriv document is
well thoughtout.

I think the issue raised is whether or not to take care of it in the
End-to-End capability or in the document itself.


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