idnits 2.17.1 draft-ietf-ecrit-location-hiding-req-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2010) is 5178 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-sipcore-location-conveyance-02 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-10 == Outdated reference: A later version (-03) exists of draft-ietf-ecrit-specifying-holes-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT H. Schulzrinne 3 Internet-Draft Columbia University 4 Intended status: Informational L. Liess 5 Expires: August 25, 2010 Deutsche Telekom 6 H. Tschofenig 7 Nokia Siemens Networks 8 B. Stark 9 AT&T 10 A. Kuett 11 Skype 12 February 21, 2010 14 Location Hiding: Problem Statement and Requirements 15 draft-ietf-ecrit-location-hiding-req-04.txt 17 Abstract 19 The emergency services architecture developed in the IETF Emergency 20 Context Resolution with Internet Technology (ECRIT) working group 21 describes an architecture where location information is provided by 22 access networks to end points or VoIP service providers in order to 23 determine the correct dial string and information to route the call 24 to a Public Safety Answering Point (PSAP). For determining the PSAP 25 Uniform Resource Identifier (URI) the usage of the Location-to- 26 Service Translation (LoST) Protocol is envisioned. 28 This document provides a problem statement and lists requirements for 29 situations where the Internet Access Provider (IAP) and/or the 30 Internet Service Provider (ISP) are only willing to disclose limited 31 or no location information. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt. 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 This Internet-Draft will expire on August 25, 2010. 56 Copyright Notice 58 Copyright (c) 2010 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the BSD License. 71 This document may contain material from IETF Documents or IETF 72 Contributions published or made publicly available before November 73 10, 2008. The person(s) controlling the copyright in some of this 74 material may not have granted the IETF Trust the right to allow 75 modifications of such material outside the IETF Standards Process. 76 Without obtaining an adequate license from the person(s) controlling 77 the copyright in such materials, this document may not be modified 78 outside the IETF Standards Process, and derivative works of it may 79 not be created outside the IETF Standards Process, except to format 80 it for publication as an RFC or to translate it into languages other 81 than English. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 1.1. Emergency Services Architecture . . . . . . . . . . . . . . 4 87 1.2. Location Hiding . . . . . . . . . . . . . . . . . . . . . . 4 88 1.3. Location by Reference . . . . . . . . . . . . . . . . . . . 5 89 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 90 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 91 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 93 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 94 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 95 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 96 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 99 1. Introduction 101 1.1. Emergency Services Architecture 103 The emergency services architecture developed in the IETF Emergency 104 Context Resolution with Internet Technology (ECRIT) working group, 105 see [I-D.ietf-ecrit-framework], describes an architecture where 106 location information is provided by access networks to end points or 107 VoIP service providers in order to determine the correct dial string 108 and information to route the call to a Public Safety Answering Point 109 (PSAP). The Location-to-Service Translation (LoST) Protocol 110 [RFC5222] allows callers and other call-routing entities to determine 111 the PSAP Uniform Resource Identifier (URI) for a specific 112 geographical location together with a service URI [RFC5031]. The 113 basic architecture is shown in Figure 1 of [I-D.ietf-ecrit-framework] 114 and further detailed in the message flow in Figure 2 of 115 [I-D.ietf-ecrit-framework]. 117 For emergency services, location information is needed in three ways: 118 1. Emergency call routing to the PSAP that is responsible for a 119 specific geographical region 120 2. Dispatch of the emergency personnel to the scene of an accident, 121 crime or other types of incidents 122 3. Additionally, a Voice Service Provider (VSP) may need to verify 123 that an call is indeed an emergency call and may therefore 124 require location information to ensure that calls routed to a 125 specific URI point to a PSAP. 127 This document focuses on item (1) and item (3). Providing location 128 information by the ISP to the PSAP and to the emergency personnel are 129 typically legal obligations covered by regulatory frameworks. 131 1.2. Location Hiding 133 Internet Access Providers (IAPs) and Internet Service Providers 134 (ISPs)) typically have little incentives to provide location 135 information to end hosts or independent VSPs (without monetary 136 compensation) for any purpose, including for emergency call routing. 137 The decision to deny disclosure of location information can be driven 138 by a number of technical and business concerns. Some providers may 139 perceive a risk that allowing users to access location information 140 for non-emergency purposes or prior to an emergency call will incur 141 additional server load and thus costs. Other providers may not want 142 to make location information available without the ability to charge 143 for it. Yet others fear problems with regard to privacy when 144 disclosing location information to potentially unknown third parties. 146 1.3. Location by Reference 148 The work on the Location Configuration Protocol (LCP) indicated the 149 need to provide the capability to obtain Location-by-References 150 (LbyRs) in addition to Location-by-Value (LbyV) from a Location 151 Information Server (LIS). 153 The LCP problem statement and requirements document can be found in 154 [I-D.ietf-geopriv-l7-lcp-ps]. The requirements for obtaining an LbyR 155 via the LCP and the corresponding dereferencing step can be found in 156 [I-D.ietf-geopriv-lbyr-requirements]. 158 HTTP Enabled Location Delivery (HELD), see 159 [I-D.ietf-geopriv-http-location-delivery], is an instantiation of the 160 LCP concept and allows LbyVs and LbyRs to be requested. 162 A location reference may already satisfy the requirement for location 163 hiding if the PSAP has the appropriate credentials to resolve the 164 reference. These credentials allow the ISP/IAP to authenticate and 165 to authorize the party that would like to request location 166 information. The policy to obtain these credentials allows ISPs/IAPs 167 to put constraints under which these credentials are handed out. 168 ISP/IAPs ideally might want to engage in a business relationship with 169 the VSP to receive a financial compensation for the service they 170 provide. On the Internet the number of VSPs is potentially large and 171 the VSPs would not want to enter a business contract with potentially 172 every ISP/IAP worldwide. The number of potential contracts between 173 ISPs/IAPs and PSAPs is, however, relatively small as they typically 174 need to have a local relationship as PSAPs provide their emergency 175 services support in a certain geographical region for which certain 176 ISPs/IAPs have networks deployed. 178 Note that the requirement being met here is for delivery of location 179 information to the PSAP, not for LoST routing or for validation at 180 the VSP. Another obstacle when it comes to the usage of location 181 reference for location-based routing from a technical point of view 182 is that a location reference cannot be used as input to LoST 183 [RFC5222], as LoST requires location per value rather than a 184 reference. Also, LoST servers may be operated by independent 185 parties, including VSPs, which again may not be able to resolve the 186 reference to location by value. (Note that LoST is a protocol used 187 for determining the location-appropriate PSAP based on location 188 information and a Service URN [RFC5031]. 190 2. Terminology 192 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119], with the 195 important qualification that, unless otherwise stated, these terms 196 apply to the design of an solution supporting location hiding, not 197 its implementation or application. 199 This document reuses terminology from [I-D.ietf-geopriv-l7-lcp-ps]. 201 3. Requirements 203 Req-1: There MUST be a way for the ISP/IAP to withhold precise 204 location information from the endpoint and from the VSP. 206 Req-2: The ISP/IAP MUST support the ability of the endpoint or the 207 VSP to route emergency calls. 209 Req-3: The VSP MUST be able to validate that a call purported to be 210 an emergency call is being routed to a bona fide URI, which is 211 denoted by being a URI in LoST for the designated emergency 212 service. This requirement is provided to deal with potential 213 security problems described in Section 5.1 of [RFC5069]. 215 Req-4: The PSAP MUST receive precise location information (by value) 216 about emergency callers. As such, any solution MUST be able to 217 provide location information to the PSAP even while withholding it 218 from the emergency caller. 219 Req-5: The proposed solution MUST NOT assume a business or trust 220 relationship between the caller's VSP and the caller's ISP. 222 Req-6: A solution MUST consider deployment scenarios where a VSP 223 does not operate in the same jurisdiction as the PSAP. 225 Req-7: The solution MUST offer automated discovery of servers and 226 and other necessary configuration information. No manual 227 configuration can be assumed. 229 Req-8: The steps needed by the endpoint for emergency calling SHOULD 230 be no different when location is withheld vs. when location is not 231 withheld. In particular, user agents cannot require additional 232 configuration to discover which particular environment (hiding or 233 no hiding) they find themselves in. 235 Req-9: The solution SHOULD work without the ISP/IAP having to 236 support SIP and without the need to utilize SIP between the 237 endpoint and the VSP. 239 Req-10: The solution MUST work if PSAP boundaries have holes. (For 240 a discussion about holes in PSAP boundaries and their encoding the 241 reader is referred to [I-D.ietf-ecrit-specifying-holes].) 243 Req-11: The solution MUST NOT assume the existence of Emergency 244 Service Routing Proxies (ESRPs) per country, state and city. 246 Req-12: The solution MUST consider that service boundaries for 247 different emergency services may differ, but they overlap at the 248 location of the caller. 250 Req-13: Though the solution MAY add steps to the emergency call 251 routing process described in [I-D.ietf-ecrit-framework], these 252 steps MUST NOT significantly increase call setup latency. For 253 example, the revised process MUST NOT include "trial-and-error" 254 operations on its critical path, such as attempts at LbyR 255 resolutions that may take time to time out. 257 Req-14: The solution MUST allow the end host to determine PSAP/ESRP 258 URLs prior to the call, for all emergency services. 260 Req-15: The solution MUST allow UAs to discover at least their dial 261 string ahead of the emergency call. 263 Req-16: The solution MUST have minimal impact on UAs, i.e., a 264 solution is preferred if it does not require an substantially 265 different emergency services procedures compared to the procedure 266 of dealing with emergency services where no location hiding is 267 applied. 269 Req-17: The solution MUST NOT interfere with the use of LoST for 270 non-emergency services. 272 Req-18: The solution MUST allow emergency calls to reach an IP-to- 273 PSTN gateway rather than the IP-based PSAP directly. 275 Req-19: The solution MUST NOT shift effort (externality), i.e., the 276 convenience of the location-hiding ISP MUST NOT impose a burden on 277 user agents or non-hiding ISPs/IAPs and SHOULD NOT impose a burden 278 on VSPs. 280 Req-20: The solution SHOULD minimize the impact on LoST, SIP 281 conveyance [I-D.ietf-sipcore-location-conveyance] and DHCP. 283 Req-21: The solution SHOULD NOT break in the presence of NATs and 284 SHOULD consider the presence of legacy devices, as described in 285 [I-D.ietf-geopriv-l7-lcp-ps]. 287 4. IANA Considerations 289 This document does not require actions by IANA. 291 5. Security Considerations 293 This document does not raise additional security consideration beyond 294 those mentioned in [I-D.ietf-geopriv-l7-lcp-ps] and discussed in this 295 document. 297 6. Acknowledgments 299 We would like to thank the following ECRIT working group members (in 300 no particular order) for their contributions: 302 o Andrew Newton (andy@hxr.us) 303 o James Winterbottom (James.Winterbottom@andrew.com) 304 o Brian Rosen (br@brianrosen.net) 305 o Richard Barnes (rbarnes@bbn.com) 306 o Marc Linsner (mlinsner@cisco.com) 307 o Ted Hardie (hardie@qualcomm.com) 309 The authors would also like to thank Ben Campbell for his Gen-ART 310 review. Additionally, we would like to thank Jari Arkko, Alexey 311 Melnikov, Tim Polk, and Dan Romascanu for their IESG review. 313 7. References 315 7.1. Normative References 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", March 1997. 320 [I-D.ietf-geopriv-l7-lcp-ps] 321 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 322 Location Configuration Protocol; Problem Statement and 323 Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in 324 progress), July 2009. 326 [I-D.ietf-sipcore-location-conveyance] 327 Polk, J. and B. Rosen, "Location Conveyance for the 328 Session Initiation Protocol", 329 draft-ietf-sipcore-location-conveyance-02 (work in 330 progress), February 2010. 332 [I-D.ietf-ecrit-framework] 333 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 334 "Framework for Emergency Calling using Internet 335 Multimedia", draft-ietf-ecrit-framework-10 (work in 336 progress), July 2009. 338 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 339 Shanmugam, "Security Threats and Requirements for 340 Emergency Call Marking and Mapping", RFC 5069, 341 January 2008. 343 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 344 Tschofenig, "LoST: A Location-to-Service Translation 345 Protocol", RFC 5222, August 2008. 347 [I-D.ietf-geopriv-lbyr-requirements] 348 Marshall, R., "Requirements for a Location-by-Reference 349 Mechanism", draft-ietf-geopriv-lbyr-requirements-09 (work 350 in progress), November 2009. 352 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 353 Emergency and Other Well-Known Services", RFC 5031, 354 January 2008. 356 [I-D.ietf-geopriv-http-location-delivery] 357 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 358 "HTTP Enabled Location Delivery (HELD)", 359 draft-ietf-geopriv-http-location-delivery-16 (work in 360 progress), August 2009. 362 [I-D.ietf-ecrit-specifying-holes] 363 Winterbottom, J. and M. Thomson, "Specifying Holes in LoST 364 Service Boundaries", draft-ietf-ecrit-specifying-holes-01 365 (work in progress), October 2008. 367 7.2. Informative References 368 Authors' Addresses 370 Henning Schulzrinne 371 Columbia University 372 Department of Computer Science 373 450 Computer Science Building 374 New York, NY 10027 375 US 377 Phone: +1 212 939 7004 378 Email: hgs+ecrit@cs.columbia.edu 379 URI: http://www.cs.columbia.edu 381 Laura Liess 382 Deutsche Telekom Networks 383 Deutsche Telekom Allee 7 384 Darmstadt, Hessen 64295 385 Germany 387 Phone: 388 Email: L.Liess@telekom.de 389 URI: http://www.telekom.de 391 Hannes Tschofenig 392 Nokia Siemens Networks 393 Linnoitustie 6 394 Espoo 02600 395 Finland 397 Phone: +358 (50) 4871445 398 Email: Hannes.Tschofenig@gmx.net 399 URI: http://www.tschofenig.priv.at 401 Barbara Stark 402 AT&T 403 725 W Peachtree St, NE 404 Atlanta, GA 30308 405 USA 407 Phone: +1 404 499 7026 408 Email: barbara.stark@att.com 409 Andres Kuett 410 Skype 412 Email: andres.kytt@skype.net