idnits 2.17.1 draft-ietf-ecrit-rough-loc-05.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 350 has weird spacing: '....police urn...' -- The document date (July 16, 2012) is 4300 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) == Unused Reference: '14' is defined on line 826, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-thomson-geopriv-uncertainty-07 == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-26 Summary: 0 errors (**), 0 flaws (~~), 5 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: January 17, 2013 July 16, 2012 7 Using Imprecise Location for Emergency Context Resolution 8 draft-ietf-ecrit-rough-loc-05.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 describe 18 additional rules for networks and endpoints to enable emergency 19 calling by endpoints that do not have access to 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 January 17, 2013. 38 Copyright Notice 40 Copyright (c) 2012 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. Privileged LoST Servers . . . . . . . . . . . . . . . . . 12 63 4.5. Maintaining Location Filters . . . . . . . . . . . . . . . 13 64 4.6. Applying Location Filters . . . . . . . . . . . . . . . . 13 65 5. Additional Requirements for Networks and Endpoints . . . . . . 14 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 74 1. Introduction 76 Information about the location of an emergency caller is a critical 77 input to the process of emergency call establshment. Endpoint 78 location is used to determine which Public Safety Answering Point 79 (PSAP) should be the destination of the call. (The entire emergency 80 calling process is described in detail in [5] and [1].) This process 81 is most likely to work properly when the endpoint is provided with 82 the most accurate and precise information available about its 83 location. Using location information with maximal precision and 84 accuracy minimizes the chance that a call will be mis-routed. 86 When location is provided to the endpoint, the endpoint is able to 87 verify that the location is correct (to the extent of the endpoint's 88 knowledge of its own location) prior to an emergency call, and is 89 able to perform emergency call routing functions on its own, 90 providing redundancy for network-provided functions. Moreover, when 91 endpoints have access to location information, they can look up PSAP 92 contact information themselves, reducing dependence on other call- 93 routing elements in the network, and increasing the overall 94 resilience of the system. 96 However, there may be situations in which it is not feasible for 97 endpoints to be provided with maximally precise and accurate 98 location. These cases may arise when computing precise location is 99 an expensive or time-consuming operation (e.g., in the case of 100 wireless triangulation), and location is needed quickly, as is often 101 the case in emergency situations. Or they may arise because the 102 policy of a location provider does not allow precise location to be 103 provided to the endpoint. While it is undesirable to use imprecise 104 location for emergency call routing, the possibility that precise 105 location may not be available to the calling device must be 106 accomodated in order to make emergency calling possible in the 107 largest possible set of circumstances. 109 To put it another way, a need for emergency calling with imprecise 110 location can arise in two ways. Either the location of the endpoint 111 is not known to the location provider with a high degree of 112 precision, or the endpoint's precise location is known and the 113 location provider chooses to provide location with lower precision. 114 In the former case, the techniques described in this document can be 115 used to determine whether a given positioning mechanism provides 116 sufficient precision to support emergency calling. In the latter 117 case, such techniques can be used to determine how much a location 118 value can be "fuzzed" before it becomes unusable for emergency 119 services. 121 This document is concerned with imprecise location only in the 122 context of routing emergency calls, i.e., for determining the correct 123 PSAP to receive a given call (e.g., via a LoST query [2]). Depending 124 on the the structure of the local emergency service network, the 125 location information provided to the endpoint may also be used to 126 route the call to an entity that is authorized to request precise 127 location, e.g., an Emergency Services Routing Proxy. The 128 requirements and processes described in this document are the same 129 for both cases. Detailed requirements are discussed in [6] 131 Location information may also be used in the emergency calling 132 framework to direct the dispatch of emergency responders. This usage 133 is treated separately from call routing for purposes of this 134 document, and this document does not place requirements on the 135 location provided for dispatch, although it should obviously be as 136 precise as possible. The only provision for dispatch in this 137 document is a recommendation that the location provider supply 138 endpoints with a URI that can be used by a PSAP or other emergency 139 authority to obtain a different location for use in dispatch, 140 hopefully more precise than the one used for routing. 142 This document describes the use of imprecise location information in 143 the emergency call routing system. Section 3 describes how location 144 providers can determine the precision necessary to support emergency 145 call routing, and how they can use this information to optimize 146 location delivery. Section 5 describes how emergency calls are 147 placed in such an environment, and how non-emergency services can be 148 invoked when precise location is not available to the endpoint by 149 value. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [3]. 157 We consider in this document patterns of interaction as described in 158 [5]. The two main parties of interest are endpoints and location 159 providers. Endpoints are hosts connected to the Internet that 160 originate emergency calls in the emergency calling architecture, 161 while location providers are entities that supply location 162 information that is used for emergency calling. In addition, we will 163 discuss how these parties interact with the LoST mapping 164 infrastructure [7], and with emergency and non-emergency location- 165 based service providers. 167 For convenience, we say that location information, either in LoST 168 queries or in service boundaries, is provided "in geodetic form" if 169 it is provided in the "geodetic-2d" LoST location profile, and "in 170 civic form" if it is provided in the "civic" profile. 172 The term "precision" is not used in a quantitative sense in this 173 document. In general, the "precision" of a location value is 174 determined by the size of its uncertainty region. [8] Higher 175 precision values have small uncertainty regions and lower precision 176 values have larger uncertainty regions. The notion of "sufficient 177 precision for emergency services is defined in Section 3 179 3. Location Precision Requirements 181 A location provider wishing to provide location information usable 182 for emergency call routing requires a mechanism for determining when 183 a description of location (e.g., a polygon) is precise enough to be 184 used for emergency call routing. This mechanism might be used to 185 decide when to terminate a positioning process that converges over 186 time, or to choose a polygon larger than the known location of the 187 endpoint (in order to obscure the known location of the endpoint), 188 while preserving the utility of the location for emergency call 189 routing. 191 There are three basic requirements for a location to be usable for 192 emergency call routing: 194 1. The location SHOULD be sufficiently precise that a LoST request 195 with the location and any emergency service URN will return a 196 unique URI mapping value. This may not be possible in all cases, 197 e.g., because of overlapping service boundaries creating areas 198 with non-unique mappings, or because of positioning limitations 199 that prevent sufficiently precise positioning. 201 2. When the location of the endpoint is known by the provider to 202 greater precision than is being provided, the provided location 203 MUST return the same mappings from LoST, for all emergency 204 service URNs, as the known location. 206 3. When the location of the endpoint is known by the provider to 207 greater precision than is being provided, the provided location 208 MUST contain the precise location (as a geographic subset). 210 4. Location Filtering 212 In effect, the first of these rules divide the world into regions 213 where each point is served by the same set of emergency services 214 (i.e., the LoST mappings are the same). We call this division of 215 space a "location filter" and the consituent regions of uniformity 216 "filter regions". The second rule says that the rough location must 217 be in the same filter region as the precise location. (The third 218 rule is unrelated to filtering.) 220 A location filter is a collection of geographical regions satisfying 221 the following criteria: 223 1. For any location value that is a subset of a filter region, a 224 LoST request for any service will return a unique mapping result. 226 2. Any two locations within the same filter region receive the same 227 LoST results for all services 229 Given a location filter, it is easy to determine when a given 230 location value is sufficiently precise, or to create a less precise 231 version of location that is still precise enough. Namely, a location 232 value is precise enough when if fits within a given filter region, 233 and any superset of a location value (e.g., a polygon containing a 234 point) can be used as a less precise version of the location value, 235 as long as it still fits within the same filter region. 237 4.1. Filter Region for a Known Location 239 A simple fuzzing algorithm that maintains sufficient precision for 240 emergency services is to replace a given location value with the 241 filter region that contains it. Given a known location, a location 242 server can compute a filter region using a series of LoST queries. 244 With each service-to-URI mapping, a LoST query provides a service 245 boundary that represents the set of locations in which that mapping 246 is valid. A consequence of this is that given a set of service 247 boundaries for different services, the intersection of those service 248 boundaries is the region in which all of the corresponding mappings 249 are valid. If one service boundary corresponds to the area where 250 "urn:service:sos.fire" is served by "sip:fire@example.com" and 251 another maps "urn:service:sos.police" to "sip:police@example.com", 252 then the intersection is the area where both of these mappings are 253 valid ("urn:service:sos.fire" maps to "sip:fire@example.com" and 254 "urn:service:sos.police" maps to "sip:police@example.com"). Outside 255 that area, one or more of the mappings is invalid. So as was 256 suggested above, the intersection of two service boundaries defines a 257 set of mappings, and any two locations within that intersection are 258 equivalent for the purpose of LoST mapping (i.e., emergency call 259 routing). 261 Filter regions can be deduced constructed from LoST mappings for a 262 sample location by intersecting all the service boundaries for 263 services available at that point. Figure 1 illustrates how the 264 filter region containing the point X is the intersection of the 265 service boundaries for police and fire services that serve X. 267 sos.police sos.fire sos.ambulance 269 +-------+ +---------------+ 270 | A | | B | 271 | | | | +-------+ 272 | X | | X | | X | 273 +-------+ +---------------+ | | 274 | C | 275 +-------+ 277 | | | 278 | | | 279 +-------------------+-------------------+ 280 | 281 V 283 +-------+-------+ 284 | A | B | 285 | +-------+ | 286 | | X | | | 287 +-------+-------+ 288 | C | 289 +-------+ 291 | 292 | 293 V 295 +---+ 296 | X | 297 +---+ 298 Resulting filter region 299 (police=>A, fire=>B, ambulance=>C) 301 Figure 1: Generating a Filter Region from a Sample Point 303 In pseudocode form, algorithm for constructing a filter region from a 304 point is as follows: 306 function filterRegion(X): 307 Set REGION = the world 308 For each service URN S in the urn:service:sos namespace 309 Perform a LoST query for Y and S 310 If LoST returned an error 311 Continue 312 Set SB = from LoST 313 If SB is not provided, throw an error 314 Else set REGION = intersection( REGION, SB ) 315 Return REGION 317 It is important that the filter take into account all emergency 318 services available in over the coverage area of the LIS. (That is, 319 the services listed in the LoST serviceList elements.) The feature 320 is necessary in order to ensure that calls to all available emergency 321 services can be routed correctly using rough location values provided 322 by the filter. 324 While in principle, a location server could execute this algorithm to 325 compute a fresh filter region on each query, it is much more 326 efficient to use the offline algorithm for computing an entire 327 location filter, described in the next section. 329 4.2. Constructing a Location Filter 331 When a location server knows ahead of time that it will be providing 332 rough location values, it can pre-compute a location filter that 333 contains all the filter regions for locations it's concerned with. 334 Once the filter has been computed (as an off-line computation), the 335 filter region for a given precise location can be found by searching 336 for the pre-computed region that contains the precise location. When 337 precise location is not known, a complete filter can be used to test 338 evaluate the utility of an imprecise location by determining the 339 degree to which it overlaps with each filter region. 341 For example, a simple fuzzing algorithm that maintains sufficient 342 precision for emergency services is to replace a given location value 343 with the filter region that contains it. This way, the server can 344 compute the filter off-line (as described below), then provision the 345 location of each possible device by storing a pointer to the filter 346 region that contains the device's location. 348 Service boundaries for individual services 350 urn:service:sos.police urn:service:sos.fire 352 +-------+ +-------+ 353 | A | | C | 354 | +---+ | +---+---+ 355 | | | | | | 356 +---+---+ | +---+ | 357 | B | | D | 358 +-------+ +-------+ 360 | | 361 | | 362 +-----------+------------+ 363 | 364 V 366 +-------+ 367 | A,C | 368 | +---+ 369 | | +---+ 370 +---+ |A,D| +---+ 371 +---+ | | 372 +---+ | 373 | B,D | 374 +-------+ 376 Resulting Location Filter Regions 378 Figure 2: Generating a Filter from Service Boundaries 380 The filter regions in a filter can are constructed by taking 381 intersections of service boundaries. Figure 2 shows a simple 382 location filter: Starting with a set of four service boundaries for 383 two different services. The filter that results from taking 384 intersections of these boundaries has three regions: 386 1. A region where police calls are directed to A and fire calls are 387 directed to C. 389 2. A region where police calls are directed to A and fire calls are 390 directed to D. 392 3. A region where police calls are directed to B and fire calls are 393 directed to D. 395 These regions satisfy the criteria for a location filter because each 396 one has a unique set of mappings and those mappings are valid across 397 the entire region. The service regions for B and C do not overlap -- 398 there is no place where police calls go to B and fire calls to C -- 399 so there is no (B,C) region. 401 More generally, a filter region is the intersection of the service 402 boundaries for all services available within the region. A filter 403 can be used to determine whether a location is usable for emergency 404 call routing in the following way: 406 1. The location SHOULD be contained in exactly one of the regions in 407 the filter. This guarantees that LoST mappings are unique. 409 2. When the precise location of the endpoint is known, the provided 410 location MUST be contained in the same region(s) of the filter as 411 the known location. This guarantees that LoST queries with the 412 provided location return the same results as those done with the 413 known location. 415 3. When the precise location of the endpoint is known, the provided 416 location MUST contain the precise location (as a geographic 417 subset). 419 Practically speaking, a location filter is built up by computing 420 filter regions for sample points, using the algorithm described 421 above. In the example of Figure 2, one would need to sample three 422 points: One in the (A,C) region, one in the (A,D) region and one in 423 the (B,D) region. The overall algorithm thus samples random points 424 until the computed filter regions cover the desired area. (For 425 simplicity, we assume that the entity performing filtering will only 426 be using the filter to test locations contained within a particular 427 geographic "coverage area". In principle, this coverage area could 428 be the entire world, but assuming a more limited coverage area allows 429 for a filter to be built more quickly) 431 function filter(LS_AREA): 432 Set FILTER = the empty set 433 Set COVERAGE = the empty set 434 Set ERR_COUNT = 0 435 While COVERAGE < LS_AREA && ERR_COUNT < 100 436 Choose a random uncovered point X in LS_AREA 437 Compute R = filterRegion(X) 438 If R != the empty set 439 Add R to FILTER 440 Set COVERAGE = union(COVERAGE, R) 441 Else 442 ERR_COUNT += 1 444 Return FILTER 446 If the server also stores the lists of URN-URI mappings for each 447 region, then the filter can also be used as a cache for LoST 448 mappings; the LoST mappings for a location are the mappings bound to 449 the region(s) containing it. 451 If the LoST servers have been provisioned properly then this 452 algorithm will terminate successfully. If LoST mappings do not cover 453 a point X, then the filterRegion(X) will return the empty set, and 454 the algorithm will give up after 100 such queries. This limit on 455 queries introduces some risk that a small covered area will be left 456 out of the filter and marked as uncovered; if this is a concern, then 457 the query limit can be increased, or the algorithm can be explicitly 458 directed to sample certain specific points. 460 Of course, if the location server operator has information about 461 service boundaries through some channel other than LoST, then the 462 LoST queries above can be replaced by queries to a local store of 463 mapping information. The choice of random points can also be guided 464 to ensure that all mapped areas are covered even if there are some 465 uncovered areas. The location server can also cache service 466 boundaries acquired during the algorithm to avoid unnecessary LoST 467 queries. 469 4.3. Civic Address Considerations 471 This algorithm actually results in two filters -- one for geodetic 472 service boundaries and one for civic service boundaries -- since 473 civic and geodetic boundaries cannot be directly compared or 474 intersected. It is RECOMMENDED that location servers always compute 475 a geodetic filter for use with emergency services, since the notion 476 of civic service boundaries have some inherent ambiguity. 478 Indeed, the notion of intersection of civic service boundaries has 479 some dependence on the jurisdiction within which the service 480 boundaries are defined. Civic service boundaries are comprised of a 481 set of elements, each defining a set of civic 482 addresses that are within the boundary, namely those that match the 483 civic elements provided. 485 When computing the intersection of two civic service boundaries, any 486 elements that are shared between the two service 487 boundaries MUST be included in the resulting intersection. When two 488 elements in the service boundaries being compared are 489 different from each other, then their intersection must be computed 490 according to local addressing standards. 492 Note that the resulting filter regions SHOULD still cover the 493 location server's coverage area, i.e., there should be a filter 494 region that contains every civic address within the coverage area. 495 In particular, the server SHOULD NOT use a specific address to 496 represent a filter region: Such an address would not include many 497 points in the service region (i.e., it would not meet the third rules 498 from the lists of rules above). If the server creates a PIDF-LO 499 document describing a civic address that does not contain the precise 500 location of the device, then it MUST set the 'method' element of the 501 PIDF-LO it returns to value 'area-representative' registered in 502 Section 8. 504 If the above procedures are not workable for a given scenario, then 505 the server MAY fall back to geocoding of service boundaries, in which 506 case the above procedures for geodetic location can be used. 508 Geocoding may also be necessary in cases where the location of the 509 target is known as a civic address with limited granularity, with 510 which service boundaries do not align. For instance, the target's 511 location may be known to the level of a postal code, but postal code 512 regions may span multiple PSAP service areas or filter regions. In 513 such cases, the server MAY geocode the target's location to obtain a 514 rough geodetic position, which can be dealt with as discussed in 515 Section 4.6 below. 517 4.4. Privileged LoST Servers 519 In certain scenarios, it may be possible that some LoST servers are 520 authorized to access more precise location information than networks 521 are willing to reveal to endpoints. For example, a network operator 522 might allow a LoST server operated by a national authority to access 523 an endpoint's precise location, even if it does not allow the 524 endpoint access to this information. 526 In these situations, the precision required for emergency services 527 routing is different than in the base case considered above. Rather 528 than needing location precise enough to identify a given PSAP, the 529 location value provided to the endpoint only needs to be precise 530 enough to route the LoST request through the mapping infrastructure 531 to a LoST server that is authorized to access the endpoint's precise 532 location. Once the request reaches that server, the server can 533 request more precise location information and use that information to 534 route the request further. 536 Indeed, such privileged LoST server could even be operated by the 537 network itself. In this case, if an endpoint complies with 538 requirement ED-52 in [1], it will send its LoST request directly to 539 the network-provided LoST server, which can look up the client's 540 location and return mappings. However, it is possible that clients 541 will use an alternative LoST resolver, so it is still beneficial to 542 provide a rough location that can route the request to a nearby 543 privileged LoST server. 545 In cases where a network allows one or more privileged LoST servers 546 to access precise location information, the network MAY designate a 547 location that is precise enough to reach one of these LoST servers as 548 precise enough for emergency call routing. 550 This document does not specify how these privileged LoST servers 551 could obtain more precise location information from network 552 operators. One possible solution is to extend LoST to carry a 553 location reference in addition to a location by value. 555 4.5. Maintaining Location Filters 557 As the LoST mappings that underlie the filter change, the filter will 558 need to be updated. The entity maintaining the filter MUST obtain a 559 new mapping for a region when an existing mapping expires. The 560 service boundary from the new mapping is compared to the service 561 boundary from the old mapping: If they are the same, then the filter 562 need not be updated. If they differ, then regions in the filter that 563 intersect either the old service boundary or the new service boundary 564 will need to be recomputed. Note that since this operation only 565 requires the server to determine if two service boundaries are 566 identical, the server need only store a hash of the old boundary to 567 which it can compare a hash of the new boundary. 569 4.6. Applying Location Filters 571 After constructing a location filter, a location server can use it to 572 optimize how it delivers location. How this is done depends on 573 whether the location server is trying to reduce the precision of a 574 known precise location, or trying to determine whether an imprecise 575 position is good enough for emergency services. 577 When the location provider knows the precise location of the caller, 578 a location filter can also be used as a "location cache". That is, 579 the location provider can simply look up which of the filter regions 580 contains the caller's precise location and return that region as the 581 caller's location, or some subset that contains the precise location. 583 This caching strategy allows an additional optimization in some 584 cases: If the location server knows that the caller's precise 585 location will be within the same region for a period of time, it can 586 instruct the client not to re-query in that time. For instance, if 587 the server is delivering location over HELD, then it can use the HTTP 588 cache-control headers (e.g., Expires). However, the location server 589 MUST NOT instruct the client to wait for longer than the current 590 filter is valid; the expiry time of the location MUST be before the 591 earliest expiry of a LoST mapping used in the filter. 593 When the location server starts with imprecise location, there are 594 different ways to apply the filter, depending on the positioning 595 technique being used. For example with a positioning algorithm that 596 grows more accurate with time, the filter can tell the server how 597 long to run the algorithm -- the algorithm can be terminated when the 598 estimated location (that is, an uncertainty region containing the 599 device's location) is within one of the regions in the filter. 601 A location filter can also be used to test whether a database of 602 rough locations for IP addresses (as is commonly used for web 603 localization today) contains precise enough values for use with 604 emergency services. To make this determination, each value in the 605 database woud be tested to see if it falls mostly or entirely within 606 a given filter region. Note, however, that this test does not 607 address concerns about the accuracy of location information, i.e., 608 the probability that the caller is actually contained within the 609 specified uncertainty region. 611 Note that the requirements for containment in a filter region differ 612 between these two use cases. When precise location is known, the 613 rough location that is returned MUST be contained within a single 614 filter region; otherwise, there will be an increased risk of mis- 615 routing. When the location server starts with imprecise location, it 616 may choose location values that are not entirely within one filter 617 region. The distribution of the imprecise location value among 618 filter regions corresponds to the risk that LoST routing will provide 619 incorrect information, so the choice of location value should balance 620 the risk of incorrect routing against the additional time needed to 621 obtain more precise location (which can translate to a delay in call 622 setup). In this case, it may not even be possible for a location 623 server to return a location value that is entirely within a single 624 filter region. 626 5. Additional Requirements for Networks and Endpoints 628 When a location provider wishes to deliver endpoints location 629 information that is below its maximum available precision while still 630 supporting emergency calling, it MUST provide to the endpoint a 631 location (by value) that is sufficient for emergency call routing (as 632 defined above) and MUST provide a location reference (i.e., a URI) 633 that can subsequently be used by authorized parties to obtain more 634 precise information about the location of the endpoint. The endpoint 635 then can then use both the location value and the location reference 636 to request emergency services and other location-based services 637 (LBS). 639 This arrangement allows the client to provide rough location (by 640 value) to any entity, and to provide precise location (by reference) 641 to authorized parties. An assumption of this model, of course, is 642 that emergency authorities are authorized by the location provider to 643 receive precise location. Location providers may also authorize 644 other entities to receive precise location information (e.g., 645 commercial services that have agreed to pay for location). 646 Authorization policy for location URIs is set by the referenced 647 location server; a mechanism for clients to request information about 648 this policy is described in [9]. 650 ED-84: When an endpoint has access to location both by value and by 651 reference, it MUST include both forms of geolocation in the SIP 652 INVITE message initiating an emergency call, each in a separate 653 Geolocation header. The endpoint SHOULD include a Geolocation- 654 Routing header with the value "yes". 656 AN-30: Networks providing imprecise location MUST also provide 657 location by reference. 659 AN-31: Networks providing imprecise location SHOULD provide DHCP- 660 based LoST discovery, advertising a LoST server that is authorized 661 to dereference location URIs issued by the network's LIS. 663 The overall procedure for placing an emergency call is identical to 664 that described in [5]. In particular, the endpoint requirements in 665 Sections 8 and 9 of [1] still apply to an endpoint that receives 666 imprecise location, with the above modification (use of the location 667 URI in LoST). 669 In addition, an endpoint that receives location both by value and by 670 reference from its location provider MUST include both the location 671 value and the location reference in the SIP INVITE message that 672 initiates an emergency call, as specified in [10]. Note that this 673 process crucially relies on the location value having sufficient 674 precision for routing emergency calls (see Section 3 for techniques 675 to ensure the location value is suitable for emergency call routing). 677 When a PSAP receives a SIP INVITE that contains both a location value 678 and a location reference, and the value is too imprecise for use in 679 dispatch then the PSAP SHOULD dereference the LbyR to obtain more 680 precise information. In turn, the location provided by the location 681 provider SHOULD allow access by all PSAPs whose service boundaries 682 overlap with the region served by the location provider. This means 683 that either the provider must supply a reference that can be 684 dereferenced by any party, or else the provider must establish 685 explicit authentication and authorization relationships with all 686 PSAPs in its service area. It is RECOMMENDED that location providers 687 establish similar relationships with other PSAPs in adjoining 688 jursidictions -- even if their service regions do not overlap with 689 the location provider's -- in case such a PSAP needs access to 690 precise location information, for example, if it is acting as a 691 backup for one of the location provider's normal PSAPs. 693 6. Acknowledgements 695 This document generalizes the concept of "rough location" that was 696 originally discussed in the context of the location hiding problem. 697 This concept was put forward by Henning Schulzrinne and Andy Newton, 698 among many others, in a long-running ECRIT discussion. Thanks to 699 Hannes Tschofenig and Martin Thomson for detailed reviews of this 700 document. 702 7. Security Considerations 704 The use of imprecise location provides a security trade-off for 705 location providers. When location providers are required to provide 706 location in support of emergency services, they have to balance that 707 requirement against the risk that location information will be 708 disclosed to an unauthorized party. The use of location 709 configuration protocols inherently introduces some risk that an 710 entity other than the device will be able to masquerade as the device 711 (e.g., another host behind the same NAT or malicious software on the 712 host) [11]. In some cases, the location provider may not authorize 713 the device itself to access precise location. At the same time, 714 because endpoints can roam between networks, it is operationally 715 difficult to have strong client authentication for LCPs. 717 Using of rough location to support emergency calling enables a 718 location provider to provide low-precision location with low 719 assurance (e.g., without client authentication)and high-precision 720 location with higher assurance. Because lower-precision location 721 generally has lower value -- to location providers and LBS providers 722 as a commercial asset, and to devices as private information -- this 723 trade-off allows a location provider to avoid the cost of protecting 724 location with high-assurance access controls when this location has 725 low value. 727 However, in order to support emergency services, location providers 728 cannot provide only low-precision location; they also have to provide 729 PSAPs with access to high-precision location information. Because 730 PSAPs require high-precision location for emergency response, a 731 location provider that normally provides imprecise location to 732 clients MUST also provide them a location URI that a PSAP can use to 733 obtain high-precision location. This constraint means that the 734 provided URI MUST have either no access control at all or a policy 735 that allows access by appropriate PSAPs and other emergency response 736 systems, e.g., ESRPs. That is, if such a location URI is access 737 controlled, then the location provider MUST be able to authenticate 738 requests from PSAPs. 740 The use of location by reference introduces some risk that the 741 reference will be used by an attacker to gain unauthorized access to 742 the device's location. These risks are not specific to emergency 743 service, however; general risks and mitigations for location by 744 reference are discussed in [12] 746 As described in Section 4 above, the location provider choosing to 747 provide a less precise location than a known location has a 748 significant amount of choice in deciding which location to provide: 749 Any location that contains the known location and is in the same 750 filter region will do. When the provider is reducing precision for 751 privacy purposes, there is a some privacy benefit to choosing a 752 random location meeting these criteria. If a watcher is interested 753 in whether or not the endpoint is moving, an imprecise location may 754 still reveal that fact if it is constant when the endpoint is at 755 rest. If the provided location is randomized each time it is 756 provided, then the watcher is unable to obtain even this level of 757 information. An algorithm for securely fuzzing a device's location 758 can be found in [13]; for emergency services, the additional 759 constraint must be added that the fuzzed location must remain in the 760 same filter region as the original. 762 8. IANA Considerations 764 This document requests that IANA register a new PIDF-LO 'method' 765 token in the registry defined by RFC 4119 [4] 767 area-representative: Location chosen as a representative of a region 768 in which the device is located; may not be the device's location. 770 9. References 771 9.1. Normative References 773 [1] Rosen, B. and J. Polk, "Best Current Practice for 774 Communications Services in support of Emergency Calling", 775 draft-ietf-ecrit-phonebcp-20 (work in progress), 776 September 2011. 778 [2] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, 779 "LoST: A Location-to-Service Translation Protocol", RFC 5222, 780 August 2008. 782 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 783 Levels", BCP 14, RFC 2119, March 1997. 785 [4] Peterson, J., "A Presence-based GEOPRIV Location Object 786 Format", RFC 4119, December 2005. 788 9.2. Informative References 790 [5] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework 791 for Emergency Calling Using Internet Multimedia", RFC 6443, 792 December 2011. 794 [6] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. 795 Kuett, "Location Hiding: Problem Statement and Requirements", 796 RFC 6444, January 2012. 798 [7] Schulzrinne, H., "Location-to-URL Mapping Architecture and 799 Framework", RFC 5582, September 2009. 801 [8] Thomson, M. and J. Winterbottom, "Representation of Uncertainty 802 and Confidence in PIDF-LO", 803 draft-thomson-geopriv-uncertainty-07 (work in progress), 804 March 2012. 806 [9] Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig, 807 "Location Configuration Extensions for Policy Management", 808 draft-barnes-geopriv-policy-uri-02 (work in progress), 809 November 2010. 811 [10] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for 812 the Session Initiation Protocol", RFC 6442, December 2011. 814 [11] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location 815 Configuration Protocol: Problem Statement and Requirements", 816 RFC 5687, March 2010. 818 [12] Marshall, R., "Requirements for a Location-by-Reference 819 Mechanism", RFC 5808, May 2010. 821 [13] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Morris, 822 J., and M. Thomson, "Geolocation Policy: A Document Format for 823 Expressing Privacy Preferences for Location Information", 824 draft-ietf-geopriv-policy-26 (work in progress), June 2012. 826 [14] Thomson, M. and K. Wolf, "Describing Boundaries for Civic 827 Addresses", draft-thomson-ecrit-civic-boundary-02 (work in 828 progress), January 2011. 830 Authors' Addresses 832 Richard Barnes 833 BBN Technologies 834 9861 Broken Land Pkwy, Suite 400 835 Columbia, MD 21046 836 USA 838 Phone: +1 410 290 6169 839 Email: rbarnes@bbn.com 841 Matt Lepinski 842 BBN Technologies 843 10 Moulton St 844 Cambridge, MA 02138 845 USA 847 Phone: +1 617 873 5939 848 Email: mlepinski@bbn.com