--- 1/draft-ietf-ecrit-rough-loc-04.txt 2012-07-16 23:14:12.725425394 +0200 +++ 2/draft-ietf-ecrit-rough-loc-05.txt 2012-07-16 23:14:12.765426010 +0200 @@ -1,50 +1,50 @@ Internet Engineering Task Force R. Barnes Internet-Draft M. Lepinski Intended status: Standards Track BBN Technologies -Expires: September 30, 2011 March 29, 2011 +Expires: January 17, 2013 July 16, 2012 Using Imprecise Location for Emergency Context Resolution - draft-ietf-ecrit-rough-loc-04.txt + draft-ietf-ecrit-rough-loc-05.txt Abstract Emergency calling works best when precise location is available for emergency call routing. However, there are situations in which a location provider is unable or unwilling to provide precise location, yet still wishes to enable subscribers to make emergency calls. This document describes the level of location accuracy that providers must - provide to enable emergency call routing. In addition, we descibe - how emergency services and non-emergency services can be invoked by - an endpoint that does not have access to its precise location. + provide to enable emergency call routing. In addition, we describe + additional rules for networks and endpoints to enable emergency + calling by endpoints that do not have access to precise location. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 30, 2011. + This Internet-Draft will expire on January 17, 2013. Copyright Notice - Copyright (c) 2011 IETF Trust and the persons identified as the + Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -52,32 +52,31 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Location Precision Requirements . . . . . . . . . . . . . . . 5 4. Location Filtering . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Filter Region for a Known Location . . . . . . . . . . . . 6 4.2. Constructing a Location Filter . . . . . . . . . . . . . . 8 4.3. Civic Address Considerations . . . . . . . . . . . . . . . 11 - 4.4. Maintaining Location Filters . . . . . . . . . . . . . . . 12 - 4.5. Applying Location Filters . . . . . . . . . . . . . . . . 12 - 5. Requesting Emergency and Non-emergency Services . . . . . . . 13 - 5.1. Emergency Calling . . . . . . . . . . . . . . . . . . . . 14 - 5.2. Non-emergency Services . . . . . . . . . . . . . . . . . . 15 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 4.4. Privileged LoST Servers . . . . . . . . . . . . . . . . . 12 + 4.5. Maintaining Location Filters . . . . . . . . . . . . . . . 13 + 4.6. Applying Location Filters . . . . . . . . . . . . . . . . 13 + 5. Additional Requirements for Networks and Endpoints . . . . . . 14 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Information about the location of an emergency caller is a critical input to the process of emergency call establshment. Endpoint location is used to determine which Public Safety Answering Point (PSAP) should be the destination of the call. (The entire emergency calling process is described in detail in [5] and [1].) This process is most likely to work properly when the endpoint is provided with the most accurate and precise information available about its @@ -468,22 +467,20 @@ queries. 4.3. Civic Address Considerations This algorithm actually results in two filters -- one for geodetic service boundaries and one for civic service boundaries -- since civic and geodetic boundaries cannot be directly compared or intersected. It is RECOMMENDED that location servers always compute a geodetic filter for use with emergency services, since the notion of civic service boundaries have some inherent ambiguity. - Considerations around civic service boundaries are discussed in - detail in [9] Indeed, the notion of intersection of civic service boundaries has some dependence on the jurisdiction within which the service boundaries are defined. Civic service boundaries are comprised of a set of elements, each defining a set of civic addresses that are within the boundary, namely those that match the civic elements provided. When computing the intersection of two civic service boundaries, any elements that are shared between the two service @@ -497,35 +494,86 @@ region that contains every civic address within the coverage area. In particular, the server SHOULD NOT use a specific address to represent a filter region: Such an address would not include many points in the service region (i.e., it would not meet the third rules from the lists of rules above). If the server creates a PIDF-LO document describing a civic address that does not contain the precise location of the device, then it MUST set the 'method' element of the PIDF-LO it returns to value 'area-representative' registered in Section 8. -4.4. Maintaining Location Filters + If the above procedures are not workable for a given scenario, then + the server MAY fall back to geocoding of service boundaries, in which + case the above procedures for geodetic location can be used. + + Geocoding may also be necessary in cases where the location of the + target is known as a civic address with limited granularity, with + which service boundaries do not align. For instance, the target's + location may be known to the level of a postal code, but postal code + regions may span multiple PSAP service areas or filter regions. In + such cases, the server MAY geocode the target's location to obtain a + rough geodetic position, which can be dealt with as discussed in + Section 4.6 below. + +4.4. Privileged LoST Servers + + In certain scenarios, it may be possible that some LoST servers are + authorized to access more precise location information than networks + are willing to reveal to endpoints. For example, a network operator + might allow a LoST server operated by a national authority to access + an endpoint's precise location, even if it does not allow the + endpoint access to this information. + + In these situations, the precision required for emergency services + routing is different than in the base case considered above. Rather + than needing location precise enough to identify a given PSAP, the + location value provided to the endpoint only needs to be precise + enough to route the LoST request through the mapping infrastructure + to a LoST server that is authorized to access the endpoint's precise + location. Once the request reaches that server, the server can + request more precise location information and use that information to + route the request further. + + Indeed, such privileged LoST server could even be operated by the + network itself. In this case, if an endpoint complies with + requirement ED-52 in [1], it will send its LoST request directly to + the network-provided LoST server, which can look up the client's + location and return mappings. However, it is possible that clients + will use an alternative LoST resolver, so it is still beneficial to + provide a rough location that can route the request to a nearby + privileged LoST server. + + In cases where a network allows one or more privileged LoST servers + to access precise location information, the network MAY designate a + location that is precise enough to reach one of these LoST servers as + precise enough for emergency call routing. + + This document does not specify how these privileged LoST servers + could obtain more precise location information from network + operators. One possible solution is to extend LoST to carry a + location reference in addition to a location by value. + +4.5. Maintaining Location Filters As the LoST mappings that underlie the filter change, the filter will need to be updated. The entity maintaining the filter MUST obtain a new mapping for a region when an existing mapping expires. The service boundary from the new mapping is compared to the service boundary from the old mapping: If they are the same, then the filter need not be updated. If they differ, then regions in the filter that intersect either the old service boundary or the new service boundary will need to be recomputed. Note that since this operation only requires the server to determine if two service boundaries are identical, the server need only store a hash of the old boundary to which it can compare a hash of the new boundary. -4.5. Applying Location Filters +4.6. Applying Location Filters After constructing a location filter, a location server can use it to optimize how it delivers location. How this is done depends on whether the location server is trying to reduce the precision of a known precise location, or trying to determine whether an imprecise position is good enough for emergency services. When the location provider knows the precise location of the caller, a location filter can also be used as a "location cache". That is, the location provider can simply look up which of the filter regions @@ -564,128 +612,111 @@ between these two use cases. When precise location is known, the rough location that is returned MUST be contained within a single filter region; otherwise, there will be an increased risk of mis- routing. When the location server starts with imprecise location, it may choose location values that are not entirely within one filter region. The distribution of the imprecise location value among filter regions corresponds to the risk that LoST routing will provide incorrect information, so the choice of location value should balance the risk of incorrect routing against the additional time needed to obtain more precise location (which can translate to a delay in call - setup). Actually, in this case, it may not even be possible for a - location server to return a location value that is entirely within a - single filter region. + setup). In this case, it may not even be possible for a location + server to return a location value that is entirely within a single + filter region. -5. Requesting Emergency and Non-emergency Services +5. Additional Requirements for Networks and Endpoints When a location provider wishes to deliver endpoints location information that is below its maximum available precision while still - supporting emergency calling, it MUST provide to the endpoint both a + supporting emergency calling, it MUST provide to the endpoint a location (by value) that is sufficient for emergency call routing (as - defined above) and a location reference (i.e., a URI) that can - subsequently be used by authorized parties to obtain more precise - information about the location of the endpoint. The endpoint then - can then use both the location value and the location reference to - request emergency services and other location-based services (LBS). + defined above) and MUST provide a location reference (i.e., a URI) + that can subsequently be used by authorized parties to obtain more + precise information about the location of the endpoint. The endpoint + then can then use both the location value and the location reference + to request emergency services and other location-based services + (LBS). This arrangement allows the client to provide rough location (by value) to any entity, and to provide precise location (by reference) to authorized parties. An assumption of this model, of course, is that emergency authorities are authorized by the location provider to receive precise location. Location providers may also authorize other entities to receive precise location information (e.g., commercial services that have agreed to pay for location). Authorization policy for location URIs is set by the referenced location server; a mechanism for clients to request information about - this policy is described in [10]. + this policy is described in [9]. -5.1. Emergency Calling + ED-84: When an endpoint has access to location both by value and by + reference, it MUST include both forms of geolocation in the SIP + INVITE message initiating an emergency call, each in a separate + Geolocation header. The endpoint SHOULD include a Geolocation- + Routing header with the value "yes". + + AN-30: Networks providing imprecise location MUST also provide + location by reference. + + AN-31: Networks providing imprecise location SHOULD provide DHCP- + based LoST discovery, advertising a LoST server that is authorized + to dereference location URIs issued by the network's LIS. The overall procedure for placing an emergency call is identical to that described in [5]. In particular, the endpoint requirements in Sections 8 and 9 of [1] still apply to an endpoint that receives - imprecise location. + imprecise location, with the above modification (use of the location + URI in LoST). In addition, an endpoint that receives location both by value and by reference from its location provider MUST include both the location value and the location reference in the SIP INVITE message that - initiates an emergency call, as specified in [11]. When the endpoint - supports LoST, it MUST use the location value to obtain a PSAP URI - for LoST queries before attempting to dereference the location - reference. Note that the caller would also have to add the "used- - for-routing" parameter to the geolocation header that points to the - location value as inserted into the INVITE message. Note that this + initiates an emergency call, as specified in [10]. Note that this process crucially relies on the location value having sufficient precision for routing emergency calls (see Section 3 for techniques to ensure the location value is suitable for emergency call routing). When a PSAP receives a SIP INVITE that contains both a location value and a location reference, and the value is too imprecise for use in dispatch then the PSAP SHOULD dereference the LbyR to obtain more precise information. In turn, the location provided by the location - provider MUST allow access by all PSAPs whose service boundaries + provider SHOULD allow access by all PSAPs whose service boundaries overlap with the region served by the location provider. This means that either the provider must supply a reference that can be dereferenced by any party, or else the provider must establish explicit authentication and authorization relationships with all PSAPs in its service area. It is RECOMMENDED that location providers establish similar relationships with other PSAPs in adjoining jursidictions -- even if their service regions do not overlap with the location provider's -- in case such a PSAP needs access to precise location information, for example, if it is acting as a backup for one of the location provider's normal PSAPs. -5.2. Non-emergency Services - - Non-emergency LBSs may require more precise information than is - required for emergency call routing. Therefore, when requesting a - non-emergency LBS, the endpoint SHOULD include the location reference - provided by its location provider, and MAY additionally provide the - location value. If the provided location value is not sufficiently - precise to deliver the requested service, then the LBS provider - should then dereference the location value to request location - information of sufficient precision from the location provider. If - the dereference fails, then the request for service may fail as well. - - Note that when the location reference provided by the location - provider is access-controled, this dereference may require a pre- - existing authentication and authorization agreement between the LBS - provider and the location provider. In such a case, the endpoint may - not know whether a given non-emergency service is authorized to - obtain the endpoint's precise location using the location reference. - The endpoint is always capable of requesting services without knowing - whether they are authorized; in this way, the endpoint can discover - authorized services by trial and error. In order to simplify this - process, a location provider may supply the endpoint with references - to authorized service providers, although there is currently no - standard protocol for this transaction. - 6. Acknowledgements This document generalizes the concept of "rough location" that was originally discussed in the context of the location hiding problem. This concept was put forward by Henning Schulzrinne and Andy Newton, among many others, in a long-running ECRIT discussion. Thanks to Hannes Tschofenig and Martin Thomson for detailed reviews of this document. 7. Security Considerations The use of imprecise location provides a security trade-off for location providers. When location providers are required to provide location in support of emergency services, they have to balance that requirement against the risk that location information will be disclosed to an unauthorized party. The use of location configuration protocols inherently introduces some risk that an entity other than the device will be able to masquerade as the device (e.g., another host behind the same NAT or malicious software on the - host) [12]. In some cases, the location provider may not authorize + host) [11]. In some cases, the location provider may not authorize the device itself to access precise location. At the same time, because endpoints can roam between networks, it is operationally difficult to have strong client authentication for LCPs. Using of rough location to support emergency calling enables a location provider to provide low-precision location with low assurance (e.g., without client authentication)and high-precision location with higher assurance. Because lower-precision location generally has lower value -- to location providers and LBS providers as a commercial asset, and to devices as private information -- this @@ -703,35 +734,35 @@ provided URI MUST have either no access control at all or a policy that allows access by appropriate PSAPs and other emergency response systems, e.g., ESRPs. That is, if such a location URI is access controlled, then the location provider MUST be able to authenticate requests from PSAPs. The use of location by reference introduces some risk that the reference will be used by an attacker to gain unauthorized access to the device's location. These risks are not specific to emergency service, however; general risks and mitigations for location by - reference are discussed in [13] + reference are discussed in [12] As described in Section 4 above, the location provider choosing to provide a less precise location than a known location has a significant amount of choice in deciding which location to provide: Any location that contains the known location and is in the same filter region will do. When the provider is reducing precision for privacy purposes, there is a some privacy benefit to choosing a random location meeting these criteria. If a watcher is interested in whether or not the endpoint is moving, an imprecise location may still reveal that fact if it is constant when the endpoint is at rest. If the provided location is randomized each time it is provided, then the watcher is unable to obtain even this level of information. An algorithm for securely fuzzing a device's location - can be found in [14]; for emergency services, the additional + can be found in [13]; for emergency services, the additional constraint must be added that the fuzzed location must remain in the same filter region as the original. 8. IANA Considerations This document requests that IANA register a new PIDF-LO 'method' token in the registry defined by RFC 4119 [4] area-representative: Location chosen as a representative of a region in which the device is located; may not be the device's location. @@ -730,81 +761,78 @@ 8. IANA Considerations This document requests that IANA register a new PIDF-LO 'method' token in the registry defined by RFC 4119 [4] area-representative: Location chosen as a representative of a region in which the device is located; may not be the device's location. 9. References - 9.1. Normative References [1] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", - draft-ietf-ecrit-phonebcp-17 (work in progress), March 2011. + draft-ietf-ecrit-phonebcp-20 (work in progress), + September 2011. [2] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. 9.2. Informative References [5] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework - for Emergency Calling using Internet Multimedia", - draft-ietf-ecrit-framework-12 (work in progress), October 2010. + for Emergency Calling Using Internet Multimedia", RFC 6443, + December 2011. [6] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. Kuett, "Location Hiding: Problem Statement and Requirements", - draft-ietf-ecrit-location-hiding-req-04 (work in progress), - February 2010. + RFC 6444, January 2012. [7] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, September 2009. [8] Thomson, M. and J. Winterbottom, "Representation of Uncertainty and Confidence in PIDF-LO", - draft-thomson-geopriv-uncertainty-06 (work in progress), - March 2011. - - [9] Thomson, M. and K. Wolf, "Describing Boundaries for Civic - Addresses", draft-thomson-ecrit-civic-boundary-02 (work in - progress), January 2011. + draft-thomson-geopriv-uncertainty-07 (work in progress), + March 2012. - [10] Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig, + [9] Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig, "Location Configuration Extensions for Policy Management", draft-barnes-geopriv-policy-uri-02 (work in progress), November 2010. - [11] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for - the Session Initiation Protocol", - draft-ietf-sipcore-location-conveyance-06 (work in progress), - February 2011. + [10] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for + the Session Initiation Protocol", RFC 6442, December 2011. - [12] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location + [11] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010. - [13] Marshall, R., "Requirements for a Location-by-Reference + [12] Marshall, R., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010. - [14] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and - J. Polk, "Geolocation Policy: A Document Format for Expressing - Privacy Preferences for Location Information", - draft-ietf-geopriv-policy-23 (work in progress), March 2011. + [13] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Morris, + J., and M. Thomson, "Geolocation Policy: A Document Format for + Expressing Privacy Preferences for Location Information", + draft-ietf-geopriv-policy-26 (work in progress), June 2012. + + [14] Thomson, M. and K. Wolf, "Describing Boundaries for Civic + Addresses", draft-thomson-ecrit-civic-boundary-02 (work in + progress), January 2011. Authors' Addresses Richard Barnes BBN Technologies 9861 Broken Land Pkwy, Suite 400 Columbia, MD 21046 USA Phone: +1 410 290 6169