idnits 2.17.1 draft-barnes-ecrit-policy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (October 18, 2010) is 4939 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TODO' is mentioned on line 587, but not defined == Unused Reference: 'RFC2119' is defined on line 595, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-ecrit-rough-loc-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Barnes 3 Internet-Draft BBN Technologies 4 Intended status: Informational B. Aboba 5 Expires: April 21, 2011 Microsoft Corporation 6 J. Peterson 7 NeuStar, Inc. 8 H. Tschofenig 9 Nokia Siemens Networks 10 October 18, 2010 12 Policy Considerations for Emergency Calling using Voice over IP 13 draft-barnes-ecrit-policy-00 15 Abstract 17 The provision of emergency calling services (e.g., 911, 112) has been 18 a critical component in the regulation of telecommunications 19 networks. The technical architectures used by modern Voice-over-IP 20 (VoIP) systems mean that if telecommunications regulators wish to 21 extend emergency calling requirements to VoIP, it will likely be 22 necessary to reconsider the ways in which such requirements are 23 applied, both in terms of what specific mandates are imposed and 24 which entities are subject to them. This document dicusses the 25 fundamental technical requirements for emergency services, how these 26 requirements can be met within the framework of VoIP, and how these 27 solutions approaches create possibilities and limitations for 28 regulatory involvement. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 21, 2011. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Fundamental Assumptions . . . . . . . . . . . . . . . . . . . 4 65 3. VoIP Architecture . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Obligations . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.1. End Hosts . . . . . . . . . . . . . . . . . . . . . . . . 10 68 4.2. ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.3. VSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 4.4. PSAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.1. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 12 73 5.2. Call Routing . . . . . . . . . . . . . . . . . . . . . . . 12 74 5.3. PSAP Reachability . . . . . . . . . . . . . . . . . . . . 12 75 5.4. Regulatory Implications . . . . . . . . . . . . . . . . . 12 76 6. Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 9. Informative References . . . . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 For several decades, emergency calling has been a critical function 85 of telecommunications networks. Starting in the 1960s, capabilities 86 were created in many places around the world to allow any user of a 87 telephone to reach emergency services simply by dialing a short 88 string of digits (e.g., 9-1-1 in the US or 1-1-2 in Europe). 89 Different countries have implemented these functions in their own 90 ways, but basic emergency calling services are available throughout 91 most of the world today. Particuarly the introduction of automatic 92 caller location, essentially for quickly and accurately dispatching 93 first responders, was a painful and long process that is still 94 ongoing in different parts of the world, particularly when 95 considering location information with better accuracy. 97 At the same time, an ever increasing amount of the voice traffic in 98 the world is being carried via Voice-over-IP services. Just as with 99 other services, the transition to VoIP entails a transition from a 100 circuit-based model of calling to a packet-based one. Instead of a 101 call having a dedicated channel over which signals are transmitted, 102 in VoIP, voice signals are divided into small packets and sent 103 through the Internet (with each packet traveling independently). 104 From the underlying network point of view a VoIP call appears like 105 any other application running over the Internet, rather than a core 106 function of the network. As we will discuss in more detail below, 107 the fact that VoIP is an application makes it siginificantly more 108 flexible than existing PSTN communications facilities, but by the 109 same token, VoIP systems cannot take advantage of certain fixed 110 properties of the PSTN, making it much more of a challenge to 111 implement emergency services. 113 So the situation is challenging: On the one hand, PSTN systems around 114 the world are being transitioned over to VoIP systems, but on the 115 other hand, the structure of VoIP systems makes them incompatible 116 with the way emergency services are provided today. In their attempt 117 to enhance voice over IP with emergency services the technical 118 community has designed a system for enabling VoIP emergency calling. 119 Different organizations considered different deployment approaches 120 known as the ECRIT architecture. Even though the required 121 technologies have already been defined the successful deployment of 122 VoIP emergency services will require sharing of responsibilities by 123 multiple players in the Internet ecosystem. There is thus a need to 124 re-think emergency calling regulation to take into account the 125 structural differences between VoIP and traditional voice services 126 and to consider the re-align of responsibilities in this multi- 127 stakeholder eco-system. 129 In this document, we review some fundamental properties of emergency 130 calling systems and VoIP systems, and discuss how these two concepts 131 come into conflict. We then present approaches for resolving these 132 conflicts, and some thoughts on the role that telecommunications 133 regulation and policy can play in fostering the deployment of VoIP 134 emergency services. 136 2. Fundamental Assumptions 138 The basic goal of an emergency calling service is to connect the 139 caller with an emergency response center that can help with his 140 emergency situation. (These response centers are traditionally known 141 as Public Safety Answering Points, or PSAPs.) A responder's ability 142 to help is typically limited to a certain geographical region for a 143 specific service (such as police, fire, ambulance), either because of 144 legal constraints (e.g., jurisdictional boundaries), because of 145 organization structure and work split or simply because of the 146 physical constraints on how fast a responder can travel to the scene 147 of an emergency. These structures and responsibilities change but in 148 a much slower pace than technology. So emergency calling is 149 fundamentally a question of ensuring that a PSAP is reached that is 150 responsible for the geographical area the emergency caller is 151 currently located iin order to dispatch first responders. 153 There are thus three fundamental functional requirements for a 154 successful emergency call (whether over the PSTN, VoIP, or any other 155 technology): 157 1. An entity routing the call must have access to information about 158 the caller's location. 159 2. The same call-routing entity must know where to route the call. 160 3. The same call-routing entity must be able to forward a call to a 161 PSAP. 163 The challenge in enabling emerency calling using a given 164 communications system is thus to determine how each of these steps is 165 accomplished within that system. In fixed-line PSTN networks, all 166 three requirements were essentially met by virtue of wiring: Customer 167 lines are connected to local switching centers, and switching centers 168 typically cover areas that are served by a single PSAP, so any 169 emergency call that arrives at a switching center can be routed to a 170 dedicated line to the PSAP. (In reality, the situation is somewhat 171 more complex, but we summarize here for simplicity.) 173 The advent of cellular systems forced a degree of separation among 174 these functions, since the caller's location was not known in 175 advance. In order to provide emergency calling, cellular networks 176 had to deploy specific capabilities to locate their subscribers, and 177 upgrade switches that handle emergency calls so that they can query 178 those capabilities and route calls based on the subsequent location. 179 Even in this case, however, the routing function can be fairly 180 static, because a particular cellular network only covers a specific 181 geographic area. 183 3. VoIP Architecture 185 The IP-based emergency services access architectures differentiate a 186 few components that have different responsibilities for offering the 187 complete end-to-end functionality. These roles are: 188 o Internet Service Provider (ISP) 189 o Voice Service Provider (VSP), or in a more generic form 190 Application Service Provider (ASP) 191 o Emergency Service Provider (that operates a PSAP) and vendors of 192 equipment for those. 193 o End Device 195 Note that multiple roles be provided by a single organisation. 197 [Editor's Note: Should we provide a short description of each of the 198 roles? 199 +--------------------+ 200 | | 201 | Emergency Network | 202 | Infrastructure | 203 | | 204 | +----------+ | 205 | | PSAP | | 206 | | | | 207 | +----------+ | 208 +------^-------------+ (d) 209 +-----------------------------+ 210 | 211 +--------------+ +-----+--------+ 212 | | ---- | | | 213 | ISP | ///- -\\\ | | VSP | 214 | | / \\ | | | 215 | +----------+ | | Distributed | | +---+------+ | 216 | | LIS | | | Mapping |<--->| | Routing | | 217 | | | | | Database | (b) | | Entity | | 218 | +----------+ | | | | +----------+ | 219 | ^ | \ // | ^ | 220 | | | \\\- -/// | | | 221 | | | ---- | | | 222 +----+---------+ (b) ^ +-----+--------+ 223 | +---------------------+ | 224 | | (c) | 225 | | +--------------------------------------+ 226 (a) | | | 227 v v v 228 +-----------+ 229 | End | 230 | Host | 231 +-----------+ 233 Figure 1: Stakeholders in the Emergency Services Eco-System 235 The references to interfaces (a), (b), (c), and (d) will be used 236 in Section 4. 238 The emergency call interaction on a high level takes place as 239 follows: the user enters an emergency services number (or potentially 240 an emergency dial string). The end device recognises the entered 241 sequence of digits as an emergency call attempt and determines 242 whether location information is available locally (as part of the GPS 243 module, for example). If no location information is available 244 locally then various protocol extensions have been defined that allow 245 the end host to obtain location information from a Location 246 Information Server in the ISPs network. Then, the call setup 247 procedure using SIP is started towards the users VSP/ASP. The VSP/ 248 ASP needs to make a route decision to determine where the call needs 249 to be forwarded to. Often, this decision is based on a combination 250 of the callers location information as well as other policy aspects 251 (such as time-of-day, workload of a specific PSAP). 253 When considering IP-access to emergency services, one should consider 254 the following categories and the challenges they induce: 255 Fixed Access: From a user point of view this scenario is 256 characterised by a stationary usage of a computer, such as a 257 desktop PC at someones home. Typically, these devices are often 258 not equipped with a GPS receiver or, because of the indoor usage, 259 these do not work very well or not at all. Information about the 260 callers location can therefore come from manual configuration 261 (which may be useful in cases where the location of the device 262 indeed rarely changes or the user is careful in keeping the 263 reported location accurate) or from the ISPs network since the 264 attachment point is known to the operators network infrastructure. 265 Nomadic Access: Nomadic access is characterised in movement patterns 266 that correspond to regular laptop usage where users switch 267 location from time to time (e.g. go to work, use their laptop at 268 the university or in a coffee shop, and at home). In this 269 scenario it is not realistic to assume that users update their 270 location manually due to the frequent change. The usage of GPS 271 may be possible even though network operator presented location 272 would be preferred since users will typically use their device 273 indoors where GPS does not work well. 274 Mobile Access: This scenario is an enhancement of the previously 275 presented nomadic access with the assumption that users roam while 276 having their communication ongoing. In this scenario, devices, 277 such as smart phones, are often equipped with GPS receivers and 278 make the location determination process more accurate. Manually 279 entered location is in this scenario not possible. 281 Note: This is a simplified view on networking from the users point of 282 view. As network architectures become more sophisticated the 283 boundaries between these scenarios get more fuzzy. As an example, 284 one may consider a traveller using a laptop with wireless LAN (as he 285 uses at home) in a train connected. The network infrastructure in 286 the train is connected via a cellular infrastructure to the Internet. 287 This example blurs nomadic access and mobile access. Consider 288 another example where a teenager uses his high-performance laptop for 289 gaming and sometimes uses it at home as a replacement for the desktop 290 PC and sometimes at some LAN parties to compete with other games. 291 From software program point of view these cases are very hard to 292 differentiate since in all cases the end device is uses WLAN 293 technology to communicate with the network. Hence, it is left to the 294 user to 'switch' between usage environments, which introduce problems 295 when software developers make too restrictive assumptions about the 296 environment where their devices will later be used or about the users 297 awareness of the necessary configuration changes. Ideally, users 298 should not need to configure their devices to prepare for the case of 299 an emergency call. For the unlikely case of an emergency users 300 should not be required to ever configure their device - zero 301 configuration is the goal. 303 From user-experience point of view the overall process of 304 establishing an emergency call begins someone dialling an emergency 305 dial string. The exact sequence of digits depends on the 306 infrastructure the device is connected to. While 1-1-2 became the 307 emergency services number for Europe and 9-1-1 the emergency number 308 for the US many countries still provide additional emergency numbers 309 mostly for historical reasons. Furthermore, many large enterprises, 310 university, and hotels prefix the emergency numbers with additional 311 digits, such as 0-112. 313 An important part of emergency handling is in the logic of delivering 314 emergency calls to the appropriate PSAP. With devices that may be 315 used with different VSPs/ASPs and in cases where there is no 316 relationship between the ISP and the VSP/ASP the automatic routing 317 decision becomes more complex. Consider the following example where 318 user Bob travels to from Sweden to Spain and wants to use their 319 device to trigger an emergency real-time text interaction. Since Bob 320 is using a real-time text provider in Sweden the messages are routed 321 to the Swedish operator. Based on the provided location the Swedish 322 operator notices that a PSAP in Spain has to be involved and, for 323 example, initiates a conference bridge with Bob, a relay provider in 324 Sweden serving as a language translator, and the PSAP operator in 325 Spain. In order for the Swedish ASP/VSP or the Swedish PSAP to 326 involve the appropriate Spanish PSAP their contact information needs 327 to be available, and information about their responsibility (i.e. for 328 which region they are responsible and which emergency service 329 function they provide) needs to be published. 331 A protocol, called Location to Service Translation (LoST), has been 332 defined to map a location together with a symbolic representation of 333 the emergency service requested to a specific PSAP contact address 334 (PSAP URI). Note that the returned PSAP URI does not necessary need 335 to be the contact information of the final PSAP but rather it will 336 route the call closer to one. 338 Location information is needed by emergency services for three 339 reasons: routing the call to the right PSAP, dispatching first 340 responders (e.g. policemen), and determining the right emergency 341 service dial strings. It is clear that the location has to be 342 automatic for the first and third application, but experience has 343 shown that automated, highly-accurate location information is vital 344 to dispatching as well, rather than relying on the caller to report 345 his or her location to the call taker. This increases accuracy and 346 avoids dispatch delays when the caller is unable to provide location 347 information due to language barriers, lack of familiarity with his or 348 her surroundings, stress, physical or mental impairment. Location 349 information for emergency purposes comes in two representations: 350 geo(detic), i.e., longitude and latitude, and civic, i.e., street 351 addresses similar to postal addresses. Particularly for indoor 352 location, vertical information (floors) is very useful. Civic 353 locations are most useful for fixed Internet access, including 354 wireless hot spots, and are often preferable for specifying indoor 355 locations, while geodetic location is frequently used for cell 356 phones. However, with the advent of femto, and pico cells, civic 357 location is both possible and probably preferable since accurate 358 geodetic information can be very hard to acquire indoors. 360 Before location can be put into a protocol for delivery and utilised 361 it first needs to be determined. Location information can be entered 362 by a user ("manual configuration"), measured by the end host, can be 363 delivered to the end system by some protocol or measured by a third 364 party. The actual process of location determination is largely 365 outside the scope of the REACH-112 project but manual configuration, 366 GPS usage, and the usage of location servers is relevant. Many VoIP 367 deployments allow their users to manually enter location information 368 for later usage with emergency services. Typically, the users enter 369 their home address into a web-based form and this data would then be 370 used for emergency service call routing and also delivered to PSAP 371 operators. This mechanism is primarily suitable for users utilising 372 fixed network deployments (such as Cable and DSL networks) rather 373 than cellular networks where the current users location changes 374 continuously. For nomadic users this approach already becomes very 375 cumbersome for end users. While this mechanism clearly has 376 limitations it is still a useful approach in absence of other 377 techniques. For devices like laptops and in particular mobile phones 378 the usage of GPS is a promising technique that is able to provide 379 highly accuracy. While it has also has limitations (for example when 380 used indoor) and may need a fair amount of time to provide the 381 initial location fix it is a promising technique. The requirements 382 for location accuracy differ between routing and dispatch. For call 383 routing, city or even county-level accuracy is often sufficient, 384 depending on how large the PSAP service areas are, while first 385 responders benefit greatly when they can pinpoint the caller to a 386 particular building or, better yet, apartment or office for indoor 387 locations, and an outdoor area of at most a few hundred meters 388 outdoors. This avoids having to search multiple buildings, e.g., for 389 medical emergencies. 391 For a realiable emergency services infrastructure utilizing the 392 location information provided by ISPs is important, largely for 393 dispatch purposes since the accuracy is sufficiently high to allow 394 first responders to locate the person in need for help. 396 4. Obligations 398 In this section we discuss how the responsibilities for deployment 399 need to be shared based on the architectural illustration from 400 Figure 1. Note that this narration focuses on the final stage of 401 deployment and do not discuss the transition architecture, in which 402 some implementation responsibilities can be re-arranged, with an 403 impact on the overall functionality offered by the emergency services 404 architecture. A few variations were introduced to handle the 405 transition from the current system to a fully developed ECRIT 406 architecture. 408 4.1. End Hosts 410 An end host, through its VoIP application, has three main 411 responsibilities: it has to attempt to obtain its own location, 412 determine the URI of the appropriate PSAP for that location, and 413 recognize when the user places an emergency call by examining the 414 dial string. The end host operating system may assist in determining 415 the device location. The protocol interaction for location 416 configuration is indicated as interface (a) in Figure 1 and a number 417 of location configuration protocols have been developed to provide 418 this capability. 420 A VoIP application needs to have the ability to detect the emergency 421 call, to obtain (potentially only locally available) location 422 information, and to make it available to the VSP during call setup. 424 4.2. ISP 426 The ISP has to make location information available to the end point 427 via one or more of the location configuration protocols. In order to 428 route an emergency call correctly to a PSAP, an ISP may initially 429 disclose the approximate location for routing to the end point and 430 more precise location information later, when emergency personnel is 431 dispatched by the PSAP operator. The functionality required by the 432 IETF emergency services architecture is restricted to the disclosure 433 of a relatively small amount of location information, as discussed in 434 [I-D.ietf-ecrit-location-hiding-req] and in 435 [I-D.ietf-ecrit-rough-loc]. 437 The ISP may also operate a (caching) LoST server to improve the 438 robustness and the reliability of the architecture. This lowers the 439 roundtrip time for contacting a LoST server and the caches are most 440 likely to hold the mappings of the area where the emergency caller is 441 currently located. 443 In case ISPs allow Internet traffic to traverse their network the 444 signaling and media protocols used for emergency calls function 445 without problems. Today, there are no legal requirements to offer 446 prioritization of emergency calls over IP-based networks. While the 447 standardization community has developed a range of Quality of Service 448 signaling protocols their (widespread) deployment still remains to 449 happen. 451 4.3. VSP 453 SIP does not mandate that call setup requests need to traverse SIP 454 proxies, i.e., SIP messages can be sent directly to the user agent. 455 Thus, even for emergency services it is possible to use SIP without 456 the involvement of a VSP. However, in terms of deployment, it is 457 highly likely that a VSP will be used. If a caller uses a VSP, this 458 VSP often forces all calls, emergency or not, to traverse an outbound 459 proxy or session border controller (SBC) operated by the VSP. If 460 some end devices are unable to perform a LoST lookup, VSP can provide 461 the necessary functions as a back-up solution. If the VSP uses a 462 signaling or media protocol that is not supported by the PSAP, it 463 needs to translate the signaling or media flows. 465 VSPs can assist the PSAP by providing identity assurance for 466 emergency calls and thus helping to prosecute prank callers. 467 However, the link between the subscriber information and the real- 468 world person making the call is weak. In many cases, VSPs have, at 469 best, only the credit card data for their customers and some of these 470 customers may use gift cards or other anonymous means of payment. 472 4.4. PSAP 474 When emergency calling has been fully converted to Internet 475 protocols, PSAPs must accept calls from any VSP, as shown in 476 interface (d) of Figure 1. Since calls may come from all sources, 477 PSAPs must develop mechanisms to reduce the number of malicious 478 calls, particularly calls containing intentionally false location 479 information. Assuring the reliability of location information 480 remains challenging, particularly as more and more devices are 481 equipped Global Navigation Satellite Systems (GNSS) receivers, 482 including GPS and Galileo, allowing them to determine their own 483 location. However, it may be possible in some cases to the veracity 484 of the location information provided by an end-point by comparing it 485 against infrastructure-provided location information, e.g., LIS 486 determined location. 488 5. Requirements 490 [[ TBD: We need to add a bit of wording here in this section to your 491 notes. I think that this section should also talk about the 492 distribution of responsibilities among the stake holders and motivate 493 why they want to do this. Then, we have no requirement yet for 494 multi-media emergency calls, which would be good to have.]] 496 5.1. Geolocation 498 [[ -- Location -- Basic requirement: Get location information to a 499 call-routing entity -- Endpoint or VoIP service -- ... but probably 500 the endpoint (security reasons) -- State of the art today -- Carrier 501 location functions; inaccessible to end devices -- "World in a DB" 502 functions; low-fidelity -- GPS; frequently fails -- Commercial 503 direction is not moving quickly away from these stovepipes -- GEOPRIV 504 model provides bridges, but not much uptake -- Also provides a 505 location interface for PSAPs, e.g. as NENA has defined ]] 507 5.2. Call Routing 509 [[ -- Call routing -- Need a pubic, open DB with a standard query 510 interface -- Source of the data needs to be local emergency 511 authorities => Need for local authorities to coordinate to create 512 LoST DB(s) ]] 514 5.3. PSAP Reachability 516 [[ -- PSAP reachability -- Basic requirement: Internet connectivity, 517 SIP reachability -- Gatways as a transition step -- Security 518 questions; ref to ESInet concepts ]] 520 5.4. Regulatory Implications 522 [[ -- Roles government can play -- Who can be the targets of 523 regulation? -- Localized (yes): PSAPs, ISPs, vertically-integrated 524 VoIP -- Non-localized (no): Application-only VoIP, application-only 525 location providers -- Enabling location: -- Several networks that 526 provide E911 are also ISPs -- Require them to open up ALI or 527 equivalents to endpoint, PSAP access -- How to enable NG911 without 528 giving away the store: rough-loc -- Encourage ISPs in general to 529 enable location services for customers -- Call routing: -- Coordinate 530 the development of a national LoST infrastructure -- Formalize LoST 531 as a national standard call-routing interface -- Encourage ISPs to 532 support LoST discovery -- PSAP reachability: -- Support PSAP upgrades 533 and gateways -- Encourage VoIP vendors to integrate emergency calling 534 into products -- E.g., support open-source location, LoST components 535 ]] 537 6. Outlook 539 In most countries, national and sometimes regional telecommunications 540 regulators have a strong influence on how emergency services are 541 provided; such as who pays for them and what obligations the various 542 parties have. Regulation is, however, still at an early stage: in 543 most countries current requirements only demand manual update of 544 location information by the VoIP user. The ability to obtain 545 location information automatically is, however, crucial for reliable 546 emergency service operation, and required for nomadic and mobile 547 devices. (Nomadic devices remain in one place during a communication 548 session, but are moved frequently from place top place. Laptops with 549 WiFi interfaces are currently the most common nomadic device.) 551 Regulators have traditionally focused on the national or, at most, 552 the European level, and the international nature of the Internet 553 poses new challenges. For example, mobile devices are now routinely 554 used beyond their country of purchase and, unlike traditional 555 cellular phones, need to support emergency calling functionality. It 556 appears likely that different countries will deploy IP-based 557 emergency services over different time horizons, so that a traveler 558 may be surprised to find that she cannot call for emergency 559 assistance outside their home country. 561 The separation between Internet access and application providers on 562 the Internet is one of the most important differences to existing 563 circuit switched telephony networks. A side effect of this 564 separation is the increased speed of innovation at the application 565 layer and the number of new communication mechanisms is steadily 566 increasing. Many emergency service organizations have recognized 567 this trend and advocated for the use of new communication mechanisms, 568 including video, real-time text, and instant messaging, to offer 569 improved emergency calling support for citizens. Again, this 570 requires regulators to re-think the distribution of responsibilities, 571 funding and liability. 573 Many communication systems in use today lack accountability, i.e., it 574 is difficult or impossible to trace malicious activities back to the 575 persons who caused it. This is not a completely new problem, as pay 576 phones and prepaid cell phones have long offered mischief makers the 577 opportunity to place hoax calls, but the weak user registration 578 procedures, the lack of deployed end-to-end identity mechanisms, and 579 the ease of providing fake location information increases the attack 580 surface at PSAPs. Attackers also got more sophisticated over time 581 and Botnets to generate a large volume of automated emergency calls 582 to exhaust PSAP resources, including call takers and first 583 responders, is not science fiction. 585 7. Security Considerations 587 [TODO] 589 8. IANA Considerations 591 This document has no actions for the IANA. 593 9. Informative References 595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", BCP 14, RFC 2119, March 1997. 598 [I-D.ietf-ecrit-location-hiding-req] 599 Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and 600 A. Kuett, "Location Hiding: Problem Statement and 601 Requirements", draft-ietf-ecrit-location-hiding-req-04 602 (work in progress), February 2010. 604 [I-D.ietf-ecrit-rough-loc] 605 Barnes, R. and M. Lepinski, "Using Imprecise Location for 606 Emergency Context Resolution", 607 draft-ietf-ecrit-rough-loc-03 (work in progress), 608 August 2010. 610 Authors' Addresses 612 Richard Barnes 613 BBN Technologies 614 9861 Broken Land Parkway 615 Columbia, MD 21046 616 USA 618 Phone: +1 410 290 6169 619 Email: rbarnes@bbn.com 620 Bernard Aboba 621 Microsoft Corporation 622 One Microsoft Way 623 Redmond, WA 98052 624 US 626 Email: bernarda@microsoft.com 628 Jon Peterson 629 NeuStar, Inc. 630 1800 Sutter St Suite 570 631 Concord, CA 94520 632 US 634 Email: jon.peterson@neustar.biz 636 Hannes Tschofenig 637 Nokia Siemens Networks 638 Linnoitustie 6 639 Espoo 02600 640 Finland 642 Phone: +358 (50) 4871445 643 Email: Hannes.Tschofenig@gmx.net 644 URI: http://www.tschofenig.priv.at