ECRIT H. Tschofenig Internet-Draft Nokia Siemens Networks Intended status: Standards Track H. Schulzrinne Expires: December 4, 2007 Columbia University June 2, 2007 Location Hiding: Carrying LoST exchanges in HELD draft-schulzrinne-ecrit-lost-in-held-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 4, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Location hiding in the context of emergency services refers to the desire of a network operator not to disclose precise location information for free to the end point. This concept was discussed in the ECRIT working group as part of the overall architecture and many different proposals have been suggested. After some time a stronger preference for two proposals was expressed by working group members. This document describes one of the two proposals, namely the ability Tschofenig & Schulzrinne Expires December 4, 2007 [Page 1] Internet-Draft Carrying LoST exchanges in HELD June 2007 to carry Location-to-Service Translation (LoST) messages in the HTTP Enabled Location Delivery (HELD) protocol, in more detail. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. High-Level Requirements . . . . . . . . . . . . . . . . . 4 3.2. Detailed Requirements . . . . . . . . . . . . . . . . . . 4 3.3. Desirable Properties . . . . . . . . . . . . . . . . . . . 5 4. Deployment Scenarios for Location Hiding . . . . . . . . . . . 5 5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Tschofenig & Schulzrinne Expires December 4, 2007 [Page 2] Internet-Draft Carrying LoST exchanges in HELD June 2007 1. Introduction Location hiding refers to the desire of a network operator not to disclose precise location information for free to the end point. This concept was discussed in the ECRIT working group as part of the overall architecture and many different proposals have been suggested. After some time a stronger preference for two proposals was expressed by working group members. This document describes one of the two proposals, namely the ability to carry Location-to-Service Translation (LoST) [I-D.ietf-ecrit-lost] messages in the HTTP Enabled Location Delivery (HELD)[I-D.winterbottom-geopriv-held-sighting] protocol, in more detail. The alternative solution that received also a lot of attention is described at http://www.tschofenig.com/ twiki/bin/view/EmergencyServices/LocationHiding and requires only a minor enhancement to the LoST protocol to return a polygon instead of a point (and hence there are not too many extensions to define apart from an additional location profile in LoST and a description of the architectural considerations in [I-D.ietf-ecrit-framework]. The intention of this document is to restart the discussions in order to make progress on the topic of location hiding for emergency services. It also shows that this proposal has a few drawbacks although it might seem to be quite obviously. More information about the proposed solutions can be found here: o http://www.tschofenig.com/twiki/bin/view/EmergencyServices/ LocationHiding o http://www1.ietf.org/mail-archive/web/ecrit/current/msg03482.html Document is structured as follows: Section 3 describes requirements, Section 4 shows two scenarios, Section 5 illustrates the necessary extensions and Section 8 concludes the document. 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 RFC 2119 [RFC2119]. This document reuses terminology from [I-D.ietf-geopriv-l7-lcp-ps]. 3. Requirements This section presents the requirements that guided the work on the solution space. Tschofenig & Schulzrinne Expires December 4, 2007 [Page 3] Internet-Draft Carrying LoST exchanges in HELD June 2007 3.1. 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 3.2. 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. Tschofenig & Schulzrinne Expires December 4, 2007 [Page 4] Internet-Draft Carrying LoST exchanges in HELD June 2007 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. 3.3. Desirable Properties 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 4. Deployment Scenarios for Location Hiding Two scenarios play a role in the context of location hiding when LoST is carried via HELD. Figure 1 shows the scenario where the ISP/ASP is independent from the VSP. Figure 2 focuses on a model where a VSP is also colocated with the ISP/ASP, i.e., all functions are provided by the same operator. Tschofenig & Schulzrinne Expires December 4, 2007 [Page 5] Internet-Draft Carrying LoST exchanges in HELD June 2007 With the scenario shown Figure 1 the end host interacts with the LCS to obtain location information and attaches (emergency) service identifiers. In response the LCS provides an LbyR, a PSAP URI and additional information from a LoST response. This exchange is shown in message (1). Then, when the user initiates an emergency call it forwards the SIP message (the LbyR, the LbyV, PSAP URI, service URI) using the extensions described in [I-D.ietf-sip-location-conveyance]. This exchange is shown in message (2). When the SIP proxy in the VSP's network receives the emergency call it resolves the LbyR in message (3) in order to obtain location information with a granularity that is sufficient for location based routing. In order to verify that the PSAP URI is indeed belonging to a PSAP or an ESRP in a PSAP operator network it needs to perform a LoST lookup. Without this additional check a malicious user could bypass charging procedures at the VSP by putting an arbirary URI instead of a PSAP URI. Alternatively, if the VSP has some form of trust relationship with the ISP/ASP then the LoST lookup of step (4) could be replaced with an authorization check whereby the SIP proxy verifies that it is indeed contacting an authorized LCS (from a known ISP/VSP). Afterwards the emergency call is forwarded towards the PSAP operator. Tschofenig & Schulzrinne Expires December 4, 2007 [Page 6] Internet-Draft Carrying LoST exchanges in HELD June 2007 +----------+ | LoST | (4) | <-------+ +----------+ | | | ^ +---------------------------+ +-------|---|-------+ | ISP/ASP | | VSP | | | | | | v |(5) | |+----------+ +----------+ | | +----------+ | || LoST | | LCS |<=====>| SIP | | || <----> | (3) | Proxy | | |+-----^----+ +----^-----+ | | +----------+ | | | | | | ^ | | +------------+ | | | | | | (1) | | | | +------+--------------------+ +-----------+-------+ | | v | +------+ (2) | | End |<-----------------------------+ | Host | +------+ Figure 1: Independent VSP Scenario The scenario shown in Figure 2 is simpler from a message exchange point of view but requires the VSP to deploy SIP proxies in the access network. Note that there is still an ongoing discussion about "unauthenticated emergency calls" whereby the emergency callers device lost the credentials for the VSP (or all configuration of the VSP) and therefore has to use a SIP proxy in the access network in order to get access to emergency services. With message (1) the end host initiates an emergency service. We assume that the visited (emergency) service number is known to the end host (althought this aspect raises a couple of issues) or occurs at the SIP proxy. Note that the end host may have location available locally (e.g., obtained via GPS) but there is, generally, not reason for the network operator with a desire to hide location information to initiate a protocol interaction to either convey LbyR or LbyV to the end host for emergency services. When the SIP proxy receives the emergency call then it interacts with a LCS, potentially using a variety of ways that largely depend on the network architecture. The SIP proxy may contact a LoST server, the LCS may contact a LoST server or emergency call routing functionality Tschofenig & Schulzrinne Expires December 4, 2007 [Page 7] Internet-Draft Carrying LoST exchanges in HELD June 2007 is hardwired into the SIP proxy. In any case, the PSAP URI or an ESRP in the PSAP operator network has to be identified. Afterwards the emergency call is forwarded towards the PSAP operator, see message (3). ^ +--------------------------------------|-----------+ | ISP/ASP/VSP | | | | (3) | | +----------+ +----------+ (2) +----------+ | | | LoST | | LCS |<=====>| SIP | | | | <---> | +---> Proxy | | | +-----^----+ +----------+ | +----------+ | | | | ^ | | +---------------------+ | | | (2) | | +--------------------------------------+-----------+ | | +------+ (1) | | End |<-------------------------+ | Host | +------+ Figure 2: ISP/ASP/VSP Colocated Environment 5. Protocol Extensions The extension requires a HELD request to be enhanced with the Service URN parameter. The extension also requires a HELD response to be enhanced with the LoST . An example mapping might have the following structure: Tschofenig & Schulzrinne Expires December 4, 2007 [Page 8] Internet-Draft Carrying LoST exchanges in HELD June 2007 New York City Police Department urn:service:sos.police 37.775 -122.4194 37.555 -122.4194 37.555 -122.4264 37.775 -122.4264 37.775 -122.4194 sip:nypd@example.com xmpp:nypd@example.com 911 It might be necessary to include the listServices/ listServicesResponse and listServicesByLocation and listServicesByLocationResponse into LoST. Furthermore, since are likely networks that do not want to hide location information it might be beneficial to offer the ability to convey a service boundary in the element. Since the service boundary may be provided as a reference the getServiceBoundary/getServiceBoundaryResponse would need to be incorporated into HELD as well. 6. XML Schema Since there are too many design decisions open it does not make sense to provide an XML schema with this version of the document. 7. Security Considerations This document does not raise additional security consideration beyond those mentioned in [I-D.ietf-geopriv-l7-lcp-ps], [I-D.winterbottom-geopriv-held-sighting], [I-D.ietf-ecrit-lost]. Tschofenig & Schulzrinne Expires December 4, 2007 [Page 9] Internet-Draft Carrying LoST exchanges in HELD June 2007 8. Conclusion While it seems that this approach is pretty obvious it raises a number of issues, namely o If the abilility to piggy-back LoST on top of HELD is provided then shouldn't there be a way to convey PSAP URIs (and other information) in DHCP, link layer protocols as well. An example of this approach can be found with [I-D.polk-dhc-ecrit-uri-psap-esrp]. o HELD seems to get overloaded and seems to be moving to a somewhat complex protocol. One of the initial claims was that it would be simpler than similar approach investigated by other SDOs. There is the risk that simplicity vanishes with every new extension. o The entire architectural picture of location hiding has not had sufficient discussion. Particularly the relationship between the deployment scenarios shown in Figure 1 and Figure 2 is still up for discussion. o Figure 1 and Figure 2 hint that extensions to HELD for LoST usage may not even be necessary or useful. o This approach treats networks that provide location hiding differently than other networks. From an architectural point of view this may introduce failure cases. When a solution for unauthenticated network access is added then another solution direction is added that introduces even more failure cases since it is again handling emergency services differently Despite the list of open issues this document is meant to re-start the discussions regarding this subject again in order to make progress. 9. Contributors We would like to thank Andrew Newton, James Winterbottom, Brian Rosen, Richard Barnes, Marc Linsner, Barbara Stark, Laura Liess, Andres Kuett, and Ted Hardie for their input to the location hiding discussion. 10. Acknowledgments Add your name here. 11. References Tschofenig & Schulzrinne Expires December 4, 2007 [Page 10] Internet-Draft Carrying LoST exchanges in HELD June 2007 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [I-D.winterbottom-geopriv-held-sighting] Winterbottom, J., "HTTP Enabled Location Delivery (HELD) - Sighting", draft-winterbottom-geopriv-held-sighting-00 (work in progress), February 2006. [I-D.ietf-ecrit-lost] Hardie, T., "LoST: A Location-to-Service Translation Protocol", draft-ietf-ecrit-lost-05 (work in progress), March 2007. 11.2. Informative References [I-D.polk-dhc-ecrit-uri-psap-esrp] Polk, J., "A Dynamic Host Configuration Protocol Option for Requesting and Receiving a Uniform Resource Identifier of a Public Safety Answering Point or Emergency services Routing Proxy", draft-polk-dhc-ecrit-uri-psap-esrp-00 (work in progress), June 2006. [I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", draft-ietf-geopriv-l7-lcp-ps-02 (work in progress), April 2007. [I-D.ietf-sip-location-conveyance] Polk, J. and B. Rosen, "Session Initiation Protocol Location Conveyance", draft-ietf-sip-location-conveyance-07 (work in progress), February 2007. [I-D.ietf-ecrit-framework] Rosen, B., "Framework for Emergency Calling in Internet Multimedia", draft-ietf-ecrit-framework-01 (work in progress), March 2007. Tschofenig & Schulzrinne Expires December 4, 2007 [Page 11] Internet-Draft Carrying LoST exchanges in HELD June 2007 Authors' Addresses Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.com Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 Email: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu Tschofenig & Schulzrinne Expires December 4, 2007 [Page 12] Internet-Draft Carrying LoST exchanges in HELD June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Tschofenig & Schulzrinne Expires December 4, 2007 [Page 13]