draft-ietf-ecrit-location-hiding-req-02.txt   draft-ietf-ecrit-location-hiding-req-03.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: January 14, 2010 Deutsche Telekom Expires: August 25, 2010 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
July 13, 2009 February 21, 2010
Location Hiding: Problem Statement and Requirements Location Hiding: Problem Statement and Requirements
draft-ietf-ecrit-location-hiding-req-02.txt draft-ietf-ecrit-location-hiding-req-03.txt
Abstract
The emergency services architecture developed in the IETF Emergency
Context Resolution with Internet Technology (ECRIT) working group
describes an architecture where location information is provided by
access networks to end points or VoIP service providers in order to
determine the correct dial string and information to route the call
to a Public Safety Answering Point (PSAP). For determining the PSAP
Uniform Resource Identifier (URI) the usage of the Location-to-
Service Translation (LoST) Protocol is envisioned.
This document provides a problem statement and lists requirements for
situations where the Internet Access Provider (IAP) and/or the
Internet Service Provider (ISP) are only willing to disclose limited
or no location information.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 2, line 9
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 January 14, 2010. This Internet-Draft will expire on August 25, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The emergency services architecture developed in the IETF Emergency described in the BSD License.
Context Resolution with Internet Technology (ECRIT) working group
describes an architecture where location information is provided by
access networks to end points or VoIP service providers in order to
determine the correct dial string and information to route the call
to a Public Safety Answering Point (PSAP). For determining the PSAP
Uniform Resource Identifier (URI) the usage of the Location-to-
Service Translation (LoST) Protocol is envisioned.
This document provides a problem statement and lists requirements for This document may contain material from IETF Documents or IETF
situations where the Internet Access Provider (IAP) and/or the Contributions published or made publicly available before November
Internet Service Provider (ISP) are only willing to disclose limited 10, 2008. The person(s) controlling the copyright in some of this
or no location information. material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Emergency Services Architecture . . . . . . . . . . . . . . 4 1.1. Emergency Services Architecture . . . . . . . . . . . . . . 4
1.2. Location Hiding . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Location Hiding . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Location by Reference . . . . . . . . . . . . . . . . . . . 5 1.3. Location by Reference . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. High-Level Requirements . . . . . . . . . . . . . . . . . . 6 3.1. High-Level Requirements . . . . . . . . . . . . . . . . . . 6
3.2. Detailed Requirements . . . . . . . . . . . . . . . . . . . 6 3.2. Detailed Requirements . . . . . . . . . . . . . . . . . . . 6
3.3. Desirable Properties . . . . . . . . . . . . . . . . . . . 7 3.3. Miscellaneous Properties . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
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 or location information is provided by access networks to end points or
skipping to change at page 6, line 42 skipping to change at page 6, line 42
3.2. Detailed Requirements 3.2. Detailed Requirements
Req-1: The proposed solution MUST NOT assume a business or trust Req-1: The proposed solution MUST NOT assume a business or trust
relationship between the caller's VSP and the caller's ISP. relationship between the caller's VSP and the caller's ISP.
Req-2: A solution MUST consider deployment scenarios where a VSP Req-2: A solution MUST consider deployment scenarios where a VSP
does not operate in the same jurisdiction as the PSAP. does not operate in the same jurisdiction as 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. and other necessary configuration information. 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
configuration to discover which particular environment (hiding or configuration to discover which particular environment (hiding or
no hiding) they find themselves in. no hiding) they find themselves in.
Req-5: The solution SHOULD work without the ISP/IAP having to Req-5: The solution SHOULD work without the ISP/IAP having to
support SIP and without the need to utilize SIP between the support SIP and without the need to utilize SIP between the
endpoint and the VSP. endpoint and the VSP.
skipping to change at page 7, line 45 skipping to change at page 7, line 45
different emergency services procedures compared to the procedure different emergency services procedures compared to the procedure
of dealing with emergency services where no location hiding is of dealing with emergency services where no location hiding is
applied. applied.
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
non-emergency services. non-emergency services.
Req-14: The solution MUST allow emergency calls to reach an IP-to- Req-14: The solution MUST allow emergency calls to reach an IP-to-
PSTN gateway rather than the IP-based PSAP directly. PSTN gateway rather than the IP-based PSAP directly.
3.3. Desirable Properties 3.3. Miscellaneous Properties
o The solution MUST NOT shift effort (externality), i.e., the o The solution MUST NOT shift effort (externality), i.e., the
convenience of the location-hiding ISP MUST NOT impose a burden on convenience of the location-hiding ISP MUST NOT impose a burden on
user agents or non-hiding ISPs/IAPs and SHOULD NOT impose a burden user agents or non-hiding ISPs/IAPs and SHOULD NOT impose a burden
on VSPs. on VSPs.
o The solution SHOULD minimize the impact on LoST, SIP conveyance o The solution SHOULD minimize the impact on LoST, SIP conveyance
[I-D.ietf-sip-location-conveyance] and DHCP. [I-D.ietf-sipcore-location-conveyance] and DHCP.
o The solution SHOULD NOT break by the presence of NATs and SHOULD o The solution SHOULD NOT break in the presence of NATs and SHOULD
consider the presence of legacy devices, as described in consider the presence of legacy devices, as described in
[I-D.ietf-geopriv-l7-lcp-ps]. [I-D.ietf-geopriv-l7-lcp-ps].
4. IANA Considerations 4. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
5. Security Considerations 5. Security Considerations
This document does not raise additional security consideration beyond This document does not raise additional security consideration beyond
skipping to change at page 8, line 35 skipping to change at page 8, line 35
no particular order) for their contributions: no particular order) for their contributions:
o Andrew Newton (andy@hxr.us) o Andrew Newton (andy@hxr.us)
o James Winterbottom (James.Winterbottom@andrew.com) o James Winterbottom (James.Winterbottom@andrew.com)
o Brian Rosen (br@brianrosen.net) o Brian Rosen (br@brianrosen.net)
o Richard Barnes (rbarnes@bbn.com) o Richard Barnes (rbarnes@bbn.com)
o Marc Linsner (mlinsner@cisco.com) o Marc Linsner (mlinsner@cisco.com)
o Ted Hardie (hardie@qualcomm.com) o Ted Hardie (hardie@qualcomm.com)
The authors would also like to thank Ben Campbell for his Gen-ART The authors would also like to thank Ben Campbell for his Gen-ART
review. review. Additionally, we would like to thank Jari Arkko, Alexey
Melnikov, Tim Polk, and Dan Romascanu for their IESG review.
7. References 7. References
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
[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-09 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in
progress), February 2009. progress), July 2009.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sipcore-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-13 (work in progress), draft-ietf-sipcore-location-conveyance-02 (work in
March 2009. progress), February 2010.
[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-09 (work in Multimedia", draft-ietf-ecrit-framework-10 (work in
progress), March 2009. progress), July 2009.
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
Shanmugam, "Security Threats and Requirements for Shanmugam, "Security Threats and Requirements for
Emergency Call Marking and Mapping", RFC 5069, Emergency Call Marking and Mapping", RFC 5069,
January 2008. January 2008.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008. Protocol", RFC 5222, August 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-07 (work Mechanism", draft-ietf-geopriv-lbyr-requirements-09 (work
in progress), February 2009. in progress), November 2009.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031, Emergency and Other Well-Known Services", RFC 5031,
January 2008. January 2008.
[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-15 (work in draft-ietf-geopriv-http-location-delivery-16 (work in
progress), June 2009. progress), August 2009.
[I-D.ietf-ecrit-specifying-holes] [I-D.ietf-ecrit-specifying-holes]
Winterbottom, J. and M. Thomson, "Specifying Holes in LoST Winterbottom, J. and M. Thomson, "Specifying Holes in LoST
Service Boundaries", draft-ietf-ecrit-specifying-holes-01 Service Boundaries", draft-ietf-ecrit-specifying-holes-01
(work in progress), October 2008. (work in progress), October 2008.
7.2. Informative References
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
Phone: +1 212 939 7004 Phone: +1 212 939 7004
 End of changes. 22 change blocks. 
44 lines changed or deleted 61 lines changed or added

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