Internet Engineering Task Force (IETF) R. Marshall, Ed. Request for Comments: 5808 TCS Category: Informational May 2010 ISSN: 2070-1721 Requirements for a Location-by-Reference Mechanism
AbstractThis document defines terminology and provides requirements relating to the Location-by-Reference approach using a location Uniform Resource Identifier (URI) to handle location information within signaling and other Internet messaging. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5808. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 1. Introduction ....................................................3 2. Terminology .....................................................5 3. Overview of Location-by-Reference ...............................6 3.1. Location URI Usage .........................................7 3.2. Location URI Expiration ....................................8 3.3. Location URI Authorization .................................8 3.4. Location URI Construction ..................................9 4. High-Level Requirements .........................................9 4.1. Requirements for a Location Configuration Protocol .........9 4.2. Requirements for a Location Dereference Protocol ..........11 5. Security Considerations ........................................12 6. Acknowledgements ...............................................13 7. References .....................................................13 7.1. Normative References ......................................13 7.2. Informative References ....................................13
RFC4119]. Using LbyV might be either infeasible or undesirable in some circumstances. There are cases where LbyR is better able to address location requirements for a specific architecture or application. This document provides a list of requirements for use with the LbyR approach, and leaves the LbyV model explicitly out of scope. As justification for an LbyR model, consider the circumstance that in some mobile networks it is not efficient for the end host to periodically query the Location Information Server (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 to make location information widely available. These kinds of location scenarios form the basis of motivation for the LbyR model. The concept of an LbyR mechanism is simple. An LbyR is made up of a URI scheme, a domain, and a randomized component. This combination of data elements, in the form of a URI, is referred to specifically as a "location URI". A location URI is thought of as a reference to the current location of the Target, yet the location value might remain unchanged over 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 mean that cached location might be used. - Policy constraints may dictate that the location provided remains fixed over time for specified Location Recipients. Without additional information, a Location Recipient cannot assume that the location information provided by any location URI is static, and will never change.
The LbyR mechanism works according to an information life cycle. Within this life cycle, location URIs are considered temporary identifiers, each undergoing the following uses: Creation; Distribution; Conveyance; Dereference; and Termination. The use of a location URI according to these various states is generally applied in one of the following ways: 1. Creation of a location URI, within a location server, based on some request for its creation. 2. Distribution of a location URI, via a Location Configuration Protocol, between a Target and a location server. 3. Conveyance, applied to LbyR, for example in SIP (Session Initiation 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 client having a location URI and a location server holding the location information that the location URI references. 5. Termination of a location URI, due to either expiration or cancellation within a location server, and that is based on a Target cancellation request or some other action, such as timer expiration. Note that this document makes no functional differentiation between a Location Server (LS), per [RFC3693], and a Location Information Server (LIS), as shown in [RFC5687], but may refer to either of them as a location server interchangeably. Location determination, as distinct from location configuration or dereferencing, often includes topics related to manual provisioning processes, automated location calculations based on a variety of measurement techniques, and/or location transformations (e.g., geo- coding), and is beyond the scope of this document. Location Conveyance for either LbyR or LbyV, as defined within SIP signaling is considered out of scope for this document. (See [LOC-CONVEY] for an explanation of location conveyance for either LbyR or LbyV scenarios.) Except for location conveyance, the above stages in the LbyR life cycle fall into one of two general categories of protocols, either a Location Configuration Protocol or a Location Dereference Protocol. The stages of LbyR Creation, Distribution, and Termination, are each
found within the set of Location Configuration Protocols (LCPs). The Dereference stage belongs solely to the set of Location Dereference Protocols. The issues around location configuration protocols have been documented in a location configuration protocol problem statement and requirements document [RFC5687]. There are currently several examples of documented location configuration protocols, namely DHCP [DHCP-LOC-URI], LLDP-MED [LLDP-MED], and HELD [HELD]. For dereferencing a location URI, depending on the type of reference used, such as a HTTP/HTTPS or SIP Presence URI, different operations can be performed. While an HTTP/HTTPS URI can be resolved to location information, a SIP Presence URI provides further benefits from the SUBSCRIBE/NOTIFY concept that can additionally be combined with location filters [LOC-FILTERS]. The structure of this document includes terminology, Section 2, followed by a discussion of the basic elements that surround how a location URI is used. These elements, or actors, are discussed in an overview section, Section 3, accompanied by a graph, associated processing steps, and a brief discussion around the use, expiration, authorization, and construction of location URIs. Requirements are outlined accordingly, separated as location configuration requirements, Section 4.1, and location dereference requirements, Section 4.2. 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 Server (LS), Location Recipient (LR), Rule Maker (RM), Target, and Location Object (LO). Furthermore, the following terms are defined in this document: Location-by-Value (LbyV): Using location information in the form of a location object (LO), such as a PIDF-LO. Location-by-Reference (LbyR): Representing location information indirectly using a location URI.
Location Configuration Protocol: A protocol that is used by a Target to acquire either a location object or a location URI from a location configuration server, based on information unique to the Target. Location Dereference Protocol: A protocol that is used by a client to query a location server, based on the location URI input, and that returns location information. Location URI: As defined within this document, an identifier that serves as a reference to location information. A location URI is provided by a location server, and is later used as input by a dereference protocol to retrieve location information. +---------+---------+ Location +-----------+ | | | Dereference | Location | | LIS/LS +---------------+ Recipient | | | | Protocol | | +----+----+----+----+ (3) +-----+-----+ | * | | Policy * | Location | Exchange * | Configuration | (*) * | Location Protocol | +----+----+ | Conveyance (1) | | Rule | | Protocol | | Maker | | (2) +----+----+ +---------+ | | | | | Target +-------------------------------+ | | +---------+ Figure 1: Location Reference Entities and Interactions Figure 1 shows the assumed communication model for both a Layer 7 location configuration protocol and a location dereference protocol. (1) The Target (an end device) uses a location configuration protocol to acquire a location reference from a LIS, which acts as (or is able to access) an LS. In the case where the Target is also a Rule Maker, the location configuration protocol can be used to convey policy information.
In 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 requester is granted access to location information. This does not preclude other means of providing authorization policies. A Target could also acquire a location URI from the LS directly using alternative means, for example, the acquisition of a presence Address of Record (AoR) to be used for location information, in which case, it could be regarded as a location URI. (2) The Target conveys the location URI to the Location Recipient (interface out of scope). (3) The Location Recipient dereferences the location URI to acquire location information from the LS. The LS controls access to location information based on the policy provided by the Rule Maker. Note A. There is no requirement for using the same protocol in (1) and (3). Note B. Figure 1 includes the interaction between the owner of the Target and the LIS to obtain Rule Maker policies. This interaction needs to happen before the LIS will authorize anything other than what is allowed based on default policies in order to dereference a location request of the Target. This communication path is out of scope for this document. Note C. The Target might take on the role of the Location Recipient, in which case, it could attempt to dereference the location URI itself, in order to obtain its own location information. LOC-FILTERS]).
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.
C2. Location URI expiration: When a location URI has a limited validity interval, its lifetime MUST be indicated. Motivation: A location URI may not intend to represent a location forever, and the identifier eventually may need to be recycled, or may be subject to a specific window of validity, after which the location reference fails to yield a location, or the location is determined to be kept confidential. C3. Location URI cancellation: The location configuration protocol MUST support the ability to request a cancellation of a specific location URI. Motivation: If the Target determines that a location URI should no longer be used to dereference a location, then there should be a way to request that the location URI be nullified. C4. Location information masking: The location URI MUST ensure, by default, through randomization and uniqueness, that the location URI does not contain location-information-specific components. Motivation: It is important to keep any location information masked from a casual observing node. C5. Target identity protection: The location URI MUST NOT contain information that identifies the Target (e.g., user or device). Examples include phone extensions, badge numbers, and first or last names. Motivation: It is important to protect caller identity or contact address from being included in the form of the location URI itself when it is generated. C6. Reuse indicator: There SHOULD be a way to allow a Target to control whether a location URI can be resolved once only or multiple times. Motivation: The Target requesting a location URI may request a location URI that has a 'one-time-use' only characteristic, as opposed to a location URI having multiple reuse capability. This would allow the server to return an error with or without location information during the subsequent dereference operation. C7. Selective disclosure: The location configuration protocol MUST provide a mechanism that allows the Rule Maker to control what information is being disclosed about the Target.
Motivation: The Rule Maker has to be in control of how much information is revealed during the dereferencing step as part of the privacy features. C8. Location URI not guessable: As a default, the location configuration protocol MUST return location URIs that are random and unique throughout the indicated lifetime. A location URI with 128 bits of randomness is RECOMMENDED. Motivation: Location URIs should be constructed in such a way that an adversary cannot guess them and dereference them without having previously obtained them from the Target. C9. Location URI options: In the case of user-provided authorization policies, where anonymous or non-guessable location URIs are not warranted, the location configuration protocol MAY support a variety of optional location URI conventions, as requested by a Target to a location configuration server (e.g., embedded location information within the location URI). Motivation: Users don't always have such strict privacy requirements, but may opt to specify their own location URI or components to be included within a location URI.
Motivation: This is in order to ensure that adequate privacy rules can be adhered to, since the PIDF-LO format comprises the necessary structures to maintain location privacy. D4. Location URI repeated use: The location dereference protocol MUST support the ability for the same location URI to be resolved more than once, based on dereference server configuration. Motivation: Through dereference server configuration, for example, it may be useful to not only allow more than one dereference request, but, in some cases, to also limit the number of dereferencing attempts by a client. D5. Location confidentiality: The location dereference protocol MUST support confidentiality protection of messages sent between the Location Recipient and the location server. Motivation: The location URI indicates what type of security protocol has to be provided. An example is a location URI using a HTTPS URI scheme.
know that B has moved. One mitigation of this is to have periodic notification, so that user B may appear to have moved even when static. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [DHCP-LOC-URI] Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", Work in Progress, March 2010. [HELD] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP Enabled Location Delivery (HELD)", Work in Progress, August 2009. [LLDP-MED] Telecommunications Industry Association (TIA), "ANSI/TIA-1057 Link Layer Discovery Protocol - Media Endpoint Discovery", 2006. [LOC-FILTERS] Mahy, R., Rosen, B., and H. Tschofenig, "Filtering Location Notifications in the Session Initiation Protocol (SIP)", Work in Progress, March 2010. [LOC-CONVEY] Polk, J. and B. Rosen, "Location Conveyance for the Session Initiation Protocol", Work in Progress, February 2010.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010. http://www.telecomsys.com