--- 1/draft-ietf-ecrit-rough-loc-03.txt 2011-03-29 14:16:21.000000000 +0200 +++ 2/draft-ietf-ecrit-rough-loc-04.txt 2011-03-29 14:16:21.000000000 +0200 @@ -1,18 +1,18 @@ Internet Engineering Task Force R. Barnes Internet-Draft M. Lepinski Intended status: Standards Track BBN Technologies -Expires: February 17, 2011 August 16, 2010 +Expires: September 30, 2011 March 29, 2011 Using Imprecise Location for Emergency Context Resolution - draft-ietf-ecrit-rough-loc-03.txt + draft-ietf-ecrit-rough-loc-04.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 @@ -26,25 +26,25 @@ 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 February 17, 2011. + This Internet-Draft will expire on September 30, 2011. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2011 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 @@ -54,38 +54,38 @@ 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 . . . . . . . 14 + 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 . . . . . . . . . . . . . . . . . . . 16 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 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 [6] and [1].) This process + 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 location. Using location information with maximal precision and accuracy minimizes the chance that a call will be mis-routed. When location is provided to the endpoint, the endpoint is able to verify that the location is correct (to the extent of the endpoint's knowledge of its own location) prior to an emergency call, and is able to perform emergency call routing functions on its own, providing redundancy for network-provided functions. Moreover, when @@ -120,21 +120,21 @@ services. This document is concerned with imprecise location only in the context of routing emergency calls, i.e., for determining the correct PSAP to receive a given call (e.g., via a LoST query [2]). Depending on the the structure of the local emergency service network, the location information provided to the endpoint may also be used to route the call to an entity that is authorized to request precise location, e.g., an Emergency Services Routing Proxy. The requirements and processes described in this document are the same - for both cases. Detailed requirements are discussed in [7] + for both cases. Detailed requirements are discussed in [6] Location information may also be used in the emergency calling framework to direct the dispatch of emergency responders. This usage is treated separately from call routing for purposes of this document, and this document does not place requirements on the location provided for dispatch, although it should obviously be as precise as possible. The only provision for dispatch in this document is a recommendation that the location provider supply endpoints with a URI that can be used by a PSAP or other emergency authority to obtain a different location for use in dispatch, @@ -149,37 +149,37 @@ invoked when precise location is not available to the endpoint by value. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3]. We consider in this document patterns of interaction as described in - [6]. The two main parties of interest are endpoints and location + [5]. The two main parties of interest are endpoints and location providers. Endpoints are hosts connected to the Internet that originate emergency calls in the emergency calling architecture, while location providers are entities that supply location information that is used for emergency calling. In addition, we will discuss how these parties interact with the LoST mapping - infrastructure [8], and with emergency and non-emergency location- + infrastructure [7], and with emergency and non-emergency location- based service providers. For convenience, we say that location information, either in LoST queries or in service boundaries, is provided "in geodetic form" if it is provided in the "geodetic-2d" LoST location profile, and "in civic form" if it is provided in the "civic" profile. The term "precision" is not used in a quantitative sense in this document. In general, the "precision" of a location value is - determined by the size of its uncertainty region. [9] Higher + determined by the size of its uncertainty region. [8] Higher precision values have small uncertainty regions and lower precision values have larger uncertainty regions. The notion of "sufficient precision for emergency services is defined in Section 3 3. Location Precision Requirements A location provider wishing to provide location information usable for emergency call routing requires a mechanism for determining when a description of location (e.g., a polygon) is precise enough to be used for emergency call routing. This mechanism might be used to @@ -299,42 +299,29 @@ Resulting filter region (police=>A, fire=>B, ambulance=>C) Figure 1: Generating a Filter Region from a Sample Point In pseudocode form, algorithm for constructing a filter region from a point is as follows: function filterRegion(X): Set REGION = the world - Perform a LoST query for X - Set SL = from LoST - If SL == NULL or LoST returned an error - Return the empty set - For each service URN S in SL + For each service URN S in the urn:service:sos namespace Perform a LoST query for Y and S If LoST returned an error Continue Set SB = from LoST If SB is not provided, throw an error Else set REGION = intersection( REGION, SB ) - If has a - Set SLB = - from LoST - Set REGION = intersection( REGION, SLB ) Return REGION - The final intersection with the serviceListBoundary is necessary - because if some parts of the region receive a different set of - services, they have different LoST routing properties, and thus need - to be excluded from the filter region. [4] - It is important that the filter take into account all emergency services available in over the coverage area of the LIS. (That is, the services listed in the LoST serviceList elements.) The feature is necessary in order to ensure that calls to all available emergency services can be routed correctly using rough location values provided by the filter. While in principle, a location server could execute this algorithm to compute a fresh filter region on each query, it is much more efficient to use the offline algorithm for computing an entire @@ -480,21 +469,22 @@ 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 [10] + 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 boundaries MUST be included in the resulting intersection. When two @@ -599,33 +589,33 @@ 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 [11]. + this policy is described in [10]. 5.1. Emergency Calling The overall procedure for placing an emergency call is identical to - that described in [6]. In particular, the endpoint requirements in + 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. 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 [12]. When the endpoint + 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 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 @@ -681,21 +671,21 @@ 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) [13]. In some cases, the location provider may not authorize + host) [12]. 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 @@ -713,112 +703,108 @@ 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 [14] + reference are discussed in [13] 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 [15]; for emergency services, the additional + can be found in [14]; 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 [5] + 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-15 (work in progress), July 2010. + draft-ietf-ecrit-phonebcp-17 (work in progress), March 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] Wolf, K., "LoST Service List Boundary Extension", - draft-ietf-ecrit-lost-servicelistboundary-04 (work in - progress), August 2010. - - [5] Peterson, J., "A Presence-based GEOPRIV Location Object + [4] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. 9.2. Informative References - [6] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework + [5] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling using Internet Multimedia", - draft-ietf-ecrit-framework-11 (work in progress), July 2010. + draft-ietf-ecrit-framework-12 (work in progress), October 2010. - [7] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. + [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. - [8] Schulzrinne, H., "Location-to-URL Mapping Architecture and + [7] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, September 2009. - [9] Thomson, M. and J. Winterbottom, "Representation of Uncertainty + [8] Thomson, M. and J. Winterbottom, "Representation of Uncertainty and Confidence in PIDF-LO", - draft-thomson-geopriv-uncertainty-05 (work in progress), - May 2010. + draft-thomson-geopriv-uncertainty-06 (work in progress), + March 2011. - [10] Thomson, M. and K. Wolf, "Describing Boundaries for Civic - Addresses", draft-thomson-ecrit-civic-boundary-01 (work in - progress), July 2010. + [9] Thomson, M. and K. Wolf, "Describing Boundaries for Civic + Addresses", draft-thomson-ecrit-civic-boundary-02 (work in + progress), January 2011. - [11] Barnes, R., Thomson, M., and J. Winterbottom, "Location - Configuration Extensions for Policy Management", - draft-barnes-geopriv-policy-uri-01 (work in progress), - May 2010. + [10] 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. - [12] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for + [11] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", - draft-ietf-sipcore-location-conveyance-03 (work in progress), - July 2010. + draft-ietf-sipcore-location-conveyance-06 (work in progress), + February 2011. - [13] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location + [12] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010. - [14] Marshall, R., "Requirements for a Location-by-Reference + [13] Marshall, R., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010. - [15] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and + [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-21 (work in progress), January 2010. + draft-ietf-geopriv-policy-23 (work in progress), March 2011. Authors' Addresses Richard Barnes BBN Technologies 9861 Broken Land Pkwy, Suite 400 Columbia, MD 21046 USA Phone: +1 410 290 6169