Location Hiding for Emergency Services

This page is based on the summary by Henning, see http://www1.cs.columbia.edu:8080/display/~hgs/ECRIT+location+hiding.

High-level requirements

There should be a way an access network can withhold detailed location information from any entity it wishes to, and specifically, the endpoint, and a VSP. Presumably, it will dereference for the PSAP.

The access network must support the ability of the endpoint or the VSP to route emergency calls.

Whatever mechanism is supported for, the VSP must be able to validate that a call purported to be an emergency call is being routed to a bona fide URI, which is denoted by being a URI in LoST for the designated emergency service.

The true location information must be conveyed (either LbyR or LbyV) to the PSAP.

There is no point making coarse locations less precise than the average resolution of IP-based address determination, i.e., around 20-50 miles.
Issue HR-1 This should not be a requirement. Not all IP address based location determination systems are that accurate. Additionally, giving away course location information should not be required to hide location. Course location information even at the country level is useful commercially. One such example is Google, which uses IP address location determination at the country level to route users to language specific start pages. Access networks should be allowed to charge for location information that is as course as this, since it is a valuable asset on today's Internet. -andy

Detailed requirements

• No business or trust relationship between ISP and VSP.
• VSPs can be outside the jurisdiction of the PSAP.
• Automated discovery of servers and other behavior, i.e., no manual configuration.
• The steps needed by the endpoint for emergency calling should be no different when location is withheld vs. when location is not withheld. In particular, user agents cannot require additional configuration to discover which particular environment (hiding or no hiding) they find themselves in.
• Should work for non-SIP entities, without the ISP having to support these protocols.
• PSAP boundaries may have holes.
• We cannot assume ESRP per country/state/city.
• Service boundaries for different emergency services may differ, but they overlap at the location of the caller.
• UAs should not have to deduce the desired behavior by having other operations, such as LbyR resolutions, fail, as failures add latency during call setup.
• User agents need to be able to determine PSAP/ESRP URLs prior to the call, for all emergency services.
• UAs need to be able to discover at least their the dial string ahead of the emergency call.
• Minimal impact on UAs.
• Must not interfere with the use of LoST for non-emergency services.
• No or minimal increase of call setup latency.

Desirable

• No effort shifting (externality), i.e., the convenience of the location-hiding ISP should not impose a burden on user agents or non-hiding ISPs.
• No discovery-by-failure, i.e., a UA should not have to try various things until it succeeds, as that can greatly increase call setup latency.
• It is desirable to minimize the impact on LoST, SIP conveyance and DHCP, as we don't know how prevalent this mode will be.
• No reliance on DHCP for LoST configuration, as DHCP may not reach the UA. Issue D-1 However, the ability for the "nearest" LoST server to be discovered by a cooperating access or IP network (in either hiding or non-hiding cases) is desirable. Therefore, while DHCP cannot be counted on to be universally deployed, other LoST discovery methods are available. They include LoST discovery via other LCPs and methods described in draft-thomson-geopriv-lis-discovery. -andy

Non-requirements

• Hiding for non-emergency services is not a concern.

Requirements (-01, R. Barnes)

Required components:

1. A mechanism to deliver to endpoints, at any time,
   1. All emergency dial strings for their location
   2. PSAP URIs (matched to service URNs) for all services available at their location
2. A mechanism to deliver endpoint location to PSAPs/emergency responders.
3. A mechanism by which a VSP can learn whether a URI is a PSAP URI

Requirements:

1. MUST NOT require the ISP to give precise location to the endpoint.
2. MUST NOT require the ISP to give rough location to an unauthorized party.
3. A party in possession of a URL MAY be considered authorized. However, in this case,
   1. The solution MUST specify which URLs are required to have this property, and
   2. URLs MUST have a cryptographically random component with a specified minimum size
4. MUST NOT require a business/trust relationship between ISP and VSP
5. MUST NOT require a business/trust relationship between VSP and PSAPs
6. MAY require a business/trust relationship between ISP and PSAPs
7. MUST NOT require any particular structure for the emergency response network
8. MUST NOT require any particular geometric propertise of PSAP boundaries

Possible requirements

1. MUST NOT require the ISP to give location of any granularity to the endpoint
2. MUST NOT require the use of a particular LoST resolver by the endpoint

Desiderata:

1. Minimal effect on call setup latency
2. Minimal changes from existing protocols & architectures
3. Minimal difference between provisioning by-value and by-reference
4. Minimal changes to UA configuration mechanisms
5. Maintain separation of protocols for location configuration and mapping
6. Independence of protocol used by the UA for calling / session establishment

Solutions

Solution 1: Return rough location

Basic idea: Based on LoST information, the LIS returns location information that yields the correct PSAP for all emergency services, but fuzzes the location.

