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

[Bernard Aboba <aboba@internaut.com>]

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.

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

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? 


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