idnits 2.17.1 draft-ietf-ecrit-psap-callback-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 : ---------------------------------------------------------------------------- ** 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 21, 2010) is 4959 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.patel-ecrit-sos-parameter' is defined on line 579, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-11 == Outdated reference: A later version (-08) exists of draft-ietf-sip-saml-07 == Outdated reference: A later version (-11) exists of draft-patel-ecrit-sos-parameter-09 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 1 error (**), 0 flaws (~~), 7 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: March 25, 2011 Nokia Siemens Networks 6 M. Patel 7 Nortel 8 September 21, 2010 10 Public Safety Answering Point (PSAP) Callbacks 11 draft-ietf-ecrit-psap-callback-00.txt 13 Abstract 15 After an emergency call is completed (either prematurely terminated 16 by the emergency caller or normally by the call-taker) it is possible 17 that the call-taker feels the need for further communication or for a 18 clarification. For example, the call may have been dropped by 19 accident without the call-taker having sufficient information about 20 the current situation of a wounded person. A call-taker may trigger 21 a callback towards the emergency caller using the contact information 22 provided with the initial emergency call. This callback could, under 23 certain circumstances, then be treated like any other call and as a 24 consequence, it may get blocked by authorization policies or may get 25 forwarded to an answering machine. 27 The IETF emergency services architecture addresses callbacks in a 28 limited fashion and thereby covers a couple of scenarios. This 29 document discusses some shortcomings and raises the question whether 30 additional solution techniques are needed. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on March 25, 2011. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Routing Asymmetry . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Multi-Stage Resolution . . . . . . . . . . . . . . . . . . 4 69 1.3. Call Forwarding . . . . . . . . . . . . . . . . . . . . . 5 70 1.4. PSTN Interworking . . . . . . . . . . . . . . . . . . . . 7 71 1.5. Network-based Service URN Resolution . . . . . . . . . . . 7 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 3. Design Approaches . . . . . . . . . . . . . . . . . . . . . . 10 74 4. Topics for Investigation . . . . . . . . . . . . . . . . . . . 13 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. It is also relatively simple to 123 implement. Below, we discuss a few cases where this approach fails. 125 1.1. Routing Asymmetry 127 In some deployment environments it is common to have incoming and 128 outgoing SIP messaging to use different routes. 130 ,-------. 131 ,' `. 132 ,-------. / Emergency \ 133 ,' `. | Services | 134 / VoIP \ I | Network | 135 | Provider | n | | 136 | | t | | 137 | | e | | 138 | +-------+ | r | | 139 +--+---|Inbound|<--+-----m | | 140 | | |Proxy | | e | +------+ | 141 | | +-------+ | d | |PSAP | | 142 | | | i | +--+---+ | 143 +----+ | | | a-+ | | | 144 | UA |<---+ | | t | | | | 145 | |----+ | | e | | | | 146 +----+ | | | | | | | 147 | | | P | | | | 148 | | | r | | | | 149 | | +--------+ | o | | | | 150 +--+-->|Outbound|--+---->v | | +--+---+ | 151 | |Proxy | | i | | +-+ESRP | | 152 | +--------+ | d | | | +------+ | 153 | | e || | | 154 | | r |+-+ | 155 \ / | | 156 `. ,' \ / 157 '-------' `. ,' 158 '-------' 160 Figure 1: Example for Routing Asymmetry 162 1.2. Multi-Stage Resolution 164 Consider the following emergency call routing scenario shown in 165 Figure 2 where routing towards the PSAP occurs in several stages. An 166 emergency call uses a SIP UA that does not run LoST on the end point. 167 Hence, the call is marked with the 'urn:service:sos' Service URN 168 [RFC5031]. The user's VoIP provider receives the emergency call and 169 determines where to route it. Local configuration or a LoST lookup 170 might, in our example, reveal that emergency calls are routed via a 171 dedicated provider FooBar and targeted to a specific entity, referred 172 as esrp1@foobar.com. FooBar does not handle emergency calls itself 173 but performs another resolution step to let calls enter the emergency 174 services network and in this case another resolution step takes place 175 and esrp-a@esinet.org is determined as the recipient, pointing to an 176 edge device at the IP-based emergency services network. Inside the 177 emergency services there might be more sophisticated routing taking 178 place somewhat depending on the existing structure of the emergency 179 services infrastructure. 181 ,-------. 182 +----+ ,' `. 183 | UA |--- urn:service:sos / Emergency \ 184 +----+ \ | Services | 185 \ ,-------. | Network | 186 ,' `. | | 187 / VoIP \ | | 188 ( Provider ) | | 189 \ / | | 190 `. ,' | | 191 '---+---' | +------+ | 192 | | |PSAP | | 193 esrp1@foobar.com | +--+---+ | 194 | | | | 195 | | | | 196 ,---+---. | | | 197 ,' `. | | | 198 / Provider \ | | | 199 + FooBar ) | | | 200 \ / | | | 201 `. ,' | +--+---+ | 202 '---+---' | +-+ESRP | | 203 | | | +------+ | 204 | | | | 205 +------------+-+ | 206 esrp-a@esinet.org | | 207 \ / 208 `. ,' 209 '-------' 211 Figure 2: Example for Multi-Stage Resolution 213 1.3. Call Forwarding 215 Imagine the following case where an emergency call enters an 216 emergency network (state.org) via an ERSP but then gets forwarded to 217 a different emergency services network (in our example to police- 218 town.org, fire-town.org or medic-town.org). The same considerations 219 apply when the the police, fire and ambulance networks are part of 220 the state.org sub-domains (e.g., police.state.org). 222 ,-------. 223 ,' `. 224 / Emergency \ 225 | Services | 226 | Network | 227 | (state.org) | 228 | | 229 | | 230 | +------+ | 231 | |PSAP +--+ | 232 | +--+---+ | | 233 | | | | 234 | | | | 235 | | | | 236 | | | | 237 | | | | 238 | +--+---+ | | 239 ------------------+---+ESRP | | | 240 esrp-a@state.org | +------+ | | 241 | | | 242 | Call Fwd | | 243 | +-+-+---+ | 244 \ | | | / 245 `. | | | ,' 246 '-|-|-|-' ,-------. 247 Police | | | Fire ,' `. 248 +------------+ | +----+ / Emergency \ 249 ,-------. | | | | Services | 250 ,' `. | | | | Network | 251 / Emergency \ | Ambulance | | fire-town.org | 252 | Services | | | | | | 253 | Network | | +----+ | | +------+ | 254 |police-town.org| | ,-------. | +----+---+PSAP | | 255 | | | ,' `. | | +------+ | 256 | +------+ | | / Emergency \ | | | 257 | |PSAP +----+--+ | Services | | | , 258 | +------+ | | Network | | `~~~~~~~~~~~~~~~ 259 | | |medic-town.org | | 260 | , | | | 261 `~~~~~~~~~~~~~~~ | +------+ | | 262 | |PSAP +----+ + 263 | +------+ | 264 | | 265 | , 266 `~~~~~~~~~~~~~~~ 268 Figure 3: Example for Call Forwarding 270 1.4. PSTN Interworking 272 In case an emergency call enters the PSTN, as shown in Figure 4, 273 there is no guarantee that the callback some time later does leave 274 the same PSTN/VoIP gateway or that the same end point identifier is 275 used in the forward as well as in the backward direction making it 276 difficult to reliably detect PSAP callbacks. 278 +-----------+ 279 | PSTN |-------------+ 280 | Calltaker | | 281 | Bob |<--------+ | 282 +-----------+ | v 283 ------------------- 284 //// \\\\ +------------+ 285 | | |PSTN / VoIP | 286 | PSTN |---->|Gateway | 287 \\\\ //// | | 288 ------------------- +----+-------+ 289 ^ | 290 | | 291 +-------------+ | +--------+ 292 | | | |VoIP | 293 | PSTN / VoIP | +->|Service | 294 | Gateway | |Provider| 295 | |<------Invite----| Y | 296 +-------------+ +--------+ 297 | ^ 298 | | 299 Invite Invite 300 | | 301 V | 302 +-------+ 303 | SIP | 304 | UA | 305 | Alice | 306 +-------+ 308 Figure 4: Example for PSTN Interworking 310 1.5. Network-based Service URN Resolution 312 The mechanism described in [I-D.ietf-ecrit-framework] assumes that 313 all devices at the call signaling path store information about the 314 domain of the communication recipient. This is necessary to match 315 the stored domain name against the domain of the sender when an 316 incoming call arrives. 318 However, the IETF emergency services architecture also considers 319 those cases where the resolution from the Service URN to the PSAP URI 320 happens somewhere in the network rather than immediately at the end 321 point itself. In such a case, the end device is therefore not able 322 to match the domain of the sender with any information from the 323 outgoing emergency call. 325 Figure 5 shows this message exchange graphically. 327 ,-------. 328 ,' `. 329 / Emergency \ 330 | Services | 331 | Network | 332 |police-town.org| 333 | | 334 | +------+ | Invite to police.example.com 335 | |PSAP +<---+------------------------+ 336 | | +----+------------------+ ^ 337 | +------+ |Invite from | | 338 | ,police.example.com| | 339 `~~~~~~~~~~~~~~~ v | 340 +--------+ ++-----+-+ 341 | | query |VoIP | 342 | LoST |<-----------------------|Service | 343 | Server | police.example.com |Provider| 344 | |----------------------->| | 345 +--------+ +--------+ 346 | ^ 347 Invite| | Invite 348 from| | to 349 police.example.com| | urn:service:sos 350 V | 351 +-------+ 352 | SIP | 353 | UA | 354 | Alice | 355 +-------+ 357 Figure 5: Example for Network-based Service URN Resolution 359 2. Terminology 361 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 362 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 363 document are to be interpreted as described in [RFC2119]. 365 Emergency services related terminology is borrowed from [RFC5012]. 367 3. Design Approaches 369 The starting point of the investigations is the currently provided 370 functionality in Section 13 of [I-D.ietf-ecrit-framework]. It 371 focuses on identifying a response to a previously made emergency 372 call. As described in the introduction this approach is quite coarse 373 grained since any call from the PSAP's domain is given preferential 374 treatment. This approach is, however, likely going to be practical. 375 Still there are a couple of limitations, as discussed in this 376 document. 378 To expand on the initially provided solution the following 379 description starts with attempt to identify the caller as a PSAP. 380 There are two approaches for accomplishing this functionality. 382 +----------+ 383 | List of |+ 384 | valid || 385 | PSAP ids || 386 +----------+| 387 +----------+ 388 * 389 * whitelist 390 * 391 V 392 Incoming +----------+ Normal 393 SIP Msg | SIP |+ Treatment 394 -------------->| Entity ||=============> 395 + Identity | ||(if not in whitelist) 396 +----------+| 397 +----------+ 398 || 399 || 400 || Preferential 401 || Treatment 402 ++=============> 403 (in whitelist) 405 Figure 6: Identity-based Authorization 407 In Figure 6 an interaction is presented that allows a SIP entity to 408 make a policy decision whether to bypass installed authorization 409 policies and thereby providing preferential treatment. To make this 410 decision the sender's identity is compared with a whitelist of valid 411 PSAPs. The identity assurances in SIP can come in different forms, 412 such as SIP Identity [RFC4474] or with P-Asserted-Identity [RFC3325]. 413 The former technique relies on a cryptographic assurance and the 414 latter on a chain of trust. 416 The establishment of a whitelist with PSAP identities is 417 operationally complex and does not easily scale world wide. When 418 there is a local relationship between the VSP/ASP and the PSAP then 419 populating the whitelist is far simpler. 421 An alternative approach to an identity based authorization model is 422 outlined in Figure 7. In fact, RFC 4484 [RFC4484] already 423 illustrated the basic requirements for this technique. 425 +----------+ 426 | List of |+ 427 | trust || 428 | anchor || 429 +----------+| 430 +----------+ 431 * 432 * 433 * 434 V 435 Incoming +----------+ Normal 436 SIP Msg | SIP |+ Treatment 437 -------------->| Entity ||=============> 438 + trait | ||(no indication 439 +----------+| of PSAP) 440 +----------+ 441 || 442 || 443 || Preferential 444 || Treatment 445 ++=============> 446 (indicated as 447 PSAP) 449 Figure 7: Trait-based Authorization 451 In a trait-based authorization scenario an incoming SIP message 452 contains a form of trait, i.e. some form of assertion. The assertion 453 contains an indication that the sending party has the role of a PSAP 454 (or similar emergency services entity). The assertion is either 455 cryptographically protected to enable end-to-end verification or an 456 chain of trust security model has to be assumed. In Figure 7 we 457 assume an end-to-end security model where trust anchors are 458 provisioned to ensure the ability for a SIP entity to verify the 459 received assertion. 461 From a solution point of view various approaches are feasible, such 462 as SIP SAML (see [I-D.ietf-sip-saml]) or URI Parameters for 463 indicating the Calling Party's Category and Originating Line 464 Information (see [I-D.patel-dispatch-cpc-oli-parameter]). 466 Still, a drawback of the outlined approaches above is that it does 467 not allow any mechanism to distinguish different types of calls 468 initiated by PSAPs. Not every call from a PSAP is indeed a response 469 to an emergency call. 471 This leads us to another mechanism on top of the previously presented 472 onces, namely the indication is that the communication attempt is of 473 emergency nature. As such, it is a slight modification of the one 474 presented previously. In addition to the indication that the calling 475 party is a PSAP there is an expression that the specific call is of 476 emergency services nature. This indication cannot be verified by 477 external parties, similarly to the emergency call marking for a 478 citizen-to-authority emergency call using a Service URN, because it 479 heavily depends on the intention of the call taker itself. 481 4. Topics for Investigation 483 When you make an IP-based emergency call to an IP-based PSAP then the 484 PSAP will get two pieces of identity information about the emergency 485 caller: 487 o Contact-URI: Information that uniquely identifies the device the 488 call came from. 490 o Address of Record: Long-term contact information 492 Should the callback functionality be tied to a previous emergency 493 call setup and as such enabled only for a specific time? For 494 example, preferential treatment for callbacks could be provided only 495 within one hour after the initial emergency call was made. 497 Is it expected that the callback reaches primarily the device that 498 initiated the emergency call? In some cases the device that was used 499 to originally initiate the call does not respond anymore to a 500 callback (e.g. imagine a fixed line phone that was used to report a 501 fire in a house and is out of order soon afterwards). Since the 502 initial emergency call provided a second contact mechanism (namely 503 the address of record) it could be used by the call taker as well. 504 Should this communication also experience the same type of override 505 privilege as the initially transmitted callback to the emergency 506 caller's device? 508 Should any restrictions be made regarding the media being used for 509 callback? Is it acceptable to return an instant message when the 510 caller started the conversation with audio? 512 5. Security Considerations 514 This document provides discussions problems of PSAP callbacks and 515 explores the design space. 517 An important aspect from a security point of view is the relationship 518 between the emergency services network and the VSP (assuming that the 519 emergency call travels via the VSP and not directly between the SIP 520 UA and the PSAP). If there is some form of relationship between the 521 emergency services operator and the VSP then the identification of a 522 PSAP call back is less problematic than in the case where the two 523 entities have not entered in some form of relationship that would 524 allow the VSP to verify whether the marked callback message indeed 525 came from a legitimate source. 527 The main attack surface can be seen in the usage of PSAP callback 528 marking to bypass blacklists, ignore call forwarding procedures and 529 similar features to interact with users and to get their attention. 530 For example, using PSAP callback marking devices would be able to 531 recognize these types of incoming messages leading to the device 532 overriding user interface configurations, such as vibrate-only mode. 533 As such, the requirement is to ensure that the mechanisms described 534 in this document can not be used for malicious purposes, including 535 SPIT. 537 It is important that PSAP callback marked SIP messages, which cannot 538 be verified adequately, are treated like a call that does not have 539 any marking attached instead of failing the call processing 540 procedure. 542 6. Acknowledgements 544 We would like to thank members from the ECRIT working group, in 545 particular Brian Rosen, for their discussions around PSAP callbacks. 546 The working group discussed the topic of callbacks at their virtual 547 interim meeting in February 2010 and the following persons provided 548 valuable input: John Elwell, Bernard Aboba, Cullen Jennings, Keith 549 Drage, Marc Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson, 550 Milan Patel, Janet Gunn. 552 7. References 554 7.1. Informative References 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, March 1997. 559 7.2. Informative References 561 [I-D.ietf-ecrit-framework] 562 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 563 "Framework for Emergency Calling using Internet 564 Multimedia", draft-ietf-ecrit-framework-11 (work in 565 progress), July 2010. 567 [I-D.ietf-sip-saml] 568 Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. 569 Sicker, "SIP SAML Profile and Binding", 570 draft-ietf-sip-saml-07 (work in progress), March 2010. 572 [I-D.patel-dispatch-cpc-oli-parameter] 573 Patel, M., Jesske, R., and M. Dolly, "Uniform Resource 574 Identifier (URI) Parameters for indicating the Calling 575 Party's Category and Originating Line Information", 576 draft-patel-dispatch-cpc-oli-parameter-03 (work in 577 progress), June 2010. 579 [I-D.patel-ecrit-sos-parameter] 580 Patel, M., "SOS Uniform Resource Identifier (URI) 581 Parameter for Marking of Session Initiation Protocol (SIP) 582 Requests related to Emergency Services", 583 draft-patel-ecrit-sos-parameter-09 (work in progress), 584 July 2010. 586 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 587 Extensions to the Session Initiation Protocol (SIP) for 588 Asserted Identity within Trusted Networks", RFC 3325, 589 November 2002. 591 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 592 Authenticated Identity Management in the Session 593 Initiation Protocol (SIP)", RFC 4474, August 2006. 595 [RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, 596 "Trait-Based Authorization Requirements for the Session 597 Initiation Protocol (SIP)", RFC 4484, August 2006. 599 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 600 Emergency Context Resolution with Internet Technologies", 601 RFC 5012, January 2008. 603 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 604 Emergency and Other Well-Known Services", RFC 5031, 605 January 2008. 607 Authors' Addresses 609 Henning Schulzrinne 610 Columbia University 611 Department of Computer Science 612 450 Computer Science Building 613 New York, NY 10027 614 US 616 Phone: +1 212 939 7004 617 Email: hgs+ecrit@cs.columbia.edu 618 URI: http://www.cs.columbia.edu 620 Hannes Tschofenig 621 Nokia Siemens Networks 622 Linnoitustie 6 623 Espoo 02600 624 Finland 626 Phone: +358 (50) 4871445 627 Email: Hannes.Tschofenig@gmx.net 628 URI: http://www.tschofenig.priv.at 630 Milan Patel 631 Nortel 632 Maidenhead Office Park, Westacott Way 633 Maidenhead SL6 3QH 634 UK 636 Email: milanpa@nortel.com