draft-ietf-geopriv-lbyr-requirements-06.txt   draft-ietf-geopriv-lbyr-requirements-07.txt 
GeoPriv R. Marshall, Ed. GeoPriv R. Marshall, Ed.
Internet-Draft TCS Internet-Draft TCS
Intended status: Informational February 26, 2009 Intended status: Informational February 26, 2009
Expires: August 30, 2009 Expires: August 30, 2009
Requirements for a Location-by-Reference Mechanism Requirements for a Location-by-Reference Mechanism
draft-ietf-geopriv-lbyr-requirements-06 draft-ietf-geopriv-lbyr-requirements-07
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 3, line 18 skipping to change at page 3, line 18
to Location-by-Reference approach using a location URI to handle to Location-by-Reference approach using a location URI to handle
location information within signaling and other Internet messaging. location information within signaling and other Internet messaging.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview of Location-by-Reference . . . . . . . . . . . . . . 8 3. Overview of Location-by-Reference . . . . . . . . . . . . . . 8
3.1. Location URI Usage . . . . . . . . . . . . . . . . . . . . 9 3.1. Location URI Usage . . . . . . . . . . . . . . . . . . . . 9
3.2. Location URI Expiration . . . . . . . . . . . . . . . . . 9 3.2. Location URI Expiration . . . . . . . . . . . . . . . . . 9
3.3. Location URI Authorization Models . . . . . . . . . . . . 10 3.3. Location URI Authorization . . . . . . . . . . . . . . . . 10
3.4. Location URI Construction . . . . . . . . . . . . . . . . 10 3.4. Location URI Construction . . . . . . . . . . . . . . . . 10
4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 12 4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 12
4.1. Requirements for a Location Configuration Protocol . . . . 12 4.1. Requirements for a Location Configuration Protocol . . . . 12
4.2. Requirements for a Location Dereference Protocol . . . . . 13 4.2. Requirements for a Location Dereference Protocol . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
All location-based services rely on ready access to location All location-based services rely on ready access to location
information. Within this document, the use of location information information. Using location information can be done one of two ways,
is constrained according to specific policies included in either in a direct, Location-by-Value (LbyV) approach, or using an
[I-D.ietf-geopriv-policy]. Using location information according to indirect, Location-by-Reference (LbyR) model.
these policies can be done one of two ways, either in a direct,
Location-by-Value (LbyV) approach, or using an indirect, Location-by-
Reference (LbyR) model. Despite the standard technique of passing
location directly in SIP, in the form of a PIDF-LO, (Presence
Information Document Format - Location Object, [RFC4119]), there are
some cases where LbyV is not desirable. In cases where additional
location requirements apply to specific applications and/or location
architectures, and when can only be met by an indirect location
mechanism, there is the Location-by-Reference model. This document
provides a list of requirements for use with the LbyR approach, and
leaves the LbyV model as explicitly out of scope.
As justification for a LbyR model, consider the following. In some For LbyV, location information is conveyed directly in the form of a
mobile networks it is not efficient for the end host to periodically PIDF-LO ([RFC4119]). Using LbyV might either be infeasible or
query the LIS for up-to-date location information. This is undesirable in some circumstances. There are cases where LbyR is
especially the case when power is a constraint or when a location better able to address location requirements for a specific
update is not immediately needed. Furthermore, the end host might architecture or application. This document provides a list of
want to delegate the task of retrieving and publishing location requirements for use with the LbyR approach, and leaves the LbyV
information to a third party, such as to a presence server. model explicitly out of scope.
As justification for a LbyR model, consider the circumstance that in
some mobile networks it is not efficient for the end host to
periodically query the LIS for up-to-date location information. This
is especially the case when power availability is a constraint or
when a location update is not immediately needed. Furthermore, the
end host might want to delegate the task of retrieving and publishing
location information to a third party, such as to a presence server.
Additionally, in some deployments, the network operator may not want Additionally, in some deployments, the network operator may not want
to make location information widely available. These kinds of to make location information widely available. These kinds of
location scenarios, and more, such as whether a Target is mobile and location scenarios provided, and others, such as whether a Target is
whether a mobile device needs to be located on demand or according to mobile and whether a mobile device needs to be located on demand or
some pre-determined interval, together form the basis of motivation according to some pre-determined interval, together, form the basis
for the LbyR concept. of motivation for the LbyR model.
The concept of an LbyR mechanism is simple. It is made up of a The concept of an LbyR mechanism is simple. It is made up of a
pointer which makes reference to the actual location information by reference identifier which indirectly references actual location
some combination of key value and fully qualified domain name. This information using some combination of key value and fully qualified
combination of data elements, in the form of a URI, is referred to domain name. This combination of data elements, in the form of a
specifically as a "location URI". URI, is referred to specifically as a "location URI".
A location URI is thought of as a dynamic reference to the current A location URI is thought of as a dynamic reference to the current
location of the Target, yet the location value might remain unchanged location of the Target, yet the location value might remain unchanged
over specific intervals of time for several reasons: over specific intervals of time for several reasons. These include:
- Limitations in the process used to generate location information - Limitations in the process used to generate location information
mean that cached location might be used. mean that cached location might be used.
- Policy constraints that may dictate that the location provided - Policy constraints that may dictate that the location provided
remains fixed over time for specified Location Recipients. Without remains fixed over time for specified Location Recipients. Without
additional information, a Location Recipient cannot assume that the additional information, a Location Recipient cannot assume that the
location information provided by any location URI is static, and will location information provided by any location URI is static, and will
never change. never change.
skipping to change at page 7, line 15 skipping to change at page 7, line 15
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document reuses the terminology of [RFC3693], such as Location This document reuses the terminology of [RFC3693], such as Location
Server (LS), Location Recipient (LR), Rule Maker (RM), Target, Server (LS), Location Recipient (LR), Rule Maker (RM), Target,
Location Generator (LG), Location Object (LO), and Using Protocol: Location Generator (LG), Location Object (LO), and Using Protocol:
Location-by-Value (LbyV): Location information in the format of a Location-by-Value (LbyV): Using location information in the form of
PIDF-LO (or related encoding). a location object (LO), such as a PIDF-LO.
Location-by-Reference (LbyR): A location URI pointing to location Location-by-Reference (LbyR): Representing location information
information. indirectly using a location URI.
Location Configuration Protocol: A protocol which is used by a Location Configuration Protocol: A protocol which is used by a
client to acquire either location or a location URI from a client to acquire either location or a location URI from a
location configuration server, based on information unique to the location configuration server, based on information unique to the
client. client.
Location Dereference Protocol: A protocol that is used by a client Location Dereference Protocol: A protocol that is used by a client
to query a location server, based on the location URI input and to query a location server, based on the location URI input and
which returns location information. which returns location information.
Location URI: As defined within this document, an identifier that Location URI: As defined within this document, an identifier that
serves as a pointer to a location information. A location URI is serves as a reference to location information. A location URI is
provided by a location server, and is later used as input by a provided by a location server, and is later used as input by a
dereference protocol to retrieve location information. dereference protocol to retrieve location information.
3. Overview of Location-by-Reference 3. Overview of Location-by-Reference
This section describes the entities and interactions involved in the This section describes the entities and interactions involved in the
LbyR model. LbyR model.
+---------+---------+ Location +-----------+ +---------+---------+ Location +-----------+
| | | Dereference | Location | | | | Dereference | Location |
skipping to change at page 9, line 21 skipping to change at page 9, line 21
The LS controls access to location information based on the policy The LS controls access to location information based on the policy
provided by the Rule Maker. provided by the Rule Maker.
Note A. There is no requirement for using the same protocol in (1) Note A. There is no requirement for using the same protocol in (1)
and (3). and (3).
Note B. Figure 1 includes the interaction between the owner of the Note B. Figure 1 includes the interaction between the owner of the
Target and the LIS to obtain Rule Maker policies. This interaction Target and the LIS to obtain Rule Maker policies. This interaction
needs to happen before the LIS will authorize anything other than needs to happen before the LIS will authorize anything other than
what is allowed based on default policies in order to dereference a what is allowed based on default policies in order to dereference a
location request of the Target. This is communications path, (*), location request of the Target. This communication path is out of
out of scope for this document. scope for this document.
Note C. The Target might take on the role of the Location Recipient, Note C. The Target might take on the role of the Location Recipient,
in which case it could attempt to dereference the location URI in which case it could attempt to dereference the location URI
itself, in order to obtain its own location information. itself, in order to obtain its own location information.
3.1. Location URI Usage 3.1. Location URI Usage
An example scenario of how the above might work, is where the Target An example scenario of how the above might work, is where the Target
obtains a location URI in the form of a subscription URI (e.g., a SIP obtains a location URI in the form of a subscription URI (e.g., a SIP
URI) via a location configuration protocol. In this case, the Target URI) via a location configuration protocol. In this case, the Target
skipping to change at page 10, line 5 skipping to change at page 10, line 5
Location URIs may have an expiry associated with them, primarily for Location URIs may have an expiry associated with them, primarily for
security considerations, and generally so that the LIS is able to security considerations, and generally so that the LIS is able to
keep track of the location URIs that have been handed out, to know keep track of the location URIs that have been handed out, to know
whether a location URI is still valid once the LIS receives it in a whether a location URI is still valid once the LIS receives it in a
request, and in order for a recipient of such a URI from being able request, and in order for a recipient of such a URI from being able
to (in some cases) permanently track a host. Expiration of a to (in some cases) permanently track a host. Expiration of a
location URI limits the time that accidental leaking of a location location URI limits the time that accidental leaking of a location
URI introduces. Other justifications for expiration of location URIs URI introduces. Other justifications for expiration of location URIs
include the ability for a LIS to do garbage collection. include the ability for a LIS to do garbage collection.
3.3. Location URI Authorization Models 3.3. Location URI Authorization
How a location URI is will ultimately be used within the dereference How a location URI is will ultimately be used within the dereference
step is an important consideration at the time that the location URI step is an important consideration at the time that the location URI
is requested via a location configuration protocol. Since is requested via a location configuration protocol. Since
dereferencing of location URIs could be done according to one of two dereferencing of location URIs can be done according to a variety of
authorization models, either an "access control authorization model" authorization models it is important that location configuration
or a "possession authorization model", it is important that location protocols indicate the type of a location URI that is being
configuration protocols indicate the type of a location URI that is requested, as well as which type is returned.
being requested, as well as which type is returned).
1. Access Control Authorization. Location URIs manifest themselves in a few different forms. The
different ways that a location URI can be represented is based on
local policy, and are depicted in the following four scenarios.
Access to the location URI is limited by policy. In this model it 1. No specific information at all: As is typical, a location URI is
is assumed that the Rule Maker provides authorization policies to used to get location information. However, in this case, the URI
the LIS and these policies are attached to a location URI and representation itself does not need to reveal any specific
control the dereferencing process. information at all. Location information is acquired by the
dereferencing operation a location URI.
2. Possession Authorization. 2. No user specific information: By default, a location URI MUST NOT
reveal any information about the Target other than location
information. This is true for the URI itself, (or in the document
acquired by dereferencing), unless policy explicitly permits
otherwise.
The possession authorization model is described as not having 3. Access control authorization model (unauthorized recipients can't
policies associated to the location URI aside from only possessing get the information): If the "access control authorization" model is
the location URI itself. In this case, possession implies used, the location URI MUST NOT include any location information
authorization. Access to the location URI is limited by in its representation. Location URIs operating under this model
distribution only. Whoever possesses the location URI has the could be widely published to recipients that are not authorized to
ability to dereference it. Possession authorization models may be receive this information.
used within specified domains only, or might be used across wide
open public networks. 4. Possession authorization model (the URI itself is a secret): If
the "possession authorization" model is used, the location URI is
confidential information shared between the LIS/LS, the Device and
all authorized Location Recipients. In this case, possession
implies authorization. Because knowledge of the location URI is
used to authenticate and authorize access to location information,
the URI needs to include sufficient randomness to make guessing
its value difficult. A possession model URI can include location
information in its representation.
3.4. Location URI Construction 3.4. Location URI Construction
Depending on local policy, a location URI may be constructed in such Depending on local policy, a location URI may be constructed in such
a way as to make it difficult to guess. Accordingly, the form of the a way as to make it difficult to guess. Accordingly, the form of the
URI is then constrained by the degree of randomness and uniqueness URI is then constrained by the degree of randomness and uniqueness
applied to it. In this case, it may be important to protect the applied to it. In this case, it may be important to protect the
actual location information from inspection by an intermediate node. actual location information from inspection by an intermediate node.
Construction of a location URI in such a way as to not reveal any Construction of a location URI in such a way as to not reveal any
domain, user, or device specific information, with the goal of making domain, user, or device specific information, with the goal of making
the location URI appear bland, uninteresting, and generic, may be the location URI appear bland, uninteresting, and generic, may be
helpful to some degree in order to keep location information more helpful to some degree in order to keep location information more
difficult to detect. Thus, obfuscating the location URI in this way difficult to detect. Thus, obfuscating the location URI in this way
may provide some level of safeguard against the undetected stripping may provide some level of safeguard against the undetected stripping
off of what would otherwise be evident location information, since it off of what would otherwise be evident location information, since it
forces a dereference operation at the location dereference server, an forces a dereference operation at the location dereference server, an
important step for the purpose of providing statistics, audit trails, important step for the purpose of providing statistics, audit trails,
and general logging for many different kinds of location based and general logging for many different kinds of location based
services. services.
Where local policy explicitly relaxes the limitations around the
information provided within the structure of the location URI itself,
default restrictions may not exist. Under such conditions, it may be
reasonable, for example, to have the location URI be the AoR itself.
4. High-Level Requirements 4. High-Level Requirements
This document outlines the requirements for an Location by Reference This document outlines the requirements for an Location by Reference
mechanism which can be used by a number of underlying protocols. mechanism which can be used by a number of underlying protocols.
Requirements here address two general types of such protocols, a Requirements here address two general types of such protocols, a
general location configuration protocol, and a general location general location configuration protocol, and a general location
dereferencing protocol. dereferencing protocol.
The requirements are broken into two sections. The requirements are broken into two sections.
skipping to change at page 18, line 23 skipping to change at page 18, line 23
[I-D.ietf-geopriv-dhcp-lbyr-uri-option] [I-D.ietf-geopriv-dhcp-lbyr-uri-option]
Polk, J., "Dynamic Host Configuration Protocol (DHCP) Polk, J., "Dynamic Host Configuration Protocol (DHCP)
Option for a Location Uniform Resource Identifier (URI)", Option for a Location Uniform Resource Identifier (URI)",
draft-ietf-geopriv-dhcp-lbyr-uri-option-03 (work in draft-ietf-geopriv-dhcp-lbyr-uri-option-03 (work in
progress), November 2008. progress), November 2008.
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)", "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-12 (work in draft-ietf-geopriv-http-location-delivery-13 (work in
progress), January 2009. progress), February 2009.
[I-D.ietf-geopriv-l7-lcp-ps] [I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-09 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-09 (work in
progress), February 2009. progress), February 2009.
[I-D.ietf-geopriv-loc-filters] [I-D.ietf-geopriv-loc-filters]
Mahy, R. and B. Rosen, "A Document Format for Filtering Mahy, R. and B. Rosen, "A Document Format for Filtering
and Reporting Location Notications in the Presence and Reporting Location Notications in the Presence
Information Document Format Location Object (PIDF-LO)", Information Document Format Location Object (PIDF-LO)",
draft-ietf-geopriv-loc-filters-03 (work in progress), draft-ietf-geopriv-loc-filters-03 (work in progress),
November 2008. November 2008.
[I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
and J. Polk, "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-20 (work in progress),
February 2009.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-12 (work in progress), draft-ietf-sip-location-conveyance-12 (work in progress),
November 2008. November 2008.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
Appendix A. Change log Appendix A. Change log
Changes to this draft in comparison to the previous version (-07 vs.
-06):
1. deleted text and reference to ID.ietf-geopriv-policy (Thomson
2/26/09).
2. replaced text in Introduction referring to SIP (Thomson).
3. reworded section 3.4 on location URI authorization (Thomson).
Changes to this draft in comparison to the previous version (-06 vs. Changes to this draft in comparison to the previous version (-06 vs.
-05): -05):
1. replaced diagram (Thomson). 1. replaced diagram (Thomson).
2. redefined term, "Location-by-Value" (1/08/2009, Tschofenig). 2. redefined term, "Location-by-Value" (1/08/2009, Tschofenig).
3. redefined term, "Location-by-Reference" (Tschofenig). 3. redefined term, "Location-by-Reference" (Tschofenig).
4. redefined term, "Location Dereference Protocol" (Tschofenig). 4. redefined term, "Location Dereference Protocol" (Tschofenig).
 End of changes. 22 change blocks. 
75 lines changed or deleted 84 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/