[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Geopriv]: Another review of the geopriv radius location attributes draft
It is very common practice to introduce Location resolutions from the
back-end systems through a RADIUS server and/or policy proxy. That is
where the data and intelligence lies and attribute "stuffing" is more
and more prevalent in these systems, particularly when the location
information requirements (generality/granularity) are variable depending
on the consuming entity and multiple policy-based correlations are used
to determine such designations (NAS-IP + Framed-Address subnet + proxy
target)
However, from a standards standpoint, it does not preclude someone from
developing proprietary policy and location logic and leverage attribute
manipulation to achieve your goals. NAS-level location data features
and formal AVP definitions for basic service information exchange is a
really good thing whether or not a company decides to preclude them by
some other proprietary manipulation. It sure does make first-mile
RADIUS diagnosis much easier. At least there is a solid value
definition and sound standards-based industry assessment to which we can
all use as a baseline.
-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of MORAND Lionel RD-CORE-ISS
Sent: Tuesday, November 09, 2004 1:50 PM
To: Hannes Tschofenig; geopriv@ietf.org; Adrangi, Farid
Cc: radiusext@ops.ietf.org; BOURDON Gilles RD-CORE-ISS; FOUQUART
Philippe RD-CORE-ISS
Subject: [Geopriv]: Another review of the geopriv radius location
attributes draft
Hi,
Here are "some" comments and questions on the location attributes draft.
As general comments:
- User location, network location, etc. should be clearly defined or
clarifed each time they are used.
- It seems that it is assumed that only the NAS can insert the location
information. However, it is likely that this information will be also
introduced by a local RADIUS server acting as a proxy (e.g. when the
exact location information is not available at the NAS).
- It is not described whether this location information will be included
in every access-request or only when some criteria are met e.g. based on
a given realm. It'd be intersting to spell out these criteria.
- If the use of location info in access-request could be optional, a COA
explicitly requesting this info (when not received in the initial
access-request) could be used by the Home RADIUS server.
*************
1. Introduction
Wireless LAN (WLAN) Access Networks (AN) are being deployed in public
places such as airports, hotels, shopping malls, and coffee shops by
a diverse set of incumbent operators such as cellular carriers (GSM
and CDMA), Wireless Internet Service Providers (WISP), and fixed
broadband operators.[skip]
[skip] Although the proposed attributes in this draft are intended
for
wireless LAN deployments, they can also be used in other wireless and
wired networks where location-aware services are required.
==> the need goes beyond location-based services for these networks. The
location information may be needed in any roaming situation, to enable
the home network to authorize/deny access based on the user's location
(network and/or geographical location), whatever the access network
technology.
Proposal: replace "where location-aware services are required" by
"whenever location information is necessary"
****************
3.2 Mid-session Delivery
Mid-session delivery method uses the Change of Authorization (COA)
message as defined in [RFC3576]. In accordance to [RFC3576], at
anytime during the session the AAA server may send the access network
a COA message containing session identification attributes (see
[RFC3576] for the possible options). The COA message may instruct
the access network to generate an Authorize-Only Access-Request
(Access-Request with Service-Type set to "Authorize-Only") in which
case it is instructing the access network to send the location
information attributes.
==> How does the AAA server instruct the access network to send location
information attributes within the new Access-Request? Is there any
specific attribute in the COA indicating that the location information
is requested? Or do you assume that any Access-Request sent by the NAS
will contain the location information attribute and so case 1 and 2 are
the same?
*****************
4.1 Use Case 1 - Use of Location Information in AAA
An Operator requires Location Informaion for Authorization and
Billing purposes. The operator may deny service if Location
Information is not available. Or it may offer limited service. The
NAS delivers Location Information to the Home AAA server.
==> Is there a way for the AAA server to indicate to the access network
that the request failed because the location information is missing?
The RADIUS server authenticates and authroizes the session. If the
user's location policies are available to the RADIUS server, the
RADIUS server may deliver those policies in an Access Accept. This
information may be needed if intermediaries or other elements want to
act as Location Servers (see Section 4.2). In the absence of
receiving the policies intermediaries MUST NOT divulge the location
information.
==> (1) the attributes that convey the policies in the Access-Accept are
not described.
==> (2) As stated in the section 6 (Policy-Information attribute),
policies can also be put by the access network and propagated with
Access-Request or Accounting-request.
Location Information may also be reported in accouning messages.
> edit "accounting"
Accounting messages are generated when the session starts, stops and
periodically. Accounting messages may also be generated when the
user roams during handoff. This information may be needed by the
billing system to calculate the users bill. For example, there may
be different tarrif rates applied based on the location and their
maybe different tax rates applied based on the location. Unless
otherwise specified, location information in the accounting stream
may not be transmitted to third parties.
The location information in the accounting stream MUST only be sent
in the proxy chain to the home network (unless specified otherwise).
==> Do the user's location policies received in the Access-Accept (in
the authorization phase) also apply to Accounting messages?
*******************
4.2 Scenario 2 - Use of Location Information for other Services
Location Servers are entities that receive the user's location
information and transmit it to other entities. For the purpose of
this scenario Location servers are the NAS, and RADIUS servers. The
RADIUS servers are in the home network, in the visited network, or in
broker networks.
Unless otherwise specified, excluding the proxy chain from the NAS to
the Home RADIUS, the Location Server may not transmit the location
information to other parties.
==> I think you mean: "Unless otherwise specified, the location servers
MUST NOT transmit the location information to other parties outside the
proxy chain between the NAS and the Home RADIUS server".
Upon authentication and authorization, the Home RADIUS may transmit
the Rule set in an Access-Accept to the other Location Server
allowing them to transmit location information. Then and only then
they are allowed to share the information.
==> Is it possible to discriminate parties allowed to distribute the
location information to third parties e.g. only the local access network
is allowed and not intermediary networks (e.g. brokers)?
Note since the NAS is the source of all Location information that is
disimenated by RADIUS, the NAS could tag the location information
with the location rules or a reference for the location rules
received in an Access-Accept. All location information in the
Accounting Stream will now be tagged.
==> Is it so sure that NAS is always the source of location information?
Couldn't we have scenarios where the location information is added by
the RADIUS proxy in the visited network, because the NAS is not able to
retrieve the user's location for instance?
***********************
5.1 Operator-Name Attribute
This attribute contains an operator name which uniquely identifies
the ownership of an access network. The Attribute value is a
non-NULL terminated string whose Length MUST NOT exceed 253 bytes.
The attribute value is comprised of the prefix and the identity,
separated by a colon. The prefix identifies the operator type;
example: GSM, CDMA, and REALM. The identity uniquely identifies the
operator name within the scope of the operator type.
==> What is the exact meaning of "operator type"? The operator name is
supposed to identify the owner of the access network. Therefore, instead
of GSM, CDMA and REALM, would it be better to define something more
generic describing the type of access network connected to the NAS?
This document defines three operator type prefixes which are: GSM,
CDMA, and REALM. The GSM prefix can be used to indicate operator
names based on GSMA TADIG codes. REALM can be used by any domain
name acquired from IANA. Possible forthcoming operator types MUST be
associated with an ogranization responsible for assigning/managing
operator names.
==> Is it really needed to have IANA assigned numbers for prefix (as
currently defined)? Prefix and name are just text information. It should
be up to the RADIUS end-points to use a common language. Ones could
decide to have something based on pref+ID, others something else (e.g.
country code+operator/network code).
**************************
5.2 Location-Information Attribute
This document describes two formats for conveying location
information: civil and geospatial location information. Section
5.2.1 defines the civil location information format. Section 5.2.2
defines the geospatial location information format.
Additionally, the Precision field provides further information about
the location information provided via Radius. For large networks
information about the location of the user can be provided in
different degrees of accuracy. This field gives a hint. Ideally the
location of the user is returned to the home network but in some
cases it might not be available. It has to be noted that the user
does not provide the location information itself.
==> (1) I don't understand the end of this paragraph! What kind of user
location are you referring to here? Whatever the precision and the
nature of the location information, the location of the user could
always be returned to the home network. Maybe you are talking about the
location of the user's end point (which could be far away from the NAS)?
==> (2) only two formats of location information are defined at this
stage: civil and geospatial. What about some "location ID" that could be
sent to the AAA server to retrieve location info? I mean that the
location info attribute may convey either explicit ("self-explicit")
location information or any identifier if there is a mean for the
receiver to extract explicit information from this ID, such as the
CellID in GSM.
*****************************
6. Policy-Information Attribute
In some environments it is possible for the user to attach
information about its privacy preferences. These preferences allow
the visited network, intermediate RADIUS proxies and the home network
to authorize the distribution of the user's location information.
==> How do these privacy preferences distributed by the
Policy-Information attribute in the Access-Request interact with the
policies being delivered by the Home RADIUS server in the Access-Accept?
*****************************
9.1 Operator-Name Attribute
Operator-Name Attribute SHOULD be sent in Access-Request, and
Accounting-Request records where the Acc-Status-Type is set to Start,
Interim, or Stop.
A summary of the Operator-Name Attribute is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Operator-Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
To Be Assigned by IANA - Operator-Name
Length:
>= 3
Operator-Name:
The text field contains an Access Network Operator Name in
prefix-based format as describe above.
Example: REALM:anyisp.com
==> If the prefix is put in the "Operator-Name" field in text format and
if it keeps the current signification, there is no reason IMHO to have
IANA-assigned numbers. Otherwise, we could have a separate field
describing the operator type (whaterver the meaning of this parameter)
as defined below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Operator-Type | Operator-Name
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*************************************
9.2 Location-Information Attribute
Location-Information attribute SHOULD be sent in Access-Request, and
Accounting-Request records where the Acc-Status-Type is set to Start,
Interim or Stop if available.
The Location-Information Attribute has two variations depending on
civil or geospatial location information. The format is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Code | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Location-Info ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits):
To Be Assigned by IANA - Location-Information
Length (8 bits):
>= 3
Code (8 bits):
Describes which location format is carried in this attribute:
(0) describes civil location information
(1) describes geospatial location information
All other bites of the Code field is reserved
and required for alignment.
==> it is proposed to add a value (2) for location ID
Precision (8 bits):
Describes which location this attribute refers to:
(0) describes the location of the NAS
(1) describes the location of the AAA server
(2) describes the location of the end host (user)
(3) describes the location of the network
==> What is the meaning of the fourth value? How could it be possible to
have less than the NAS or the visited RADIUS location information?
BR,
Lionel
--
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/>