RFC 5808

Requirements for a Location-by-Reference Mechanism

📅 published May 2010, from ietf

Requirements for a Location-by-Reference Mechanism 🎀

Okay bestie, here's the header rundown 💅

  • Publisher: Internet Engineering Task Force (IETF) 🌸
  • RFC number: 5808
  • Authors: R. Marshall, Ed., from TCS ✨
  • Category: Informational (not a Standards Track spec, just for info 🧚)
  • Date: May 2010
  • ISSN: 2070-1721
  • Obsoletes / Updates: neither. The header doesn't list any Obsoletes or Updates lines, so this one doesn't replace or change any other RFC 🦋

Abstract ✨

This doc sets up the vocab and the requirements for the Location-by-Reference approach, which uses a location Uniform Resource Identifier (URI) to handle location info inside signaling and other Internet messaging 💜

Status of This Memo 🌈

Not a standards-track spec, it's published for informational purposes 🍓

This doc is a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 🫶

Want the current status, errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc5808 🔥

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions for this doc 👀 Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes ⭐

This doc may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person or people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Without an adequate license from them, this doc may not be modified outside the IETF Standards Process, and derivative works of it may not be made outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🙈

Table of Contents 🧚

   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

1. Introduction 🌸

Okay so every location-based service needs easy access to location info 📍 Location info can be used in one of two ways: the direct approach, Location-by-Value (LbyV), or the indirect one, Location-by-Reference (LbyR) 💖

With LbyV, the location info gets passed around directly as a Presence Information Data Format Location Object (PIDF-LO) [RFC4119] ✨ LbyV might be infeasible or just not it in some situations 🙅‍♀️ That's where LbyR slays, because it can handle location requirements for a specific architecture or application better. This doc lists requirements for the LbyR approach and leaves LbyV explicitly out of scope 🦋

So why LbyR? Picture a mobile network where it's not efficient for the end host to keep asking the Location Information Server (LIS) for up-to-date location info. That's especially true when power is limited or when a location update isn't urgent 🔋 The end host might also want to hand off getting and publishing location info to a third party, like a presence server 🫶 And in some deployments, the network operator may not want location info to be widely available 🔒 Those are the scenarios that motivate the LbyR model, and honestly it's giving main character energy 👑

The LbyR concept is simple. An LbyR is made up of a URI scheme, a domain, and a randomized component. Put those together as a URI and you get what's officially called a "location URI" 💅

A location URI is basically a reference to the Target's current location. The location value can stay the same over certain stretches of time for a few reasons, though 🕰️ The type of location info returned during dereferencing can be shaped by factors like these:

  • Limits in the process used to generate location info mean that cached location might be used.
  • Policy constraints may dictate that the location provided stays fixed over time for specified Location Recipients. Without extra info, a Location Recipient can't assume that the location info from any location URI is static and will never change.

The LbyR mechanism runs on an information life cycle 🔄 During that life cycle, location URIs are treated as temporary identifiers, and each one goes through these uses: Creation, Distribution, Conveyance, Dereference, and Termination 💜 Each use generally shows up in one of these ways:

  1. Creation of a location URI, inside a location server, based on a request for its creation.
  2. Distribution of a location URI, through a Location Configuration Protocol, between a Target and a location server.
  3. Conveyance, applied to LbyR (for example, in SIP (Session Initiation Protocol)), is transporting the location URI between any successive signaling nodes.
  4. Dereference of a location URI, which is a request and response between a client holding a location URI and a location server holding the location info that the URI references.
  5. Termination of a location URI, due to either expiration or cancellation inside a location server. This is based on a Target cancellation request or some other action, like a timer expiring ⏰

Quick note: this doc makes no functional difference between a Location Server (LS), per [RFC3693], and a Location Information Server (LIS), as shown in [RFC5687]. It may refer to either one as a location server, interchangeably 🧚

Location determination is a different thing from location configuration or dereferencing 🙃 It often involves manual provisioning, automated location calculations from various measurement techniques, and/or location transformations (for example, geo-coding). That's beyond the scope of this doc 🙅‍♀️

Location Conveyance for either LbyR or LbyV, as defined within SIP signaling, is out of scope for this doc. (See [LOC-CONVEY] if you want an explanation of location conveyance for either LbyR or LbyV scenarios 📚)

Except for location conveyance, the stages of the LbyR life cycle fall into two general categories of protocols: a Location Configuration Protocol or a Location Dereference Protocol 💅 The Creation, Distribution, and Termination stages each sit within the set of Location Configuration Protocols (LCPs). The Dereference stage belongs only to the set of Location Dereference Protocols 🌈

The issues around location configuration protocols are documented in a problem statement and requirements document, [RFC5687] ✨ Some documented examples of location configuration protocols right now are DHCP [DHCP-LOC-URI], LLDP-MED [LLDP-MED], and HELD [HELD] 🫶

