idnits 2.17.00 (12 Aug 2021) /tmp/idnits26107/draft-ietf-ecrit-psap-callback-03.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 27, 2011) is 3858 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3966' is defined on line 472, but no explicit reference was found in the text == Unused Reference: 'RFC3969' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'RFC5341' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sip-saml' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'RFC5031' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 557, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3325 ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) -- No information found for draft-holmberg-emergency-callback-id - is the name correct? == Outdated reference: draft-ietf-ecrit-framework has been published as RFC 6443 == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 Summary: 2 errors (**), 0 flaws (~~), 11 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: Standards Track H. Tschofenig 5 Expires: April 29, 2012 Nokia Siemens Networks 6 C. Holmberg 7 Ericsson 8 M. Patel 9 InterDigital Communications 10 October 27, 2011 12 Public Safety Answering Point (PSAP) Callback 13 draft-ietf-ecrit-psap-callback-03.txt 15 Abstract 17 After an emergency call is completed (either prematurely terminated 18 by the emergency caller or normally by the call-taker) it is possible 19 that the call-taker feels the need for further communication. For 20 example, the call may have been dropped by accident without the call- 21 taker having sufficient information about the current situation of a 22 wounded person. A call-taker may trigger a callback towards the 23 emergency caller using the contact information provided with the 24 initial emergency call. This callback could, under certain 25 circumstances, be treated like any other call and as a consequence it 26 may get blocked by authorization policies or may get forwarded to an 27 answering machine. 29 The IETF emergency services architecture offers capabilities to allow 30 callbask to bypass authorization policies to reach the caller without 31 unnecessary delays. However, the mechanism specified prior to this 32 document supports only limited scenarios. This document discusses 33 some shortcomings, presents additional scenarios where better-than- 34 normal call treatment behavior would be desirable, and specifies a 35 protocol solution. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 29, 2012. 54 Copyright Notice 56 Copyright (c) 2011 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Callback Scenarios . . . . . . . . . . . . . . . . . . . . . . 6 74 3.1. Routing Asymmetry . . . . . . . . . . . . . . . . . . . . 6 75 3.2. Multi-Stage Routing . . . . . . . . . . . . . . . . . . . 7 76 3.3. Call Forwarding . . . . . . . . . . . . . . . . . . . . . 8 77 3.4. Network-based Service URN Resolution . . . . . . . . . . . 10 78 3.5. PSTN Interworking . . . . . . . . . . . . . . . . . . . . 11 79 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 12 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 86 Appendix A. Alternative Solutions Considered . . . . . . . . . . 19 87 A.1. Identity-based Authorization . . . . . . . . . . . . . . . 19 88 A.2. Trait-based Authorization . . . . . . . . . . . . . . . . 20 89 A.3. Call Marking . . . . . . . . . . . . . . . . . . . . . . . 21 91 1. Introduction 93 Summoning police, the fire department or an ambulance in emergencies 94 is one of the fundamental and most-valued functions of the telephone. 95 As telephone functionality moves from circuit-switched telephony to 96 Internet telephony, its users rightfully expect that this core 97 functionality will continue to work at least as well as it has for 98 the legacy technology. New devices and services are being made 99 available that could be used to make a request for help, which are 100 not traditional telephones, and users are increasingly expecting them 101 to be used to place emergency calls. 103 An overview of the protocol interactions for emergency calling using 104 the IETF emergency services architecture are described in 105 [I-D.ietf-ecrit-framework] and [I-D.ietf-ecrit-phonebcp] specifies 106 the technical details. As part of the emergency call setup procedure 107 two important identifiers are conveyed to the PSAP call-taker's user 108 agent, namely the Address-Of-Record (AoR), and the Globally Routable 109 User Agent (UA) URIs (GRUU). RFC 3261 [RFC3261] defines the AoR as: 111 An address-of-record (AOR) is a SIP or SIPS URI that points to a 112 domain with a location service that can map the URI to another URI 113 where the user might be available. Typically, the location 114 service is populated through registrations. An AOR is frequently 115 thought of as the "public address" of the user. 117 In SIP systems a single user can have a number of user agents 118 (handsets, softphones, voicemail accounts, etc.) which are all 119 referenced by the same AOR. There are a number of cases in which it 120 is desirable to have an identifier which addresses a single user 121 agent rather than the group of user agents indicated by an AOR. The 122 GRUU is such a unique user- agent identifier, which is still globally 123 routable. [RFC5627] specifies how to obtain and use GRUUs. 125 Regulatory requirements demand that the emergency call itself 126 provides enough information to allow the call-taker to initiate a 127 call back to the emergency caller in case the call dropped or to 128 interact with the emergency caller in case of further questions. The 129 AoR and the GRUU serve this purpose. The communication attempt by 130 the PSAP call-taker back to the emergency caller is called 'PSAP 131 callback'. 133 A PSAP callback may, however, be blocked by user configured whitelis 134 or may be forwarded to an answering machine as SIP entities (SIP 135 proxies as well as the SIP UA itself) cannot differentiate the 136 callback from any other SIP call establishing attempt from the SIP 137 signaling message. 139 While there are no regulatory requirements at the time of writing of 140 this specification there is the believe that PSAP callbacks have to 141 be treated in such a way that they reach the emergency caller. For 142 this purpose guidance for PSAP callback handling has been provided in 143 Section 13 of [I-D.ietf-ecrit-framework]: 145 A UA may be able to determine a PSAP call back by examining the 146 domain of incoming calls after placing an emergency call and 147 comparing that to the domain of the answering PSAP from the 148 emergency call. Any call from the same domain and directed to the 149 supplied Contact header or AoR after an emergency call should be 150 accepted as a callback from the PSAP if it occurs within a 151 reasonable time after an emergency call was placed. 153 This approach mimics a stateful packet filtering firewall and is 154 indeed helpful in a number of cases. It is also relatively simple to 155 implement. Unfortunately, it does not work in all SIP deployment 156 scenarios. In Section 3 we describe scenarios where the currently 157 standardized approach is insufficient. In Section 4 a solution is 158 described. 160 2. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 Emergency services related terminology is borrowed from [RFC5012]. 168 3. Callback Scenarios 170 This section illustrates a number of scenarios where the currently 171 specified solution, as specified in [I-D.ietf-ecrit-phonebcp], for 172 preferential treatment of callbacks fails. As explained in Section 1 173 a SIP entity examines an incoming PSAP call back by comparing the 174 domain of the PSAP with the destination domain of the emergency call. 176 3.1. Routing Asymmetry 178 In some deployment environments it is common to have incoming and 179 outgoing SIP messaging routed through different SIP entities. 180 Figure 1 shows this graphically whereby a VoIP provider uses 181 different SIP proxies for inbound and for outbound call handling. 182 Unless they two devices are state synchronized the callback hitting 183 the inbound proxy would get treated like any other call since the 184 emergency call established state information at the outbound proxy 185 only. 187 ,-------. 188 ,' `. 189 ,-------. / Emergency \ 190 ,' `. | Services | 191 / VoIP \ I | Network | 192 | Provider | n | | 193 | | t | | 194 | | e | | 195 | +-------+ | r | | 196 +--+---|Inbound|<--+-----m | | 197 | | |Proxy | | e | +------+ | 198 | | +-------+ | d | |PSAP | | 199 | | | i | +--+---+ | 200 +----+ | | | a-+ | | | 201 | UA |<---+ | | t | | | | 202 | |----+ | | e | | | | 203 +----+ | | | | | | | 204 | | | P | | | | 205 | | | r | | | | 206 | | +--------+ | o | | | | 207 +--+-->|Outbound|--+---->v | | +--+---+ | 208 | |Proxy | | i | | +-+ESRP | | 209 | +--------+ | d | | | +------+ | 210 | | e || | | 211 | | r |+-+ | 212 \ / | | 213 `. ,' \ / 214 '-------' `. ,' 215 '-------' 217 Figure 1: Example for Routing Asymmetry 219 3.2. Multi-Stage Routing 221 Consider the following emergency call routing scenario shown in 222 Figure 2 where routing towards the PSAP occurs in several stages. In 223 this scenario we consider a SIP UA that uses LoST to learn the next 224 hop destination closer to the PSAP. This call is then sent to the 225 user's VoIP provider. The user's VoIP provider receives the 226 emergency call and creates state based on the destination domain, 227 namely state.com. It then routes it to the indicated ESRP. When the 228 ESRP receives it it needs to decide what the next hop is to get it 229 closer to the PSAP. In our example the next hop is the PSAP with the 230 URI psap@town.com. 232 When a callback is sent from psap@town.com towards the emergency 233 caller the call will get normal treatment by the VoIP providers 234 inbound proxy since the domain of the PSAP does not match the stored 235 state information. 237 ,-------. 238 +----+ ,' `. 239 | UA |--- esrp1@foobar.com / Emergency \ 240 +----+ \ | Services | 241 \ ,-------. | Network | 242 ,' `. | | 243 / VoIP \ | +------+ | 244 ( Provider ) | |PSAP | | 245 \ / | +--+---+ | 246 `. ,' | | 247 '---+---' | | | 248 | |psap@town.com | 249 esrp@state.com | | | 250 | | | | 251 | | | | 252 | | +--+---+ | 253 +------------+---+ESRP | | 254 | +------+ | 255 | | 256 \ / 257 `. ,' 258 '-------' 260 Figure 2: Example for Multi-Stage Routing 262 3.3. Call Forwarding 264 Imagine the following case where an emergency call enters an 265 emergency network (state.org) via an ERSP but then gets forwarded to 266 a different emergency services network (in our example to police- 267 town.org, fire-town.org or medic-town.org). The same considerations 268 apply when the the police, fire and ambulance networks are part of 269 the state.org sub-domains (e.g., police.state.org). 271 Similarly to the previous scenario the problem here is with the wrong 272 state information being established during the emergency call setup 273 procedure. A callback would originate in the police-town.org, fire- 274 town.org or medic-town.org domain whereas the emergency caller's SIP 275 UA or the VoIP outbound proxy has stored state.org. 277 ,-------. 278 ,' `. 279 / Emergency \ 280 | Services | 281 | Network | 282 | (state.org) | 283 | | 284 | | 285 | +------+ | 286 | |PSAP +--+ | 287 | +--+---+ | | 288 | | | | 289 | | | | 290 | | | | 291 | | | | 292 | | | | 293 | +--+---+ | | 294 ------------------+---+ESRP | | | 295 esrp-a@state.org | +------+ | | 296 | | | 297 | Call Fwd | | 298 | +-+-+---+ | 299 \ | | | / 300 `. | | | ,' 301 '-|-|-|-' ,-------. 302 Police | | | Fire ,' `. 303 +------------+ | +----+ / Emergency \ 304 ,-------. | | | | Services | 305 ,' `. | | | | Network | 306 / Emergency \ | Ambulance | | fire-town.org | 307 | Services | | | | | | 308 | Network | | +----+ | | +------+ | 309 |police-town.org| | ,-------. | +----+---+PSAP | | 310 | | | ,' `. | | +------+ | 311 | +------+ | | / Emergency \ | | | 312 | |PSAP +----+--+ | Services | | | , 313 | +------+ | | Network | | `~~~~~~~~~~~~~~~ 314 | | |medic-town.org | | 315 | , | | | 316 `~~~~~~~~~~~~~~~ | +------+ | | 317 | |PSAP +----+ + 318 | +------+ | 319 | | 320 | , 321 `~~~~~~~~~~~~~~~ 323 Figure 3: Example for Call Forwarding 325 3.4. Network-based Service URN Resolution 327 The IETF emergency services architecture also considers cases where 328 the resolution from the Service URN to the PSAP URI does not only 329 happen at the SIP UA itself but at intermedidate SIP entities, such 330 as the user's VoIP provider. 332 Figure 4 shows this message exchange of the outgoing emergency call 333 and the incoming PSAP graphically. While the state information 334 stored at the VoIP provider is correct the state allocated at the SIP 335 UA is not. 337 ,-------. 338 ,' `. 339 / Emergency \ 340 | Services | 341 | Network | 342 |police-town.org| 343 | | 344 | +------+ | Invite to police.example.com 345 | |PSAP +<---+------------------------+ 346 | | +----+------------------+ ^ 347 | +------+ |Invite from | | 348 | ,police.example.com| | 349 `~~~~~~~~~~~~~~~ v | 350 +--------+ ++-----+-+ 351 | | query |VoIP | 352 | LoST |<-----------------------|Service | 353 | Server | police.example.com |Provider| 354 | |----------------------->| | 355 +--------+ +--------+ 356 | ^ 357 Invite| | Invite 358 from| | to 359 police.example.com| | urn:service:sos 360 V | 361 +-------+ 362 | SIP | 363 | UA | 364 | Alice | 365 +-------+ 367 Figure 4: Example for Network-based Service URN Resolution 369 3.5. PSTN Interworking 371 In case an emergency call enters the PSTN, as shown in Figure 5, 372 there is no guarantee that the callback some time later does leave 373 the same PSTN/VoIP gateway or that the same end point identifier is 374 used in the forward as well as in the backward direction making it 375 difficult to reliably detect PSAP callbacks. 377 +-----------+ 378 | PSTN |-------------+ 379 | Calltaker | | 380 | Bob |<--------+ | 381 +-----------+ | v 382 ------------------- 383 //// \\\\ +------------+ 384 | | |PSTN / VoIP | 385 | PSTN |---->|Gateway | 386 \\\\ //// | | 387 ------------------- +----+-------+ 388 ^ | 389 | | 390 +-------------+ | +--------+ 391 | | | |VoIP | 392 | PSTN / VoIP | +->|Service | 393 | Gateway | |Provider| 394 | |<------Invite----| Y | 395 +-------------+ +--------+ 396 | ^ 397 | | 398 Invite Invite 399 | | 400 V | 401 +-------+ 402 | SIP | 403 | UA | 404 | Alice | 405 +-------+ 407 Figure 5: Example for PSTN Interworking 409 Note: This scenario is considered outside the scope of this document. 410 The specified solution does not support this use case. 412 4. Specification 414 [Editor's Note: The solution approach described in 415 [I-D.holmberg-emergency-callback-id] will be discussed at the IETF#82 416 ECRIT meeting and at the ECRIT mailing list and will be incorporated 417 here if agreed by the working group.] 419 5. Security Considerations 421 [Editor's Note: Instead of an abstract security description text will 422 be provided with the solution description.] 424 6. IANA Considerations 426 [Editor's Note: IANA consideration text will be added once an 427 agreement on the solution has been reached. 429 7. Acknowledgements 431 We would like to thank members from the ECRIT working group, in 432 particular Brian Rosen, for their discussions around PSAP callbacks. 433 The working group discussed the topic of callbacks at their virtual 434 interim meeting in February 2010 and the following persons provided 435 valuable input: John Elwell, Bernard Aboba, Cullen Jennings, Keith 436 Drage, Marc Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson, 437 Janet Gunn. 439 At IETF#81 a small group of people got to together to continue the 440 discussions started at the working group meeting to explore a GRUU- 441 based solution approach. Martin Thomson, Marc Linsner, Andrew Allen, 442 Brian Rosen, Martin Dolly, and Atle Monrad participated at this side- 443 meeting. 445 Finally, we would like to thank Cullen Jennings for his discussion 446 input. He was the first to propose a "token-based" solution. 448 8. References 450 8.1. Normative References 452 [RFC2119] Bradner, S., "Key words for use 453 in RFCs to Indicate Requirement 454 Levels", BCP 14, RFC 2119, 455 March 1997. 457 [RFC3261] Rosenberg, J., Schulzrinne, H., 458 Camarillo, G., Johnston, A., 459 Peterson, J., Sparks, R., 460 Handley, M., and E. Schooler, 461 "SIP: Session Initiation 462 Protocol", RFC 3261, June 2002. 464 [RFC3325] Jennings, C., Peterson, J., and 465 M. Watson, "Private Extensions 466 to the Session Initiation 467 Protocol (SIP) for Asserted 468 Identity within Trusted 469 Networks", RFC 3325, 470 November 2002. 472 [RFC3966] Schulzrinne, H., "The tel URI 473 for Telephone Numbers", 474 RFC 3966, December 2004. 476 [RFC3969] Camarillo, G., "The Internet 477 Assigned Number Authority 478 (IANA) Uniform Resource 479 Identifier (URI) Parameter 480 Registry for the Session 481 Initiation Protocol (SIP)", 482 BCP 99, RFC 3969, 483 December 2004. 485 [RFC4474] Peterson, J. and C. Jennings, 486 "Enhancements for Authenticated 487 Identity Management in the 488 Session Initiation Protocol 489 (SIP)", RFC 4474, August 2006. 491 [RFC5341] Jennings, C. and V. Gurbani, 492 "The Internet Assigned Number 493 Authority (IANA) tel Uniform 494 Resource Identifier (URI) 495 Parameter Registry", 496 September 2008. 498 [RFC5627] Rosenberg, J., "Obtaining and 499 Using Globally Routable User 500 Agent URIs (GRUUs) in the 501 Session Initiation Protocol 502 (SIP)", RFC 5627, October 2009. 504 8.2. Informative References 506 [I-D.holmberg-emergency-callback-id] Holmberg, C., "Session 507 Initiation Protocol (SIP) 508 emergency call back 509 identification", draft- 510 holmberg-emergency-callback-id- 511 00 (work in progress), 512 October 2011. 514 [I-D.ietf-ecrit-framework] Rosen, B., Schulzrinne, H., 515 Polk, J., and A. Newton, 516 "Framework for Emergency 517 Calling using Internet 518 Multimedia", 519 draft-ietf-ecrit-framework-13 520 (work in progress), 521 September 2011. 523 [I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best 524 Current Practice for 525 Communications Services in 526 support of Emergency Calling", 527 draft-ietf-ecrit-phonebcp-20 528 (work in progress), 529 September 2011. 531 [I-D.ietf-sip-saml] Tschofenig, H., Hodges, J., 532 Peterson, J., Polk, J., and D. 533 Sicker, "SIP SAML Profile and 534 Binding", 535 draft-ietf-sip-saml-08 (work in 536 progress), October 2010. 538 [RFC4484] Peterson, J., Polk, J., Sicker, 539 D., and H. Tschofenig, "Trait- 540 Based Authorization 541 Requirements for the Session 542 Initiation Protocol (SIP)", 543 RFC 4484, August 2006. 545 [RFC5012] Schulzrinne, H. and R. 546 Marshall, "Requirements for 547 Emergency Context Resolution 548 with Internet Technologies", 549 RFC 5012, January 2008. 551 [RFC5031] Schulzrinne, H., "A Uniform 552 Resource Name (URN) for 553 Emergency and Other Well-Known 554 Services", RFC 5031, 555 January 2008. 557 [RFC5234] Crocker, D. and P. Overell, 558 "Augmented BNF for Syntax 559 Specifications: ABNF", STD 68, 560 RFC 5234, January 2008. 562 Appendix A. Alternative Solutions Considered 564 In an attempt to describe the problem and to explore solution 565 approaches the working group had also investigated alternative 566 approaches. We document them here for completeness. The solutions 567 fall into three categories: (1) Identity-based authorization, (2) 568 Trait-based authorization, and (3) Call Marking. Even though these 569 solutions are not mutually exclusive we describe them in separate 570 sub-sections. 572 Beyond the disadvantages listed in each solution category none of 573 them provides the emergency caller with the ability to restrict 574 preferential PSAP callback handling to those cases where an earlier 575 emergency call was initiated. 577 A.1. Identity-based Authorization 579 In Figure 6 an interaction is presented that allows a SIP entity to 580 make a policy decision whether to bypass installed authorization 581 policies and thereby providing preferential treatment. To make this 582 decision the sender's identity is compared with a whitelist of valid 583 PSAPs. The identity assurances in SIP can come in different forms, 584 such as SIP Identity [RFC4474] or with P-Asserted-Identity [RFC3325]. 585 The former technique relies on a cryptographic assurance and the 586 latter on a chain of trust. 588 +----------+ 589 | List of |+ 590 | valid || 591 | PSAP ids || 592 +----------+| 593 +----------+ 594 * 595 * whitelist 596 * 597 V 598 Incoming +----------+ Normal 599 SIP Msg | SIP |+ Treatment 600 -------------->| Entity ||=============> 601 + Identity | ||(if not in whitelist) 602 +----------+| 603 +----------+ 604 || 605 || 606 || Preferential 607 || Treatment 608 ++=============> 609 (in whitelist) 611 Figure 6: Identity-based Authorization 613 This approach was not chosen because the establishment of a whitelist 614 containing PSAP identities is operationally complex and does not 615 easily scale world wide. Only when there is a local relationship 616 between the VSP/ASP and the PSAP then populating the whitelist is far 617 simpler. This would, however, constrain the applicability of the 618 mechanism considerably. 620 A.2. Trait-based Authorization 622 An alternative approach to an identity based authorization model is 623 outlined in Figure 7. In fact, RFC 4484 [RFC4484] illustrates a 624 related emergency service use case. 626 +----------+ 627 | List of |+ 628 | trust || 629 | anchor || 630 +----------+| 631 +----------+ 632 * 633 * 634 * 635 V 636 Incoming +----------+ Normal 637 SIP Msg | SIP |+ Treatment 638 -------------->| Entity ||=============> 639 + trait | ||(no indication 640 +----------+| of PSAP) 641 +----------+ 642 || 643 || 644 || Preferential 645 || Treatment 646 ++=============> 647 (indicated as 648 PSAP) 650 Figure 7: Trait-based Authorization 652 In a trait-based authorization scenario an incoming SIP message 653 contains a form of trait, i.e. some form of assertion. The assertion 654 contains an indication that the sending party has the role of a PSAP 655 (or similar emergency services entity). The assertion is either 656 cryptographically protected to enable end-to-end verification or an 657 chain of trust security model has to be assumed. In Figure 7 we 658 assume an end-to-end security model where trust anchors are 659 provisioned to ensure the ability for a SIP entity to verify the 660 received assertion. 662 This solution was not chosen because trait-based authorization never 663 got deployed in SIP. Furthermore, in order to ensure that the 664 assertions are properly protected it is necessary to digitally sign, 665 which requires some form of public key infrastructure for usage with 666 emergency services. Finally, there need to be some policies in place 667 that define which entities are allowed to obtain various roles. 668 These policies and procedures do not exist today. 670 A.3. Call Marking 672 Call marking allows the PSAP to place a non-cryptographic label on 673 outgoing calls that gives, when received by a SIP entity, 674 preferential treatment for these callbacks. 676 When used in isolation this mechanism introduces considerable denial 677 of service attacks due to the ability to bypass any authorization 678 policies and could be utilized to distribute unwanted traffic. 680 Authors' Addresses 682 Henning Schulzrinne 683 Columbia University 684 Department of Computer Science 685 450 Computer Science Building 686 New York, NY 10027 687 US 689 Phone: +1 212 939 7004 690 EMail: hgs+ecrit@cs.columbia.edu 691 URI: http://www.cs.columbia.edu 693 Hannes Tschofenig 694 Nokia Siemens Networks 695 Linnoitustie 6 696 Espoo 02600 697 Finland 699 Phone: +358 (50) 4871445 700 EMail: Hannes.Tschofenig@gmx.net 701 URI: http://www.tschofenig.priv.at 703 Christer Holmberg 704 Ericsson 705 Hirsalantie 11 706 Jorvas 02420 707 Finland 709 EMail: christer.holmberg@ericsson.com 711 Milan Patel 712 InterDigital Communications 714 EMail: Milan.Patel@interdigital.com