idnits 2.17.1 draft-ietf-ecrit-psap-callback-02.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (November 5, 2010) is 4919 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-sip-saml' is defined on line 618, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-12 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: May 9, 2011 Nokia Siemens Networks 6 M. Patel 7 InterDigital Communications 8 November 5, 2010 10 Public Safety Answering Point (PSAP) Callbacks 11 draft-ietf-ecrit-psap-callback-02.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 May 9, 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 4.1. Tel URI . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.2. SIP URI . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 83 1. Introduction 85 Summoning police, the fire department or an ambulance in emergencies 86 is one of the fundamental and most-valued functions of the telephone. 87 As telephone functionality moves from circuit-switched telephony to 88 Internet telephony, its users rightfully expect that this core 89 functionality will continue to work at least as well as it has for 90 the legacy technology. New devices and services are being made 91 available that could be used to make a request for help, which are 92 not traditional telephones, and users are increasingly expecting them 93 to be used to place emergency calls. 95 Regulatory requirements demand that the emergency call itself 96 provides enough information to allow the call-taker to initiate a 97 call back to the emergency caller in case the call dropped or to 98 interact with the emergency caller in case of further questions. 99 Such a call, referred as PSAP callback subsequently in this document, 100 may, however, be blocked or forwarded to an answering machine as SIP 101 entities (SIP proxies as well as the SIP UA itself) cannot associate 102 the potential importantance of the call based on the SIP signaling. 104 Note that the authors are, however, not aware of regulatory 105 requirements for providing preferential treatment of callbacks 106 initiated by the call-taker at the PSAP towards the emergency 107 caller. 109 Section 10 of [I-D.ietf-ecrit-framework] discusses the identifiers 110 required for callbacks, namely AOR URI and a globally routable URI in 111 a Contact: header. Section 13 of [I-D.ietf-ecrit-framework] provides 112 the following guidance regarding callback handling: 114 A UA may be able to determine a PSAP call back by examining the 115 domain of incoming calls after placing an emergency call and 116 comparing that to the domain of the answering PSAP from the 117 emergency call. Any call from the same domain and directed to the 118 supplied Contact header or AoR after an emergency call should be 119 accepted as a call-back from the PSAP if it occurs within a 120 reasonable time after an emergency call was placed. 122 This approach mimics a stateful packet filtering firewall and is 123 indeed helpful in a number of cases. It is also relatively simple to 124 implement. Below, we discuss a few cases where this approach fails. 126 1.1. Routing Asymmetry 128 In some deployment environments it is common to have incoming and 129 outgoing SIP messaging to use different routes. 131 ,-------. 132 ,' `. 133 ,-------. / Emergency \ 134 ,' `. | Services | 135 / VoIP \ I | Network | 136 | Provider | n | | 137 | | t | | 138 | | e | | 139 | +-------+ | r | | 140 +--+---|Inbound|<--+-----m | | 141 | | |Proxy | | e | +------+ | 142 | | +-------+ | d | |PSAP | | 143 | | | i | +--+---+ | 144 +----+ | | | a-+ | | | 145 | UA |<---+ | | t | | | | 146 | |----+ | | e | | | | 147 +----+ | | | | | | | 148 | | | P | | | | 149 | | | r | | | | 150 | | +--------+ | o | | | | 151 +--+-->|Outbound|--+---->v | | +--+---+ | 152 | |Proxy | | i | | +-+ESRP | | 153 | +--------+ | d | | | +------+ | 154 | | e || | | 155 | | r |+-+ | 156 \ / | | 157 `. ,' \ / 158 '-------' `. ,' 159 '-------' 161 Figure 1: Example for Routing Asymmetry 163 1.2. Multi-Stage Resolution 165 Consider the following emergency call routing scenario shown in 166 Figure 2 where routing towards the PSAP occurs in several stages. An 167 emergency call uses a SIP UA that does not run LoST on the end point. 168 Hence, the call is marked with the 'urn:service:sos' Service URN 169 [RFC5031]. The user's VoIP provider receives the emergency call and 170 determines where to route it. Local configuration or a LoST lookup 171 might, in our example, reveal that emergency calls are routed via a 172 dedicated provider FooBar and targeted to a specific entity, referred 173 as esrp1@foobar.com. FooBar does not handle emergency calls itself 174 but performs another resolution step to let calls enter the emergency 175 services network and in this case another resolution step takes place 176 and esrp-a@esinet.org is determined as the recipient, pointing to an 177 edge device at the IP-based emergency services network. Inside the 178 emergency services there might be more sophisticated routing taking 179 place somewhat depending on the existing structure of the emergency 180 services infrastructure. 182 ,-------. 183 +----+ ,' `. 184 | UA |--- urn:service:sos / Emergency \ 185 +----+ \ | Services | 186 \ ,-------. | Network | 187 ,' `. | | 188 / VoIP \ | | 189 ( Provider ) | | 190 \ / | | 191 `. ,' | | 192 '---+---' | +------+ | 193 | | |PSAP | | 194 esrp1@foobar.com | +--+---+ | 195 | | | | 196 | | | | 197 ,---+---. | | | 198 ,' `. | | | 199 / Provider \ | | | 200 + FooBar ) | | | 201 \ / | | | 202 `. ,' | +--+---+ | 203 '---+---' | +-+ESRP | | 204 | | | +------+ | 205 | | | | 206 +------------+-+ | 207 esrp-a@esinet.org | | 208 \ / 209 `. ,' 210 '-------' 212 Figure 2: Example for Multi-Stage Resolution 214 1.3. Call Forwarding 216 Imagine the following case where an emergency call enters an 217 emergency network (state.org) via an ERSP but then gets forwarded to 218 a different emergency services network (in our example to police- 219 town.org, fire-town.org or medic-town.org). The same considerations 220 apply when the the police, fire and ambulance networks are part of 221 the state.org sub-domains (e.g., police.state.org). 223 ,-------. 224 ,' `. 225 / Emergency \ 226 | Services | 227 | Network | 228 | (state.org) | 229 | | 230 | | 231 | +------+ | 232 | |PSAP +--+ | 233 | +--+---+ | | 234 | | | | 235 | | | | 236 | | | | 237 | | | | 238 | | | | 239 | +--+---+ | | 240 ------------------+---+ESRP | | | 241 esrp-a@state.org | +------+ | | 242 | | | 243 | Call Fwd | | 244 | +-+-+---+ | 245 \ | | | / 246 `. | | | ,' 247 '-|-|-|-' ,-------. 248 Police | | | Fire ,' `. 249 +------------+ | +----+ / Emergency \ 250 ,-------. | | | | Services | 251 ,' `. | | | | Network | 252 / Emergency \ | Ambulance | | fire-town.org | 253 | Services | | | | | | 254 | Network | | +----+ | | +------+ | 255 |police-town.org| | ,-------. | +----+---+PSAP | | 256 | | | ,' `. | | +------+ | 257 | +------+ | | / Emergency \ | | | 258 | |PSAP +----+--+ | Services | | | , 259 | +------+ | | Network | | `~~~~~~~~~~~~~~~ 260 | | |medic-town.org | | 261 | , | | | 262 `~~~~~~~~~~~~~~~ | +------+ | | 263 | |PSAP +----+ + 264 | +------+ | 265 | | 266 | , 267 `~~~~~~~~~~~~~~~ 269 Figure 3: Example for Call Forwarding 271 1.4. PSTN Interworking 273 In case an emergency call enters the PSTN, as shown in Figure 4, 274 there is no guarantee that the callback some time later does leave 275 the same PSTN/VoIP gateway or that the same end point identifier is 276 used in the forward as well as in the backward direction making it 277 difficult to reliably detect PSAP callbacks. 279 +-----------+ 280 | PSTN |-------------+ 281 | Calltaker | | 282 | Bob |<--------+ | 283 +-----------+ | v 284 ------------------- 285 //// \\\\ +------------+ 286 | | |PSTN / VoIP | 287 | PSTN |---->|Gateway | 288 \\\\ //// | | 289 ------------------- +----+-------+ 290 ^ | 291 | | 292 +-------------+ | +--------+ 293 | | | |VoIP | 294 | PSTN / VoIP | +->|Service | 295 | Gateway | |Provider| 296 | |<------Invite----| Y | 297 +-------------+ +--------+ 298 | ^ 299 | | 300 Invite Invite 301 | | 302 V | 303 +-------+ 304 | SIP | 305 | UA | 306 | Alice | 307 +-------+ 309 Figure 4: Example for PSTN Interworking 311 1.5. Network-based Service URN Resolution 313 The mechanism described in [I-D.ietf-ecrit-framework] assumes that 314 all devices at the call signaling path store information about the 315 domain of the communication recipient. This is necessary to match 316 the stored domain name against the domain of the sender when an 317 incoming call arrives. 319 However, the IETF emergency services architecture also considers 320 those cases where the resolution from the Service URN to the PSAP URI 321 happens somewhere in the network rather than immediately at the end 322 point itself. In such a case, the end device is therefore not able 323 to match the domain of the sender with any information from the 324 outgoing emergency call. 326 Figure 5 shows this message exchange graphically. 328 ,-------. 329 ,' `. 330 / Emergency \ 331 | Services | 332 | Network | 333 |police-town.org| 334 | | 335 | +------+ | Invite to police.example.com 336 | |PSAP +<---+------------------------+ 337 | | +----+------------------+ ^ 338 | +------+ |Invite from | | 339 | ,police.example.com| | 340 `~~~~~~~~~~~~~~~ v | 341 +--------+ ++-----+-+ 342 | | query |VoIP | 343 | LoST |<-----------------------|Service | 344 | Server | police.example.com |Provider| 345 | |----------------------->| | 346 +--------+ +--------+ 347 | ^ 348 Invite| | Invite 349 from| | to 350 police.example.com| | urn:service:sos 351 V | 352 +-------+ 353 | SIP | 354 | UA | 355 | Alice | 356 +-------+ 358 Figure 5: Example for Network-based Service URN Resolution 360 2. Terminology 362 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 363 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 364 document are to be interpreted as described in [RFC2119]. 366 Emergency services related terminology is borrowed from [RFC5012]. 368 3. Architecture 370 Section 4 describes how to mark a call as a callback. However, the 371 pure emergency service callback marking is insufficient since it 372 lacks any built-in security mechanism. Fortunately, available SIP 373 security techniques for the purpose of authorization can be re-used, 374 as described in the rest of the section. 376 In Figure 6 an interaction is presented that allows a SIP entity to 377 make a policy decision whether to bypass installed authorization 378 policies and thereby providing preferential treatment. To make this 379 decision the sender's identity is compared with a whitelist of valid 380 PSAPs. The identity assurances in SIP can come in different forms, 381 such as SIP Identity [RFC4474] or with P-Asserted-Identity [RFC3325]. 382 The former technique relies on a cryptographic assurance and the 383 latter on a chain of trust. 385 +----------+ 386 | List of |+ 387 | valid || 388 | PSAP ids || 389 +----------+| 390 +----------+ 391 * 392 * whitelist 393 * 394 V 395 Incoming +----------+ Normal 396 SIP Msg | SIP |+ Treatment 397 -------------->| Entity ||=============> 398 + Identity | ||(if not in whitelist) 399 +----------+| 400 +----------+ 401 || 402 || 403 || Preferential 404 || Treatment 405 ++=============> 406 (in whitelist) 408 Figure 6: Identity-based Authorization 410 The establishment of a whitelist with PSAP identities is 411 operationally complex and does not easily scale world wide. When 412 there is a local relationship between the VSP/ASP and the PSAP then 413 populating the whitelist is far simpler. 415 An alternative approach to an identity based authorization model is 416 outlined in Figure 7. In fact, RFC 4484 [RFC4484] already 417 illustrated the basic requirements for this technique. 419 +----------+ 420 | List of |+ 421 | trust || 422 | anchor || 423 +----------+| 424 +----------+ 425 * 426 * 427 * 428 V 429 Incoming +----------+ Normal 430 SIP Msg | SIP |+ Treatment 431 -------------->| Entity ||=============> 432 + trait | ||(no indication 433 +----------+| of PSAP) 434 +----------+ 435 || 436 || 437 || Preferential 438 || Treatment 439 ++=============> 440 (indicated as 441 PSAP) 443 Figure 7: Trait-based Authorization 445 In a trait-based authorization scenario an incoming SIP message 446 contains a form of trait, i.e. some form of assertion. The assertion 447 contains an indication that the sending party has the role of a PSAP 448 (or similar emergency services entity). The assertion is either 449 cryptographically protected to enable end-to-end verification or an 450 chain of trust security model has to be assumed. In Figure 7 we 451 assume an end-to-end security model where trust anchors are 452 provisioned to ensure the ability for a SIP entity to verify the 453 received assertion. 455 4. Callback Marking 457 The callback marking is represented as URI parameter for an URI 458 scheme. The ABNF [RFC5234] syntax is shown below. 460 4.1. Tel URI 462 The 'par' production is defined in RFC 3966 [RFC3966]. The "/=" 463 syntax indicates an extension of the production on the left-hand 464 side: 466 par /= callback 468 callback = callback-tag "=" callback-value 470 callback-tag = "callback" 472 callback-value = "normal" / "test" / 474 The semantics of the callback values are described below: 476 normal: This represents an normal PSAP callback. 478 test: This is a test callback. 480 An example of the "callback" parameter is given below: 482 P-Asserted-Identity: 484 4.2. SIP URI 486 The 'uri-parameter' production is defined in RFC 3966 [RFC3261]. The 487 "/=" syntax indicates an extension of the production on the left-hand 488 side: 490 uri-parameter =/ callback 492 callback = callback-tag "=" callback-value 494 callback-tag = "callback" 496 callback-value = "normal" / "test" / 498 The semantics of the callback values are described below: 500 normal: This represents an normal PSAP callback. 502 test: This is a test callback. 504 An example of the "callback" parameter is given below: 506 P-Asserted-Identity: 508 5. Security Considerations 510 This document defines a callback marking scheme using URI parameters 511 and illustrates how to handle authorization for preferential 512 treatment. The URI parameter that is included for a URI MUST be used 513 in concert with either the PAI [RFC3325] or the SIP Identity 514 [RFC4474] header. A pure From header does not provide security 515 assurance that the calling party is indeed a PSAP. 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 A SIP entity MAY treat the call as a normal incoming call if it 538 considers the request with the included URI parameter to be 539 fraudulent, i.e. if it does not recognize the originator, or the 540 domain from where the call originated from as being trusted/owned by 541 a PSAP. It is NOT RECOMMENDED to drop a call that is marked as PSAP 542 callback in such a case since this may severely impact the ability 543 for calltakers at PSAPs to contact emergency callers. 545 6. IANA Considerations 547 This document extends the registry of URI parameters for SIP, as 548 defined in RFC 3969 [RFC3969]. A new SIP URI parameter is defined in 549 this document as follows: 551 Parameter Name: callback 553 Predefined Values: Yes 555 Reference: This document 557 This document extends the registry of Tel URI parameters for SIP, as 558 defined in RFC 5341[RFC5341]. A new Tel URI parameter is defined in 559 this document as follows: 561 Parameter Name: callback 563 Predefined Values: Yes 565 Reference: This document 567 7. Acknowledgements 569 We would like to thank members from the ECRIT working group, in 570 particular Brian Rosen, for their discussions around PSAP callbacks. 571 The working group discussed the topic of callbacks at their virtual 572 interim meeting in February 2010 and the following persons provided 573 valuable input: John Elwell, Bernard Aboba, Cullen Jennings, Keith 574 Drage, Marc Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson, 575 Janet Gunn. 577 8. References 579 8.1. Normative References 581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 582 Requirement Levels", BCP 14, RFC 2119, March 1997. 584 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 585 A., Peterson, J., Sparks, R., Handley, M., and E. 586 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 587 June 2002. 589 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 590 Extensions to the Session Initiation Protocol (SIP) for 591 Asserted Identity within Trusted Networks", RFC 3325, 592 November 2002. 594 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 595 RFC 3966, December 2004. 597 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 598 (IANA) Uniform Resource Identifier (URI) Parameter 599 Registry for the Session Initiation Protocol (SIP)", 600 BCP 99, RFC 3969, December 2004. 602 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 603 Authenticated Identity Management in the Session 604 Initiation Protocol (SIP)", RFC 4474, August 2006. 606 [RFC5341] Jennings, C. and V. Gurbani, "The Internet Assigned Number 607 Authority (IANA) tel Uniform Resource Identifier (URI) 608 Parameter Registry", September 2008. 610 8.2. Informative References 612 [I-D.ietf-ecrit-framework] 613 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 614 "Framework for Emergency Calling using Internet 615 Multimedia", draft-ietf-ecrit-framework-12 (work in 616 progress), October 2010. 618 [I-D.ietf-sip-saml] 619 Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. 620 Sicker, "SIP SAML Profile and Binding", 621 draft-ietf-sip-saml-08 (work in progress), October 2010. 623 [RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, 624 "Trait-Based Authorization Requirements for the Session 625 Initiation Protocol (SIP)", RFC 4484, August 2006. 627 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 628 Emergency Context Resolution with Internet Technologies", 629 RFC 5012, January 2008. 631 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 632 Emergency and Other Well-Known Services", RFC 5031, 633 January 2008. 635 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 636 Specifications: ABNF", STD 68, RFC 5234, January 2008. 638 Authors' Addresses 640 Henning Schulzrinne 641 Columbia University 642 Department of Computer Science 643 450 Computer Science Building 644 New York, NY 10027 645 US 647 Phone: +1 212 939 7004 648 Email: hgs+ecrit@cs.columbia.edu 649 URI: http://www.cs.columbia.edu 651 Hannes Tschofenig 652 Nokia Siemens Networks 653 Linnoitustie 6 654 Espoo 02600 655 Finland 657 Phone: +358 (50) 4871445 658 Email: Hannes.Tschofenig@gmx.net 659 URI: http://www.tschofenig.priv.at 661 Milan Patel 662 InterDigital Communications 664 Email: Milan.Patel@interdigital.com