When you dereference a location URI, the operations depend on the type of reference, like an HTTP/HTTPS or SIP Presence URI. An HTTP/HTTPS URI can be resolved to location info. A SIP Presence URI gets extra perks from the SUBSCRIBE/NOTIFY concept, and that can also be combined with location filters [LOC-FILTERS] 🔥

Here's how this doc is laid out. Section 2 is terminology. After that, Section 3 is an overview of the basic elements around how a location URI is used, which covers the actors, a graph, the processing steps, and a brief discussion of use, expiration, authorization, and construction of location URIs 🗺️ Then the requirements, split into location configuration requirements (Section 4.1) and location dereference requirements (Section 4.2) 💖

2. Terminology 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. There's one important catch: unless stated otherwise, these terms apply to the design of the Location Configuration Protocol and the Location Dereferencing Protocol, not to their implementation or application ⚠️

This doc reuses the terminology of [RFC3693], like Location Server (LS), Location Recipient (LR), Rule Maker (RM), Target, and Location Object (LO) 📖 It also defines these terms of its own:

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 a Target uses 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 a client uses 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 server provides a location URI, and a dereference protocol later uses it as input to retrieve location information. 🎀

Heads up: this is part 1 of the rewrite, so the next parts pick up with Section 3 and carry on from there 🫶

3. Overview of Location-by-Reference ✨

okay so this section is the big picture, bestie 🗺️ it walks through the LbyR model and who does what. Here's the cast: a Target (an end device), a LIS/LS, a Location Recipient, and a Rule Maker. Figure 1 is the whole vibe, so check it out 👀

            +---------+---------+   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. It's giving clean architecture 🧚

(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. Policy is the boss here 👑

Note A. There is no requirement for using the same protocol in (1) and (3). Mix and match, it's fine 🌈

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. Self-stalking but make it a feature 💅

3.1. Location URI Usage

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 URI) via a location configuration protocol. In this case, the Target 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 subscription parameters. 📡

In the example, parameters are set up for a specific Target/Recipient along with an expressed geospatial boundary, so that the Target/Recipient receives an updated location notification once the boundary is crossed (see [LOC-FILTERS]). It's like a geofence with main character energy 🌸

3.2. Location URI Expiration

Location URIs may have an expiry associated with them, primarily for security considerations, and generally in order for the LIS to 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 request, and for preventing a recipient of such a URI from being able to (in some cases) permanently track a host. 🕰️ Expiration of a location URI limits the time that accidental leaking of a location URI introduces. Other justifications for expiration of location URIs include the ability for a LIS to do garbage collection. Honestly, expiry is a whole safety net 🧹

3.3. Location URI Authorization

How a location URI will ultimately be used within the dereference step is an important consideration at the time the location URI is requested via a location configuration protocol. The process of dereferencing location URIs will be influenced by the specific authorization model applied by the Location Information Server and the URI scheme that indicates the protocol to be used to resolve the reference to a location object. 🎀

Location URIs manifest themselves in a few different forms. The different ways that a location URI can be represented are based on local policy, and are depicted in the following four scenarios. Here they are, the four looks 👗

  1. No location information included in the URI: As is typical, a location URI is used to get location information. However, in this case, the URI representation itself does not need to reveal any specific information at all. Location information is acquired by the dereferencing operation using a location URI. Minimalist era 🤍
  2. URI does not identify a Target: 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. Privacy is non-negotiable bestie 🙅‍♀️
  3. Access control authorization model: If this model is used, the location URI MUST NOT include any location information in its representation. Location URIs operating under this model could be widely published to recipients that are not authorized to receive this information. Gatekeeping but make it chic 🚪
  4. Possession authorization model (the URI itself is a secret): If this model is used, the location URI is confidential information shared between the LIS/LS, the Target, 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. The URI is the password, so keep it a secret 🤫🔑

3.4. Location URI Construction

Given scenarios 2 and 4, above, and 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 URI is then constrained by the degree of randomness and uniqueness applied to it. In this case, it may be important to protect the actual location information from inspection by an intermediate node. 🕵️‍♀️

Construction of a location URI in such a way as to not reveal any Target-specific information (e.g., user or device information), with the goal of making the location URI appear bland, uninteresting, and generic, may be helpful to some degree in order to keep location information more difficult to detect. Thus, obfuscating the location URI in this way may provide some level of safeguard against the undetected inspection and unintended use of what would otherwise be evident location information, since it forces a dereference operation at the location dereference server, an important step for the purpose of providing statistics, audit trails, and general logging for many different kinds of location-based services. Blend in, be boring, stay safe 🫥

4. High-Level Requirements ✨

This document outlines the requirements for a Location by Reference mechanism that can be used by a number of underlying protocols. Requirements here address two general types of such protocols, a general location configuration protocol and a general location dereferencing protocol. Two protocol types, one vibe 🧚‍♀️

The requirements are broken into two sections. 📋

