idnits 2.17.1 draft-ietf-ecrit-psap-callback-01.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 : ---------------------------------------------------------------------------- == 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 (October 25, 2010) is 4926 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-sip-saml' is defined on line 546, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-11 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 0 errors (**), 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 H. Tschofenig 5 Expires: April 28, 2011 Nokia Siemens Networks 6 M. Patel 7 Nortel 8 October 25, 2010 10 Public Safety Answering Point (PSAP) Callbacks 11 draft-ietf-ecrit-psap-callback-01.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 illustrates an extension. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 28, 2011. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Routing Asymmetry . . . . . . . . . . . . . . . . . . . . 3 66 1.2. Multi-Stage Resolution . . . . . . . . . . . . . . . . . . 4 67 1.3. Call Forwarding . . . . . . . . . . . . . . . . . . . . . 5 68 1.4. PSTN Interworking . . . . . . . . . . . . . . . . . . . . 7 69 1.5. Network-based Service URN Resolution . . . . . . . . . . . 7 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4. Callback Marking . . . . . . . . . . . . . . . . . . . . . . . 12 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 8.1. Informative References . . . . . . . . . . . . . . . . . . 16 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 81 1. Introduction 83 Summoning police, the fire department or an ambulance in emergencies 84 is one of the fundamental and most-valued functions of the telephone. 85 As telephone functionality moves from circuit-switched telephony to 86 Internet telephony, its users rightfully expect that this core 87 functionality will continue to work at least as well as it has for 88 the legacy technology. New devices and services are being made 89 available that could be used to make a request for help, which are 90 not traditional telephones, and users are increasingly expecting them 91 to be used to place emergency calls. 93 Regulatory requirements demand that the emergency call itself 94 provides enough information to allow the call-taker to initiate a 95 call back to the emergency caller in case the call dropped or to 96 interact with the emergency caller in case of further questions. 97 Such a call, referred as PSAP callback subsequently in this document, 98 may, however, be blocked or forwarded to an answering machine as SIP 99 entities (SIP proxies as well as the SIP UA itself) cannot associate 100 the potential importantance of the call based on the SIP signaling. 102 Note that the authors are, however, not aware of regulatory 103 requirements for providing preferential treatment of callbacks 104 initiated by the call-taker at the PSAP towards the emergency 105 caller. 107 Section 10 of [I-D.ietf-ecrit-framework] discusses the identifiers 108 required for callbacks, namely AOR URI and a globally routable URI in 109 a Contact: header. Section 13 of [I-D.ietf-ecrit-framework] provides 110 the following guidance regarding callback handling: 112 A UA may be able to determine a PSAP call back by examining the 113 domain of incoming calls after placing an emergency call and 114 comparing that to the domain of the answering PSAP from the 115 emergency call. Any call from the same domain and directed to the 116 supplied Contact header or AoR after an emergency call should be 117 accepted as a call-back from the PSAP if it occurs within a 118 reasonable time after an emergency call was placed. 120 This approach mimics a stateful packet filtering firewall and is 121 indeed helpful in a number of cases. It is also relatively simple to 122 implement. Below, we discuss a few cases where this approach fails. 124 1.1. Routing Asymmetry 126 In some deployment environments it is common to have incoming and 127 outgoing SIP messaging to use different routes. 129 ,-------. 130 ,' `. 131 ,-------. / Emergency \ 132 ,' `. | Services | 133 / VoIP \ I | Network | 134 | Provider | n | | 135 | | t | | 136 | | e | | 137 | +-------+ | r | | 138 +--+---|Inbound|<--+-----m | | 139 | | |Proxy | | e | +------+ | 140 | | +-------+ | d | |PSAP | | 141 | | | i | +--+---+ | 142 +----+ | | | a-+ | | | 143 | UA |<---+ | | t | | | | 144 | |----+ | | e | | | | 145 +----+ | | | | | | | 146 | | | P | | | | 147 | | | r | | | | 148 | | +--------+ | o | | | | 149 +--+-->|Outbound|--+---->v | | +--+---+ | 150 | |Proxy | | i | | +-+ESRP | | 151 | +--------+ | d | | | +------+ | 152 | | e || | | 153 | | r |+-+ | 154 \ / | | 155 `. ,' \ / 156 '-------' `. ,' 157 '-------' 159 Figure 1: Example for Routing Asymmetry 161 1.2. Multi-Stage Resolution 163 Consider the following emergency call routing scenario shown in 164 Figure 2 where routing towards the PSAP occurs in several stages. An 165 emergency call uses a SIP UA that does not run LoST on the end point. 166 Hence, the call is marked with the 'urn:service:sos' Service URN 167 [RFC5031]. The user's VoIP provider receives the emergency call and 168 determines where to route it. Local configuration or a LoST lookup 169 might, in our example, reveal that emergency calls are routed via a 170 dedicated provider FooBar and targeted to a specific entity, referred 171 as esrp1@foobar.com. FooBar does not handle emergency calls itself 172 but performs another resolution step to let calls enter the emergency 173 services network and in this case another resolution step takes place 174 and esrp-a@esinet.org is determined as the recipient, pointing to an 175 edge device at the IP-based emergency services network. Inside the 176 emergency services there might be more sophisticated routing taking 177 place somewhat depending on the existing structure of the emergency 178 services infrastructure. 180 ,-------. 181 +----+ ,' `. 182 | UA |--- urn:service:sos / Emergency \ 183 +----+ \ | Services | 184 \ ,-------. | Network | 185 ,' `. | | 186 / VoIP \ | | 187 ( Provider ) | | 188 \ / | | 189 `. ,' | | 190 '---+---' | +------+ | 191 | | |PSAP | | 192 esrp1@foobar.com | +--+---+ | 193 | | | | 194 | | | | 195 ,---+---. | | | 196 ,' `. | | | 197 / Provider \ | | | 198 + FooBar ) | | | 199 \ / | | | 200 `. ,' | +--+---+ | 201 '---+---' | +-+ESRP | | 202 | | | +------+ | 203 | | | | 204 +------------+-+ | 205 esrp-a@esinet.org | | 206 \ / 207 `. ,' 208 '-------' 210 Figure 2: Example for Multi-Stage Resolution 212 1.3. Call Forwarding 214 Imagine the following case where an emergency call enters an 215 emergency network (state.org) via an ERSP but then gets forwarded to 216 a different emergency services network (in our example to police- 217 town.org, fire-town.org or medic-town.org). The same considerations 218 apply when the the police, fire and ambulance networks are part of 219 the state.org sub-domains (e.g., police.state.org). 221 ,-------. 222 ,' `. 223 / Emergency \ 224 | Services | 225 | Network | 226 | (state.org) | 227 | | 228 | | 229 | +------+ | 230 | |PSAP +--+ | 231 | +--+---+ | | 232 | | | | 233 | | | | 234 | | | | 235 | | | | 236 | | | | 237 | +--+---+ | | 238 ------------------+---+ESRP | | | 239 esrp-a@state.org | +------+ | | 240 | | | 241 | Call Fwd | | 242 | +-+-+---+ | 243 \ | | | / 244 `. | | | ,' 245 '-|-|-|-' ,-------. 246 Police | | | Fire ,' `. 247 +------------+ | +----+ / Emergency \ 248 ,-------. | | | | Services | 249 ,' `. | | | | Network | 250 / Emergency \ | Ambulance | | fire-town.org | 251 | Services | | | | | | 252 | Network | | +----+ | | +------+ | 253 |police-town.org| | ,-------. | +----+---+PSAP | | 254 | | | ,' `. | | +------+ | 255 | +------+ | | / Emergency \ | | | 256 | |PSAP +----+--+ | Services | | | , 257 | +------+ | | Network | | `~~~~~~~~~~~~~~~ 258 | | |medic-town.org | | 259 | , | | | 260 `~~~~~~~~~~~~~~~ | +------+ | | 261 | |PSAP +----+ + 262 | +------+ | 263 | | 264 | , 265 `~~~~~~~~~~~~~~~ 267 Figure 3: Example for Call Forwarding 269 1.4. PSTN Interworking 271 In case an emergency call enters the PSTN, as shown in Figure 4, 272 there is no guarantee that the callback some time later does leave 273 the same PSTN/VoIP gateway or that the same end point identifier is 274 used in the forward as well as in the backward direction making it 275 difficult to reliably detect PSAP callbacks. 277 +-----------+ 278 | PSTN |-------------+ 279 | Calltaker | | 280 | Bob |<--------+ | 281 +-----------+ | v 282 ------------------- 283 //// \\\\ +------------+ 284 | | |PSTN / VoIP | 285 | PSTN |---->|Gateway | 286 \\\\ //// | | 287 ------------------- +----+-------+ 288 ^ | 289 | | 290 +-------------+ | +--------+ 291 | | | |VoIP | 292 | PSTN / VoIP | +->|Service | 293 | Gateway | |Provider| 294 | |<------Invite----| Y | 295 +-------------+ +--------+ 296 | ^ 297 | | 298 Invite Invite 299 | | 300 V | 301 +-------+ 302 | SIP | 303 | UA | 304 | Alice | 305 +-------+ 307 Figure 4: Example for PSTN Interworking 309 1.5. Network-based Service URN Resolution 311 The mechanism described in [I-D.ietf-ecrit-framework] assumes that 312 all devices at the call signaling path store information about the 313 domain of the communication recipient. This is necessary to match 314 the stored domain name against the domain of the sender when an 315 incoming call arrives. 317 However, the IETF emergency services architecture also considers 318 those cases where the resolution from the Service URN to the PSAP URI 319 happens somewhere in the network rather than immediately at the end 320 point itself. In such a case, the end device is therefore not able 321 to match the domain of the sender with any information from the 322 outgoing emergency call. 324 Figure 5 shows this message exchange graphically. 326 ,-------. 327 ,' `. 328 / Emergency \ 329 | Services | 330 | Network | 331 |police-town.org| 332 | | 333 | +------+ | Invite to police.example.com 334 | |PSAP +<---+------------------------+ 335 | | +----+------------------+ ^ 336 | +------+ |Invite from | | 337 | ,police.example.com| | 338 `~~~~~~~~~~~~~~~ v | 339 +--------+ ++-----+-+ 340 | | query |VoIP | 341 | LoST |<-----------------------|Service | 342 | Server | police.example.com |Provider| 343 | |----------------------->| | 344 +--------+ +--------+ 345 | ^ 346 Invite| | Invite 347 from| | to 348 police.example.com| | urn:service:sos 349 V | 350 +-------+ 351 | SIP | 352 | UA | 353 | Alice | 354 +-------+ 356 Figure 5: Example for Network-based Service URN Resolution 358 2. Terminology 360 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 361 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 362 document are to be interpreted as described in [RFC2119]. 364 Emergency services related terminology is borrowed from [RFC5012]. 366 3. Architecture 368 Section 4 describes how to mark a call as a callback. However, the 369 pure emergency service callback marking is insufficient since it 370 lacks any built-in security mechanism. Fortunately, available SIP 371 security techniques for the purpose of authorization can be re-used, 372 as described in the rest of the section. 374 In Figure 6 an interaction is presented that allows a SIP entity to 375 make a policy decision whether to bypass installed authorization 376 policies and thereby providing preferential treatment. To make this 377 decision the sender's identity is compared with a whitelist of valid 378 PSAPs. The identity assurances in SIP can come in different forms, 379 such as SIP Identity [RFC4474] or with P-Asserted-Identity [RFC3325]. 380 The former technique relies on a cryptographic assurance and the 381 latter on a chain of trust. 383 +----------+ 384 | List of |+ 385 | valid || 386 | PSAP ids || 387 +----------+| 388 +----------+ 389 * 390 * whitelist 391 * 392 V 393 Incoming +----------+ Normal 394 SIP Msg | SIP |+ Treatment 395 -------------->| Entity ||=============> 396 + Identity | ||(if not in whitelist) 397 +----------+| 398 +----------+ 399 || 400 || 401 || Preferential 402 || Treatment 403 ++=============> 404 (in whitelist) 406 Figure 6: Identity-based Authorization 408 The establishment of a whitelist with PSAP identities is 409 operationally complex and does not easily scale world wide. When 410 there is a local relationship between the VSP/ASP and the PSAP then 411 populating the whitelist is far simpler. 413 An alternative approach to an identity based authorization model is 414 outlined in Figure 7. In fact, RFC 4484 [RFC4484] already 415 illustrated the basic requirements for this technique. 417 +----------+ 418 | List of |+ 419 | trust || 420 | anchor || 421 +----------+| 422 +----------+ 423 * 424 * 425 * 426 V 427 Incoming +----------+ Normal 428 SIP Msg | SIP |+ Treatment 429 -------------->| Entity ||=============> 430 + trait | ||(no indication 431 +----------+| of PSAP) 432 +----------+ 433 || 434 || 435 || Preferential 436 || Treatment 437 ++=============> 438 (indicated as 439 PSAP) 441 Figure 7: Trait-based Authorization 443 In a trait-based authorization scenario an incoming SIP message 444 contains a form of trait, i.e. some form of assertion. The assertion 445 contains an indication that the sending party has the role of a PSAP 446 (or similar emergency services entity). The assertion is either 447 cryptographically protected to enable end-to-end verification or an 448 chain of trust security model has to be assumed. In Figure 7 we 449 assume an end-to-end security model where trust anchors are 450 provisioned to ensure the ability for a SIP entity to verify the 451 received assertion. 453 4. Callback Marking 455 The callback marking is represented as URI parameter for an URI 456 scheme. The ABNF [RFC5234] syntax is as follows. The 'par' 457 production is defined in RFC 3966 [RFC3966]. The "/=" syntax 458 indicates an extension of the production on the left-hand side: 460 par /= callback 462 callback = callback-tag "=" callback-value 464 callback-tag = "callback" 466 callback-value = "normal" / "test" / 468 The semantics of the callback values are described below: 470 normal: This represents an normal PSAP callback. 472 test: This is a test callback. 474 An example of the "callback" parameter is given below: 476 From: ;tag=1928301774 478 5. Security Considerations 480 This document defines a callback marking scheme using URI parameters 481 and illustrates how to handle authorization for preferential 482 treatment. 484 An important aspect from a security point of view is the relationship 485 between the emergency services network and the VSP (assuming that the 486 emergency call travels via the VSP and not directly between the SIP 487 UA and the PSAP). If there is some form of relationship between the 488 emergency services operator and the VSP then the identification of a 489 PSAP call back is less problematic than in the case where the two 490 entities have not entered in some form of relationship that would 491 allow the VSP to verify whether the marked callback message indeed 492 came from a legitimate source. 494 The main attack surface can be seen in the usage of PSAP callback 495 marking to bypass blacklists, ignore call forwarding procedures and 496 similar features to interact with users and to get their attention. 497 For example, using PSAP callback marking devices would be able to 498 recognize these types of incoming messages leading to the device 499 overriding user interface configurations, such as vibrate-only mode. 500 As such, the requirement is to ensure that the mechanisms described 501 in this document can not be used for malicious purposes, including 502 SPIT. 504 It is important that PSAP callback marked SIP messages, which cannot 505 be verified adequately, are treated like a call that does not have 506 any marking attached instead of failing the call processing 507 procedure. 509 6. IANA Considerations 511 This document extends the registry of URI parameters, as defined RFC 512 3969 [RFC3969]. Two new URI parameters are defined in this document 513 as follows: 515 Parameter Name: callback 517 Predefined Values: Yes 519 Reference: This document 521 7. Acknowledgements 523 We would like to thank members from the ECRIT working group, in 524 particular Brian Rosen, for their discussions around PSAP callbacks. 525 The working group discussed the topic of callbacks at their virtual 526 interim meeting in February 2010 and the following persons provided 527 valuable input: John Elwell, Bernard Aboba, Cullen Jennings, Keith 528 Drage, Marc Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson, 529 Milan Patel, Janet Gunn. 531 8. References 533 8.1. Informative References 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, March 1997. 538 8.2. Informative References 540 [I-D.ietf-ecrit-framework] 541 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 542 "Framework for Emergency Calling using Internet 543 Multimedia", draft-ietf-ecrit-framework-11 (work in 544 progress), July 2010. 546 [I-D.ietf-sip-saml] 547 Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. 548 Sicker, "SIP SAML Profile and Binding", 549 draft-ietf-sip-saml-08 (work in progress), October 2010. 551 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 552 Extensions to the Session Initiation Protocol (SIP) for 553 Asserted Identity within Trusted Networks", RFC 3325, 554 November 2002. 556 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 557 RFC 3966, December 2004. 559 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 560 (IANA) Uniform Resource Identifier (URI) Parameter 561 Registry for the Session Initiation Protocol (SIP)", 562 BCP 99, RFC 3969, December 2004. 564 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 565 Authenticated Identity Management in the Session 566 Initiation Protocol (SIP)", RFC 4474, August 2006. 568 [RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, 569 "Trait-Based Authorization Requirements for the Session 570 Initiation Protocol (SIP)", RFC 4484, August 2006. 572 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 573 Emergency Context Resolution with Internet Technologies", 574 RFC 5012, January 2008. 576 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 577 Emergency and Other Well-Known Services", RFC 5031, 578 January 2008. 580 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 581 Specifications: ABNF", STD 68, RFC 5234, January 2008. 583 Authors' Addresses 585 Henning Schulzrinne 586 Columbia University 587 Department of Computer Science 588 450 Computer Science Building 589 New York, NY 10027 590 US 592 Phone: +1 212 939 7004 593 Email: hgs+ecrit@cs.columbia.edu 594 URI: http://www.cs.columbia.edu 596 Hannes Tschofenig 597 Nokia Siemens Networks 598 Linnoitustie 6 599 Espoo 02600 600 Finland 602 Phone: +358 (50) 4871445 603 Email: Hannes.Tschofenig@gmx.net 604 URI: http://www.tschofenig.priv.at 606 Milan Patel 607 Nortel 608 Maidenhead Office Park, Westacott Way 609 Maidenhead SL6 3QH 610 UK 612 Email: milanpa@nortel.com