idnits 2.17.1 draft-ietf-geopriv-sip-lo-retransmission-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2009) is 5524 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 416 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Peterson 3 Internet-Draft NeuStar, Inc. 4 Intended status: Informational T. Hardie 5 Expires: September 10, 2009 Qualcomm 6 J. Morris 7 CDT 8 March 9, 2009 10 Implications of 'retransmission-allowed' for SIP Location Conveyance 11 draft-ietf-geopriv-sip-lo-retransmission-02 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 10, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document explores an ambiguity in the interpretation of the 60 element of the Presence Information Data 61 Format for Location Objects (PIDF-LO) in cases where PIDF-LO is 62 conveyed by the Session Initiation Protocol (SIP). It provides 63 recommendations for how the SIP location conveyance mechanism should 64 adapt to these ambiguities. 66 Documents standardizing the SIP location conveyance mechanisms will 67 be standards-track documents processed according to the usual SIP 68 process. This document is intended primarily to provide the SIP 69 working group with a statement of the consensus of the GEOPRIV 70 working group on this topic. It secondarily provides tutorial 71 information on the problem space for the general reader. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 6 78 3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 3.2. Core Semantics . . . . . . . . . . . . . . . . . . . . . . 7 80 3.3. Limiting Access . . . . . . . . . . . . . . . . . . . . . 7 81 3.3.1. Limiting Access using Public Key Encryption . . . . . 7 82 3.3.2. Limiting Access using Location-by-Reference . . . . . 8 83 3.3.3. Refraining from Including Location Information . . . . 9 84 3.4. Choosing Among the Available Mechanisms . . . . . . . . . 9 85 3.5. Indicating Permission to Use Location-Based Routing in 86 SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 3.6. Behavior of Back-to-Back User Agents . . . . . . . . . . . 11 88 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 90 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 91 7. Informative References . . . . . . . . . . . . . . . . . . . . 12 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 94 1. Introduction 96 The Presence Information Data Format for Location Objects (PIDF-LO 97 [RFC4119]) carries both location information (LI) and policy 98 information set by the Rule Maker, as is stipulated in [RFC3693]. 99 The policy carried along with LI allows the Rule Maker to restrict, 100 among other things, the duration for which LI will be retained by 101 recipients and the redistribution of LI by recipients. 103 The Session Initiation Protocol [RFC3261] is one proposed Using 104 Protocol for PIDF-LO. The conveyance of PIDF-LO within SIP is 105 specified in [I-D.ietf-sip-location-conveyance]. The common 106 motivation for providing LI in SIP is to allow location to be 107 considered in routing the SIP message. One example use case would be 108 emergency services, in which the location will be used by dispatchers 109 to direct the response. Another use case might be providing location 110 to be used by services associated with the SIP session; a location 111 associated with a call to a taxi service, for example, might be used 112 to route to a local franchisee of a national service and also to 113 route the taxi to pick up the caller. 115 Some ambiguities have arisen in the interpretation of Rule Maker 116 policy when PIDF-LO is conveyed by SIP. The following sections 117 explore the problem and provide a recommendation. 119 2. Problem Statement 121 The element of RFC4119 was designed for use 122 in an environment like that of Section 4 of RFC3693, in which 123 Location Information (LI) propagates from a Location Generator 124 through a Location Server to a Location Recipient. In this 125 architecture, it is the responsibility of the Location Server to act 126 on the rules (policy) governing access control to LI, which are in 127 turn set by the Rule Maker. The most important of these 128 responsibilities is delivering LI to authorized Location Recipients 129 and denying it to others. Internal to RFC4119-compliant location 130 objects (LOs) are additional privacy rules which are intended to 131 constrain Location Recipients. These include the element. This element is intended to prevent a compromise 133 of privacy when an authorized recipient of LI shares that LI with 134 third-party entities, principally those who are not authorized by the 135 Rule Maker to receive LI. For example, a user might be willing to 136 share their LI with a pizza shop, but they might not want that pizza 137 shop to sell their LI to a targeted advertising company that will 138 contact the user with coupons for a nearby hair salon. 140 Bear in mind, however, that is not intended 141 to provide any protocol-level mechanism to prevent unauthorized 142 parties from learning location through means like eavesdropping. It 143 is merely a way to express the preferences of the Rule Maker to the 144 LR. If the LR were, for example, legally bound to follow the privacy 145 preferences expressed by Rule Makers, then they might incur liability 146 of they ignored the parameter. No further 147 privacy protection is assumed to be provided by . 150 There is a use case for LI that involves embedding it in a SIP 151 request that will potentially traverse multiple SIP intermediaries 152 before arriving at a UAS. In this use case, one or more 153 intermediaries might inspect the LI in order to make a SIP routing 154 decision; we will hereafter refer to this as location-based routing. 155 Common examples could include emergency services and other more 156 mundane cases where the originator of a SIP request wants to reach a 157 service in proximity to a particular geographic location, such as 158 contacting a nearby pizza shop. In both such cases the UAC may 159 intend for selected intermediaries and the UAS to have access to the 160 LI. In the pizza case, for instance, the UAC shares an address both 161 for location-based routing and additionally so that the pizza shop 162 reached by that routing has the address to which a pizza should be 163 sent. 165 This location-based routing use case for LI has a number of important 166 disconnects from the RFC3693 model. Unlike the RFC3693 model, there 167 is no LS designating to which specific entities LI will be sent. 168 There may be multiple intermediaries between the UAC and UAS, some of 169 which need or want to inspect LI (which would seem to qualify them as 170 LRs) and some of them will not. While SIP proxy servers generally 171 are not RFC4119-aware and do not need to inspect SIP request bodies 172 in order to perform their function, nothing precludes proxy servers 173 inspecting or logging any SIP message bodies, including LI. 174 Furthermore, it is very difficult for the UAC to anticipate which 175 intermediaries and which eventual UAS a SIP request might reach. 177 This architecture is further complicated by the possibility of 178 sending location information by-reference, that is, placing a URL 179 where LI can be retrieved in SIP requests instead of using a PIDF-LO 180 body (commonly called including the PIDF-LO by value) Depending on 181 the qualities of a reference, further authorization checks may be 182 performed before LI is retrieved, LI may be customized depending on 183 who is asking, and so forth. As will be discussed in greater detail 184 below, the conveyance of a reference may have very different privacy 185 properties than conveying a PIDF-LO body by-value in a SIP request. 187 In this architecture, the question of who is an "authorized 188 recipient" from the point of view of the Rule Maker has been muddy. 190 The SIP elements along the path are authorized to receive and forward 191 the SIP message; does that make them automatically authorized 192 recipients of the LI it contains? The final target of the SIP 193 message will receive the LI along with other information, but it may 194 be different than the initial target in a variety of scenarios; is it 195 authorized to read the LI? 197 These questions and concerns are particularly problematic when 198 is set to "no" (the default case). This 199 core concern might be put as "to whom does 200 apply in location-based routing?" More specifically: 202 Is any entity that reads LI bound by ? If 203 so, does that mean a proxy that performs location-based routing is 204 unable to forward a request and complete a SIP call if 205 is "no"? Alternatively, must they strip the 206 location body from the message in order to complete the call? 208 If the proxy does not understand RFC4119, it may forward a SIP 209 message containing a policy statement set to 210 "no". Is any proxy that does understand RFC4119 required to parse 211 the LI for this statement, even if it would not do so in order to 212 route the message? 214 Is there a need for SIP-level indications regarding retransmission 215 for the benefit of entities that do not understand 4119? 217 Since the UAC cannot anticipate who may receive a SIP request, how do 218 we understand who the intended LR is in the location-based routing 219 case? Can a UAC have intended for there to be multiple serial LRs in 220 a transmission? If so, if one LR is authorized to retransmit to 221 another LR, how will it know it is not also authorized to transmit LI 222 to other third parties (i.e., how will the serial LRs know to whom 223 they are authorized to retransmit)? How could all of this be 224 designated? 226 3. Recommendation 228 The following sections provide a recommendation for how the 229 flag should be understood in a SIP 230 environment. The core semantics of this recommendation represent the 231 consensus of the GEOPRIV working group. While Section 3.5 proposes a 232 syntax that might be adopted by the SIP WG to implement these 233 semantics in its protocol, the actual syntax of SIP is the 234 responsibility of the SIP WG. 236 3.1. Goals 238 After extensive discussion in both GEOPRIV and SIP contexts, there 239 seems to be consensus that a solution for this problem must enable 240 location-based routing to work even when the 241 flag is set to "no". A solution should also give the Rule Maker the 242 ability to allow or forbid the use of LI for location-based routing 243 and the ability to allow or forbid the use of LI for the consumption 244 of the endpoint. 246 3.2. Core Semantics 248 Consensus has emerged that any SIP entity which receives a SIP 249 message containing LI through the operation of SIP's normal routing 250 procedures or as a result of location-based routing should be 251 considered an authorized recipient of that LI. Because of this 252 presumption, one SIP element may pass the LI to another even if the 253 LO it contains has set to "no"; this sees 254 the passing of the SIP message as part of the delivery to authorized 255 recipients, rather than as retransmission. SIP entities are still 256 enjoined from passing these messages outside the normal routing to 257 external entities if is set to "no", as it 258 is the passing to 3rd parties that is meant 259 to control. 261 This architecture is considerably different from the presumptions of 262 RFC3963, in that authorized recipients pass the LO on to other 263 authorized recipients, but it seems to be the most sensible mechanism 264 given SIP's operation. 266 To maintain the Rule Maker's ability to affect the consumption of 267 this information, two different mechanisms may be used to limit the 268 distribution of LI and one may used to limit the sphere in which it 269 may be used; these are discussed below. 271 3.3. Limiting Access 273 3.3.1. Limiting Access using Public Key Encryption 275 One way of limiting access to LI is to encrypt the PIDF-LO object in 276 a SIP request. If the originator knows which specific entity on the 277 path needs to inspect the LI, and knows a public key for that entity, 278 this is a straightforward matter. It is even possible to encrypt 279 multiple instance of PIDF-LO, containing different policies or levels 280 of location granularity, in the same SIP request if multiple entities 281 along the path need to inspect the location. 283 This is most likely to be effective in cases where the originator 284 does not wish the LI to be inspected by intermediate entities and has 285 the public key for the target of the SIP message, as it is very 286 difficult for the originator to anticipate the intermediaries through 287 which a SIP message will pass. It may also be useful in limited 288 environments where the originator has a trust relationship with a 289 specific SIP element (e.g. a "home" or first-hop proxy) and it wants 290 to reveal that LI only to that element. 292 Note that even in the case where the originator intends to encrypt LI 293 for the benefit only of the target of the message it may be quite 294 difficult to anticipate the eventual endpoint of the message. These 295 encrypted LIs will not be useful in any case where the anticipation 296 of the originators is not met. 298 An additional problem posed by this approach is that it requires some 299 sort of public key discovery system, which compounds the operational 300 complexity significantly. While this method is included for 301 completeness, it is the consensus of the working group that the 302 deployment scenarios in which this is appropriate will be relatively 303 few; we do not believe it is an appropriate baseline approach. 305 3.3.2. Limiting Access using Location-by-Reference 307 Another, more feasible approach is leveraging location by reference. 308 When a SIP request conveys a reference, it cannot be properly said to 309 be conveying location; location is conveyed upon dereferencing the 310 URI in the question, and the meaning of must 311 be understood in the context of that conveyance, not the forwarding 312 of the SIP request. 314 The properties of references, especially the security properties, 315 vary significantly depending on the nature and disposition of the 316 resource indicated. Clearly, if the referenced PIDF-LO is available, 317 in the same form, to any entity along the SIP signaling path that 318 requests it, then inserting a reference has no advantages over 319 inserting LI by value (and introduces wasteful complexity). However, 320 if the Rule Maker influences the results of the dereferencing 321 process, including determining who can receive LI at what degree of 322 granularity and what policies are bound with the LI, the security 323 properties are different. 325 It might superficially appear that this suffers from the same 326 problems as the encryption approach, since the Rule Maker must 327 anticipate a set of entities who are authorized to receive location 328 information. The difference is that this set does not need to be 329 communicated in the SIP request in order for authorization decisions 330 to be made. There is a world of difference between managing a 331 whitelist of a thousand parties that might ask for LI and sending a 332 SIP request containing a thousand differently-encrypted adumbrations 333 on LI - the former is commonplace and the latter is impossible. 334 Additionally, some Rule Maker policies might not even require the 335 establishment of an exhaustive whitelist. For example, it may be 336 that there exists a finite set of commercial requestors that the Rule 337 Maker would like to block, in a manner similar to the way ad-blockers 338 operate in modern web browsers. 340 In any system where one makes an authorization decision, a certain 341 cost in authentication must be paid - the greater the assurance the 342 greater the cost. The precise cost will of course depend on the URI 343 scheme of the reference. For SIP, Digest has a low computational 344 cost but requires pre-established keys, which limits applicability. 345 RFC4474 Identity does not require any pre-association, but it does 346 make signaling more heavyweight and requires the deployment of 347 additional features in the network, including a web-like PKI. 349 But even if no authentication takes place, in the LbyR case the 350 meaning of is unambiguous - each entity to 351 which LI is conveyed in the dereference process is bound by the 352 retransmission policy. The cost of the reference itself is of course 353 the server that maintains the resource. While not every SIP client 354 has access to an appropriate server for this purpose, the fact that 355 PIDF-LO builds on the typical SIP presence service makes this less 356 implausible than it might be. Moreover, the LbyR approach casts the 357 conveyance architecture in a manner familiar from RFC3693, with a 358 Location Server receiving requests from Location Recipients which may 359 be accepted or denied. This allows the preservation of the original 360 semantics of . 362 3.3.3. Refraining from Including Location Information 364 The most fundamental mechanism for limiting access to location 365 information is simply not including it. While location-based-routing 366 might conceivably occur in almost any SIP message in the future, 367 there is no requirement that location be included in the general case 368 to support it. If it is not included and is required, an appropriate 369 error indicating the lack may be returned and the choice made to 370 continue communication with the information included. This challenge 371 and response will slow the establishment of communication when it is 372 required, but it is the most basic way to ensure that location 373 distribution is limited to the times when it is required for 374 communication to proceed. 376 3.4. Choosing Among the Available Mechanisms 378 Refraining from including location is the most appropriate choice for 379 systems that do not wish to reveal location to any party in the SIP 380 path. 382 Location-by-Reference is generally recommended as the most deployable 383 mechanism for limiting access to LI which is passed via a SIP 384 message. It is significantly easier to deploy than public key 385 discovery systems, allows for both whitelists and blacklists, and can 386 scale in ways that the inclusion of multiple encrypted bodies cannot. 387 Encryption may be used in a limited set of circumstance where 388 location-by-value must be used. 390 3.5. Indicating Permission to Use Location-Based Routing in SIP 392 The discussion in Section 3.3.2 describes 3 mechanisms for limiting 393 the distribution of LI to specific entities. There remains the 394 problem of limiting the use to which LI included by value or by 395 reference may be put. In order to meet the need to limit that use, 396 this document recommends the creation of a syntactical element in SIP 397 to carry this information. As an exemplary concrete proposal, we 398 recommend a "Location-Routing-Allowed" header as described below. 400 When "Location-Routing-Allowed" is set to "Yes", the Rule Maker is 401 indicating permission to use the included LI for location-based 402 routing. When "Location-Routing-Allowed" is set to "No", the 403 originator is indicating that this use is not permitted. "Location- 404 Routing-Allowed" being set to "No" has no protocol-level mechanism 405 for enforcement of this behavior; like the PIDF-LO being set to "no", it is a way for the Rule Maker to express 407 a preference to the SIP elements which are LI recipients. It may, 408 however, present a significant optimization. Where a location-by- 409 reference is included with "Location-Routing-Allowed" set to "No", 410 the SIP elements along the path know that they do not need to attempt 411 to dereference the location information; this is significantly faster 412 than attempting the dereference and being denied at the 413 authentication stage. 415 We recommend that "Location-Routing-Allowed" be made mandatory-to- 416 implement for elements complying with [1]. 418 We recommend that it appear in any SIP message that contains a 419 location, whether by reference or by value. 421 We recommend that any SIP message containing a location but no 422 "Location-Routing-Allowed" header should be treated as containing a 423 "Location-Routing-Allowed" header set to "No". 425 We recommend that a UA be allowed to insert a "Location-Routing- 426 Allowed" header even when it has not included a location, in order to 427 set the policy for any locations inserted by other SIP elements. 429 This allows the UA to assert that it is a Rule Maker for locations, 430 even when the network architecture in which the UA is present inserts 431 the location into SIP messages after the UA has originated the SIP 432 exchange. 434 We recommend that any SIP element inserting a location, whether by 435 reference or by value, insert a "Location-Routing-Allowed header if 436 one is not already present. If one is present, it should not be 437 over-ridden by the SIP element inserting the location. 439 We recommend that any SIP element not the originator of a message and 440 not inserting a location be enjoined from inserting a "Location- 441 Routing-Allowed" header. 443 3.6. Behavior of Back-to-Back User Agents 445 Back-to-back user agent behavior is often difficult to proscribe. 446 There are many uses of B2BUAs, and the rules that apply to location 447 would depend on the actual use case. This section suggests what any 448 SIP mechanism arising from this document might wish to consider with 449 regard to B2BUA behavior. 451 In most uses of B2BUAs, they act as a simple intermediary between the 452 nominal originating and nominal terminating UAs, that is, a proxy 453 that does something proxies aren't allowed to do. In such cases, the 454 B2BUA must conform to any new routing-allowed mechanism if it chooses 455 an outgoing route. As this document advises proxies, 456 does not apply to the B2BUA in this case and 457 the B2BUA must copy the LI, the new routing-allowed and existing 458 values. 460 Where the B2BUA in fact does act as an endpoint (terminating the 461 session and originating a different session), applies to it, and it must not copy location if 463 is "no". If it chooses a route for the 464 outgoing leg, any new routing-allowed mechanism applies to it. 466 Encryption lets the originator control who, including B2BUAs, is 467 allowed to see location. On the other hand, using encryption with LI 468 which is needed for routing is problematic, in that it is often 469 difficult to know in advance which elements do location based 470 routing. Similarly, using location-by-reference instead of location- 471 by-value provides additional control to the originator over B2BUA 472 behavior by controlling who can dereference. See Section 3.4 for 473 more guidance on this trade off. 475 4. IANA Considerations 477 This memo includes no request to IANA. 479 5. Security Considerations 481 The privacy and security implications of distributing location 482 information are the fundamental subject of this document. 484 6. Acknowledgements 486 James Polk provided a series of questions regarding the specifics of 487 the Location-Routing-Allowed mechanism, and this resulted in the 488 recommendations in Section 3.4. Thanks to Brian Rosen for the text 489 on B2BUAs. 491 7. Informative References 493 [I-D.ietf-sip-location-conveyance] 494 Polk, J. and B. Rosen, "Location Conveyance for the 495 Session Initiation Protocol", 496 draft-ietf-sip-location-conveyance-13 (work in progress), 497 March 2009. 499 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 500 A., Peterson, J., Sparks, R., Handley, M., and E. 501 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 502 June 2002. 504 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 505 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 507 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 508 Format", RFC 4119, December 2005. 510 Authors' Addresses 512 Jon Peterson 513 NeuStar, Inc. 515 Email: jon.peterson@neustar.biz 516 Ted Hardie 517 Qualcomm 519 Email: hardie@qualcomm.com 521 John Morris 522 CDT 524 Email: jmorris@cdt.org