idnits 2.17.1 draft-ietf-ecrit-data-only-ea-22.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2020) is 1502 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) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B. Rosen 3 Internet-Draft 4 Intended status: Standards Track H. Schulzrinne 5 Expires: September 10, 2020 Columbia U. 6 H. Tschofenig 7 ARM Limited 8 R. Gellens 9 Core Technology Consulting 10 March 9, 2020 12 Non-Interactive Emergency Calls 13 draft-ietf-ecrit-data-only-ea-22 15 Abstract 17 Use of the Internet for emergency calling is described in RFC 6443, 18 'Framework for Emergency Calling Using Internet Multimedia'. In some 19 cases of emergency calls, the transmission of application data is all 20 that is needed and no interactive media channel is established: a 21 situation referred to as 'non-interactive emergency calls', where, 22 unlike most emergency calls, there is no two way interactive media 23 such as voice or video or text. This document describes use of a SIP 24 MESSAGE transaction that includes a container for the data based on 25 the Common Alerting Protocol (CAP). That type of emergency request 26 does not establish a session, distinguishing it from SIP INVITE, 27 which does. Any device that needs to initiate a request for 28 emergency services without an interactive media channel would use the 29 mechanisms in this document. 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 https://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 September 10, 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 68 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 6 69 4.1. CAP Transport . . . . . . . . . . . . . . . . . . . . . . 6 70 4.2. Profiling of the CAP Document Content . . . . . . . . . . 7 71 4.3. Sending a non-interactive Emergency Call . . . . . . . . 8 72 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.1. 425 (Bad Alert Message) Response Code . . . . . . . . . . 9 74 5.2. The AlertMsg-Error Header Field . . . . . . . . . . . . . 9 75 6. Call Backs . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7. Handling Large Amounts of Data . . . . . . . . . . . . . . . 11 77 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 80 10.1. Registration of the 81 'application/EmergencyCallData.cap+xml' media type . . . 18 82 10.2. IANA Registration of 'cap' Additional Data Block . . . . 19 83 10.3. IANA Registration for 425 Response Code . . . . . . . . 19 84 10.4. IANA Registration of New AlertMsg-Error Header Field . . 20 85 10.5. IANA Registration for the SIP AlertMsg-Error Codes . . . 20 86 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 89 12.2. Informative References . . . . . . . . . . . . . . . . . 23 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 92 1. Introduction 94 [RFC6443] describes how devices use the Internet to place emergency 95 calls and how Public Safety Answering Points (PSAPs) handle Internet 96 multimedia emergency calls natively. The exchange of multimedia 97 traffic for emergency services involves a SIP session establishment 98 starting with a SIP INVITE that negotiates various parameters for 99 that session. 101 In some cases, however, there is only application data to be conveyed 102 from the end devices to a PSAP or an intermediary. Examples of such 103 environments include sensors issuing alerts, and certain types of 104 medical monitors. These messages may be one-shot alerts to emergency 105 authorities and do not require establishment of a session. These 106 types of interactions are called 'non-interactive emergency calls'. 107 In this document, we use the term "call" so that similarities between 108 non-interactive alerts and sessions with interactive media are more 109 obvious. 111 Non-interactive emergency calls are similar to regular emergency 112 calls in the sense that they require the emergency indications, 113 emergency call routing functionality and location. However, the 114 communication interaction will not lead to the exchange of 115 interactive media, that is, Real-Time Protocol packets, such as 116 voice, video data or real-time text. 118 The Common Alerting Protocol (CAP) [cap] is a format for exchanging 119 emergency alerts and public warnings. CAP is mainly used for 120 conveying alerts and warnings between authorities and from 121 authorities to citizens/individuals. This document is concerned with 122 citizen-to-authority "alerts", where the alert is a call without any 123 interactive media. 125 This document describes a method of including a CAP message in a SIP 126 transaction by defining it as a block of "additional data" as defined 127 in [RFC7852]. The CAP message is included either by value (the CAP 128 message is in the body of the message, using a CID) or by reference 129 (the message includes a URI that, when dereferenced, returns the CAP 130 message). The additional data mechanism is also used to send alert- 131 specific data beyond that available in the CAP message. This 132 document also describes how a SIP MESSAGE [RFC3428] transaction can 133 be used to send a non-interactive call. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 A non-interactive emergency call is an emergency call where there is 144 no two-way interactive media. 146 SIP is the Session Initiation Protocol [RFC3261] 148 PIDF-LO is Presence Information Data Format - Location Object, a data 149 structure for carrying location [RFC4119] 151 LoST is the Location To Service Translation protocol [RFC5222] 153 CID is Content-ID [RFC2392] 155 CAP is the Common Alerting Protocol [cap] 157 PSAP is a Public Safety Answering Point, the call center for 158 emergency calls. 160 ESRP is an Emergency Services Routing Proxy, a type of SIP Proxy 161 Server used in some emergency services networks 163 3. Architectural Overview 165 This section illustrates two envisioned usage modes: targeted and 166 location-based emergency alert routing. 168 1. Emergency alerts containing only data are targeted to an 169 intermediary recipient responsible for evaluating the next steps. 170 These steps could include: 172 1. Sending a non-interactive call containing only data towards a 173 Public Safety Answering Point (PSAP); 175 2. Establishing a third-party-initiated emergency call towards a 176 PSAP that could include audio, video, and data. 178 2. Emergency alerts may be targeted to a Service URN [RFC5031] used 179 for IP-based emergency calls where the recipient is not known to 180 the originator. In this scenario, the alert may contain only 181 data (e.g., a CAP, Geolocation header field and one or more Call- 182 Info header fields containing Additional Data [RFC7852] in a SIP 183 MESSAGE). 185 Figure 1 shows a deployment variant where a sensor is pre-configured 186 (using techniques outside the scope of this document) to issue an 187 alert to an aggregator that processes these messages and performs 188 whatever steps are necessary to appropriately react to the alert. 189 For example, a security firm may use different sensor inputs to 190 dispatch their security staff to a building they protect or to 191 initiate a third-party emergency call. 193 +------------+ +------------+ 194 | Sensor | | Aggregator | 195 | | | | 196 +---+--------+ +------+-----+ 197 | | 198 Sensors | 199 trigger | 200 emergency | 201 alert | 202 | SIP MESSAGE with CAP | 203 |----------------------------->| 204 | | 205 | Aggregator 206 | processes 207 | emergency 208 | alert 209 | SIP 200 (OK) | 210 |<-----------------------------| 211 | | 212 | | 214 Figure 1: Targeted Emergency Alert Routing 216 In Figure 2 a scenario is shown whereby the alert is routed using 217 location information and a Service URN. An emergency services 218 routing proxy (ESRP) may use LoST (a protocol defined by [RFC5222] 219 which translates a location to a URI used to route an emergency call) 220 to determine the next-hop proxy to route the alert message to. A 221 possible receiver is a PSAP and the recipient of the alert may be a 222 call taker. In the generic case, there is very likely no prior 223 relationship between the originator and the receiver, e.g., a PSAP. 224 For example, a PSAP is likely to receive and accept alerts from 225 entities it has no previous relationship with. This scenario is 226 similar to a classic voice emergency services call and the 227 description in [RFC6881] is applicable. In this use case, the only 228 difference between an emergency call and an emergency non-interactive 229 call is that the former uses INVITE, creates a session, and 230 negotiates one or more media streams, while the latter uses MESSAGE, 231 does not create a session, and does not have interactive media. 233 +----------+ +----------+ +-----------+ 234 |Sensor or | | ESRP | | PSAP | 235 |Aggregator| | | | | 236 +----+-----+ +---+------+ +----+------+ 237 | | | 238 Sensors | | 239 trigger | | 240 emergency | | 241 alert | | 242 | | | 243 | | | 244 | SIP MESSAGE w/CAP | | 245 | (including Service URN, | 246 | such as urn:service:sos) | 247 |------------------>| | 248 | | | 249 | ESRP performs | 250 | emergency alert | 251 | routing | 252 | | MESSAGE with CAP | 253 | | (including identity info) | 254 | |----------------------------->| 255 | | | 256 | | PSAP 257 | | processes 258 | | emergency 259 | | alert 260 | | SIP 200 (OK) | 261 | |<-----------------------------| 262 | | | 263 | SIP 200 (OK) | | 264 |<------------------| | 265 | | | 266 | | | 268 Figure 2: Location-Based Emergency Alert Routing 270 4. Protocol Specification 272 4.1. CAP Transport 274 A CAP message is sent in the initial message of any SIP transaction. 275 However, this document only addresses sending a CAP message in a SIP 276 MESSAGE transaction for a one-shot, non-interactive emergency call. 277 Behavior with other transactions is not defined. 279 The CAP message is included in a SIP message as an additional-data 280 block [RFC7852]. Accordingly, it is introduced to the SIP message 281 with a Call-Info header field with a purpose of 282 "EmergencyCallData.cap". The header field may contain a URI that is 283 used by the recipient (or in some cases, an intermediary) to obtain 284 the CAP message. Alternatively, the Call-Info header field may 285 contain a Content-ID url [RFC2392] and the CAP message included in 286 the body of the message. In the latter case, the CAP message is 287 located in a MIME block of the type 'application/ 288 emergencyCallData.cap+xml'. 290 If the SIP server does not support the functionality required to 291 fulfill the request then a 501 Not Implemented will be returned as 292 specified in [RFC3261]. This is the appropriate response when a User 293 Agent Server (UAS) does not recognize the request method and is not 294 capable of supporting it for any user. 296 The 415 Unsupported Media Type error will be returned as specified in 297 [RFC3261] if the SIP server is refusing to service the request 298 because the message body of the request is in a format not supported 299 by the server for the requested method. The server MUST return a 300 list of acceptable formats using the Accept, Accept-Encoding, or 301 Accept-Language header fields, depending on the specific problem with 302 the content. 304 4.2. Profiling of the CAP Document Content 306 The usage of CAP MUST conform to the specification provided with 307 [cap]. For usage with SIP the following additional requirements are 308 imposed (where "sender" and "author" are as defined in CAP and 309 "Originator" is the entity sending the alert): 311 sender: The following restrictions and conditions apply to setting 312 the value of the element: 314 * Originator is a SIP entity, Author indication irrelevant: When 315 the alert was created by a SIP-based originator and it is not 316 useful to be explicit about the author of the alert, then the 317 element MUST be populated with the SIP URI of the user 318 agent. 320 * Originator is a non-SIP entity, Author indication irrelevant: 321 When the alert was created by a non-SIP based entity and the 322 identity of this original sender is to be preserved, then this 323 identity MUST be placed into the element. In this 324 situation it is not useful to be explicit about the author of 325 the alert. The specific type of identity being used will 326 depend on the technology used by the original originator. 328 * Author indication relevant: When the author is different from 329 the actual originator of the message and this distinction 330 should be preserved, then the element MUST NOT contain 331 the SIP URI of the user agent. 333 incidents: The element MUST be present. This incident 334 identifier MUST be chosen in such a way that it is unique for a 335 given combination. Note that the 336 element is OPTIONAL and might not be present. 338 scope: The value of the element MAY be set to "Private" if 339 the alert is not meant for public consumption. The 340 element is, however, not used by this specification since the 341 message routing is performed by SIP and the respective address 342 information is already available in other SIP header fields. 343 Populating information twice into different parts of the message 344 may lead to inconsistency. 346 parameter: The element MAY contain additional 347 information specific to the sender, conforming to the CAP message 348 syntax. 350 area: It is RECOMMENDED to omit this element when constructing a 351 message. If the CAP message is given to the SIP entity to 352 transport and it already contains an element, then the 353 specified location information SHOULD be copied into a PIDF-LO 354 structure (the data format for location used by emergency calls on 355 the Internet) referenced by the SIP 'Geolocation' header field. 356 If the CAP message is being created by the SIP entity using a 357 PIDF-LO structure referenced by 'geolocation' to construct , 358 implementers must be aware that is limited to a circle or 359 polygon, and conversion of other shapes will be required. Points 360 SHOULD be converted to a circle with a radius equal to the 361 uncertainty of the point. Arc- bands and ellipses SHOULD be 362 converted to polygons with similar coverage, and 3D locations 363 SHOULD be converted to 2D forms with similar coverage. 365 4.3. Sending a non-interactive Emergency Call 367 A non-interactive emergency call is sent using a SIP MESSAGE 368 transaction with a CAP URI or body part as described above in a 369 manner similar to how an emergency call with interactive media is 370 sent, as described in [RFC6881]. The MESSAGE transaction does not 371 create a session nor establish interactive media streams, but 372 otherwise, the header content of the transaction, routing, and 373 processing of non-interactive calls are the same as those of other 374 emergency calls. 376 5. Error Handling 378 This section defines a new error response code and a header field for 379 additional information. 381 5.1. 425 (Bad Alert Message) Response Code 383 This SIP extension creates a new location-specific response code, 384 defined as follows: 386 425 (Bad Alert Message) 388 The 425 response code is a rejection of the request, indicating that 389 it was malformed enough that no reasonable emergency response to the 390 alert can be determined. 392 A SIP intermediary can also this code to reject an alert it receives 393 from a User Agent (UA) when it detects that the provided alert is 394 malformed. 396 Section 5.2 describes an AlertMsg-Error header field with more 397 details about what was wrong with the alert message in the request. 398 This header field MUST be included in the 425 response. 400 It is usually the case that emergency calls are not rejected if there 401 is any useful information that can be acted upon. It is only 402 appropriate to generate a 425 response when the responding entity has 403 no other information in the request that is usable by the responder. 405 A 425 response code MUST NOT be sent in response to a request that 406 lacks an alert message, as the user agent in that case may not 407 support this extension. 409 A 425 response is a final response within a transaction, and MUST NOT 410 terminate an existing dialog. 412 5.2. The AlertMsg-Error Header Field 414 The AlertMsg-Error header field provides additional information about 415 what was wrong with the original request. In some cases the provided 416 information will be used for debugging purposes. 418 The AlertMsg-Error header field has the following ABNF [RFC5234]: 420 message-header =/ AlertMsg-Error 421 ; (message-header from RFC3261) 422 AlertMsg-Error = "AlertMsg-Error" HCOLON 423 ErrorValue 424 ErrorValue = error-code 425 *(SEMI error-params) 426 error-code = 3DIGIT 427 error-params = error-code-text 428 / generic-param ; from RFC3261 429 error-code-text = "message" EQUAL quoted-string ; from RFC3261 431 HCOLON, SEMI, and EQUAL are defined in [RFC3261]. DIGIT is defined 432 in [RFC5234]. 434 The AlertMsg-Error header field MUST contain only one ErrorValue to 435 indicate what was wrong with the alert payload the recipient 436 determined was bad. 438 The ErrorValue contains a 3-digit error code indicating what was 439 wrong with the alert in the request. This error code has a 440 corresponding quoted error text string that is human readable. The 441 text string is OPTIONAL, but RECOMMENDED for human readability, 442 similar to the string phrase used for SIP response codes. The 443 strings in this document are recommendations, and are not 444 standardized -- meaning an operator can change the strings -- but 445 MUST NOT change the meaning of the error code. The code space for 446 ErrorValue is separate from SIP Status Codes. 448 The AlertMsg-Error header field MAY be included in any response if an 449 alert message was in the request part of the same transaction. For 450 example, suppose a UA includes an alert in a MESSAGE to a PSAP. The 451 PSAP can accept this MESSAGE, even though its UA determined that the 452 alert message contained in the MESSAGE was bad. The PSAP merely 453 includes an AlertMsg-Error header field value in the 200 OK to the 454 MESSAGE, thus informing the UA that the MESSAGE was accepted but the 455 alert provided was bad. 457 If, on the other hand, the PSAP cannot accept the transaction without 458 a suitable alert message, a 425 response is sent. 460 A SIP intermediary that requires the UA's alert message in order to 461 properly process the transaction may also send a 425 with an 462 AlertMsg-Error code. 464 This document defines an initial list of AlertMsg-Error values for 465 any SIP response, including provisional responses (other than 100 466 Trying) and the new 425 response. There MUST NOT be more than one 467 AlertMsg-Error code in a SIP response. AlertMsg-Error values sent in 468 provisional responses MUST be sent using the mechanism defined in 469 [RFC3262]; or, if that mechanism is not negotiated, MUST be repeated 470 in the final response to the transaction. 472 AlertMsg-Error: 100 ; message="Cannot Process the Alert Payload" 474 AlertMsg-Error: 101 ; message="Alert Payload was not present or could 475 not be found" 477 AlertMsg-Error: 102 ; message="Not enough information to determine 478 the purpose of the alert" 480 AlertMsg-Error: 103 ; message="Alert Payload was corrupted" 482 Additionally, if an entity cannot or chooses not to process the alert 483 message from a SIP request, a 500 (Server Internal Error) SHOULD be 484 used with or without a configurable Retry-After header field. 486 6. Call Backs 488 This document does not describe any method for the recipient to call 489 back the sender of a non-interactive call. Usually, these alerts are 490 sent by automata, which do not have a mechanism to receive calls of 491 any kind. The identifier in the 'From' header field may be useful to 492 obtain more information, but any such mechanism is not defined in 493 this document. The CAP message may contain related contact 494 information for the sender. 496 7. Handling Large Amounts of Data 498 It is not atypical for sensors to have large quantities of data that 499 they may wish to send. Including large amounts of data (tens of 500 kilobytes) in a MESSAGE is not advisable, because SIP entities are 501 usually not equipped to handle very large messages. In such cases, 502 the sender SHOULD make use of the by-reference mechanisms defined in 503 [RFC7852], which involves making the data available via HTTPS 504 [RFC2818] (either at the originator or at another entity), placing a 505 URI to the data in the 'Call-Info' header field, and the recipient 506 uses HTTPS to retrieve the data. The CAP message itself can be sent 507 by reference using this mechanism, as can any or all of the 508 Additional Data blocks that may contain sensor-specific data. 510 There are no rate limiting mechanisms for any SIP transactions that 511 are standardized, although implementations often include such 512 functions. Non-interactive emergency calls are typically handled the 513 same as any emergency call, which means a human call-taker is 514 involved. Implementations should take note of this limitation, 515 especially when calls are placed automatically without human 516 initiation. 518 8. Example 520 The following example shows a CAP document indicating a BURGLARY 521 alert issued by a sensor called 'sensor1@example.com'. The location 522 of the sensor can be obtained from the attached location information 523 provided via the 'geolocation' header field contained in the SIP 524 MESSAGE structure. Additionally, the sensor provided some data along 525 with the alert message, using proprietary information elements 526 intended only to be processed by the receiver, a SIP entity acting as 527 an aggregator. 529 MESSAGE sip:aggregator@example.com SIP/2.0 530 Via: SIP/2.0/TCP sensor1.example.com;branch=z9hG4bK776sgdkse 531 Max-Forwards: 70 532 From: sip:sensor1@example.com;tag=49583 533 To: sip:aggregator@example.com 534 Call-ID: asd88asd77a@2001:db8::ff 535 Geolocation: 536 ;routing-allowed=yes 537 Supported: geolocation 538 CSeq: 1 MESSAGE 539 Call-Info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap 540 Content-Type: multipart/mixed; boundary=boundary1 541 Content-Length: ... 543 --boundary1 544 Content-Type: application/EmergencyCallData.cap+xml 545 Content-ID: 546 Content-Disposition: by-reference;handling=optional 548 550 551 S-1 552 sip:sensor1@example.com 553 2020-01-04T20:57:35Z 554 Actual 555 Alert 556 Private 557 abc1234 558 559 Security 560 BURGLARY 561 Expected 562 Likely 563 Moderate 564 SENSOR 1 565 566 SENSOR-DATA-NAMESPACE1 567 123 568 569 570 SENSOR-DATA-NAMESPACE2 571 TRUE 572 573 574 576 --boundary1 577 Content-Type: application/pidf+xml 578 Content-ID: 580 581 590 591 592 593 594 595 44.85249659 -93.238665712 596 597 598 599 600 false 601 602 2020-02-04T20:57:29Z 603 604 605 802.11 606 607 2020-01-04T20:57:29Z 608 609 611 --boundary1-- 613 Figure 3: Example Message conveying an Alert to an aggregator 615 The following shows the same CAP document sent as a non-interactive 616 emergency call towards a PSAP. 618 MESSAGE urn:service:sos SIP/2.0 619 Via: SIP/2.0/TCP sip:aggreg.1.example.com;branch=z9hG4bK776abssa 620 Max-Forwards: 70 621 From: sip:aggregator@example.com;tag=32336 622 To: 112 623 Call-ID: asdf33443a@example.com 624 Route: sip:psap1.example.gov 625 Geolocation: 626 ;routing-allowed=yes 627 Supported: geolocation 628 Call-info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap 629 CSeq: 1 MESSAGE 630 Content-Type: multipart/mixed; boundary=boundary1 631 Content-Length: ... 633 --boundary1 635 Content-Type: application/EmergencyCallData.cap+xml 636 Content-ID: 637 639 640 S-1 641 sip:sensor1@example.com 642 2020-01-04T20:57:35Z 643 Actual 644 Alert 645 Private 646 abc1234 647 648 Security 649 BURGLARY 650 Expected 651 Likely 652 Moderate 653 SENSOR 1 654 655 SENSOR-DATA-NAMESPACE1 656 123 657 658 659 SENSOR-DATA-NAMESPACE2 660 TRUE 661 662 663 665 --boundary1 667 Content-Type: application/pidf+xml 668 Content-ID: 669 670 679 680 681 682 683 684 44.85249659 -93.2386657124 685 686 687 688 689 false 690 691 2020-02-04T20:57:25Z 692 693 694 802.11 695 696 2020-01-04T20:57:25Z 697 698 699 --boundary1-- 701 Figure 4: Example Message conveying an Alert to a PSAP 703 9. Security Considerations 705 This section discusses security considerations when SIP user agents 706 issue emergency alerts utilizing MESSAGE and CAP. Location-specific 707 threats are not unique to this document and are discussed in 708 [RFC7378] and [RFC6442]. 710 The ECRIT emergency services architecture [RFC6443] considers classic 711 individual-to-authority emergency calling where the identity of the 712 emergency caller does not play a role at the time of the call 713 establishment itself, i.e., a response to the emergency call does not 714 depend on the identity of the caller. In the case of emergency 715 alerts generated by devices such as sensors, the processing may be 716 different in order to reduce the number of falsely generated 717 emergency alerts. Alerts could get triggered based on certain sensor 718 input that might have been caused by factors other than the actual 719 occurrence of an alert-relevant event. For example, a sensor may 720 simply be malfunctioning. For this reason, not all alert messages 721 are directly sent to a PSAP, but rather may be pre-processed by a 722 separate entity, potentially under supervision by a human, to filter 723 alerts and potentially correlate received alerts with others to 724 obtain a larger picture of the ongoing situation. 726 In any case, for alerts initiated by sensors, the identity could play 727 an important role in deciding whether to accept or ignore an incoming 728 alert message. With the scenario shown in Figure 1 it is very likely 729 that only authenticated sensor input will be processed. For this 730 reason, it needs to be possible to refuse to accept alert messages 731 from unknown origins. Two types of information elements can be used 732 for this purpose: 734 1. SIP itself provides security mechanisms that allow the 735 verification of the originator's identity, such as P-Asserted- 736 Identity [RFC3325] or SIP Identity [RFC8224]. The latter 737 provides a cryptographic assurance while the former relies on a 738 chain of trust model. These mechanisms can be reused. 740 2. CAP provides additional security mechanisms and the ability to 741 carry further information about the sender's identity. 742 Section 3.3.4.1 of [cap] specifies the signing algorithms of CAP 743 documents. 745 The specific policy and mechanisms used in a given deployment are out 746 of scope for this document. 748 There is no rate limiting mechanisms in SIP, and all kinds of 749 emergency calls, including those defined in this document could be 750 used by malicious actors, or misbehaving devices to effect a denial 751 of service attack on the emergency services. The mechanism defined 752 in this document does not introduce any new considerations although 753 it may be more likely that devices that place non-interactive 754 emergency calls without a human initiating them may be more likely 755 than those that require a user to initiate them. 757 Implementors should note that automated emergency calls may be 758 prohibited or regulated in some jurisdictions, and there may be 759 penalties for "false positive" calls. 761 This document describes potential retrieval of information by 762 dereferencing URIs found in a Call Info header of a SIP MESSAGE. 763 These may include a CAP message as well as other Additional Data 764 (RFC7852) blocks. The domain of the device sending the SIP MESSAGE, 765 the domain of the server holding the CAP message, if sent by 766 reference, and the domain of other Additional Data blocks, if sent by 767 reference, may all be different. No assumptions can be made that 768 there are trust relationships between these entities. Recipients 769 MUST take precautions in retrieving any Additional Data blocks passed 770 by reference, including the CAP message, because the URI may point to 771 a malicious actor or entity not expecting to be referred to for this 772 purpose. The considerations in handling URIs in [RFC3986] apply. 774 Use of timestamps to prevent replay is subject to the availability of 775 accurate time at all participants. Because emergency event 776 notification via this mechanism is relatively low frequency and 777 generally involves human interaction, implementations may wish to 778 consider messages with times within small number of seconds of each 779 other to be effectively simultaneous for the purposes of detecting 780 replay. Implementations may also wish to consider that most deployed 781 time distribution protocols likely to be used by these systems are 782 not presently secure. 784 In addition to the desire to perform identity-based access control, 785 the classic communication security threats need to be considered, 786 including integrity protection to prevent forgery or replay of alert 787 messages in transit. To deal with replay of alerts, a CAP document 788 contains the mandatory , , elements and an 789 optional element. Together, these elements make the CAP 790 document unique for a specific sender and provide time restrictions. 791 An entity that has already received a CAP message within the 792 indicated timeframe is able to detect a replayed message and, if the 793 content of that message is unchanged, then no additional security 794 vulnerability is created. Additionally, it is RECOMMENDED to make 795 use of SIP security mechanisms, such as the SIP Identity PASSporT 796 [RFC8225], to tie the CAP message to the SIP message. To provide 797 protection of the entire SIP message exchange between neighboring SIP 798 entities, the usage of TLS is RECOMMENDED. [RFC6443] discusses the 799 issues of using TLS with emergency calls, which are equally 800 applicable to non-interactive emergency calls 802 Note that none of the security mechanisms in this document protect 803 against a compromised sensor sending crafted alerts. Confidentiality 804 provided for any emergency calls, including non-interactive messages, 805 is subject to local regulations. Privacy issues are discussed in 806 [RFC7852] and are applicable here. 808 10. IANA Considerations 810 10.1. Registration of the 'application/EmergencyCallData.cap+xml' media 811 type 813 To: ietf-types@iana.org 815 Subject: Registration of media type application/ 816 EmergencyCallData.cap+xml 818 Type name: application 820 Subtype name: cap+xml 822 Required parameters: (none) 824 Optional parameters: charset; Indicates the character encoding of 825 enclosed XML. Default is UTF-8 [RFC3629]. 827 Encoding considerations: 7bit, 8bit or binary. See [RFC7303], 828 Section 3.2. 830 Security considerations: This content type is designed to carry 831 payloads of the Common Alerting Protocol (CAP). RFC XXX [Replace 832 by the RFC number of this specification] discusses security 833 considerations for this. 835 Interoperability considerations: This content type provides a way to 836 convey CAP payloads. 838 Published specification: RFC XXX [Replace by the RFC number of this 839 specification]. 841 Applications which use this media type: Applications that convey 842 alerts and warnings according to the CAP standard. 844 Fragment Identifier Considerations: N/A . 846 Additional information: OASIS has published the Common Alerting 847 Protocol at http://www.oasis-open.org/committees/ 848 documents.php&wg_abbrev=emergency 850 Person and email address to contact for further information: Hannes 851 Tschofenig, hannes.tschofenig@gmx.net 853 Intended usage: Limited use 855 Author/Change controller: The IESG 857 Other information: This media type is a specialization of 858 application/xml [RFC7303], and many of the considerations 859 described there also apply to application/cap+xml. 861 10.2. IANA Registration of 'cap' Additional Data Block 863 This document registers a new block type in the sub-registry called 864 'Emergency Call Data Types' of the Emergency Call Additional Data 865 Registry defined in [RFC7852]. The token is "cap", the Data About is 866 "The Call" and the reference is this document. 868 10.3. IANA Registration for 425 Response Code 870 In the SIP Response Codes registry, the following is added 872 Reference: RFC-XXXX (i.e., this document) 874 Response code: 425 (recommended number to assign) 876 Default reason phrase: Bad Alert Message 877 Registry: 878 Response Code Reference 879 ------------------------------------------ --------- 880 Request Failure 4xx 881 425 Bad Alert Message [this doc] 883 This SIP Response code is defined in Section 5. 885 10.4. IANA Registration of New AlertMsg-Error Header Field 887 The SIP AlertMsg-error header field is created by this document, with 888 its definition and rules in Section 5, to be added to the IANA 889 Session Initiation Protocol (SIP) Parameters registry with two 890 actions: 892 1. Update the Header Fields registry with 894 Registry: 895 Header Name compact Reference 896 ----------------- ------- --------- 897 AlertMsg-Error [this doc] 899 2. In the portion titled "Header Field Parameters and Parameter 900 Values", add 902 Predefined 903 Header Field Parameter Name Values Reference 904 ----------------- ------------------- ---------- --------- 905 AlertMsg-Error code no [this doc] 907 10.5. IANA Registration for the SIP AlertMsg-Error Codes 909 This document creates a new registry for SIP, called "AlertMsg-Error 910 Codes". AlertMsg-Error codes provide reasons for an error discovered 911 by a recipient, categorized by the action to be taken by the error 912 recipient. The initial values for this registry are shown below. 914 Registry Name: AlertMsg-Error Codes 916 Reference: [this doc] 918 Registration Procedures: Specification Required 919 Code Default Reason Phrase Reference 920 ---- --------------------------------------------------- --------- 921 100 "Cannot Process the Alert Payload" [this doc] 923 101 "Alert Payload was not present or could not be found" [this doc] 925 102 "Not enough information to determine 926 the purpose of the alert" [this doc] 928 103 "Alert Payload was corrupted" [this doc] 930 Details of these error codes are in Section 5. 932 11. Acknowledgments 934 The authors would like to thank the participants of the Early Warning 935 adhoc meeting at IETF#69 for their feedback. Additionally, we would 936 like to thank the members of the NENA Long Term Direction Working 937 Group for their feedback. 939 Additionally, we would like to thank Martin Thomson, James 940 Winterbottom, Shida Schubert, Bernard Aboba, Marc Linsner, Christer 941 Holmberg and Ivo Sedlacek for their review comments. 943 12. References 945 12.1. Normative References 947 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 948 Requirement Levels", March 1997. 950 [cap] Jones, E. and A. Botterell, "Common Alerting Protocol v. 951 1.2", October 2005, . 954 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 955 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 956 . 958 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 959 DOI 10.17487/RFC2818, May 2000, 960 . 962 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 963 A., Peterson, J., Sparks, R., Handley, M., and E. 964 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 965 DOI 10.17487/RFC3261, June 2002, 966 . 968 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 969 Provisional Responses in Session Initiation Protocol 970 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 971 . 973 [RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., 974 Huitema, C., and D. Gurle, "Session Initiation Protocol 975 (SIP) Extension for Instant Messaging", RFC 3428, 976 DOI 10.17487/RFC3428, December 2002, 977 . 979 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 980 Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, 981 . 983 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 984 Specifications: ABNF", STD 68, RFC 5234, 985 DOI 10.17487/RFC5234, January 2008, 986 . 988 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 989 DOI 10.17487/RFC7303, July 2014, 990 . 992 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 993 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 994 2003, . 996 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 997 Resource Identifier (URI): Generic Syntax", STD 66, 998 RFC 3986, DOI 10.17487/RFC3986, January 2005, 999 . 1001 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 1002 for the Session Initiation Protocol", RFC 6442, 1003 DOI 10.17487/RFC6442, December 2011, 1004 . 1006 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1007 Communications Services in Support of Emergency Calling", 1008 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1009 . 1011 [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 1012 J. Winterbottom, "Additional Data Related to an Emergency 1013 Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, 1014 . 1016 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1017 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1018 May 2017, . 1020 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 1021 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 1022 . 1024 12.2. Informative References 1026 [RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., 1027 "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, 1028 December 2014, . 1030 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1031 "Authenticated Identity Management in the Session 1032 Initiation Protocol (SIP)", RFC 8224, 1033 DOI 10.17487/RFC8224, February 2018, 1034 . 1036 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1037 Emergency and Other Well-Known Services", RFC 5031, 1038 DOI 10.17487/RFC5031, January 2008, 1039 . 1041 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1042 Extensions to the Session Initiation Protocol (SIP) for 1043 Asserted Identity within Trusted Networks", RFC 3325, 1044 DOI 10.17487/RFC3325, November 2002, 1045 . 1047 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 1048 Tschofenig, "LoST: A Location-to-Service Translation 1049 Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, 1050 . 1052 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1053 "Framework for Emergency Calling Using Internet 1054 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 1055 2011, . 1057 Authors' Addresses 1058 Brian Rosen 1059 470 Conrad Dr 1060 Mars, PA 16046 1061 US 1063 Phone: 1064 Email: br@brianrosen.net 1066 Henning Schulzrinne 1067 Columbia University 1068 Department of Computer Science 1069 450 Computer Science Building 1070 New York, NY 10027 1071 US 1073 Phone: +1 212 939 7004 1074 Email: hgs+ecrit@cs.columbia.edu 1075 URI: http://www.cs.columbia.edu 1077 Hannes Tschofenig 1078 ARM Limited 1080 Austria 1082 Email: Hannes.Tschofenig@gmx.net 1083 URI: http://www.tschofenig.priv.at 1085 Randall Gellens 1086 Core Technology Consulting 1088 Email: rg+ietf@coretechnologyconsulting.com 1089 URI: http://www.coretechnologyconsulting.com