< draft-ietf-geopriv-lbyr-requirements-07.txt   draft-ietf-geopriv-lbyr-requirements-08.txt >
GeoPriv R. Marshall, Ed. GeoPriv R. Marshall, Ed.
Internet-Draft TCS Internet-Draft TCS
Intended status: Informational February 26, 2009 Intended status: Informational September 2, 2009
Expires: August 30, 2009 Expires: March 6, 2010
Requirements for a Location-by-Reference Mechanism Requirements for a Location-by-Reference Mechanism
draft-ietf-geopriv-lbyr-requirements-07 draft-ietf-geopriv-lbyr-requirements-08
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 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2009. This Internet-Draft will expire on March 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Abstract Abstract
This document defines terminology and provides requirements relating This document defines terminology and provides requirements relating
to Location-by-Reference approach using a location URI to handle to Location-by-Reference approach using a location Uniform Resource
location information within signaling and other Internet messaging. Identifier (URI) to handle 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 . . . . . . . . . . . . . . . . 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 . . . . . 14
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 . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
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. Using location information can be done one of two ways, information. Using location information can be done one of two ways,
either in a direct, Location-by-Value (LbyV) approach, or using an either in a direct, Location-by-Value (LbyV) approach, or using an
indirect, Location-by-Reference (LbyR) model. indirect, Location-by-Reference (LbyR) model.
For LbyV, location information is conveyed directly in the form of a For LbyV, location information is conveyed directly in the form of a
PIDF-LO ([RFC4119]). Using LbyV might either be infeasible or Presence Information Data Format-Location Object (PIDF-LO)
undesirable in some circumstances. There are cases where LbyR is ([RFC4119]). Using LbyV might either be infeasible or undesirable in
better able to address location requirements for a specific some circumstances. There are cases where LbyR is better able to
architecture or application. This document provides a list of address location requirements for a specific architecture or
requirements for use with the LbyR approach, and leaves the LbyV application. This document provides a list of requirements for use
model explicitly out of scope. with the LbyR approach, and leaves the LbyV model explicitly out of
scope.
As justification for a LbyR model, consider the circumstance that in As justification for a LbyR model, consider the circumstance that in
some mobile networks it is not efficient for the end host to some mobile networks it is not efficient for the end host to
periodically query the LIS for up-to-date location information. This periodically query the Location Information Server (LIS) for up-to-
is especially the case when power availability is a constraint or date location information. This is especially the case when ower
when a location update is not immediately needed. Furthermore, the availability is a constraint or when a location update is not
end host might want to delegate the task of retrieving and publishing immediately needed. Furthermore, the end host might want to delegate
location information to a third party, such as to a presence server. the task of retrieving and publishing location information to a third
Additionally, in some deployments, the network operator may not want party, such as to a presence server. Additionally, in some
to make location information widely available. These kinds of deployments, the network operator may not want to make location
location scenarios provided, and others, such as whether a Target is information widely available. These kinds of location scenarios form
mobile and whether a mobile device needs to be located on demand or the basis of motivation for the LbyR model.
according to some pre-determined interval, together, form the basis
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. An LbyR is made up of a
reference identifier which indirectly references actual location URI scheme, a domain and a randomized component. This combination of
information using some combination of key value and fully qualified data elements, in the form of a URI, is referred to specifically as a
domain name. This combination of data elements, in the form of 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 reference to the current location
location of the Target, yet the location value might remain unchanged of the Target, yet the location value might remain unchanged over
over specific intervals of time for several reasons. These include: specific intervals of time for several reasons. The type of location
information returned as part of the dereferencing step may, for
example, be influenced by the following factors:
- 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 5, line 16 skipping to change at page 5, line 16
Within this lifecycle, location URIs are considered temporary Within this lifecycle, location URIs are considered temporary
identifiers, each undergoing the following uses: Creation; identifiers, each undergoing the following uses: Creation;
Distribution; Conveyance; Dereference; and Termination. The use of a Distribution; Conveyance; Dereference; and Termination. The use of a
location URI according to these various states is generally applied location URI according to these various states is generally applied
in one of the following ways: in one of the following ways:
1. Creation of a location URI, within a location server, based on 1. Creation of a location URI, within a location server, based on
some request for its creation. some request for its creation.
2. Distribution of a location URI, via a Location Configuration 2. Distribution of a location URI, via a Location Configuration
Protocol, between a target and a location server. Protocol, between a Target and a location server.
3. Conveyance, applied to LbyR, in SIP, is the transporting of the 3. Conveyance, applied to LbyR, for example in SIP (Session
location URI, in this case, between any successive signaling nodes. Inititiation Protocol), is the transporting of the location URI, in
this case, between any successive signaling nodes.
4. Dereference of a location URI, a request/response between a 4. Dereference of a location URI, a request/response between a
client having a location URI and a location server holding the client having a location URI and a location server holding the
location information that the location URI references. location information that the location URI references.
5. Termination of a location URI, either due to expiration or 5. Termination of a location URI, either due to expiration or
cancellation within a location server, and which is based on a target cancellation within a location server, and which is based on a Target
cancellation request or some other action, such as timer cancellation request or some other action, such as timer
expiration. expiration.
Note that this document makes no differentiation between a LS, per Note that this document makes no differentiation between a Location
[RFC3693], and a LIS, as shown in [I-D.ietf-geopriv-l7-lcp-ps]), but Server (LS), per [RFC3693], and a Location Information Server (LIS),
may refer to either of them as a location server interchangeably. as shown in [I-D.ietf-geopriv-l7-lcp-ps]), but may refer to either of
them as a location server interchangeably.
Location determination, different than location configuration or Location determination, different than location configuration or
dereferencing, often includes topics related to manual provisioning dereferencing, often includes topics related to manual provisioning
processes, automated location calculations based on a variety of processes, automated location calculations based on a variety of
measurement techniques, and/or location transformations, (e.g., geo- measurement techniques, and/or location transformations, (e.g., geo-
coding), and is beyond the scope of this document. coding), and is beyond the scope of this document.
Location Conveyance for either LbyR or LbyV as defined within SIP Location Conveyance for either LbyR or LbyV, as defined within SIP
signaling is considered out of scope for this document (see signaling is considered out of scope for this document (see
[I-D.ietf-sip-location-conveyance] for an explanation of location [I-D.ietf-sip-location-conveyance] for an explanation of location
conveyance for either LbyR or LbyV scenarios.) conveyance for either LbyR or LbyV scenarios.)
Except for location conveyance, the above stages in the LbyR Except for location conveyance, the above stages in the LbyR
lifecycle fall into one of two general categories of protocols, lifecycle fall into one of two general categories of protocols,
either a Location Configuration Protocol or a Location Dereference either a Location Configuration Protocol or a Location Dereference
Protocol. The stages of LbyR Creation, Distribution, and Protocol. The stages of LbyR Creation, Distribution, and
Termination, are each found within the set of Location Configuration Termination, are each found within the set of Location Configuration
Protocols (LCP). The Dereference stage belongs solely to the set of Protocols (LCP). The Dereference stage belongs solely to the set of
Location Dereference Protocols. Location Dereference Protocols.
The issues around location configuration protocols have been The issues around location configuration protocols have been
documented in a location configuration protocol problem statement and documented in a location configuration protocol problem statement and
requirements document [I-D.ietf-geopriv-l7-lcp-ps]. There are requirements document [I-D.ietf-geopriv-l7-lcp-ps]. There are
currently several examples of a location configuration protocols currently several examples of documented location configuration
currently proposed, including, DHCP protocols, namely DHCP DHCP [I-D.ietf-geopriv-dhcp-lbyr-uri-option],
[I-D.ietf-geopriv-dhcp-lbyr-uri-option], LLDP-MED, and HELD LLDP-MED [LLDP-MED], and HELD HELD
[I-D.ietf-geopriv-http-location-delivery] protocols. [I-D.ietf-geopriv-http-location-delivery] protocols.
For dereferencing of a location URI, depending on the type of For dereferencing of a location URI, depending on the type of
reference used, such as a HTTP/HTTPS, or SIP Presence URI, different reference used, such as a HTTP/HTTPS, or SIP Presence URI, different
operations can be performed. While an HTTP/HTTPS URI can be resolved operations can be performed. While an HTTP/HTTPS URI can be resolved
to location information, a SIP Presence URI provides further benefits to location information, a SIP Presence URI provides further benefits
from the SUBSCRIBE/NOTIFY concept that can additionally be combined from the SUBSCRIBE/NOTIFY concept that can additionally be combined
with location filters [I-D.ietf-geopriv-loc-filters]. with location filters [I-D.ietf-geopriv-loc-filters].
The structure of this document includes terminology, Section 2, The structure of this document includes terminology, Section 2,
skipping to change at page 7, line 9 skipping to change at page 7, line 9
authorization, and construction of location URIs. authorization, and construction of location URIs.
Requirements are outlined accordingly, separated as location Requirements are outlined accordingly, separated as location
configuration requirements, Section 4.1, and location dereference configuration requirements, Section 4.1, and location dereference
requirements, Section 4.2. requirements, Section 4.2.
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],
with the important qualification that, unless otherwise stated, these
terms apply to the design of the Location Configuration Protocol and
the Location Dereferencing Protocol, not its implementation or
application.
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 Object (LO). Furthermore, the following terms are defined
in this document:
Location-by-Value (LbyV): Using location information in the form of Location-by-Value (LbyV): Using location information in the form of
a location object (LO), such as a PIDF-LO. a location object (LO), such as a PIDF-LO.
Location-by-Reference (LbyR): Representing location information Location-by-Reference (LbyR): Representing location information
indirectly using a location URI. indirectly using a location URI.
Location Configuration Protocol: A protocol which is used by a Location Configuration Protocol: A protocol that is used by a Target
client to acquire either location or a location URI from a to acquire either location or a location URI from a location
location configuration server, based on information unique to the configuration server, based on information unique to the Target.
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 reference to 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.
skipping to change at page 8, line 33 skipping to change at page 8, line 33
| | | | | |
| Target +-------------------------------+ | Target +-------------------------------+
| | | |
+---------+ +---------+
Figure 1: Location Reference Entities and Interactions Figure 1: Location Reference Entities and Interactions
Figure 1 shows the assumed communication model for both a layer 7 Figure 1 shows the assumed communication model for both a layer 7
location configuration protocol and a location dereference protocol. location configuration protocol and a location dereference protocol.
1. The Target (a Device) uses a Location Configuration Protocol to 1. The Target (an end device) uses a Location Configuration Protocol
acquire a location reference from a LIS, which acts as (or is able to to acquire a location reference from a LIS, which acts as (or is able
access) an LS. to access) an LS.
In the case where the Target is also a Rule Maker, the location In the case where the Target is also a Rule Maker, the location
configuration protocol can be used to convey policy information. In configuration protocol can be used to convey policy information. In
the case where possession of a location URI is the only required form the case where possession of a location URI is the only required form
of authorization, (see, Section 3.3), a policy is implied whereby any of authorization, see Section 3.3, a policy is implied whereby any
requester is granted access to location information. This does not requester is granted access to location information. This does not
preclude other means of providing authorization policies. preclude other means of providing authorization policies.
A Target could also acquire a location URI from the LS directly using A Target could also acquire a location URI from the LS directly using
alternative means, for example, the acquisition of a presence AoR to alternative means, for example, the acquisition of a presence AoR to
be used for location information, in which case, it could be regarded be used for location information, in which case, it could be regarded
as a location URI. as a location URI.
2. The Target conveys the location URI to the Location Recipient 2. The Target conveys the location URI to the Location Recipient
(interface out of scope). (interface out of scope).
skipping to change at page 9, line 30 skipping to change at page 9, line 30
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 communication path is out of location request of the Target. This communication path is 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 location configuration and
location dereference steps might work using SIP, is where a 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
is the same as the Recipient, therefore the Target can subscribe to is the same as the Recipient, therefore the Target can subscribe to
the URI in order to be notified of its current location based on the URI in order to be notified of its current location based on
subscription parameters. In the example, parameters are set up for a subscription parameters. In the example, parameters are set up for a
specific Target/Recipient along with an expressed geospatial specific Target/Recipient along with an expressed geospatial
boundary, so that the Target/Recipient receives an updated location boundary, so that the Target/Recipient receives an updated location
notification once the boundary is crossed (see notification once the boundary is crossed (see
[I-D.ietf-geopriv-loc-filters]). [I-D.ietf-geopriv-loc-filters]).
skipping to change at page 10, line 7 skipping to change at page 10, line 7
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 3.3. Location URI Authorization
How a location URI is will ultimately be used within the dereference How a location URI 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 the location URI is
is requested via a location configuration protocol. Since requested via a location configuration protocol. The process of
dereferencing of location URIs can be done according to a variety of dereferencing location URIs will be influenced by the specific
authorization models it is important that location configuration authorization model applied by the Location Information Server and
protocols indicate the type of a location URI that is being the URI scheme that indicates the protocol to be used to resolve the
requested, as well as which type is returned. reference to a location object.
Location URIs manifest themselves in a few different forms. The Location URIs manifest themselves in a few different forms. The
different ways that a location URI can be represented is based on different ways that a location URI can be represented is based on
local policy, and are depicted in the following four scenarios. local policy, and are depicted in the following four scenarios.
1. No specific information at all: As is typical, a location URI is 1. No specific information at all: As is typical, a location URI is
used to get location information. However, in this case, the URI used to get location information. However, in this case, the URI
representation itself does not need to reveal any specific representation itself does not need to reveal any specific
information at all. Location information is acquired by the information at all. Location information is acquired by the
dereferencing operation a location URI. dereferencing operation a location URI.
2. No user specific information: By default, a location URI MUST NOT 2. No Target specific information: By default, a location URI MUST
reveal any information about the Target other than location NOT reveal any information about the Target other than location
information. This is true for the URI itself, (or in the document information. This is true for the URI itself, (or in the document
acquired by dereferencing), unless policy explicitly permits acquired by dereferencing), unless policy explicitly permits
otherwise. otherwise.
3. Access control authorization model (unauthorized recipients can't 3. Access control authorization model: If the "access control
get the information): If the "access control authorization" model is authorization model" is used, the location URI MUST NOT include
used, the location URI MUST NOT include any location information any location information in its representation. Location URIs
in its representation. Location URIs operating under this model operating under this model could be widely published to recipients
could be widely published to recipients that are not authorized to that are not authorized to receive this information.
receive this information.
4. Possession authorization model (the URI itself is a secret): If 4. Possession authorization model (the URI itself is a secret): If
the "possession authorization" model is used, the location URI is the "possession authorization" model is used, the location URI is
confidential information shared between the LIS/LS, the Device and confidential information shared between the LIS/LS, the Target and
all authorized Location Recipients. In this case, possession all authorized Location Recipients. In this case, possession
implies authorization. Because knowledge of the location URI is implies authorization. Because knowledge of the location URI is
used to authenticate and authorize access to location information, used to authenticate and authorize access to location information,
the URI needs to include sufficient randomness to make guessing the URI needs to include sufficient randomness to make guessing
its value difficult. A possession model URI can include location its value difficult. A possession model URI can include location
information in its representation. 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 Target specific, (e.g., user or device), information, with the goal
the location URI appear bland, uninteresting, and generic, may be of making the location URI appear bland, uninteresting, and generic,
helpful to some degree in order to keep location information more may be helpful to some degree in order to keep location information
difficult to detect. Thus, obfuscating the location URI in this way more difficult to detect. Thus, obfuscating the location URI in this
may provide some level of safeguard against the undetected stripping way may provide some level of safeguard against the undetected
off of what would otherwise be evident location information, since it stripping off of what would otherwise be evident location
forces a dereference operation at the location dereference server, an information, since it forces a dereference operation at the location
important step for the purpose of providing statistics, audit trails, dereference server, an important step for the purpose of providing
and general logging for many different kinds of location based statistics, audit trails, and general logging for many different
services. kinds of location based services.
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 12, line 40 skipping to change at page 12, line 40
Motivation: A location URI may not intend to represent a location Motivation: A location URI may not intend to represent a location
forever, and the identifier eventually may need to be recycled, or forever, and the identifier eventually may need to be recycled, or
may be subject to a specific window of validity, after which the may be subject to a specific window of validity, after which the
location reference fails to yield a location, or the location is location reference fails to yield a location, or the location is
determined to be kept confidential. determined to be kept confidential.
C3. Location URI cancellation: The location configuration protocol C3. Location URI cancellation: The location configuration protocol
MUST support the ability to request a cancellation of a specific MUST support the ability to request a cancellation of a specific
location URI. location URI.
Motivation: If the client determines that in its best interest to Motivation: If the Target determines that in its best interest to
destroy the ability for a location URI to effectively be used to destroy the ability for a location URI to effectively be used to
dereference a location, then there should be a way to nullify the dereference a location, then there should be a way to nullify the
location URI. location URI.
C4. Location Information Masking: The location URI MUST, through C4. Location Information Masking: The location URI MUST, through
randomization and uniqueness, ensure that the location URI does randomization and uniqueness, ensure that the location URI does
not contain location information specific components. not contain location information specific components.
Motivation: It is important to keep any location information Motivation: It is important to keep any location information
masked from a casual observing node. masked from a casual observing node.
C5. User Identity Protection: The location URI MUST NOT contain C5. Target Identity Protection: The location URI MUST NOT contain
information that identifies the user or device. Examples include information that identifies the Target (e.g., user or device).
phone extensions, badge numbers, first or last names. Examples include phone extensions, badge numbers, first or last
names.
Motivation: It is important to protect caller identity or contact Motivation: It is important to protect caller identity or contact
address from being included in the form of the location URI itself address from being included in the form of the location URI itself
when it is generated. when it is generated.
C6. Reuse indicator: There SHOULD be a way to allow a client to C6. Reuse indicator: There SHOULD be a way to allow a Target to
control whether a location URI can be resolved once only, or control whether a location URI can be resolved once only, or
multiple times. multiple times.
Motivation: The client requesting a location URI may request a Motivation: The Target requesting a location URI may request a
location URI which has a 'one-time-use' only characteristic, as location URI which has a 'one-time-use' only characteristic, as
opposed to a location URI having multiple reuse capability. opposed to a location URI having multiple reuse capability. This
would allow the server to return an error with or without location
during the subsequent dereference operation.
C7. Selective disclosure: The location configuration protocol MUST C7. Selective disclosure: The location configuration protocol MUST
provide a mechanism to control what information is being disclosed provide a mechanism to control what information is being disclosed
about the Target. about the Target.
Motivation: The Rule Maker has to be in control of how much Motivation: The Rule Maker has to be in control of how much
information is revealed during the dereferencing step as part of information is revealed during the dereferencing step as part of
the privacy features. the privacy features.
C8. Location URI Not guessable: As a default, the location C8. Location URI Not guessable: As a default, the location
configuration protocol MUST return location URIs that are random configuration protocol MUST return location URIs that are random
and unique throughout the indicated lifetime. A location URI with and unique throughout the indicated lifetime. A location URI with
128-bits of randomness is RECOMMENDED. 128-bits of randomness is RECOMMENDED.
Motivation: Location URIs should be constructed in such a way that Motivation: Location URIs should be constructed in such a way that
an adversary cannot guess them and dereference them without having an adversary cannot guess them and dereference them without having
ever obtained them from the Target. ever obtained them from the Target.
C9. Location URI Optional: In the case of user-provided C9. Location URI Options: In the case of user-provided authorization
authorization policies, where anonymous or non-guessable location policies, where anonymous or non-guessable location URIs are not
URIs are not warranted, the location configuration protocol MAY warranted, the location configuration protocol MAY support a
support optional location URI forms, (such as embedded location variety of optional location URI conventions, as requested by a
information within the location URI). Target to a location configuration server, (e.g., embedded
location information within the location URI).
Motivation: Users don't always have such strict privacy Motivation: Users don't always have such strict privacy
requirements, but may opt to specify their own location URI, or requirements, but may opt to specify their own location URI, or
components thereof. components to be included within a location URI.
4.2. Requirements for a Location Dereference Protocol 4.2. Requirements for a Location Dereference Protocol
Below, we summarize high-level design requirements needed for a Below, we summarize high-level design requirements needed for a
location-by-reference mechanism as used within the location location-by-reference mechanism as used within the location
dereference protocol. dereference protocol.
D1. Location URI support: The location dereference protocol MUST D1. Location URI support: The location dereference protocol MUST
support a location reference in URI form. support a location reference in URI form.
skipping to change at page 16, line 5 skipping to change at page 15, line 28
to enforce the basic rule set that is attached to location to enforce the basic rule set that is attached to location
information in a PIDF-LO document. information in a PIDF-LO document.
Any location URI, by necessity, indicates the server (name) that Any location URI, by necessity, indicates the server (name) that
hosts the location information. Knowledge of the server in some hosts the location information. Knowledge of the server in some
specific domain could therefore reveal something about the location specific domain could therefore reveal something about the location
of the Target. This kind of threat may be mitigated somewhat by of the Target. This kind of threat may be mitigated somewhat by
introducing another layer of indirection: namely the use of a introducing another layer of indirection: namely the use of a
(remote) presence server. (remote) presence server.
A covert channel for protocol message exchange is an important
consideration, given an example scenario where user A subscribes to
location information for user B, then every time A gets a location
update an (external) observer of the subscription notification may
know that B has moved. One mitigation to this is to have periodic
notification, so that user B may appear to have moved, even when
static.
6. IANA Considerations 6. IANA Considerations
This document does not require actions by the IANA. This document does not require actions by the IANA.
7. Acknowledgements 7. Acknowledgements
I would like to thank the present IETF GEOPRIV working group chairs, I would like to thank the present IETF GEOPRIV working group chairs,
Robert Sparks and Richard Barnes, past chairs, Andy Newton, Allison Alissa Cooper and Richard Barnes, past chairs, Robert Sparks, Andy
Mankin and Randall Gellens, for establishing the design team which Newton, Allison Mankin and Randall Gellens, who established a design
initiated this requirements work. I'd also like to thank those team that initiated this requirements work. I'd also like to thank
original design team participants for their inputs, comments, and those original design team participants for their inputs, comments,
insightful reviews. The design team included the following folks: and insightful reviews. The design team included the following
Richard Barnes; Martin Dawson; Keith Drage; Randall Gellens; Ted folks: Richard Barnes; Martin Dawson; Keith Drage; Randall Gellens;
Hardie; Cullen Jennings; Marc Linsner; Rohan Mahy; Allison Mankin; Ted Hardie; Cullen Jennings; Marc Linsner; Rohan Mahy; Allison
Roger Marshall; Andrew Newton; Jon Peterson; James M. Polk; Brian Mankinl; Andrew Newton; Jon Peterson; James M. Polk; Brian Rosen;
Rosen; John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes
Tschofenig; Martin Thomson; and James Winterbottom. Tschofenig; Martin Thomson; and James Winterbottom.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[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) IPv4
Option for a Location Uniform Resource Identifier (URI)", and IPv6 Option for a Location Uniform Resource
draft-ietf-geopriv-dhcp-lbyr-uri-option-03 (work in Identifier (URI)",
progress), November 2008. draft-ietf-geopriv-dhcp-lbyr-uri-option-05 (work in
progress), July 2009.
[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-13 (work in draft-ietf-geopriv-http-location-delivery-16 (work in
progress), February 2009. progress), August 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-10 (work in
progress), February 2009. progress), July 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., Rosen, B., and H. Tschofenig, "A Document Format
and Reporting Location Notications in the Presence for Filtering and Reporting Location Notications in the
Information Document Format Location Object (PIDF-LO)", Presence Information Document Format Location Object
draft-ietf-geopriv-loc-filters-03 (work in progress), (PIDF-LO)", draft-ietf-geopriv-loc-filters-05 (work in
November 2008. progress), July 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-13 (work in progress),
November 2008. March 2009.
[LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery".
[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 (-08 vs.
-07), as part of the IESG review process:
1. changes sent 09/02/2009 based on IESG Security comments from
Hilarie Orman, 06/08/2009.
2. changes sent 09/02/2009 based on Operational Directorate comments
from Hannes Tschofenig, 06/11/2009.
Changes to this draft in comparison to the previous version (-07 vs. Changes to this draft in comparison to the previous version (-07 vs.
-06): -06):
1. deleted text and reference to ID.ietf-geopriv-policy (Thomson 1. deleted text and reference to ID.ietf-geopriv-policy (Thomson
2/26/09). 2/26/09).
2. replaced text in Introduction referring to SIP (Thomson). 2. replaced text in Introduction referring to SIP (Thomson).
3. reworded section 3.4 on location URI authorization (Thomson). 3. reworded section 3.4 on location URI authorization (Thomson).
 End of changes. 42 change blocks. 
119 lines changed or deleted 152 lines changed or added

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