draft-ietf-ecrit-location-hiding-req-00.txt   draft-ietf-ecrit-location-hiding-req-01.txt 
ECRIT H. Schulzrinne ECRIT H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Intended status: Informational L. Liess Intended status: Informational L. Liess
Expires: December 19, 2008 Deutsche Telekom Expires: April 15, 2009 Deutsche Telekom
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
B. Stark B. Stark
AT&T AT&T
A. Kuett A. Kuett
Skype Skype
June 17, 2008 October 12, 2008
Location Hiding: Problem Statement and Requirements Location Hiding: Problem Statement and Requirements
draft-ietf-ecrit-location-hiding-req-00.txt draft-ietf-ecrit-location-hiding-req-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 19, 2008. This Internet-Draft will expire on April 15, 2009.
Abstract Abstract
The emergency services architecture developed in the IETF Emergency The emergency services architecture developed in the IETF Emergency
Context Resolution with Internet Technology (ECRIT) working group Context Resolution with Internet Technology (ECRIT) working group
describes an architecture where location information is provided by describes an architecture where location information is provided by
access networks to end points in order to determine the correct dial access networks to end points or VoIP service providers in order to
string and information to route the call to a Public Safety Answering determine the correct dial string and information to route the call
Point (PSAP). For determining the PSAP Uniform Resource Identifier to a Public Safety Answering Point (PSAP). For determining the PSAP
(URI) the usage of the Location-to-Service Translation (LoST) Uniform Resource Identifier (URI) the usage of the Location-to-
Protocol is envisioned. Service Translation (LoST) Protocol is envisioned.
This document explores the architectural impact for the IETF This document explores the architectural impact for the IETF
emergency services architecture for situations where the Internet emergency services architecture for situations where the Internet
Access Provider (IAP) and/or the Internet Service Provider (ISP) are Access Provider (IAP) and/or the Internet Service Provider (ISP) are
only willing to disclose limited or no location information. only willing to disclose limited or no location information.
This document provides a problem statement and lists requirements. This document provides a problem statement and lists requirements.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Emergency Services Architecture . . . . . . . . . . . . . 3 1.1. Emergency Services Architecture . . . . . . . . . . . . . 3
1.2. Location Hiding . . . . . . . . . . . . . . . . . . . . . 3 1.2. Location Hiding . . . . . . . . . . . . . . . . . . . . . 3
1.3. Location by Reference . . . . . . . . . . . . . . . . . . 3 1.3. Location by Reference . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. High-Level Requirements . . . . . . . . . . . . . . . . . 4 3.1. High-Level Requirements . . . . . . . . . . . . . . . . . 4
3.2. Detailed Requirements . . . . . . . . . . . . . . . . . . 5 3.2. Detailed Requirements . . . . . . . . . . . . . . . . . . 5
3.3. Desirable Properties . . . . . . . . . . . . . . . . . . . 6 3.3. Desirable Properties . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 10
1. Introduction 1. Introduction
1.1. Emergency Services Architecture 1.1. Emergency Services Architecture
The emergency services architecture developed in the IETF Emergency The emergency services architecture developed in the IETF Emergency
Context Resolution with Internet Technology (ECRIT) working group, Context Resolution with Internet Technology (ECRIT) working group,
see [I-D.ietf-ecrit-framework], describes an architecture where see [I-D.ietf-ecrit-framework], describes an architecture where
location information is provided by access networks to end points in location information is provided by access networks to end points or
order to determine the correct dial string and information to route VoIP service providers in order to determine the correct dial string
the call to a Public Safety Answering Point (PSAP). The Location-to- and information to route the call to a Public Safety Answering Point
Service Translation (LoST) Protocol [I-D.ietf-ecrit-lost] allows to (PSAP). The Location-to-Service Translation (LoST) Protocol
determine the PSAP Uniform Resource Identifier (URI) for a specific [RFC5222] allows callers and other call-routing entities to determine
geographical location together with a service URI the PSAP Uniform Resource Identifier (URI) for a specific
[I-D.ietf-ecrit-service-urn]. The basic architecture is shown in geographical location together with a service URI [RFC5031]. The
Figure 1 of [I-D.ietf-ecrit-framework] and further detailed in the basic architecture is shown in Figure 1 of [I-D.ietf-ecrit-framework]
message flow in Figure 2 of [I-D.ietf-ecrit-framework]. and further detailed in the message flow in Figure 2 of
[I-D.ietf-ecrit-framework].
For emergency services, location information is needed for two For emergency services, location information is needed in three ways:
different purposes, namely for routing an emergency call to the PSAP 1. Emergency call routing to the PSAP that is responsible for a
that is responsible for a specific geographical region (and also for specific geographical region
requested service, such as police or ambulance) and for dispatch of 2. Dispatch of the emergency personnel to the scene of an accident,
the emergency personell to the scene of an accident, crime or other crime or other types of incidents
types of incidents. 3. Additionally, a VSP may need to verify that an call is indeed an
emergency call and may therefore require location information to
ensure that calls routed to a specific URI point to a PSAP.
It is very important to note that this document only discusses It is very important to note that this document only discusses
location hiding in the context of location information that is need location hiding in the context of location information that is need
for call routing. ISPs have no interest or even legal basis for for call routing. ISPs have no interest or even legal basis for
hiding location information from emergency services personnel. hiding location information from emergency services personnel.
1.2. Location Hiding 1.2. Location Hiding
In some cases, Internet Access Providers (IAPs) and/or the Internet In some cases, location providers (e.g., Internet Access Providers
Service Providers (ISPs) are afraid that allowing users to access (IAPs) and/or the Internet Service Providers (ISPs)) are unwilling to
location information for non-emergency purposes or prior to an provide precise location information to end points or VSPs, as is
emergency call will incur additional server load and thus costs. called for in the above model. The decision to deny location can be
Hence, they do not to disclose precise location information (at the driven by a number of technical and business concerns. Some
quality suitable for dispatch emergency personell by the PSAP providers may perceive a risk that allowing users to access location
operator) or not to disclose any location information. information for non-emergency purposes or prior to an emergency call
will incur additional server load and thus costs. Other providers
In some other cases IAPs and ISPs may not want to make location may not want to make location information available without the
information available without the ability to charge for it. This is ability to charge for it.
a pure business decision.
1.3. Location by Reference 1.3. Location by Reference
The work on the Location Configuration Protocol (LCP) indicated the The work on the Location Configuration Protocol (LCP) indicated the
need to provide the capability to obtain Location-by-References need to provide the capability to obtain Location-by-References
(LbyRs) in addition to Location-by-Value (LbyV) from a Location (LbyRs) in addition to Location-by-Value (LbyV) from a Location
Information Server (LIS). Information Server (LIS).
The LCP problem statement and requirements document can be found in The LCP problem statement and requirements document can be found in
[I-D.ietf-geopriv-l7-lcp-ps]. The requirements for obtaining an LbyR [I-D.ietf-geopriv-l7-lcp-ps]. The requirements for obtaining an LbyR
via the LCP and the corresponding dereferencing step can be found in via the LCP and the corresponding dereferencing step can be found in
[I-D.ietf-geopriv-lbyr-requirements]. [I-D.ietf-geopriv-lbyr-requirements].
HTTP Enabled Location Delivery (HELD), see HTTP Enabled Location Delivery (HELD), see
[I-D.ietf-geopriv-http-location-delivery], is an instantiation of the [I-D.ietf-geopriv-http-location-delivery], is an instantiation of the
LCP concept and allows LbyVs and LbyRs to be requested. LCP concept and allows LbyVs and LbyRs to be requested.
A location reference may already satisfy the requirement for location A location reference may already satisfy the requirement for location
hiding if the PSAP has the appropriate credentials to resolve the hiding if the PSAP has the appropriate credentials to resolve the
reference. This requires a trust relationship between the PSAP and reference. This requires a trust relationship between the PSAP and
the ISP. the ISP. Note that the requirement being met here is for delivery of
location information to the PSAP, not for LoST routing or for
validation at the VSP.
Unfortunately, a location reference is not compatible with LoST, as Unfortunately, a location reference is not compatible with LoST, as
LoST requires an information value rather than a reference. Also, LoST requires an information value rather than a reference. Also,
LoST servers may be operated by the VSP, which may not have a trust LoST servers may be operated by the VSP, which may not have a trust
relationship with the ISP. relationship with the ISP.
This document explores the architectural impact for the current
architecture and lists requirements.
2. Terminology 2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119], with the document are to be interpreted as described in [RFC2119], with the
important qualification that, unless otherwise stated, these terms important qualification that, unless otherwise stated, these terms
apply to the design of an solution supporting location hiding, not apply to the design of an solution supporting location hiding, not
its implementation or application. its implementation or application.
This document reuses terminology from [I-D.ietf-geopriv-l7-lcp-ps]. This document reuses terminology from [I-D.ietf-geopriv-l7-lcp-ps].
3. Requirements 3. Requirements
This section presents requirements.
3.1. High-Level Requirements 3.1. High-Level Requirements
Req-A: There MUST be a way an access network can withhold detailed
Req-A: There SHOULD be a way an access network can withhold detailed
location information from any entity it wishes to, and location information from any entity it wishes to, and
specifically, the endpoint, and a VSP. specifically, the endpoint, and a VSP.
Req-B: The ISP/IAP MUST support the ability of the endpoint or the Req-B: The ISP/IAP MUST support the ability of the endpoint or the
VSP to route emergency calls. VSP to route emergency calls.
Req-C: The VSP MUST be able to validate that a call purported to be Req-C: 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 an emergency call is being routed to a bona fide URI, which is
denoted by being a URI in LoST for the designated emergency denoted by being a URI in LoST for the designated emergency
service. service.
Req-D: Precise location information must be conveyed (either LbyR or Req-D: The PSAP MUST be provided precise location information (by
LbyV) to the PSAP. value) for emergency callers. The endpoint and/or VSP may provide
this information either by value or by reference.
3.2. Detailed Requirements 3.2. Detailed Requirements
Req-1: A business or trust relationship between an ISP and a VSP Req-1: The proposed solution MUST NOT assume a business or trust
MUST NOT be assumed. relationship between the caller's VSP and the caller's ISP.
Req-2: A solution MUST consider deployment scenarios where a VSP is Req-2: A solution MUST consider deployment scenarios where a VSP is
outside the jurisdiction of the PSAP. outside the jurisdiction of the PSAP.
Req-3: The solution MUST offer automated discovery of servers and Req-3: The solution MUST offer automated discovery of servers and
other behavior, i.e., no manual configuration can be assumed. other behavior, i.e., no manual configuration can be assumed.
Req-4: The steps needed by the endpoint for emergency calling SHOULD Req-4: The steps needed by the endpoint for emergency calling SHOULD
be no different when location is withheld vs. when location is not be no different when location is withheld vs. when location is not
withheld. In particular, user agents cannot require additional withheld. In particular, user agents cannot require additional
skipping to change at page 5, line 45 skipping to change at page 6, line 5
Req-6: The solution MUST work if PSAP boundaries have holes. Req-6: The solution MUST work if PSAP boundaries have holes.
Req-7: The solution MUST NOT assume the existence of Emergency Req-7: The solution MUST NOT assume the existence of Emergency
Service Routing Proxies (ESRPs) per country, state and city. Service Routing Proxies (ESRPs) per country, state and city.
Req-8: The solution MUST consider that service boundaries for Req-8: The solution MUST consider that service boundaries for
different emergency services may differ, but they overlap at the different emergency services may differ, but they overlap at the
location of the caller. location of the caller.
Req-9: UAs MUST NOT have to deduce the desired behavior by trial- Req-9: Though the solution MAY add steps to the emergency call
and-error operations, such as LbyR resolutions, fail, as failures routing process described in [framework], these steps MUST NOT
add latency during call setup. The solution MUST NOT significantly increase call setup latency. For example, the
significantly increase call setup latency. revised process MUST NOT include "trial-and-error" operations on
its critical path, such as attempts at LbyR resolutions that may
take time to time out.
Req-10: The solution MUST allow the end host to determine PSAP/ESRP Req-10: The solution MUST allow the end host to determine PSAP/ESRP
URLs prior to the call, for all emergency services. URLs prior to the call, for all emergency services.
Req-11: The solution MUST allow UAs to discover at least their dial Req-11: The solution MUST allow UAs to discover at least their dial
string ahead of the emergency call. string ahead of the emergency call.
Req-12: The solution MUST have minimal impact on UAs. Req-12: The solution MUST have minimal impact on UAs.
Req-13: The solution MUST NOT interfere with the use of LoST for Req-13: The solution MUST NOT interfere with the use of LoST for
skipping to change at page 7, line 24 skipping to change at page 7, line 30
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
7.2. Informative References 7.2. Informative References
[I-D.ietf-geopriv-l7-lcp-ps] [I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-07 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
progress), March 2008. progress), June 2008.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-10 (work in progress), draft-ietf-sip-location-conveyance-10 (work in progress),
February 2008. September 2008.
[I-D.ietf-ecrit-framework] [I-D.ietf-ecrit-framework]
Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling using Internet "Framework for Emergency Calling using Internet
Multimedia", draft-ietf-ecrit-framework-05 (work in Multimedia", draft-ietf-ecrit-framework-06 (work in
progress), February 2008. progress), July 2008.
[I-D.ietf-ecrit-lost] [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
Protocol", draft-ietf-ecrit-lost-10 (work in progress), Protocol", RFC 5222, August 2008.
May 2008.
[I-D.ietf-geopriv-lbyr-requirements] [I-D.ietf-geopriv-lbyr-requirements]
Marshall, R., "Requirements for a Location-by-Reference Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-02 (work Mechanism", draft-ietf-geopriv-lbyr-requirements-03 (work
in progress), February 2008. in progress), July 2008.
[I-D.ietf-ecrit-service-urn] [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031,
Emergency and Other Well-Known Services", January 2008.
draft-ietf-ecrit-service-urn-07 (work in progress),
August 2007.
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)", "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-07 (work in draft-ietf-geopriv-http-location-delivery-09 (work in
progress), April 2008. progress), September 2008.
Authors' Addresses Authors' Addresses
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
 End of changes. 25 change blocks. 
71 lines changed or deleted 68 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/