4.1. Requirements for a Location Configuration Protocol ✨

okay so bestie, here's the high-level wishlist for a location-by-reference mechanism when it's used inside the location configuration protocol 💖 these are the design requirements, the vibe check for what this thing has to do 🎀

C1. Location URI support: The location configuration protocol MUST support a location reference in URI form.

Motivation: a standardized location reference mechanism makes things way more interoperable 🌸

C2. Location URI expiration: When a location URI has a limited validity interval, its lifetime MUST be indicated.

Motivation: a location URI might not be meant to represent a location forever ⏳ the identifier may eventually need to be recycled, or it may only be valid for a specific window. After that the reference stops yielding a location, or the location gets treated as 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 decides a location URI shouldn't be used to dereference a location anymore, there needs to be a way to ask for that URI to 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: location info has to stay masked from any casual nosy 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: the caller's identity or contact address should never get baked into the location URI itself when it's 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 asking for a location URI can request a "one-time-use" version instead of one with multiple-reuse capability ✌️ that lets the server send back an error, with or without location info, on any later dereference attempt.

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 the boss of how much info gets revealed during dereferencing, that's the whole privacy glow-up 💅

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 need to be built so an adversary can't guess one and dereference it without having gotten it from the Target first 🕵️‍♀️💀

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: not everyone needs super strict privacy, and some users want to pick their own location URI or the components that go inside it 🎀

4.2. Requirements for a Location Dereference Protocol 🦋

okay now the dereference side 💅 same deal, these are the high-level design requirements for a location-by-reference mechanism inside the location dereference protocol 🧚

D1. Location URI support: The location dereference protocol MUST support a location reference in URI form.

Motivation: the location URI formats used in a configuration protocol have to match the ones used by a dereference protocol, so everything stays consistent ✨

D2. Authentication: The location dereference protocol MUST include mechanisms to authenticate both the client and the server.

Motivation: even though implementations have to support authentication of both parties, any given transaction gets to choose not to authenticate one or both parties 🤷‍♀️

D3. Dereferenced location form: The value returned by the dereference protocol MUST contain a well-formed PIDF-LO document.

Motivation: this makes sure adequate privacy rules can be followed, because the PIDF-LO format has the structures needed to keep location private 🔐

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: depending on how the dereference server is configured, it can be useful to allow more than one dereference request, and sometimes to also cap how many dereferencing attempts a client gets 🔢

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 tells you what kind of security protocol has to be used. For example, a location URI that uses an HTTPS URI scheme 🔒

5. Security Considerations ✨

this section is SERIOUS bestie, read it all 🚨 it's the part that keeps everyone safe 😭

the way we build the location URI with randomized components helps stop adversaries from getting location info without ever retrieving a location URI 🎲 in the possession model, though, a location URI is a whole different story. If it's made publicly available, regardless of how it was built, there's no safeguard at all against anyone dereferencing it and getting the location 💀 so be careful about who you hand that location URI to, and only trusted location recipients should get one 🫶 if that worries you, the authorization model is the way to go. And even then, you have to be careful about how the authorization policies get written, so that only parties trustworthy enough to enforce the basic rule set attached to location information in a PIDF-LO document can access it 🛡️

every location URI, by necessity, tells you which server (name) hosts the location information 🏠 so just knowing the server in some specific domain could reveal something about where the Target is 👀 you can soften this threat a bit by adding another layer of indirection, namely a (remote) presence server 🧚

then there's the covert channel for protocol message exchange, which is a major concern 😱 picture this: user A subscribes to location info for user B. Every time A gets a location update, an (external) observer of that subscription notification can tell that B has moved 🏃‍♀️ one way to deal with this is periodic notification, so user B can appear to have moved even when they're actually sitting still 🪑✨

6. Acknowledgements 🫶

okay the thank-you list 💖 big shoutout to the present IETF GEOPRIV working group chairs, Alissa Cooper and Richard Barnes 👑, and the past chairs, Robert Sparks, Andy Newton, Allison Mankin, and Randall Gellens, who set up the design team that kicked off this requirements work 🌈 thanks also to the original design team participants for their inputs, comments, and insightful reviews. The design team included Richard Barnes, Martin Dawson, Keith Drage, Randall Gellens, Ted Hardie, Cullen Jennings, Marc Linsner, Rohan Mahy, Allison Mankin, Andrew Newton, Jon Peterson, James M. Polk, Brian Rosen, John Schnizlein, Henning Schulzrinne, Barbara Stark, Hannes Tschofenig, Martin Thomson, and James Winterbottom 🎀

7. References 📚

7.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2. Informative References

  • [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.

Author's Address 📮

Roger Marshall (editor)
TeleCommunication Systems, Inc.
2401 Elliott Avenue
2nd Floor
Seattle, WA  98121
US

Phone: +1 206 792 2424
EMail: rmarshall@telecomsys.com
URI:   http://www.telecomsys.com
📦 where this page comes from