AW: Review of draft-ietf-geopriv-radius-lo-04.txt

["Tschofenig, Hannes" <hannes.tschofenig@siemens.com>]

hi bernard, 

thanks for summarizing the potential options regarding this particular issue. 

please find my feedback inline: 

> -----Ursprüngliche Nachricht-----
> Von: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] Im Auftrag von Bernard Aboba
> Gesendet: Samstag, 27. August 2005 02:43
> An: radiusext@ops.ietf.org; geopriv@ietf.org
> Betreff: 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. 

the problem was the following. the nas might support 
- civic location
- geospatial location
- both 
(or nothing) 

the radius server might also understand either civic, geospatial or both. 
when we tried to mandate civic location as the default that has to be understood i was told that this is not possible in all environments. geospatial is not possible as a default either. 

now, the idea was include something in the first exchange from the nas to the aaa server to allow the aaa server to determine whether he actually understands the format that can be provided by the nas. 

whether the desire to support this functionality justifies the introduction of an avp is subject for discussion. 
based on the feedback from the current mailing list thread at least you do not seem to be in favor of it. 

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

from previous discussions i remember that this was not the best approach particularly if many radius server want to obtain location information from the nas. 
 
> Alternatively if the authentication mechanism (e.g. EAP) supports 
> Access-Challenges, the RADIUS server can place a "Send 
> location" attribute in the Challenge.

this was the approach that was suggested to us in previous discussions. 
sounds good to me. 


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

i guess you would suggest to return an access reject if the the nas is unable to understand the returned location information format. 

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


sounds good to me. 

> perhaps specifying 
> more details on
> how location should be provided (e.g. Accounting-Stop only, interim
> records, civil/geographic, etc.).

this requirement hasn't be presented to me yet. 


> 
> 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 hope it is simple. 

ciao
hannes

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

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