[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Capabilities complexity summary
I think that Avi's point is that the desired result is *not*
Access-Reject in the particular scenario he describes: a roaming
consortium which contains none legacy, non-GEOPRIV NASes. The home
provider would *like* to use GEOPRIV information to authorize its
roaming customers, but doesn't want to risk annoying the customer by
denying any form of access when they happen to be roaming via a non-home
ISP that has legacy NASes.
It would appear to me that there are multiple ways to address this scenario
without additional complexity. At least four potential solutions come to
As has been pointed out, this problem would not exist if location
information were made available in the Access-Request. It's not clear to me
that the granularity of information required to make authorization decisions
represents a legitimate privacy concern.
It's worth pointing out that RFC 2865 requires that an Access-Request
contain at least one NAS identificaiton attribute: NAS-Identifier,
NAS-IP-Address, or NAS-IPv6-Address. Therefore some location-relevant
information is always present in an Access-Request. It is fairly routine
for providers to include location information in the NAS-Identifier
attribute, or to include a PTR RR in the DNS that maps the NAS-IP-Address to
a city, state and country. For example, "22.214.171.124" has a PTR RR for
Given this, it would seem that course-grained location information (e.g.
information at the state/city level) could be included in the Access-Request
by default without representing an additional privacy risk.
There are also ways to address the issue that do not require sending
location in the initial Access-Request. Since location is not required for
initial authorization, an Access-Accept is sent requesting location. This
allows the user to access the network. Location information, if
available, is then sent within the Accounting-Request and may be stored for
the duration of the session.
Access to location services can then be made available by one of the
1. An application-specific request can then be sent for the location-aware
services, which will be granted by a RADIUS server that has access to the
location information sent in previous Accounting-Requests.
2. An RFC 3576 DAC can upgrade the user authorizations once location
information is available.
3. The original Access-Request can contain a Session-Timeout attribute,
allowing re-authentication/re-authorization to occur once the location
information has been made available.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.