Re: Location draft issues raised today

["Bernard Aboba" <bernard_aboba@hotmail.com>]

> I agree that it would support the packing as it is, but I think the
> overriding criterium is whether or not the server wants access to
> individual members in order to apply administrator defined policy.

In this particular case, the question is whether the RADIUS server would 
need to define policy based on the individual geospatial and civil location 
elements.

For geospatial location, this would be equivalent to asking whether the 
RADIUS server would need to parse the geospatial data, or would just pass it 
to a location module for the authorization decision.  If we are talking 
about determining whether the geospatial location is within a well defined 
boundary (e.g. a manufacturing plant), then I suspect that a special module 
would make that determination, not a standard RADIUS server policy engine.  
While it is possible that the RADIUS server would want to ask questions like 
"Is the client above or below the equator?" I suspect that this will be 
relatively rare. So there seems to be a plausible argument that Geospatial 
location need not be parsed by the RADIUS server.

However, I do not think that this argument is as convincing for civil 
location.  For example, could RADIUS server policy depend on the country or 
state that the user is accessing the network from?  This seems somewhat 
likely.

> I am hesitant to make gratuitous changes to existing location data
> structures just to satisfy RADIUS historical practices.  Doing so
> would affect interoperability and implementation.  It would make
> location-based systems harder to implement, because of the pointless
> translation from location structures to RADIUS-friendly structures.

The location structures used in this document are largely derived from RFC 
3825 (Geospatial) and
draft-ietf-geopriv-dhcp-civil-09.txt.  However, in those documents, the DHCP 
server is providing data to the client, and therefore the policy issues 
discussed above did not come up.  Rather the issue was only the creation of 
UI for the administrator to enter the data.

However, there are substantial issues with attempting to allocate a single 
RADIUS attribute for each
Civil Address type (CAtype) described in 
draft-ietf-geopriv-dhcp-civil-09.txt:

a. It is possible for the attribute to refer to the NAS or user location, 
and therefore it is possible for both locations to be communicated in the 
same message. This implies that separating the elements would require a 
tagging format to be used.

b. There are a considerable number of CAtype values.  Aside from Country 
Code, there are 39 values allocated, with allocation of up to 254 value 
possible (the value 255 is reserved).   Therefore allocating CAtype values 
out of the standard RADIUS attribute space would in practice be difficult, 
because separate CAtype and RADIUS type allocations would be needed for each 
new value.  Also, the CAtype allocation collides with existing RADIUS type 
allocations defined in RFC 3575.  Therefore it is not clear to me that 
mapping the CAtype into the RADIUS type space is a good idea.

Given this, my conclusions are as follows:

a. Civil and Geospatial location should *not* be encoded in the same 
attribute.
b. Civil location should not be encoded as separate standard RADIUS 
attributes;  it is not even clear to me that a Diameter-compatible format 
(with grouping) would work well for this.



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