RFC 5606

Implications of 'retransmission-allowed' for SIP Location Conveyance

📅 published August 2009, from ietf

RFC 5606: Implications of 'retransmission-allowed' for SIP Location Conveyance 🎀

Network Working Group ✨ Request for Comments: 5606

  • Authors: J. Peterson (NeuStar, Inc.), T. Hardie (Qualcomm), J. Morris (CDT) 💖
  • Category: Informational 🌸
  • Date: August 2009 🦋
  • Obsoletes/Updates: the title block doesn't list anything this one obsoletes or updates 🧚

Abstract ✨

Okay so this doc pokes at a confusing bit about the <retransmission-allowed> element of the Presence Information Data Format for Location Objects (PIDF-LO) when it's carried by the Session Initiation Protocol (SIP). 🔍 It gives recommendations for how the SIP location conveyance mechanism should adapt to that confusion.

Docs that standardize SIP location conveyance mechanisms will be Standards-Track documents, handled by the usual SIP process 📋. This one is mainly there to give the SIP working group the GEOPRIV working group's consensus on this topic. It also secondarily offers tutorial info on the problem space for general readers 🫶.

Status of This Memo 🌷

This memo gives information to the Internet community. It doesn't specify an Internet standard of any kind 🙅. Distribution of this memo is unlimited 💜.

