Subject: [Geopriv]: Another review of the geopriv radius location attributes draft

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Tue, 9 Nov 2004 22:50:06 +0100

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

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 9 Nov 2004 15:29:45 -0800 (PST)

> will contain the location information attribute and so case 1 and 2 are

RFC 3576 does not use attributes in the CoA-Request in order to request
attributes in a subsequent Access-Request.  Nor does it make sense to
include location attributes in a CoA-Request.  The session to which the
CoA applies is not selected using location attributes, nor is the request
that the NAS change its location -- "Please move NAS17483 to Cleveland,
Ohio."

> that the request failed because the location information is missing?

See RFC 3576 Error-Cause attribute, value 402 (Missing Attribute)

> retrieve the user's location for instance?

This seems quite likely, in fact.

> location of the user's end point (which could be far away from the NAS)?

I was confused about this as well.

> have less than the NAS or the visited RADIUS location information?

I don't understand this either.