idnits 2.17.1 draft-ietf-ecrit-rough-loc-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 364 has weird spacing: '....police urn...' -- The document date (August 16, 2010) is 4996 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-15 == Outdated reference: A later version (-05) exists of draft-ietf-ecrit-lost-servicelistboundary-04 ** 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-11 == Outdated reference: A later version (-08) exists of draft-thomson-geopriv-uncertainty-05 == Outdated reference: A later version (-02) exists of draft-thomson-ecrit-civic-boundary-01 == Outdated reference: A later version (-02) exists of draft-barnes-geopriv-policy-uri-01 == Outdated reference: A later version (-09) exists of draft-ietf-sipcore-location-conveyance-03 == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-21 Summary: 1 error (**), 0 flaws (~~), 10 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: February 17, 2011 August 16, 2010 7 Using Imprecise Location for Emergency Context Resolution 8 draft-ietf-ecrit-rough-loc-03.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 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). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on February 17, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Location Precision Requirements . . . . . . . . . . . . . . . 5 58 4. Location Filtering . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Filter Region for a Known Location . . . . . . . . . . . . 6 60 4.2. Constructing a Location Filter . . . . . . . . . . . . . . 8 61 4.3. Civic Address Considerations . . . . . . . . . . . . . . . 11 62 4.4. Maintaining Location Filters . . . . . . . . . . . . . . . 12 63 4.5. Applying Location Filters . . . . . . . . . . . . . . . . 12 64 5. Requesting Emergency and Non-emergency Services . . . . . . . 14 65 5.1. Emergency Calling . . . . . . . . . . . . . . . . . . . . 14 66 5.2. Non-emergency Services . . . . . . . . . . . . . . . . . . 15 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 75 1. Introduction 77 Information about the location of an emergency caller is a critical 78 input to the process of emergency call establshment. Endpoint 79 location is used to determine which Public Safety Answering Point 80 (PSAP) should be the destination of the call. (The entire emergency 81 calling process is described in detail in [6] and [1].) This process 82 is most likely to work properly when the endpoint is provided with 83 the most accurate and precise information available about its 84 location. Using location information with maximal precision and 85 accuracy minimizes the chance that a call will be mis-routed. 87 When location is provided to the endpoint, the endpoint is able to 88 verify that the location is correct (to the extent of the endpoint's 89 knowledge of its own location) prior to an emergency call, and is 90 able to perform emergency call routing functions on its own, 91 providing redundancy for network-provided functions. Moreover, when 92 endpoints have access to location information, they can look up PSAP 93 contact information themselves, reducing dependence on other call- 94 routing elements in the network, and increasing the overall 95 resilience of the system. 97 However, there may be situations in which it is not feasible for 98 endpoints to be provided with maximally precise and accurate 99 location. These cases may arise when computing precise location is 100 an expensive or time-consuming operation (e.g., in the case of 101 wireless triangulation), and location is needed quickly, as is often 102 the case in emergency situations. Or they may arise because the 103 policy of a location provider does not allow precise location to be 104 provided to the endpoint. While it is undesirable to use imprecise 105 location for emergency call routing, the possibility that precise 106 location may not be available to the calling device must be 107 accomodated in order to make emergency calling possible in the 108 largest possible set of circumstances. 110 To put it another way, a need for emergency calling with imprecise 111 location can arise in two ways. Either the location of the endpoint 112 is not known to the location provider with a high degree of 113 precision, or the endpoint's precise location is known and the 114 location provider chooses to provide location with lower precision. 115 In the former case, the techniques described in this document can be 116 used to determine whether a given positioning mechanism provides 117 sufficient precision to support emergency calling. In the latter 118 case, such techniques can be used to determine how much a location 119 value can be "fuzzed" before it becomes unusable for emergency 120 services. 122 This document is concerned with imprecise location only in the 123 context of routing emergency calls, i.e., for determining the correct 124 PSAP to receive a given call (e.g., via a LoST query [2]). Depending 125 on the the structure of the local emergency service network, the 126 location information provided to the endpoint may also be used to 127 route the call to an entity that is authorized to request precise 128 location, e.g., an Emergency Services Routing Proxy. The 129 requirements and processes described in this document are the same 130 for both cases. Detailed requirements are discussed in [7] 132 Location information may also be used in the emergency calling 133 framework to direct the dispatch of emergency responders. This usage 134 is treated separately from call routing for purposes of this 135 document, and this document does not place requirements on the 136 location provided for dispatch, although it should obviously be as 137 precise as possible. The only provision for dispatch in this 138 document is a recommendation that the location provider supply 139 endpoints with a URI that can be used by a PSAP or other emergency 140 authority to obtain a different location for use in dispatch, 141 hopefully more precise than the one used for routing. 143 This document describes the use of imprecise location information in 144 the emergency call routing system. Section 3 describes how location 145 providers can determine the precision necessary to support emergency 146 call routing, and how they can use this information to optimize 147 location delivery. Section 5 describes how emergency calls are 148 placed in such an environment, and how non-emergency services can be 149 invoked when precise location is not available to the endpoint by 150 value. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [3]. 158 We consider in this document patterns of interaction as described in 159 [6]. The two main parties of interest are endpoints and location 160 providers. Endpoints are hosts connected to the Internet that 161 originate emergency calls in the emergency calling architecture, 162 while location providers are entities that supply location 163 information that is used for emergency calling. In addition, we will 164 discuss how these parties interact with the LoST mapping 165 infrastructure [8], and with emergency and non-emergency location- 166 based service providers. 168 For convenience, we say that location information, either in LoST 169 queries or in service boundaries, is provided "in geodetic form" if 170 it is provided in the "geodetic-2d" LoST location profile, and "in 171 civic form" if it is provided in the "civic" profile. 173 The term "precision" is not used in a quantitative sense in this 174 document. In general, the "precision" of a location value is 175 determined by the size of its uncertainty region. [9] Higher 176 precision values have small uncertainty regions and lower precision 177 values have larger uncertainty regions. The notion of "sufficient 178 precision for emergency services is defined in Section 3 180 3. Location Precision Requirements 182 A location provider wishing to provide location information usable 183 for emergency call routing requires a mechanism for determining when 184 a description of location (e.g., a polygon) is precise enough to be 185 used for emergency call routing. This mechanism might be used to 186 decide when to terminate a positioning process that converges over 187 time, or to choose a polygon larger than the known location of the 188 endpoint (in order to obscure the known location of the endpoint), 189 while preserving the utility of the location for emergency call 190 routing. 192 There are three basic requirements for a location to be usable for 193 emergency call routing: 195 1. The location SHOULD be sufficiently precise that a LoST request 196 with the location and any emergency service URN will return a 197 unique URI mapping value. This may not be possible in all cases, 198 e.g., because of overlapping service boundaries creating areas 199 with non-unique mappings, or because of positioning limitations 200 that prevent sufficiently precise positioning. 202 2. When the location of the endpoint is known by the provider to 203 greater precision than is being provided, the provided location 204 MUST return the same mappings from LoST, for all emergency 205 service URNs, as the known location. 207 3. When the location of the endpoint is known by the provider to 208 greater precision than is being provided, the provided location 209 MUST contain the precise location (as a geographic subset). 211 4. Location Filtering 213 In effect, the first of these rules divide the world into regions 214 where each point is served by the same set of emergency services 215 (i.e., the LoST mappings are the same). We call this division of 216 space a "location filter" and the consituent regions of uniformity 217 "filter regions". The second rule says that the rough location must 218 be in the same filter region as the precise location. (The third 219 rule is unrelated to filtering.) 221 A location filter is a collection of geographical regions satisfying 222 the following criteria: 224 1. For any location value that is a subset of a filter region, a 225 LoST request for any service will return a unique mapping result. 227 2. Any two locations within the same filter region receive the same 228 LoST results for all services 230 Given a location filter, it is easy to determine when a given 231 location value is sufficiently precise, or to create a less precise 232 version of location that is still precise enough. Namely, a location 233 value is precise enough when if fits within a given filter region, 234 and any superset of a location value (e.g., a polygon containing a 235 point) can be used as a less precise version of the location value, 236 as long as it still fits within the same filter region. 238 4.1. Filter Region for a Known Location 240 A simple fuzzing algorithm that maintains sufficient precision for 241 emergency services is to replace a given location value with the 242 filter region that contains it. Given a known location, a location 243 server can compute a filter region using a series of LoST queries. 245 With each service-to-URI mapping, a LoST query provides a service 246 boundary that represents the set of locations in which that mapping 247 is valid. A consequence of this is that given a set of service 248 boundaries for different services, the intersection of those service 249 boundaries is the region in which all of the corresponding mappings 250 are valid. If one service boundary corresponds to the area where 251 "urn:service:sos.fire" is served by "sip:fire@example.com" and 252 another maps "urn:service:sos.police" to "sip:police@example.com", 253 then the intersection is the area where both of these mappings are 254 valid ("urn:service:sos.fire" maps to "sip:fire@example.com" and 255 "urn:service:sos.police" maps to "sip:police@example.com"). Outside 256 that area, one or more of the mappings is invalid. So as was 257 suggested above, the intersection of two service boundaries defines a 258 set of mappings, and any two locations within that intersection are 259 equivalent for the purpose of LoST mapping (i.e., emergency call 260 routing). 262 Filter regions can be deduced constructed from LoST mappings for a 263 sample location by intersecting all the service boundaries for 264 services available at that point. Figure 1 illustrates how the 265 filter region containing the point X is the intersection of the 266 service boundaries for police and fire services that serve X. 268 sos.police sos.fire sos.ambulance 270 +-------+ +---------------+ 271 | A | | B | 272 | | | | +-------+ 273 | X | | X | | X | 274 +-------+ +---------------+ | | 275 | C | 276 +-------+ 278 | | | 279 | | | 280 +-------------------+-------------------+ 281 | 282 V 284 +-------+-------+ 285 | A | B | 286 | +-------+ | 287 | | X | | | 288 +-------+-------+ 289 | C | 290 +-------+ 292 | 293 | 294 V 296 +---+ 297 | X | 298 +---+ 299 Resulting filter region 300 (police=>A, fire=>B, ambulance=>C) 302 Figure 1: Generating a Filter Region from a Sample Point 304 In pseudocode form, algorithm for constructing a filter region from a 305 point is as follows: 307 function filterRegion(X): 308 Set REGION = the world 309 Perform a LoST query for X 310 Set SL = from LoST 311 If SL == NULL or LoST returned an error 312 Return the empty set 313 For each service URN S in SL 314 Perform a LoST query for Y and S 315 If LoST returned an error 316 Continue 317 Set SB = from LoST 318 If SB is not provided, throw an error 319 Else set REGION = intersection( REGION, SB ) 320 If has a 321 Set SLB = 322 from LoST 323 Set REGION = intersection( REGION, SLB ) 324 Return REGION 326 The final intersection with the serviceListBoundary is necessary 327 because if some parts of the region receive a different set of 328 services, they have different LoST routing properties, and thus need 329 to be excluded from the filter region. [4] 331 It is important that the filter take into account all emergency 332 services available in over the coverage area of the LIS. (That is, 333 the services listed in the LoST serviceList elements.) The feature 334 is necessary in order to ensure that calls to all available emergency 335 services can be routed correctly using rough location values provided 336 by the filter. 338 While in principle, a location server could execute this algorithm to 339 compute a fresh filter region on each query, it is much more 340 efficient to use the offline algorithm for computing an entire 341 location filter, described in the next section. 343 4.2. Constructing a Location Filter 345 When a location server knows ahead of time that it will be providing 346 rough location values, it can pre-compute a location filter that 347 contains all the filter regions for locations it's concerned with. 348 Once the filter has been computed (as an off-line computation), the 349 filter region for a given precise location can be found by searching 350 for the pre-computed region that contains the precise location. When 351 precise location is not known, a complete filter can be used to test 352 evaluate the utility of an imprecise location by determining the 353 degree to which it overlaps with each filter region. 355 For example, a simple fuzzing algorithm that maintains sufficient 356 precision for emergency services is to replace a given location value 357 with the filter region that contains it. This way, the server can 358 compute the filter off-line (as described below), then provision the 359 location of each possible device by storing a pointer to the filter 360 region that contains the device's location. 362 Service boundaries for individual services 364 urn:service:sos.police urn:service:sos.fire 366 +-------+ +-------+ 367 | A | | C | 368 | +---+ | +---+---+ 369 | | | | | | 370 +---+---+ | +---+ | 371 | B | | D | 372 +-------+ +-------+ 374 | | 375 | | 376 +-----------+------------+ 377 | 378 V 380 +-------+ 381 | A,C | 382 | +---+ 383 | | +---+ 384 +---+ |A,D| +---+ 385 +---+ | | 386 +---+ | 387 | B,D | 388 +-------+ 390 Resulting Location Filter Regions 392 Figure 2: Generating a Filter from Service Boundaries 394 The filter regions in a filter can are constructed by taking 395 intersections of service boundaries. Figure 2 shows a simple 396 location filter: Starting with a set of four service boundaries for 397 two different services. The filter that results from taking 398 intersections of these boundaries has three regions: 400 1. A region where police calls are directed to A and fire calls are 401 directed to C. 403 2. A region where police calls are directed to A and fire calls are 404 directed to D. 406 3. A region where police calls are directed to B and fire calls are 407 directed to D. 409 These regions satisfy the criteria for a location filter because each 410 one has a unique set of mappings and those mappings are valid across 411 the entire region. The service regions for B and C do not overlap -- 412 there is no place where police calls go to B and fire calls to C -- 413 so there is no (B,C) region. 415 More generally, a filter region is the intersection of the service 416 boundaries for all services available within the region. A filter 417 can be used to determine whether a location is usable for emergency 418 call routing in the following way: 420 1. The location SHOULD be contained in exactly one of the regions in 421 the filter. This guarantees that LoST mappings are unique. 423 2. When the precise location of the endpoint is known, the provided 424 location MUST be contained in the same region(s) of the filter as 425 the known location. This guarantees that LoST queries with the 426 provided location return the same results as those done with the 427 known location. 429 3. When the precise location of the endpoint is known, the provided 430 location MUST contain the precise location (as a geographic 431 subset). 433 Practically speaking, a location filter is built up by computing 434 filter regions for sample points, using the algorithm described 435 above. In the example of Figure 2, one would need to sample three 436 points: One in the (A,C) region, one in the (A,D) region and one in 437 the (B,D) region. The overall algorithm thus samples random points 438 until the computed filter regions cover the desired area. (For 439 simplicity, we assume that the entity performing filtering will only 440 be using the filter to test locations contained within a particular 441 geographic "coverage area". In principle, this coverage area could 442 be the entire world, but assuming a more limited coverage area allows 443 for a filter to be built more quickly) 444 function filter(LS_AREA): 445 Set FILTER = the empty set 446 Set COVERAGE = the empty set 447 Set ERR_COUNT = 0 448 While COVERAGE < LS_AREA && ERR_COUNT < 100 449 Choose a random uncovered point X in LS_AREA 450 Compute R = filterRegion(X) 451 If R != the empty set 452 Add R to FILTER 453 Set COVERAGE = union(COVERAGE, R) 454 Else 455 ERR_COUNT += 1 456 Return FILTER 458 If the server also stores the lists of URN-URI mappings for each 459 region, then the filter can also be used as a cache for LoST 460 mappings; the LoST mappings for a location are the mappings bound to 461 the region(s) containing it. 463 If the LoST servers have been provisioned properly then this 464 algorithm will terminate successfully. If LoST mappings do not cover 465 a point X, then the filterRegion(X) will return the empty set, and 466 the algorithm will give up after 100 such queries. This limit on 467 queries introduces some risk that a small covered area will be left 468 out of the filter and marked as uncovered; if this is a concern, then 469 the query limit can be increased, or the algorithm can be explicitly 470 directed to sample certain specific points. 472 Of course, if the location server operator has information about 473 service boundaries through some channel other than LoST, then the 474 LoST queries above can be replaced by queries to a local store of 475 mapping information. The choice of random points can also be guided 476 to ensure that all mapped areas are covered even if there are some 477 uncovered areas. The location server can also cache service 478 boundaries acquired during the algorithm to avoid unnecessary LoST 479 queries. 481 4.3. Civic Address Considerations 483 This algorithm actually results in two filters -- one for geodetic 484 service boundaries and one for civic service boundaries -- since 485 civic and geodetic boundaries cannot be directly compared or 486 intersected. It is RECOMMENDED that location servers always compute 487 a geodetic filter for use with emergency services, since the notion 488 of civic service boundaries have some inherent ambiguity. 489 Considerations around civic service boundaries are discussed in 490 detail in [10] 491 Indeed, the notion of intersection of civic service boundaries has 492 some dependence on the jurisdiction within which the service 493 boundaries are defined. Civic service boundaries are comprised of a 494 set of elements, each defining a set of civic 495 addresses that are within the boundary, namely those that match the 496 civic elements provided. 498 When computing the intersection of two civic service boundaries, any 499 elements that are shared between the two service 500 boundaries MUST be included in the resulting intersection. When two 501 elements in the service boundaries being compared are 502 different from each other, then their intersection must be computed 503 according to local addressing standards. 505 Note that the resulting filter regions SHOULD still cover the 506 location server's coverage area, i.e., there should be a filter 507 region that contains every civic address within the coverage area. 508 In particular, the server SHOULD NOT use a specific address to 509 represent a filter region: Such an address would not include many 510 points in the service region (i.e., it would not meet the third rules 511 from the lists of rules above). If the server creates a PIDF-LO 512 document describing a civic address that does not contain the precise 513 location of the device, then it MUST set the 'method' element of the 514 PIDF-LO it returns to value 'area-representative' registered in 515 Section 8. 517 4.4. Maintaining Location Filters 519 As the LoST mappings that underlie the filter change, the filter will 520 need to be updated. The entity maintaining the filter MUST obtain a 521 new mapping for a region when an existing mapping expires. The 522 service boundary from the new mapping is compared to the service 523 boundary from the old mapping: If they are the same, then the filter 524 need not be updated. If they differ, then regions in the filter that 525 intersect either the old service boundary or the new service boundary 526 will need to be recomputed. Note that since this operation only 527 requires the server to determine if two service boundaries are 528 identical, the server need only store a hash of the old boundary to 529 which it can compare a hash of the new boundary. 531 4.5. Applying Location Filters 533 After constructing a location filter, a location server can use it to 534 optimize how it delivers location. How this is done depends on 535 whether the location server is trying to reduce the precision of a 536 known precise location, or trying to determine whether an imprecise 537 position is good enough for emergency services. 539 When the location provider knows the precise location of the caller, 540 a location filter can also be used as a "location cache". That is, 541 the location provider can simply look up which of the filter regions 542 contains the caller's precise location and return that region as the 543 caller's location, or some subset that contains the precise location. 545 This caching strategy allows an additional optimization in some 546 cases: If the location server knows that the caller's precise 547 location will be within the same region for a period of time, it can 548 instruct the client not to re-query in that time. For instance, if 549 the server is delivering location over HELD, then it can use the HTTP 550 cache-control headers (e.g., Expires). However, the location server 551 MUST NOT instruct the client to wait for longer than the current 552 filter is valid; the expiry time of the location MUST be before the 553 earliest expiry of a LoST mapping used in the filter. 555 When the location server starts with imprecise location, there are 556 different ways to apply the filter, depending on the positioning 557 technique being used. For example with a positioning algorithm that 558 grows more accurate with time, the filter can tell the server how 559 long to run the algorithm -- the algorithm can be terminated when the 560 estimated location (that is, an uncertainty region containing the 561 device's location) is within one of the regions in the filter. 563 A location filter can also be used to test whether a database of 564 rough locations for IP addresses (as is commonly used for web 565 localization today) contains precise enough values for use with 566 emergency services. To make this determination, each value in the 567 database woud be tested to see if it falls mostly or entirely within 568 a given filter region. Note, however, that this test does not 569 address concerns about the accuracy of location information, i.e., 570 the probability that the caller is actually contained within the 571 specified uncertainty region. 573 Note that the requirements for containment in a filter region differ 574 between these two use cases. When precise location is known, the 575 rough location that is returned MUST be contained within a single 576 filter region; otherwise, there will be an increased risk of mis- 577 routing. When the location server starts with imprecise location, it 578 may choose location values that are not entirely within one filter 579 region. The distribution of the imprecise location value among 580 filter regions corresponds to the risk that LoST routing will provide 581 incorrect information, so the choice of location value should balance 582 the risk of incorrect routing against the additional time needed to 583 obtain more precise location (which can translate to a delay in call 584 setup). Actually, in this case, it may not even be possible for a 585 location server to return a location value that is entirely within a 586 single filter region. 588 5. Requesting Emergency and Non-emergency Services 590 When a location provider wishes to deliver endpoints location 591 information that is below its maximum available precision while still 592 supporting emergency calling, it MUST provide to the endpoint both a 593 location (by value) that is sufficient for emergency call routing (as 594 defined above) and a location reference (i.e., a URI) that can 595 subsequently be used by authorized parties to obtain more precise 596 information about the location of the endpoint. The endpoint then 597 can then use both the location value and the location reference to 598 request emergency services and other location-based services (LBS). 600 This arrangement allows the client to provide rough location (by 601 value) to any entity, and to provide precise location (by reference) 602 to authorized parties. An assumption of this model, of course, is 603 that emergency authorities are authorized by the location provider to 604 receive precise location. Location providers may also authorize 605 other entities to receive precise location information (e.g., 606 commercial services that have agreed to pay for location). 607 Authorization policy for location URIs is set by the referenced 608 location server; a mechanism for clients to request information about 609 this policy is described in [11]. 611 5.1. Emergency Calling 613 The overall procedure for placing an emergency call is identical to 614 that described in [6]. In particular, the endpoint requirements in 615 Sections 8 and 9 of [1] still apply to an endpoint that receives 616 imprecise location. 618 In addition, an endpoint that receives location both by value and by 619 reference from its location provider MUST include both the location 620 value and the location reference in the SIP INVITE message that 621 initiates an emergency call, as specified in [12]. When the endpoint 622 supports LoST, it MUST use the location value to obtain a PSAP URI 623 for LoST queries before attempting to dereference the location 624 reference. Note that the caller would also have to add the "used- 625 for-routing" parameter to the geolocation header that points to the 626 location value as inserted into the INVITE message. Note that this 627 process crucially relies on the location value having sufficient 628 precision for routing emergency calls (see Section 3 for techniques 629 to ensure the location value is suitable for emergency call routing). 631 When a PSAP receives a SIP INVITE that contains both a location value 632 and a location reference, and the value is too imprecise for use in 633 dispatch then the PSAP SHOULD dereference the LbyR to obtain more 634 precise information. In turn, the location provided by the location 635 provider MUST allow access by all PSAPs whose service boundaries 636 overlap with the region served by the location provider. This means 637 that either the provider must supply a reference that can be 638 dereferenced by any party, or else the provider must establish 639 explicit authentication and authorization relationships with all 640 PSAPs in its service area. It is RECOMMENDED that location providers 641 establish similar relationships with other PSAPs in adjoining 642 jursidictions -- even if their service regions do not overlap with 643 the location provider's -- in case such a PSAP needs access to 644 precise location information, for example, if it is acting as a 645 backup for one of the location provider's normal PSAPs. 647 5.2. Non-emergency Services 649 Non-emergency LBSs may require more precise information than is 650 required for emergency call routing. Therefore, when requesting a 651 non-emergency LBS, the endpoint SHOULD include the location reference 652 provided by its location provider, and MAY additionally provide the 653 location value. If the provided location value is not sufficiently 654 precise to deliver the requested service, then the LBS provider 655 should then dereference the location value to request location 656 information of sufficient precision from the location provider. If 657 the dereference fails, then the request for service may fail as well. 659 Note that when the location reference provided by the location 660 provider is access-controled, this dereference may require a pre- 661 existing authentication and authorization agreement between the LBS 662 provider and the location provider. In such a case, the endpoint may 663 not know whether a given non-emergency service is authorized to 664 obtain the endpoint's precise location using the location reference. 665 The endpoint is always capable of requesting services without knowing 666 whether they are authorized; in this way, the endpoint can discover 667 authorized services by trial and error. In order to simplify this 668 process, a location provider may supply the endpoint with references 669 to authorized service providers, although there is currently no 670 standard protocol for this transaction. 672 6. Acknowledgements 674 This document generalizes the concept of "rough location" that was 675 originally discussed in the context of the location hiding problem. 676 This concept was put forward by Henning Schulzrinne and Andy Newton, 677 among many others, in a long-running ECRIT discussion. Thanks to 678 Hannes Tschofenig and Martin Thomson for detailed reviews of this 679 document. 681 7. Security Considerations 683 The use of imprecise location provides a security trade-off for 684 location providers. When location providers are required to provide 685 location in support of emergency services, they have to balance that 686 requirement against the risk that location information will be 687 disclosed to an unauthorized party. The use of location 688 configuration protocols inherently introduces some risk that an 689 entity other than the device will be able to masquerade as the device 690 (e.g., another host behind the same NAT or malicious software on the 691 host) [13]. In some cases, the location provider may not authorize 692 the device itself to access precise location. At the same time, 693 because endpoints can roam between networks, it is operationally 694 difficult to have strong client authentication for LCPs. 696 Using of rough location to support emergency calling enables a 697 location provider to provide low-precision location with low 698 assurance (e.g., without client authentication)and high-precision 699 location with higher assurance. Because lower-precision location 700 generally has lower value -- to location providers and LBS providers 701 as a commercial asset, and to devices as private information -- this 702 trade-off allows a location provider to avoid the cost of protecting 703 location with high-assurance access controls when this location has 704 low value. 706 However, in order to support emergency services, location providers 707 cannot provide only low-precision location; they also have to provide 708 PSAPs with access to high-precision location information. Because 709 PSAPs require high-precision location for emergency response, a 710 location provider that normally provides imprecise location to 711 clients MUST also provide them a location URI that a PSAP can use to 712 obtain high-precision location. This constraint means that the 713 provided URI MUST have either no access control at all or a policy 714 that allows access by appropriate PSAPs and other emergency response 715 systems, e.g., ESRPs. That is, if such a location URI is access 716 controlled, then the location provider MUST be able to authenticate 717 requests from PSAPs. 719 The use of location by reference introduces some risk that the 720 reference will be used by an attacker to gain unauthorized access to 721 the device's location. These risks are not specific to emergency 722 service, however; general risks and mitigations for location by 723 reference are discussed in [14] 725 As described in Section 4 above, the location provider choosing to 726 provide a less precise location than a known location has a 727 significant amount of choice in deciding which location to provide: 728 Any location that contains the known location and is in the same 729 filter region will do. When the provider is reducing precision for 730 privacy purposes, there is a some privacy benefit to choosing a 731 random location meeting these criteria. If a watcher is interested 732 in whether or not the endpoint is moving, an imprecise location may 733 still reveal that fact if it is constant when the endpoint is at 734 rest. If the provided location is randomized each time it is 735 provided, then the watcher is unable to obtain even this level of 736 information. An algorithm for securely fuzzing a device's location 737 can be found in [15]; for emergency services, the additional 738 constraint must be added that the fuzzed location must remain in the 739 same filter region as the original. 741 8. IANA Considerations 743 This document requests that IANA register a new PIDF-LO 'method' 744 token in the registry defined by RFC 4119 [5] 746 area-representative: Location chosen as a representative of a region 747 in which the device is located; may not be the device's location. 749 9. References 751 9.1. Normative References 753 [1] Rosen, B. and J. Polk, "Best Current Practice for 754 Communications Services in support of Emergency Calling", 755 draft-ietf-ecrit-phonebcp-15 (work in progress), July 2010. 757 [2] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, 758 "LoST: A Location-to-Service Translation Protocol", RFC 5222, 759 August 2008. 761 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 762 Levels", BCP 14, RFC 2119, March 1997. 764 [4] Wolf, K., "LoST Service List Boundary Extension", 765 draft-ietf-ecrit-lost-servicelistboundary-04 (work in 766 progress), August 2010. 768 [5] Peterson, J., "A Presence-based GEOPRIV Location Object 769 Format", RFC 4119, December 2005. 771 9.2. Informative References 773 [6] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework 774 for Emergency Calling using Internet Multimedia", 775 draft-ietf-ecrit-framework-11 (work in progress), July 2010. 777 [7] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. 778 Kuett, "Location Hiding: Problem Statement and Requirements", 779 draft-ietf-ecrit-location-hiding-req-04 (work in progress), 780 February 2010. 782 [8] Schulzrinne, H., "Location-to-URL Mapping Architecture and 783 Framework", RFC 5582, September 2009. 785 [9] Thomson, M. and J. Winterbottom, "Representation of Uncertainty 786 and Confidence in PIDF-LO", 787 draft-thomson-geopriv-uncertainty-05 (work in progress), 788 May 2010. 790 [10] Thomson, M. and K. Wolf, "Describing Boundaries for Civic 791 Addresses", draft-thomson-ecrit-civic-boundary-01 (work in 792 progress), July 2010. 794 [11] Barnes, R., Thomson, M., and J. Winterbottom, "Location 795 Configuration Extensions for Policy Management", 796 draft-barnes-geopriv-policy-uri-01 (work in progress), 797 May 2010. 799 [12] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for 800 the Session Initiation Protocol", 801 draft-ietf-sipcore-location-conveyance-03 (work in progress), 802 July 2010. 804 [13] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location 805 Configuration Protocol: Problem Statement and Requirements", 806 RFC 5687, March 2010. 808 [14] Marshall, R., "Requirements for a Location-by-Reference 809 Mechanism", RFC 5808, May 2010. 811 [15] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and 812 J. Polk, "Geolocation Policy: A Document Format for Expressing 813 Privacy Preferences for Location Information", 814 draft-ietf-geopriv-policy-21 (work in progress), January 2010. 816 Authors' Addresses 818 Richard Barnes 819 BBN Technologies 820 9861 Broken Land Pkwy, Suite 400 821 Columbia, MD 21046 822 USA 824 Phone: +1 410 290 6169 825 Email: rbarnes@bbn.com 827 Matt Lepinski 828 BBN Technologies 829 10 Moulton St 830 Cambridge, MA 02138 831 USA 833 Phone: +1 617 873 5939 834 Email: mlepinski@bbn.com