The LIS returns (at least) an LbyR. If an endpoint or VSP dereferences the LbyR, they get a coarse location. A coarse location is defined as a large area containing the endpoint location, which, if submitted to LoST as the location of an endpoint, would yield the correct PSAP URI for the service requested. This is true for every emergency service. The VSP can also dereference, get the coarse location, and use that in a LoST request to validate the URI. As an optimization, the LIS can return the coarse LbyV as well as the LbyR. This avoids the requirement of the endpoint to dereference before its LoST request. As an optimization, the endpoint can include both the LbyV and the LbyR to avoid the VSP dereference.

In most cases, the coarse location can be a polygon, namely the PSAP boundary. This simply algorithm will fail if the PSAP boundary has holes OR if different services have different boundaries. The latter is addressed by defining the intersection of the service regions. The LIS then returns either that polygon or some other (large) shape.

For PSAP boundaries with holes, the shape returned should be something where the centroid falls into the service area of all call centers.

Different countries have different conditions. Multiple services with different coverage regions don't occur in the United States, as there is only one emergency number. (Other emergency services, such as suicide hotlines, tend to be national.)

Providing both LbyR and LbyV implies that the client needs to decide whether to attempt to dereference the LbyR URL and use that value for LoST, as it has no way of knowing whether the location returned is of higher quality. Also, LbyR might be used to update locations in real time, recommending its use at call time, but this would fail with hiding.

Advantages: no changes in UA behavior; no complexity increase for non-hiding LIS; no changes in LoST

Disadvantage: for ISPs that serve customers in areas where emergency services have different coverage regions or holes, one-time off-line computation of intersections is required.
Issue 1-1 The algorithms for centroid calculation and hole compensation would need to be normatively specified (most likely, referenced). -andy
Issue 1-2 This assumes that course location information is acceptable in all cases of location hiding. -andy
Issue 1-3 UAs must now be forbidden from conveying dereferenced location information. -andy
Issue 1-4 The semantic difference regarding authorization/nonauthorization of location information is lost, making it difficult for UAs to know if they truly are not authorized to get true location information. This introduces ambiquity, which should be avoided for emergency situations. -andy

UA discovery/configuration: none

Solution 1a: Rough location, with service-aware LIS

The location query contains the service URN, so that the LIS can return an appropriate region that matches the service region.

UA configuration: none (if every LIS query contains the service URN)

Advantage: Avoids polygon-intersection in Solution 1.

Disadvantage: UA behavior now differs significantly from the non-hiding case. If the UA determines location ahead of time, it has to query once for each emergency service, greatly increasing the load on the LIS, even if the LIS does not hide location information. It is unclear whether this would have to be done for every service, or just emergency services.

[RLB] Solution 1b. Rough location via LCP

If an LIS returns an access-controlled LbyR, it must also provide a rough LbyV (via the LCP, not via dereference). The LbyV is then used the same as any other location object obtained from the LIS for call routing and verification purposes: It is used in LoST queries, and included (alongside the LbyR) in emergency calls for VSP routing/verification.

Advantages: no changes in UA behavior; no complexity increase for non-hiding LIS; no changes in LoST

Disadvantages: See Solution 1

UA discovery/configuration: none

Solution 2: LoST server does LbyR

The LoST protocol is enhanced to permit/require the LoST server to accept an LbyR and dereference it as part of resolution. The LIS arranges for all LoST servers to be able to dereference to the actual location. The VSP gets the LbyR and sends that to LoST to get the URI which should be the same as the URI it is asked to route towards.

Solution 2a: Trusted LoST server

Same as Solution 2, but a UA located in a hiding ISP can only use an ISP-provided LoST server.
Issue 2a-1 This description is not accurate. Unlike Solution 2, 2a would not require any protocol specification specific to location-hiding. -andy

UA configuration: needs to find the LIS-associated LoST server
Issue 2a-2 The work around LoST discovery needs to be completed. This is not specific to location hiding. -andy

Solution 3: New protocol

A protocol is defined which combines an L7 LCP and a LoST request into one operation. The LIS does the LoST lookup on the actual location and returns an LbyR and the LoST return (URI, dialstring, service boundary...). A new operation in LoST is defined which allows a validation by reverse lookup (query with PSAP URI and service, return either a validation indication or a service boundary).

UA configuration: none, since the L7 return value would presumably then cause the UA not to perform the LoST lookup

The following draft (not submitted officially; it just uses the IETF draft template) describes the approach in more detail: draft-schulzrinne-ecrit-lost-in-held-00.txt: Location Hiding: Carrying LoST exchanges in HELD

-- HannesTschofenig - 02 Jun 2007