Copyright (c) 2009 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, as they stand on the date this document was published (http://trustee.ietf.org/license-info). Please review those documents carefully, since they spell out your rights and restrictions with respect to this document 📜.

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 🕰️. The people controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications of it outside the IETF Standards Process. Unless you get an adequate license from the people controlling the copyright in those 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. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍.

Table of Contents 🗂️

1. Introduction ....................................................2
2. Problem Statement ...............................................3
3. Recommendation ..................................................5
   3.1. Goals ......................................................5
   3.2. Core Semantics .............................................5
   3.3. Limiting Access ............................................6
        3.3.1. Limiting Access Using Public Key Encryption .........6
        3.3.2. Limiting Access Using Location-by-Reference .........7
        3.3.3. Refraining from Including Location Information ......8
   3.4. Choosing among the Available Mechanisms ....................8
   3.5. Indicating Permission to Use Location-Based Routing
        in SIP .....................................................8
   3.6. Behavior of Back-to-Back User Agents ......................10
4. Security Considerations ........................................10
5. Acknowledgements ...............................................10
6. Informative References .........................................11

1. Introduction 🌸

Okay so PIDF-LO [RFC4119] carries two things in one bundle: location information (LI) and policy information set by the Rule Maker, as stipulated in [RFC3693] 🎁. That policy is what lets the Rule Maker restrict things like how long recipients can keep the LI and whether recipients can pass it along to others 🔐.

The Session Initiation Protocol [RFC3261] is one proposed Using Protocol for PIDF-LO 📞. How PIDF-LO gets conveyed within SIP is specified in [LOC-CONVEY] 📦. The main reason people want LI in SIP is so location can be considered when routing the SIP message 🗺️. Emergency services are the big example, since dispatchers use the location to direct the response 🚨. Another use case is providing location for services tied to the SIP session. Like, a location attached to a call to a taxi service could be used to route to a local franchisee of a national service, and also to route the taxi to pick up the caller 🚕✨.

Some ambiguities have popped up in how Rule Maker policy gets interpreted when PIDF-LO is conveyed by SIP 🤔. The following sections explore the problem and provide a recommendation 💅.

2. Problem Statement 💅

The <retransmission-allowed> element of RFC 4119 was designed for an environment like the one in Section 4 of RFC 3693 🧩. In that setup, Location Information (LI) propagates from a Location Generator, through a Location Server (LS), to a Location Recipient (LR). The Location Server is responsible for acting on the rules (policy) that govern access control to LI, and those rules are set by the Rule Maker 📜. The most important part of that job is delivering LI to authorized Location Recipients and denying it to everyone else 🙅‍♀️.

Inside [RFC4119]-compliant location objects (LOs) there are extra privacy rules meant to constrain Location Recipients, and <retransmission-allowed> is one of them 🔒. It's meant to prevent a compromise of privacy when an authorized recipient of LI shares that LI with third-party entities, mainly ones the Rule Maker hasn't authorized to receive LI 🙈. For example, a user might be totally fine sharing their LI with a pizza shop 🍕, but not want that shop to sell their LI to a targeted advertising company that'll send them coupons for a nearby hair salon 💀.

Bear in mind, though, that <retransmission-allowed> is not intended to provide any protocol-level mechanism to stop unauthorized parties from learning location through things like eavesdropping 👀. It's just a way to express the Rule Maker's preferences to the LR. If the LR were, for example, legally bound to follow the privacy preferences that Rule Makers express, then ignoring the <retransmission-allowed> parameter could mean they incur liability ⚖️. No further privacy protection is assumed to be provided by <retransmission-allowed> 🫠.

There's a use case for LI that involves embedding it in a SIP request. That request might traverse multiple SIP intermediaries before arriving at a user agent server (UAS) 🛤️. In this use case, one or more intermediaries might inspect the LI to make a SIP routing decision, and from here on we'll call this location-based routing 🧭. Common examples include emergency services and more everyday cases, like when the originator of a SIP request wants to reach a service near a particular geographic location, such as contacting a nearby pizza shop 🍕. In both kinds of case, the UAC might intend for selected intermediaries and the UAS to have access to the LI. In the pizza case, for instance, the user agent client (UAC) shares an address both for location-based routing and so that the pizza shop reached by that routing knows where to send the pizza 🛵💖.

This location-based routing use case has a number of important disconnects from the RFC 3693 model 🙃. Unlike the RFC 3693 model, there's no LS designating which specific entities the LI will be sent to. There may be multiple intermediaries between the UAC and UAS. Some of them will need or want to inspect the LI (which would seem to qualify them as LRs), and some won't. SIP proxy servers generally aren't [RFC4119]-aware and don't need to inspect SIP request bodies to perform their function. Still, nothing precludes proxy servers from inspecting or logging any SIP message bodies, including LI 👩‍💻. On top of that, it's very difficult for the UAC to anticipate which intermediaries, and which eventual UAS, a SIP request might reach 😭.

This architecture gets further complicated by the possibility of sending location information by-reference 🔗. That means placing a URL where LI can be retrieved in the SIP request, instead of using a PIDF-LO body (commonly called including the PIDF-LO by value) ✨. Depending on the qualities of a reference, further authorization checks may be performed before LI is retrieved, LI may be customized depending on who is asking, and so on 🎀. As we'll discuss in more detail below, conveying a reference can have very different privacy properties than conveying a PIDF-LO body by-value in a SIP request 🦋.

In this architecture, the question of who is an "authorized recipient" from the point of view of the Rule Maker has been muddy 🌫️.

The SIP elements along the path are authorized to receive and forward the SIP message. Does that make them automatically authorized recipients of the LI it contains? 🤨 The final target of the SIP message will receive the LI along with other information, but that target may be different from the initial target in a variety of scenarios. Is it authorized to read the LI? 🧐

These questions and concerns are especially problematic when <retransmission-allowed> is set to "no" (the default case) 🚫. This core concern might be put as "to whom does <retransmission-allowed> apply in location-based routing?" 🤯 More specifically:

Is any entity that reads LI bound by <retransmission-allowed>? If so, does that mean a proxy that performs location-based routing is unable to forward a request and complete a SIP call if <retransmission-allowed> is "no"? Alternatively, must it strip the location body from the message in order to complete the call? If the proxy does not understand RFC 4119, it may forward a SIP message containing a policy statement with <retransmission-allowed> set to "no". Is any proxy that does understand RFC 4119 required to parse the LI for this statement, even if it wouldn't do so in order to route the message? 🧠

Is there a need for SIP-level indications regarding retransmission, for the benefit of entities that do not understand RFC 4119? 📣

Since the UAC can't anticipate who may receive a SIP request, how do we understand who the intended LR is in the location-based routing case? Can a UAC have intended for there to be multiple serial LRs in a transmission? If so, and if one LR is authorized to retransmit to another LR, how will it know it is not also authorized to transmit LI to other third parties? In other words, how will the serial LRs know who they're authorized to retransmit to? How could all of this be designated? 🥺💜

3. Recommendation 👑

The following sections provide a recommendation for how the <retransmission-allowed> flag should be understood in a SIP environment 🌟. The core semantics of this recommendation represent the consensus of the GEOPRIV working group. Section 3.5 proposes a syntax that might be adopted by the SIP WG to implement these semantics in its protocol, but the actual syntax of SIP is the responsibility of the SIP WG 🌈.

3.1. Goals 💖

okay so after SO much discussion in both GEOPRIV and SIP land 💅, there's consensus that a solution has to make location-based routing work even when <retransmission-allowed> is set to "no" 🫶. It should also give the Rule Maker the power to allow or forbid using LI for location-based routing, plus the power to allow or forbid using LI for the endpoint's own consumption 🔥.

3.2. Core Semantics ✨

okay this part is lowkey the heart of it 🥹. Everyone agreed that any SIP entity which gets a SIP message carrying LI, whether through SIP's normal routing or because of location-based routing, counts as an authorized recipient of that LI 🎀. Because of that, one SIP element can pass the LI along to another even if the LO inside has <retransmission-allowed> set to "no". The passing counts as part of delivering to authorized recipients, not as retransmission 🦋. BUT 🚨 SIP entities still can't pass these messages out through normal routing to external entities when <retransmission-allowed> is set to "no", because passing to third parties is exactly what <retransmission-allowed> exists to control 💀.

This setup is pretty different from the assumptions in RFC 3963, since here authorized recipients pass the LO on to other authorized recipients. Still, it seems like the most sensible option given how SIP works 🧚.

To keep the Rule Maker in charge of how this info gets used, two different mechanisms can limit who receives LI, and one can limit where it's allowed to be used. We'll go through these below 👑.

3.3. Limiting Access 🔒

3.3.1. Limiting Access Using Public Key Encryption 🗝️

One way to limit access to LI is to encrypt the PIDF-LO object in a SIP request 🌸. If the originator knows which specific entity on the path needs to inspect the LI, and has a public key for that entity, this is pretty straightforward 💅. It's even possible to encrypt several instances of PIDF-LO, each with different policies or levels of location granularity, in the same SIP request, in case multiple entities along the path need to look at the location 🌈.

This is most likely to work well when the originator doesn't want intermediate entities to inspect the LI and has the public key for the target of the SIP message. Honestly, it's really hard for the originator to predict which intermediaries a SIP message will pass through 😭. It might also be useful in limited environments where the originator trusts one specific SIP element (like a "home" or first-hop proxy) and only wants to reveal the LI to that element 🫶.

Also, even when the originator means to encrypt LI just for the target of the message, it can be super hard to predict where the message will actually end up 🙈. These encrypted LIs won't be useful in any case where the originator's prediction turns out to be wrong ❌.

Another problem with this approach is that it needs some sort of public key discovery system, which makes the operational complexity a LOT worse 💀. The working group agreed that this method is included for completeness, but the deployment scenarios where it fits are relatively few. It is NOT the baseline approach we'd recommend 🙅‍♀️.

3.3.2. Limiting Access Using Location-by-Reference 🔗

Another approach that's way more feasible is location by reference ✨. When a SIP request carries a reference, it can't really be said to be carrying location 🙃. The location is conveyed when the URI in question gets dereferenced, so the meaning of <retransmission-allowed> has to be understood in terms of that conveyance, not in terms of forwarding the SIP request 🦋.

The properties of references, especially the security ones, can vary a lot depending on what the referenced resource is and how it's set up 🫠. If the referenced PIDF-LO is available in the same form to any entity on the SIP signaling path that asks for it, then putting in a reference has no advantage over putting LI in by value, and it just adds unnecessary complexity 🙄. But if the Rule Maker gets to influence the results of dereferencing, including who can receive LI, at what level of granularity, and which policies are attached to the LI, then the security properties are different 👑.

It might seem like this has the same problems as the encryption approach, since the Rule Maker still has to predict a set of entities who are allowed to receive location information 🤔. The difference is that this set doesn't have to be sent along in the SIP request for authorization decisions to happen 💖. There's a world of difference between managing a whitelist of a thousand parties that might ask for LI and sending a SIP request with a thousand differently encrypted versions of the LI. The first is totally commonplace, and the second is impossible 💀. Plus, some Rule Maker policies don't even need an exhaustive whitelist 🛡️. For example, there might be a finite set of commercial requestors the Rule Maker wants to block, kind of like how ad-blockers work in modern web browsers 🚫.

Any system that makes an authorization decision has to pay some cost in authentication, and the greater the assurance, the greater the cost 💸. The exact cost depends on the URI scheme of the reference. For SIP, Digest has a low computational cost but needs pre-established keys, which limits where it can be used 🔑. RFC 4474 Identity doesn't need any pre-association, but it makes signaling more heavyweight and requires additional features in the network, including a web-like public key infrastructure (PKI) 🏗️.

Even if no authentication happens, in the Location-by-Reference (LbyR) case the meaning of <retransmission-allowed> is still clear 🌟. Every entity that receives LI during the dereference process is bound by the retransmission policy 🎀. The cost of the reference itself is the server that maintains the resource 🖥️. Not every SIP client has access to an appropriate server for this, but since PIDF-LO builds on the typical SIP presence service, that's a lot less unlikely than it might otherwise be 🌈. On top of that, the LbyR approach sets up the conveyance architecture in a way that's familiar from RFC 3693, with a Location Server receiving requests from Location Recipients, which can be accepted or denied 🧚. This lets the original semantics of <retransmission-allowed> be preserved 💅.

3.3.3. Refraining from Including Location Information 🙈

The most fundamental way to limit access to location information is to simply not include it 🤷‍♀️. Location-based routing might conceivably happen in almost any SIP message in the future, but there's no requirement that location be included in the general case just to support it 💫. If location isn't included and is required, an appropriate error can be returned to indicate the lack, and then the choice can be made to continue communication with the information included 🔁. This back-and-forth slows down setting up communication when location is needed, but it's the most basic way to make sure location is only distributed when it's actually required for communication to go on 🫶.

3.4. Choosing among the Available Mechanisms 🧭

Leaving location out is the best choice for systems that don't want to reveal location to any party on the SIP path 🙊.

Location-by-Reference is generally recommended as the most deployable mechanism for limiting access to LI passed via a SIP message 🏆. It's a LOT easier to deploy than public key discovery systems, it allows for both whitelists and blacklists, and it can scale in ways that including multiple encrypted bodies just can't 📈. Encryption can still be used in a limited set of circumstances where location-by-value has to be used 🔐.

3.5. Indicating Permission to Use Location-Based Routing in SIP 🚦

The discussion in Section 3.3.2 describes 3 mechanisms for limiting the distribution of LI to specific entities 🎯. There's still the problem of limiting what LI (included by value or by reference) can be used for 😤. To handle that, this document recommends creating a syntactical element in SIP to carry this information 🧩. As an example of a concrete proposal, we recommend a Location-Routing-Allowed header, described below 💌.

When Location-Routing-Allowed is set to "Yes", the Rule Maker is saying it's okay to use the included LI for location-based routing ✅. When Location-Routing-Allowed is set to "No", the originator is saying this use is NOT permitted 🚫. Setting Location-Routing-Allowed to "No" has no protocol-level way to enforce this behavior 🙃. Like <retransmission-allowed> being set to "no" in PIDF-LO, it's a way for the Rule Maker to express a preference to the SIP elements that are LI recipients 🫶. It can still be a big optimization, though 🚀. When a location-by-reference comes with Location-Routing-Allowed set to "No", the SIP elements along the path know they don't need to try dereferencing the location information. That's a lot faster than trying the dereference and getting denied at the authentication stage ⚡.

We recommend that Location-Routing-Allowed be made mandatory-to-implement for elements complying with [LOC-CONVEY] 🎀.

We recommend that it appear in any SIP message that contains a location, whether by reference or by value 💖.

We recommend that any SIP message containing a location but no Location-Routing-Allowed header be treated as containing a Location-Routing-Allowed header set to "no" 🙅‍♀️.

We recommend that a UA be allowed to insert a Location-Routing-Allowed header even when it hasn't included a location, so it can set the policy for any locations inserted by other SIP elements 🌈.

This lets the UA assert that it's a Rule Maker for locations, even when the network architecture the UA sits in inserts the location into SIP messages after the UA has started the SIP exchange 👑.

We recommend that any SIP element inserting a location, whether by reference or by value, insert a Location-Routing-Allowed header if one isn't already there. If one is already present, the SIP element inserting the location should not override it 🛑.

We recommend that any SIP element that isn't the originator of a message and isn't inserting a location be prohibited from inserting a Location-Routing-Allowed header 🚫💅.

3.6. Behavior of Back-to-Back User Agents 🎀

Okay so B2BUA behavior is lowkey hard to lock down with rules 😭 There are so many ways people use B2BUAs, and what applies to location totally depends on the use case. This section is just a list of things any SIP mechanism coming out of this doc might wanna think about when it comes to B2BUAs 💅

In most uses, a B2BUA acts as a simple middleman between the originating UA and the terminating UA. Basically it's a proxy doing stuff proxies aren't allowed to do ✨ In that case, the B2BUA must follow any new routing-allowed mechanism if it picks an outgoing route. Also, as this doc tells proxies, <retransmission-allowed> doesn't apply to the B2BUA here, and the B2BUA must copy the LI, the new routing-allowed value, and the existing <retransmission-allowed> value 🫶

Now if the B2BUA is actually acting as an endpoint (it ends the session and starts a different one), then <retransmission-allowed> applies to it. It must not copy location if <retransmission-allowed> is "no" 🙈 And if it picks a route for the outgoing leg, then any new routing-allowed mechanism applies to it too.

Here's the tea 🍓 Encryption lets the originator decide who gets to see location, and that includes B2BUAs. BUT using encryption with LI is kinda problematic, because LI is needed for routing and it's often hard to know ahead of time which elements actually do location-based routing 💀 Location-by-Reference is another option. Instead of sending location by value, you get more control over B2BUA behavior, because you decide who can dereference it 👑 For more on that tradeoff, check Section 3.4 🦋

4. Security Considerations 🔥

The privacy and security implications of distributing location information are the whole point of this document 🥺🔒 Like, it's the main event, bestie 💜

5. Acknowledgements 🫶

James Polk asked a bunch of questions about the specifics of the Location-Routing-Allowed mechanism, and those questions led to the recommendations in Section 3.4. Huge thanks to Brian Rosen for writing the text on B2BUAs 🌸✨

6. Informative References 📚

[LOC-CONVEY] Polk, J. and B. Rosen, "Location Conveyance for the
             Session Initiation Protocol", Work in Progress, March
             2009.

[RFC3261]    Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
             A., Peterson, J., Sparks, R., Handley, M., and E.
             Schooler, "SIP: Session Initiation Protocol", RFC 3261,
             June 2002.

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

Authors' Addresses 🧚

Jon Peterson
NeuStar, Inc.

EMail: jon.peterson@neustar.biz


Ted Hardie
Qualcomm

EMail: hardie@qualcomm.com


John Morris
Center for Democracy & Technology

EMail: jmorris@cdt.org
📦 where this page comes from