1. Location Hiding: Problem Statement, Requirements, (and Solutions?) Richard Barnes IETF 71, Philadelphia, PA, USA

2. Basic facts of ECRIT Three steps in establishing an emergency call:  Fetch endpoint location  Query LoST with location to get PSAP URI(s)‏  Direct call to PSAP  (Verify that call is an emergency call)‏ This process involves four entities  Endpoint  Voice Service Provider (SIP Proxy/proxies)‏  Location Provider  LoST mapping infrastructure

3. Problem statement The success of an emergency call depends on these entities giving each other information  LP gives location to endpoint or proxy  LoST gives mappings to endpoint or proxy  Proxies route invite to PSAP Use case: The LP is not willing or able to provide precise location information an endpoint or proxy  How does endpoint/proxy get LoST mappings?  How can a proxy recognize emergency calls?

4. Basic functional requirements Support for LoST routing: The entity that performs LoST routing MUST have access LoST mappings, whether provided by LoST queries or directly Support for proxy verification: A SIP proxy MUST be able to distinguish emergency calls from non-emergency calls Support for dispatch: Precise location MUST be available to the PSAP(s) that receive the emergency call

5. Two other essential requirements MUST NOT assume any trust relationship between LP and endpoint/VSP SHOULD minimize protocol and processing differences from the case where access to location is not constrained

6. Paths forward Do nothing Describe a solution; some candidates:  Rough Location: Provide imprecise location to endpoint / VSP  LbyR in LoST: Use a LoST resolver that is authorized to access location information  LP Proxy: Emergency calls are routed through a proxy operated by the location provider  LoST in LCP: Provide LoST mappings directly, without a LoST query

7. Option 1: Do Nothing This may not be a matter for IETF or ECRIT Location hiding can be supported without protocol or processing changes  “Rough location” solution implements this No normative documents are necessary  Location providers can make local decisions to support this use case  Still might want to provide informational guidance

8. Option 2: Rough Location Location Provider provides the endpoint/proxy with a location that is  Precise enough that it identifies LoST mappings  Not precise enough to be useful for non-emergency services Advantages  No protocol changes  Burden of hiding is on the location provider Disadvantages  LP must determine imprecise location

9. Option 3: LbyR in LoST Endpoint / proxy uses a LoST resolver that is authorized to access endpoint location LoST server obtains location to determine mappings Advantages  More difficult for unauthorized parties to get location Disadvantages  Added complexity in LoST  Requires discovery mechanism  Constrains which LoST resolver can be used

10. Option 4: Location Provider Proxy Call is routed through a proxy that has access to location (a proxy associated with the LP)‏ Advantages  Similar a proxy-routed call without location hiding  All routing decisions are local to the LP Disadvantages  Requires mechanism for proxy/endpoint to find LP proxy  Different routing process from normal calls

11. Option 5: LoST in LCP Location Information Server (LIS) that provides location (by reference) also provides LoST mappings for emergency services Advantages  Removes a step from the call (no separate LoST)‏  Doesn't require separate discovery Disadvantages  Proxy can't do LoST routing on behalf of endpoint  Additional complexity in LIS and location protocol  Impacts GEOPRIV as well

12. Questions Is this a problem that ECRIT wants to address? Choice of solutions:  Do Nothing  Rough Location  LbyR in LoST  Location Provider Proxy  LoST in LCP  Others?

13. References http://www.tschofenig.priv.at/twiki/bin/view/Eme rgencyServices/LocationHiding draft-schulzrinne-ecrit-location-hiding-req-00 draft-barnes-ecrit-rough-location-00