idnits 2.17.00 (12 Aug 2021) /tmp/idnits58071/draft-schulzrinne-ecrit-psap-callback-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2009) is 4589 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-ecrit-framework has been published as RFC 6443 == Outdated reference: A later version (-08) exists of draft-ietf-sip-saml-06 == Outdated reference: A later version (-03) exists of draft-patel-dispatch-cpc-oli-parameter-00 == Outdated reference: A later version (-11) exists of draft-patel-ecrit-sos-parameter-06 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 2 errors (**), 0 flaws (~~), 6 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 H. Tschofenig 5 Expires: April 29, 2010 Nokia Siemens Networks 6 M. Patel 7 Nortel 8 October 26, 2009 10 Public Safety Answering Point (PSAP) Callbacks 11 draft-schulzrinne-ecrit-psap-callback-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 29, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 After an emergency call is completed (either prematurely terminated 50 by the emergency caller or normally by the call-taker) it is possible 51 that the call-taker feels the need for further communication or for a 52 clarification. For example, the call may have been dropped by 53 accident without the call-taker having sufficient information about 54 the current situation of a wounded person. A call-taker may trigger 55 a callback towards the emergency caller using the contact information 56 provided with the initial emergency call. This callback could, under 57 certain circumstances, then be treated like any other call and as a 58 consequence, it may get blocked by authorization policies or may get 59 forwarded to an answering machine. 61 The IETF emergency services architecture addresses callbacks in a 62 limited fashion and thereby covers a couple of scenarios. This 63 document discusses some shortcomings and raises the question whether 64 additional solution techniques are needed. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Multi-Stage Resolution . . . . . . . . . . . . . . . . . . 4 70 1.2. Call Forwarding . . . . . . . . . . . . . . . . . . . . . 6 71 1.3. PSTN Interworking . . . . . . . . . . . . . . . . . . . . 8 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 3. Requirements and Design Approaches . . . . . . . . . . . . . . 10 74 4. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 12 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 7.1. Informative References . . . . . . . . . . . . . . . . . . 16 79 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 Summoning police, the fire department or an ambulance in emergencies 85 is one of the fundamental and most-valued functions of the telephone. 86 As telephone functionality moves from circuit-switched telephony to 87 Internet telephony, its users rightfully expect that this core 88 functionality will continue to work at least as well as it has for 89 the legacy technology. New devices and services are being made 90 available that could be used to make a request for help, which are 91 not traditional telephones, and users are increasingly expecting them 92 to be used to place emergency calls. 94 Regulatory requirements demand that the emergency call itself 95 provides enough information to allow the call-taker to initiate a 96 call back to the emergency caller in case the call dropped or to 97 interact with the emergency caller in case of further questions. 98 Such a call, referred as PSAP callback subsequently in this document, 99 may, however, be blocked or forwarded to an answering machine as SIP 100 entities (SIP proxies as well as the SIP UA itself) cannot associate 101 the potential importantance of the call based on the SIP signaling. 103 Note that the authors are, however, not aware of regulatory 104 requirements for providing preferential treatment of callbacks 105 initiated by the call-taker at the PSAP towards the emergency 106 caller. 108 Section 10 of [I-D.ietf-ecrit-framework] discusses the identifiers 109 required for callbacks, namely AOR URI and a globally routable URI in 110 a Contact: header. Section 13 of [I-D.ietf-ecrit-framework] provides 111 the following guidance regarding callback handling: 113 A UA may be able to determine a PSAP call back by examining the 114 domain of incoming calls after placing an emergency call and 115 comparing that to the domain of the answering PSAP from the 116 emergency call. Any call from the same domain and directed to the 117 supplied Contact header or AoR after an emergency call should be 118 accepted as a call-back from the PSAP if it occurs within a 119 reasonable time after an emergency call was placed. 121 This approach mimics a stateful packet filtering firewall and is 122 indeed helpful in a number of cases. Below, we discuss a few cases 123 where this approach fails. 125 1.1. Multi-Stage Resolution 127 Consider the following emergency call routing scenario shown in 128 Figure 1 where routing towards the PSAP occurs in several stages. An 129 emergency call uses a SIP UA that does not run LoST on the end point. 131 Hence, the call is marked with the 'urn:service:sos' Service URN 132 [RFC5031]. The user's VoIP provider receives the emergency call and 133 determines where to route it. Local configuration or a LoST lookup 134 might, in our example, reveal that emergency calls are routed via a 135 dedicated provider FooBar and targeted to a specific entity, referred 136 as esrp1@foobar.com. FooBar does not handle emergency calls itself 137 but performs another resolution step to let calls enter the emergency 138 services network and in this case another resolution step takes place 139 and esrp-a@esinet.org is determined as the recipient, pointing to an 140 edge device at the IP-based emergency services network. Inside the 141 emergency services there might be more sophisticated routing taking 142 place somewhat depending on the existing structure of the emergency 143 services infrastructure. 145 ,-------. 146 +----+ ,' `. 147 | UA |--- urn:service:sos / Emergency \ 148 +----+ \ | Services | 149 \ ,-------. | Network | 150 ,' `. | | 151 / VoIP \ | | 152 ( Provider ) | | 153 \ / | | 154 `. ,' | | 155 '---+---' | +------+ | 156 | | |PSAP | | 157 esrp1@foobar.com | +--+---+ | 158 | | | | 159 | | | | 160 ,---+---. | | | 161 ,' `. | | | 162 / Provider \ | | | 163 + FooBar ) | | | 164 \ / | | | 165 `. ,' | +--+---+ | 166 '---+---' | +-+ESRP | | 167 | | | +------+ | 168 | | | | 169 +------------+-+ | 170 esrp-a@esinet.org | | 171 \ / 172 `. ,' 173 '-------' 175 Figure 1: Multi-Stage Resolution 177 1.2. Call Forwarding 179 Imagine the following case where an emergency call enters an 180 emergency network (state.org) via an ERSP but then gets forwarded to 181 a different emergency services network (in our example to police- 182 town.org, fire-town.org or medic-town.org). The same considerations 183 apply when the the police, fire and ambulance networks are part of 184 the state.org sub-domains (e.g., police.state.org). 186 ,-------. 187 ,' `. 188 / Emergency \ 189 | Services | 190 | Network | 191 | (state.org) | 192 | | 193 | | 194 | +------+ | 195 | |PSAP +--+ | 196 | +--+---+ | | 197 | | | | 198 | | | | 199 | | | | 200 | | | | 201 | | | | 202 | +--+---+ | | 203 ------------------+---+ESRP | | | 204 esrp-a@state.org | +------+ | | 205 | | | 206 | Call Fwd | | 207 | +-+-+---+ | 208 \ | | | / 209 `. | | | ,' 210 '-|-|-|-' ,-------. 211 Police | | | Fire ,' `. 212 +------------+ | +----+ / Emergency \ 213 ,-------. | | | | Services | 214 ,' `. | | | | Network | 215 / Emergency \ | Ambulance | | fire-town.org | 216 | Services | | | | | | 217 | Network | | +----+ | | +------+ | 218 |police-town.org| | ,-------. | +----+---+PSAP | | 219 | | | ,' `. | | +------+ | 220 | +------+ | | / Emergency \ | | | 221 | |PSAP +----+--+ | Services | | | , 222 | +------+ | | Network | | `~~~~~~~~~~~~~~~ 223 | | |medic-town.org | | 224 | , | | | 225 `~~~~~~~~~~~~~~~ | +------+ | | 226 | |PSAP +----+ + 227 | +------+ | 228 | | 229 | , 230 `~~~~~~~~~~~~~~~ 232 Figure 2: Call Forwarding 234 1.3. PSTN Interworking 236 In case an emergency call enters the PSTN, as shown in Figure 3, 237 there is no guarantee that the callback some time later does leave 238 the same PSTN/VoIP gateway or that the same end point identifier is 239 used in the forward as well as in the backward direction making it 240 difficult to reliably detect PSAP callbacks. 242 +-----------+ 243 | PSTN |-------------+ 244 | Calltaker | | 245 | Bob |<--------+ | 246 +-----------+ | v 247 ------------------- 248 //// \\\\ +------------+ 249 | | |PSTN / VoIP | 250 | PSTN |---->|Gateway | 251 \\\\ //// | | 252 ------------------- +----+-------+ 253 ^ | 254 | | 255 +-------------+ | +--------+ 256 | | | |VoIP | 257 | PSTN / VoIP | +->|Service | 258 | Gateway | |Provider| 259 | |<------Invite----| Y | 260 +-------------+ +--------+ 261 | ^ 262 | | 263 Invite Invite 264 | | 265 V | 266 +-------+ 267 | SIP | 268 | UA | 269 | Alice | 270 +-------+ 272 Figure 3: PSTN Interworking 274 2. Terminology 276 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 277 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 278 document are to be interpreted as described in [RFC2119]. 280 Emergency services related terminology is borrowed from [RFC5012]. 282 3. Requirements and Design Approaches 284 From the previously presented scenarios, the following generic 285 requirements can be crafted: 287 Resistance Against Security Vulnerabilities: 289 The main possibility of attack involves use of the PSAP callback 290 marking to bypass blacklists, ignore call forwarding procedures 291 and similar features to interact with users and to raise their 292 attention. For example, using PSAP callback marking devices would 293 be able to recognize these types of incoming messages leading to 294 the device overriding user interface configurations, such as 295 vibrate-only mode. As such, the requirement is to ensure that the 296 mechanisms described in this document can not be used for 297 malicious purposes, including SPIT. 299 Fallback to Normal Call 301 When the newly defined extension is not recognized by 302 intermediaries or other entities then it MUST NOT lead to a 303 failure of the call handling procedure but rather a fall-back to a 304 call that did not have any marking provided. 306 In addition to the high-level requirements there are a few design 307 choices. 309 What is the granularity of the decision making? 311 There are a few choices that impact the solution mechanism quite 312 considerably: 314 * Verify that the caller is a PSAP 316 * Verify that the call is in response to a previous emergency 317 call. 319 * Verify that the call is related to an emergency, but not 320 necessarily an earlier emergency call. This might include 321 public notification (authority-to-citizen). 323 Who calls back? 325 The relationship between the person who previously received the 326 emergency call and the person who triggers the callback allows a 327 couple of choices: 329 * The callback has to be made using the same User Agent. 331 * The callback has to made by the same user but potentially with 332 a different UA. 334 * A different user from a different UA can make the callback. 336 4. Solution Approaches 338 This version of the document does not yet contain a fully specified 339 solution description. Instead, it tries to explore the different 340 alternatives. 342 An example solution can be found in an earlier version of 343 [I-D.patel-ecrit-sos-parameter]. The "sos" URI parameter is appended 344 to the URI in the Contact header field of the INVITE request for PSAP 345 call-back establishment. Although this approach can distinguish the 346 PSAP call-back from other sessions, such a solution is prone to 347 security vulnerabilities since the insertion of the URI parameter 348 cannot verify the request was generated from a PSAP rather than a 349 malicious entity. 351 The usage of the In-Reply-To header field can provide the capability 352 to relate the PSAP call-back to a previously made emergency call. 353 The UA of the emergency caller, as well as enities within the service 354 provider's network can therefore infer that the request is a PSAP 355 callback, providing they maintained information pertaining to the 356 emergency call. This solution also relies on the PSAP call-back 357 routing over the same entities that the emergency call was routed 358 over if such a solution is used to provide preferential treatment of 359 callbacks. A solution based on the inclusion of the In-Reply-To 360 header would be useful in the case the network or the UA is required 361 to disable services or features which may prevent the callback from 362 reaching the UA from which the emergency call was placed. 363 Furthermore, it may facilitate success of the callback by removing, 364 for example, incoming call barring restrictions that may have been 365 enforced for the emergency caller's service. 367 To fulfill the requirements of verifying the caller is a PSAP, 368 mechanisms such as those described in RFC 4474 [RFC4474] or in RFC 369 3325 [RFC3325] are recommended to be used. Such an approach would 370 mitigate security vulnerabilities, but does not explicitly mark the 371 request generated from the PSAP as a request for callback. 372 Additional information, such a PSAP whitelist, would have to be 373 known. This is, however, only likely to work in a smaller scale 374 rather than world wide. 376 The use of the Calling Party's Category URI parameter in the 377 P-Asserted-Identity [RFC3325], as described in 378 [I-D.patel-dispatch-cpc-oli-parameter], is one method of a network 379 asserted identifier, describing the nature of the calling party and 380 in this case, the PSAP. This approach only works when the entity 381 that inserts the CPC parameter is trusted by those who verify it. 382 This relies on a circle of trust similar to the a white list. 383 Additionally, it has to be mentioned that unlike [I-D.ietf-sip-saml] 384 applying SIP Identity over the parameter does not ensure that the 385 authentication service indeed asserts the validity of the parameter. 387 5. Security Considerations 389 This document provides discussions problems of PSAP callbacks and 390 lists requirements, some of which illustrate security challenges. 391 The current version does not yet provide a specific solution but 392 rather starts with overall architectural observations. 394 An important aspect from a security point of view is the relationship 395 between the emergency services network and the VSP (assuming that the 396 emergency call travels via the VSP and not directly between the SIP 397 UA and the PSAP). If there is a strong trust relationship between 398 the PSAP operator and the VSP (for example based on a peering 399 relationship) without any intermediate VoIP providers then the 400 identification of a PSAP call back is less problematic than in the 401 case where the two entities have not entered in some form of 402 relationship that would allow the VSP to verify whether the marked 403 callback message indeed came from a legitimate source. 405 6. Acknowledgements 407 We would like to thank members from the ECRIT working group, in 408 particular Brian Rosen, for their discussions around PSAP callbacks. 410 7. References 412 7.1. Informative References 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, March 1997. 417 7.2. Informative References 419 [I-D.ietf-ecrit-framework] 420 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 421 "Framework for Emergency Calling using Internet 422 Multimedia", draft-ietf-ecrit-framework-10 (work in 423 progress), July 2009. 425 [I-D.ietf-sip-saml] 426 Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. 427 Sicker, "SIP SAML Profile and Binding", 428 draft-ietf-sip-saml-06 (work in progress), March 2009. 430 [I-D.patel-dispatch-cpc-oli-parameter] 431 Patel, M., Jesske, R., and M. Dolly, "Uniform Resource 432 Identifier (URI) Parameters for indicating the Calling 433 Party's Catagory and Originating Line Identity", 434 draft-patel-dispatch-cpc-oli-parameter-00 (work in 435 progress), October 2009. 437 [I-D.patel-ecrit-sos-parameter] 438 Patel, M., "SOS Uniform Resource Identifier (URI) 439 Parameter for Marking of Session Initiation Protocol 440 (SIP) Requests related to Emergency Services", 441 draft-patel-ecrit-sos-parameter-06 (work in progress), 442 May 2009. 444 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 445 Extensions to the Session Initiation Protocol (SIP) for 446 Asserted Identity within Trusted Networks", RFC 3325, 447 November 2002. 449 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 450 Authenticated Identity Management in the Session 451 Initiation Protocol (SIP)", RFC 4474, August 2006. 453 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 454 Emergency Context Resolution with Internet Technologies", 455 RFC 5012, January 2008. 457 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 458 Emergency and Other Well-Known Services", RFC 5031, 459 January 2008. 461 Authors' Addresses 463 Henning Schulzrinne 464 Columbia University 465 Department of Computer Science 466 450 Computer Science Building 467 New York, NY 10027 468 US 470 Phone: +1 212 939 7004 471 Email: hgs+ecrit@cs.columbia.edu 472 URI: http://www.cs.columbia.edu 474 Hannes Tschofenig 475 Nokia Siemens Networks 476 Linnoitustie 6 477 Espoo 02600 478 Finland 480 Phone: +358 (50) 4871445 481 Email: Hannes.Tschofenig@gmx.net 482 URI: http://www.tschofenig.priv.at 484 Milan Patel 485 Nortel 486 Maidenhead Office Park, Westacott Way 487 Maidenhead SL6 3QH 488 UK 490 Email: milanpa@nortel.com