idnits 2.17.1 draft-ietf-ecrit-rough-loc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 == Line 244 has weird spacing: '....police urn...' -- The document date (January 20, 2010) is 5202 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-14 == Outdated reference: A later version (-05) exists of draft-ietf-ecrit-lost-servicelistboundary-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-ecrit-lost-servicelistboundary (ref. '4') == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-10 == Outdated reference: A later version (-09) exists of draft-ietf-sipcore-location-conveyance-01 == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-21 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Barnes 3 Internet-Draft M. Lepinski 4 Intended status: Standards Track BBN Technologies 5 Expires: July 24, 2010 January 20, 2010 7 Using Imprecise Location for Emergency Context Resolution 8 draft-ietf-ecrit-rough-loc-01.txt 10 Abstract 12 Emergency calling works best when precise location is available for 13 emergency call routing. However, there are situations in which a 14 location provider is unable or unwilling to provide precise location, 15 yet still wishes to enable subscribers to make emergency calls. This 16 document describes the level of location accuracy that providers must 17 provide to enable emergency call routing. In addition, we descibe 18 how emergency services and non-emergency services can be invoked by 19 an endpoint that does not have access to its precise location. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on July 24, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Determining sufficient location precision . . . . . . . . . . 4 64 3.1. Location filtering . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Constructing location filters . . . . . . . . . . . . . . 10 66 3.2.1. Civic address considerations . . . . . . . . . . . . . 11 67 3.3. Maintaining location filters . . . . . . . . . . . . . . . 12 68 3.4. Applying location filters . . . . . . . . . . . . . . . . 12 69 4. Requesting emergency and non-emergency services . . . . . . . 13 70 4.1. Emergency calling . . . . . . . . . . . . . . . . . . . . 13 71 4.2. Non-emergency services . . . . . . . . . . . . . . . . . . 14 72 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 Information about the location of an emergency caller is a critical 83 input to the process of emergency call establshment. Endpoint 84 location is used to determine which Public Safety Answering Point 85 (PSAP) should be the destination of the call. (The entire emergency 86 calling process is described in detail in [6] and [1].) This process 87 is most likely to work properly when the endpoint is provided with 88 the most accurate and precise information available about its 89 location. Using location information with maximal precision and 90 accuracy minimizes the chance that a call will be mis-routed. In 91 addition, when that location is provided to the endpoint, the 92 endpoint is able to verify that the location is correct (to the 93 extent of the endpoint's knowledge of its own location) prior to an 94 emergency call, and is able to perform emergency call routing 95 functions on its own, providing redundancy for network-provided 96 functions. 98 However, there may be situations in which it is not feasible for 99 endpoints to be provided with maximally precise and accurate 100 location. These cases may arise when computing precise location is 101 an expensive or time-consuming operation (e.g., in the case of 102 wireless triangulation), and location is needed quickly, as is often 103 the case in emergency situations. Or they may arise because the 104 policy of a location provider does not allow precise location to be 105 provided to the endpoint. While it is undesirable to use imprecise 106 location for emergency call routing, the possibility that precise 107 location may not be available to the calling device must be 108 accomodated in order to make emergency calling possible in the 109 largest possible set of circumstances. 111 This document is concerned with imprecise location only in the 112 context of routing emergency calls, i.e., for determining the correct 113 PSAP to receive a given call (e.g., via a LoST query [2]). Depending 114 on the the structure of the local emergency service network, the 115 location information provided to the endpoint may also be used to 116 route the call to an entity that is authorized to request precise 117 location, e.g., an Emergency Services Routing Proxy. The 118 requirements and processes described in this document are the same 119 for both cases. 121 Location information may also be used in the emergency calling 122 framework to direct the dispatch of emergency responders. This usage 123 is treated separately from call routing for purposes of this 124 document, and this document does not place requirements on the 125 location provided for dispatch, although it should obviously be as 126 precise as possible. The only provision for dispatch in this 127 document is a recommendation that the location provider supply 128 endpoints with a URI that can be used by a PSAP or other emergency 129 authority to obtain a different location for use in dispatch, 130 hopefully more precise than the one used for routing. 132 This document describes the use of imprecise location information in 133 the emergency call routing system. Section 3 describes how location 134 providers can determine the precision necessary to support emergency 135 call routing, and how they can use this information to optimize 136 location delivery. Section 4 describes how emergency calls are 137 placed in such an environment, and how non-emergency services can be 138 invoked when precise location is not available to the endpoint by 139 value. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [3]. 147 We consider in this document patterns of interaction as described in 148 [6]. The two main parties of interest are endpoints and location 149 providers. Endpoints are hosts connected to the Internet that 150 originate emergency calls in the emergency calling architecture, 151 while location providers are entities that supply location 152 information that is used for emergency calling. In addition, we will 153 discuss how these parties interact with the LoST mapping 154 infrastructure [7], and with emergency and non-emergency location- 155 based service providers. 157 For convenience, we say that location information, either in LoST 158 queries or in service boundaries, is provided "in geodetic form" if 159 it is provided in the "geodetic-2d" LoST location profile, and "in 160 civic form" if it is provided in the "civic" profile. 162 3. Determining sufficient location precision 164 A location provider wishing to provide location information usable 165 for emergency call routing requires a mechanism for determining when 166 a description of location (e.g., a polygon) is precise enough to be 167 used for emergency call routing. This mechanism might be used to 168 decide when to terminate a positioning process that converges over 169 time, or to choose a polygon larger than the known location of the 170 endpoint (in order to obscure the known location of the endpoint), 171 while preserving the utility of the location for emergency call 172 routing. 174 There are three basic requirements for a location to be usable for 175 emergency call routing: 177 1. The location SHOULD be sufficiently precise that a LoST request 178 with the location and any service URN will return a unique URI 179 mapping value. This may not be possible in all cases, e.g., 180 because of overlapping service boundaries creating areas with 181 non-unique mappings, or because of positioning limitations that 182 prevent sufficiently precise positioning. 184 2. When the location of the endpoint is known by the provider to 185 greater precision than is being provided, the provided location 186 MUST return the same mappings from LoST, for all service URNs, as 187 the known location. 189 3. When the location of the endpoint is known by the provider to 190 greater precision than is being provided, the provided location 191 MUST contain the precise location (as a geographic subset). 193 These requirements lead naturally to the idea of a "location filter". 194 A location filter is a collection of geographical regions satisfying 195 the following criteria: 197 1. For any location value that is a subset of a filter region, a 198 LoST request for any service will return a unique mapping result. 200 2. Any two locations within the same filter region receive the same 201 LoST results for all services 203 Given a location filter, it is easy to determine when a given 204 location value is sufficiently precise, or to create a less precise 205 version of location that is still precise enough. Namely, a location 206 value is precise enough when if fits within a given filter region, 207 and any superset of a location value (e.g., a polygon containing a 208 point) can be used as a less precise version of the location value as 209 long as it still fits within the same filter region. 211 For example, a simple fuzzing algorithm that maintains sufficient 212 precision for emergency services is to replace a given location value 213 with the filter region that contains it. This way, the server can 214 compute the filter off-line (as described below), then provision the 215 location of each possible target by storing a pointer to the filter 216 region that contains the target's location. 218 The remainder of this section discusses the concept of location 219 filtering in more detail, and describes how a location server can 220 construct and maintain a location filter based on information from 221 the LoST mapping infrastructure. 223 3.1. Location filtering 225 With each service-to-URI mapping, a LoST query provides a service 226 boundary that represents the set of locations in which that mapping 227 is valid. A consequence of this is that given a set of service 228 boundaries for different services, the intersection of those service 229 boundaries is the region in which two mappings are valid. If one 230 service boundary corresponds to the area where "urn:service:sos.fire" 231 is served by "sip:fire@example.com" and another maps 232 "urn:service:sos.police" to "sip:police@example.com", then the 233 intersection is the are where both of these mappings are valid 234 ("urn:service:sos.fire" maps to "sip:fire@example.com" and 235 "urn:service:sos.police" maps to "sip:police@example.com"). Outside 236 that area, one or more of the mappings is invalid. So as was 237 suggested above, the intersection of two service boundaries defines a 238 set of mappings, and any two locations within that intersection are 239 equivalent for the purpose of LoST mapping (i.e., emergency call 240 routing). 242 Service boundaries for individual services 244 urn:service:sos.police urn:service:sos.fire 246 +-------+ +-------+ 247 | A | | C | 248 | +---+ | +---+---+ 249 | | | | X | | 250 +---+---+ | +---+ | 251 | B | | D | 252 +-------+ +-------+ 254 | | 255 | | 256 +-----------+------------+ 257 | 258 V 260 +-------+ 261 | A,C | 262 | +---+ 263 | | +---+ 264 +---+ |A,D| +---+ 265 +---+ | | 266 +---+ | 267 | B,D | 268 +-------+ 270 Resulting Location Filter Regions 272 Figure 1: Generating a filter from service boundaries 274 The regions in a location filter can thus be constructed by taking 275 intersections of service boundaries. Figure 1 shows a simple 276 location filter: Starting with a set of four service boundaries for 277 two different services. The filter that results from taking 278 intersections of these boundaries has three regions: 280 1. A region where police calls are directed to A and fire calls are 281 directed to C. 283 2. A region where police calls are directed to A and fire calls are 284 directed to D. 286 3. A region where police calls are directed to B and fire calls are 287 directed to D. 289 These regions satisfy the criteria for a location filter because each 290 one has a unique set of mappings and those mappings are valid across 291 the entire region. The service regions for B and C do not overlap -- 292 there is no place where police calls go to B and fire calls to C -- 293 so there is no (B,C) region. 295 More generally, a filter region is the intersection of the service 296 boundaries for all services available within the region. A filter 297 can used to determine whether a location is usable for emergency call 298 routing in the following way: 300 1. The location SHOULD be contained in exactly one of the regions in 301 the filter. This guarantees that LoST mappings are unique. 303 2. When the precise location of the endpoint is known, the provided 304 location MUST be contained in the same region(s) of the filter as 305 the known location. This guarantees that LoST queries with the 306 provided location return the same results as those done with the 307 known location. 309 3. When the precise location of the endpoint is known, the provided 310 location MUST contain the precise location (as a geographic 311 subset). 313 Filter regions can be deduced constructed from LoST mappings for a 314 sample location by intersecting all the service boundaries for 315 services available at that point. Figure 2 illustrates how the 316 filter region containing the point X is the intersection of the 317 service boundaries for police and fire services that serve X. 319 If the server also stores the lists of URN-URI mappings for each 320 region, x then the filter can also be used as a cache for LoST 321 mappings; the LoST mappings for a location are the mappings bound to 322 the region(s) containing it. 324 sos.police sos.fire sos.ambulance 326 +-------+ +---------------+ 327 | A | | B | 328 | | | | +-------+ 329 | X | | X | | X | 330 +-------+ +---------------+ | | 331 | C | 332 +-------+ 334 | | | 335 | | | 336 +-------------------+-------------------+ 337 | 338 V 340 +-------+-------+ 341 | A | B | 342 | +-------+ | 343 | | X | | | 344 +-------+-------+ 345 | C | 346 +-------+ 348 | 349 | 350 V 352 +---+ 353 | X | 354 +---+ 355 Resulting filter region 356 (police=>A, fire=>B, ambulance=>C) 358 Figure 2: Generating a filter region from a sample point 360 When the location of the endpoint is known to more precision than the 361 location provided to the endpoint, although any location meeting the 362 two criteria above is equivalent to the known location for purposes 363 of LoST, the provided location MUST contain the known location in 364 order to avoid errors if the location is used for other purposes in 365 the course of an emergency (e.g., if the location is provided to 366 first responders for dispatch). This guarantee also allows the 367 endpoint to do some course verification that the provided location is 368 correct (in order to prevent very gross errors in routing). Thus, 369 any location that (1) contains the known location and (2) is 370 contained in the same filter region as the known location is 371 allowable. Locations that also are contained in only one filter 372 region are preferred. Adding randomness to the provided locations 373 may have privacy benefits in some cases, as discussed in the security 374 considerations below. 376 3.2. Constructing location filters 378 For simplicity, we assume that the entity performing filtering will 379 only be using the filter to test locations contained within a 380 particular geographic "coverage area". In principle, this coverage 381 area could be the entire world, but assuming a more limited coverage 382 area allows for a filter to be built more quickly. 384 Given a coverage area and the ability to act as a LoST client, a 385 location service provider can autonomously compute a location filter 386 by constructing regions around sample points until it has a 387 collection of filter regions that collectively cover its service 388 region. (The process for an individual point is illustrated in 389 Figure 2.) 391 In order to ensure that all services boundaries are taken into 392 account, the server starts by issuing a 393 query, and caching the list of services that it returns, along with 394 the corresponding service list boundary [4]. The server then samples 395 points within that service list boundary, retrieving mappings with 396 service boundaries for each service in the service list and 397 intersecting the service boundaries to obtain a new filter region. 398 In pseudocode, the algorithm is as follows: 400 Set FILTER = the empty set 401 While filter does not cover LS coverage area 402 Choose a random uncovered point X in the LS coverage area 403 Perform a LoST query for X 404 Set SL = from LoST response 405 Set SLB = from LoST response 406 If SLB is not provided, choose new point X and re-query 407 If more than 100 points X have been tried 408 Set R = uncovered area 409 Add R to FILTER 410 END 411 While filter does not cover SLB 412 Choose a random uncovered point Y in SLB 413 Set R = SLB 414 For each service S in SL 415 Perform a LoST query for Y and S 416 Set SB = from LoST response 417 If SB is not provided, return an error 418 Else set R = intersection( R, SB(S,Y) ) 420 Add R to FILTER 422 If the LoST servers have been provisioned properly then this 423 algorithm will terminate successfully. If LoST mapping do not cover 424 part of the service region, then the will not 425 be returned, and the algorithm will give up after 100 queries. This 426 limit on queries introduces some risk that a small covered area will 427 be left out of the filter and marked as uncovered; if this is a 428 concern, then the query limit can be increased. 430 Of course, if the location server operator has information about 431 service boundaries through some channel other than LoST, then the 432 LoST queries above can be replaced by queries to a local store of 433 mapping information. The choice of random points can also be guided 434 to ensure that all mapped areas are covered even if there are some 435 uncovered areas. The location server can also cache service 436 boundaries acquired during the algorithm to avoid unnecessary LoST 437 queries. 439 3.2.1. Civic address considerations 441 This algorithm actually results in two filters -- one for geodetic 442 service boundaries and one for civic service boundaries -- since 443 civic and geodetic boundaries cannot be directly compared or 444 intersected. It is RECOMMENDED that location servers always compute 445 a geodetic filter for use with emergency services, since the notion 446 of civic service boundaries have some inherent ambiguity. 448 Indeed, the notion of intersection of civic service boundaries has 449 some dependence on the jurisdiction within which the service 450 boundaries are defined. Civic service boundaries are comprised of a 451 set of elements, each defining a set of civic 452 addresses that are within the boundary, namely those that match the 453 civic elements provided. 455 When computing the intersection of two civic service boundaries, any 456 elements that are shared between the two service 457 boundaries MUST be included in the resulting intersection. When two 458 elements in the service boundaries being compared are 459 different from each other, then their intersection must be computed 460 according to local addressing standards. 462 Note that the resulting filter regions SHOULD still cover the 463 location server's coverage area, i.e., there should be a filter 464 region that contains every civic address within the coverage area. 465 In particular, the server SHOULD NOT use a specific address to 466 represent a filter region: Such an address would not include many 467 points in the service region (i.e., it would not meet the third rules 468 from the lists of rules above). If the server creates a PIDF-LO 469 document describing a civic address that does not contain the precise 470 location of the target, then it MUST set the 'method' element of the 471 PIDF-LO it returns to value 'area-representative' registered in 472 Section 7. 474 3.3. Maintaining location filters 476 As the LoST mappings that underlie the filter change, the filter will 477 need to be updated. The entity maintaining the filter MUST obtain a 478 new mapping for a region when an existing mapping expires. The 479 service boundary from the new mapping is compared to the service 480 boundary from the old mapping: If they are the same, then the filter 481 need not be updated. If they differ, then regions in the filter that 482 intersect either the old service boundary or the new service boundary 483 will need to be recomputed. Note that since this operation only 484 requires the server to determine if two service boundaries are 485 identical, the server need only store a hash of the old boundary to 486 which it can compare a hash of the new boundary. 488 3.4. Applying location filters 490 After constructing a location filter, a location server can use it to 491 optimize how it delivers location. When the location server is using 492 a positioning algorithm that grows more accurate with time, the 493 filter tells it how long to run the algorithm. Namely, the algorithm 494 can be terminated when the estimated location (that is, an 495 uncertainty region containing the target's location) is within one of 496 the regions in the filter. 498 When the location provider knows the precise location of the caller, 499 a location filter can also be used as a "location cache". That is, 500 the location provider can simply look up which of the filter regions 501 contains the caller's precise location and return that region as the 502 caller's location, or some subset that contains the precise location. 504 This caching strategy allows an additional optimization in some 505 cases: If the location server knows that the caller's precise 506 location will be within the same region for a period of time, it can 507 instruct the client not to re-query in that time. For instance, if 508 the server is delivering location over HELD, then it can use the HTTP 509 cache-control headers (e.g., Expires). However, the location server 510 MUST NOT instruct the client to wait for longer than the current 511 filter is valid; the expiry time of the location MUST be before the 512 earliest expiry of a LoST mapping used in the filter. 514 4. Requesting emergency and non-emergency services 516 When a location provider wishes to deliver endpoints location 517 information that is below its maximum available precision while still 518 supporting emergency calling, it MUST provide to the endpoint both a 519 location (by value) that is sufficient for emergency call routing (as 520 defined above) and a location reference (i.e., a URI) that can 521 subsequently be used by authorized parties to obtain more precise 522 information about the location of the endpoint. The endpoint then 523 can then use both the location value and the location reference to 524 request emergency services and other location-based services (LBS). 526 4.1. Emergency calling 528 The overall procedure for placing an emergency call is identical to 529 that described in [6]. In particular, the endpoint requirements in 530 Sections 8 and 9 of [1] still apply to an endpoint that receives 531 imprecise location. 533 In addition, an endpoint that receives location both by value and by 534 reference from its location provider MUST include both the location 535 value and the location reference in the SIP INVITE message that 536 initiates an emergency call, as specified in [8]. When the endpoint 537 supports LoST, it MUST use the location value to obtain a PSAP URI 538 for LoST queries before attempting to dereference the location 539 reference. Note that the caller would also have to add the "used- 540 for-routing" parameter to the geolocation header that points to the 541 location value as inserted into the INVITE message. Note that this 542 process crucially relies on the location value having sufficient 543 precision for routing emergency calls (see Section 3 for techniques 544 to ensure the location value is suitable for emergency call routing). 546 When a PSAP receives a SIP INVITE that contains both a location value 547 and a location reference, and the value is too imprecise for use in 548 dispatch then the PSAP SHOULD dereference the LbyR to obtain more 549 precise information. In turn, the location provided by the location 550 provider MUST allow access by all PSAPs whose service boundaries 551 overlap with the region served by the location provider. This means 552 that either the provider must supply a reference that can be 553 dereferenced by any party, or else the provider must establish 554 explicit authentication and authorization relationships with all 555 PSAPs in its service area. It is RECOMMENDED that location providers 556 establish similar relationships with other PSAPs in adjoining 557 jursidictions -- even if their service regions do not overlap with 558 the location provider's -- in case such a PSAP needs access to 559 precise location information, for example, if it is acting as a 560 backup for one of the location provider's normal PSAPs. 562 4.2. Non-emergency services 564 Non-emergency LBSs may require more precise information than is 565 required for emergency call routing. Therefore, when requesting a 566 non-emergency LBS, the endpoint SHOULD include the location reference 567 provided by its location provider, and MAY additionally provide the 568 location value. If the provided location value is not sufficiently 569 precise to deliver the requested service, then the LBS provider 570 should then dereference the location value to request location 571 information of sufficient precision from the location provider. If 572 the dereference fails, then the request for service may fail as well. 574 Note that when the location reference provided by the location 575 provider is access-controled, this dereference may require a pre- 576 existing authentication and authorization agreement between the LBS 577 provider and the location provider. In such a case, the endpoint may 578 not know whether a given non-emergency service is authorized to 579 obtain the endpoint's precise location using the location reference. 580 The endpoint is always capable of requesting services without knowing 581 whether they are authorized; in this way, the endpoint can discover 582 authorized services by trial and error. In order to simplify this 583 process, a location provider may supply the endpoint with references 584 to authorized service providers, although there is currently no 585 standard protocol for this transaction. 587 5. Acknowledgements 589 This document generalizes the concept of "rough location" that was 590 originally discussed in the context of the location hiding problem. 591 This concept was put forward by Henning Schulzrinne and Andy Newton, 592 among many others, in a long-running ECRIT discussion. 594 6. Security Considerations 596 The use of imprecise location provides a security trade-off for 597 location providers. When location providers are required to provide 598 location in support of emergency services, they have to balance that 599 requirement against the risk that location information will be 600 disclosed to an unauthorized party. The use of location 601 configuration protocols inherently introduces some risk that an 602 entity other than the target will be able to masquerade as the target 603 (e.g., another host behind the same NAT or malicious software on the 604 host) [9]. In some cases, the location provider may not authorize 605 the target itself to access precise location. At the same time, 606 because endpoints can roam between networks, it is not generally 607 possible to have strong client authentication for LCPs. 609 Using of rough location to support emergency calling enables a 610 location provider to provide low-precision location with low 611 assurance (e.g., without client authentication)and high-precision 612 location with higher assurance. Because lower-precision location 613 generally has lower value -- to location providers and LBS providers 614 as a commercial asset, and to targets as private information -- this 615 trade-off allows a location provider to avoid the cost of protecting 616 location with high-assurance access controls when this location has 617 low value. 619 However, in order to support emergency services, location providers 620 cannot provide only low-precision location; they also have to provide 621 PSAPs with access to high-precision location information. Because 622 PSAPs require high-precision location for emergency response, a 623 location provider that normally provides imprecise location to 624 clients MUST also provide them a location URI that a PSAP can use to 625 obtain high-precision location. This constraint means that the 626 provided URI MUST have either no access control at all or a policy 627 that allows access by appropriate PSAPs and other emergency response 628 systems, e.g., ESRPs. That is, if such a location URI is access 629 controlled, then the location provider MUST be able to authenticate 630 requests from PSAPs. 632 The use of location by reference introduces some risk that the 633 reference will be used by an attacker to gain unauthorized access to 634 the target's location. These risks are not specific to emergency 635 service, however; general risks and mitigations for location by 636 reference are discussed in [10] 638 As described in Section 3.1 above, the location provider choosing to 639 provide a less precise location than a known location has a 640 significant amount of choice in deciding which location to provide: 641 Any location that contains the known location and is in the same 642 filter region will do. When the provider is reducing precision for 643 privacy purposes, there is a some privacy benefit to choosing a 644 random location meeting these criteria. If a watcher is interested 645 in whether or not the endpoint is moving, an imprecise location may 646 still reveal that fact if it is constant when the endpoint is at 647 rest. If the provided location is randomized each time it is 648 provided, then the watcher is unable to obtain even this level of 649 information. An algorithm for securely fuzzing a target's location 650 can be found in [11]; for emergency services, the additional 651 constraint must be added that the fuzzed location must remain in the 652 same filter region as the original. 654 7. IANA Considerations 656 This document requests that IANA register a new PIDF-LO 'method' 657 token in the registry defined by RFC 4119 [5] 659 area-representative: Location chosen as a representative of a region 660 in which the target is located; may not be the target's location. 662 8. References 664 8.1. Normative References 666 [1] Rosen, B. and J. Polk, "Best Current Practice for 667 Communications Services in support of Emergency Calling", 668 draft-ietf-ecrit-phonebcp-14 (work in progress), January 2010. 670 [2] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, 671 "LoST: A Location-to-Service Translation Protocol", RFC 5222, 672 August 2008. 674 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 675 Levels", BCP 14, RFC 2119, March 1997. 677 [4] Wolf, K., "Location-to-Service Translation Protocol (LoST) 678 Extension: ServiceListBoundary", 679 draft-ietf-ecrit-lost-servicelistboundary-01 (work in 680 progress), November 2009. 682 [5] Peterson, J., "A Presence-based GEOPRIV Location Object 683 Format", RFC 4119, December 2005. 685 8.2. Informative References 687 [6] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework 688 for Emergency Calling using Internet Multimedia", 689 draft-ietf-ecrit-framework-10 (work in progress), July 2009. 691 [7] Schulzrinne, H., "Location-to-URL Mapping Architecture and 692 Framework", draft-ietf-ecrit-mapping-arch-04 (work in 693 progress), March 2009. 695 [8] Polk, J. and B. Rosen, "Location Conveyance for the Session 696 Initiation Protocol", draft-ietf-sipcore-location-conveyance-01 697 (work in progress), July 2009. 699 [9] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location 700 Configuration Protocol; Problem Statement and Requirements", 701 draft-ietf-geopriv-l7-lcp-ps-10 (work in progress), July 2009. 703 [10] Marshall, R., "Requirements for a Location-by-Reference 704 Mechanism", draft-ietf-geopriv-lbyr-requirements-09 (work in 705 progress), November 2009. 707 [11] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and 708 J. Polk, "Geolocation Policy: A Document Format for Expressing 709 Privacy Preferences for Location Information", 710 draft-ietf-geopriv-policy-21 (work in progress), January 2010. 712 Authors' Addresses 714 Richard Barnes 715 BBN Technologies 716 9861 Broken Land Pkwy, Suite 400 717 Columbia, MD 21046 718 USA 720 Phone: +1 410 290 6169 721 Email: rbarnes@bbn.com 723 Matt Lepinski 724 BBN Technologies 725 10 Moulton St 726 Cambridge, MA 02138 727 USA 729 Phone: +1 617 873 5939 730 Email: mlepinski@bbn.com