idnits 2.17.00 (12 Aug 2021) /tmp/idnits51873/draft-rosen-stir-emergency-calls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 9, 2020) is 796 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) == Outdated reference: draft-ietf-stir-rph-emergency-services has been published as RFC 9027 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 stir B. Rosen 3 Internet-Draft March 9, 2020 4 Intended status: Standards Track 5 Expires: September 10, 2020 7 Non-Interactive Emergency Calls 8 draft-rosen-stir-emergency-calls-00 10 Abstract 12 Emergency calls from citizens to authorities, and call back of such 13 emergency calls by authorities to citizens need assurances that 14 headers intended to get appropriate priority from the networks they 15 traverse, and in some cases, appropriate routing. Protection of the 16 SIP Resource Priority Header and the SIP Priority header is needed 17 for such calls. This document describes the environment for placing 18 emergency calls and call backs which motivate the need and use of the 19 mechanisms described in other documents 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 10, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Emergency Calls . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Emergency Call-backs . . . . . . . . . . . . . . . . . . . . 4 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 8.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 [RFC6643] describes how devices use the Internet to place emergency 70 calls and how Public Safety Answering Points (PSAPs) handle Internet 71 emergency calls. In traditional telephone networks, emergency calls 72 are not afforded any priority in the network. Emergency calls are 73 marked with a Service URN, [RFC5031]. 75 Sometimes, the emergency services need to call the person that placed 76 an emergency call after the original emergency call was terminated. 77 This is a case of "call-back". [RFC7090] discusses using SIP 78 Priority to mark a call as a call back. The Resource Priority 79 Header, [RFC4412] defines a way to request the network afford 80 priority in resources: The 'Priority' header field describes the 81 importance that the SIP request should have for the receiving human 82 or its agent. For example, that header may be factored into 83 decisions about call routing to mobile devices and assistants and 84 about call acceptance when the call destination is busy. The 85 'Priority' header field does not affect the usage of PSTN gateway or 86 proxy resources, for example. In addition, any User Agent Client 87 (UAC) can assert any 'Priority' value, and usage of 'Resource- 88 Priority' header field values is subject to authorization. 90 This document describes the environment for placing emergency calls 91 on the Internet, which has different capabilities than the PSTN, as 92 well as call backs across the Internet and describes the requirements 93 for protecting them with the "stir" mechanism. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 SIP is the Session Initiation Protocol [RFC3261] 105 PSAP is a Public Safety Answering Point, the call center for 106 emergency calls. 108 3. Emergency Calls 110 SIP signaling for emergency calls is defined in [RFC6881]. An 111 emergency call is marked with a Service URN [RFC5031] in the Request- 112 URI field. RFC6881 does not have any recommendations for the 113 Resource Priority Header. Emergency calls will make use of the stir 114 mechanism to assure the PSAP that the calling party identifier is 115 accurate. There are numerous cases of what is called "swatting" 116 where an emergency call with a spoofed identity is placed and the 117 caller fraudulently reports serious criminal activity at some 118 address, prompting the authorities to respond with significant force 119 (SWAT team). By validating the identity, authorities hope swatting 120 will become much less possible. 122 It is desirable in some networks to be able to provide some priority 123 in the call handling network for emergency calls, even though the 124 PSTN does not do that. [RFC7135] defines the "esnet" namespace, and 125 4 priority levels "for local emergency session establishment to a 126 public safety answering point (PSAP), between PSAPs, and between a 127 PSAP and first responders and their organizations. ". There is 128 presently no recommendation for what priority level to assign to 129 emergency calls. There are other documents [i3] that describe how to 130 use the esnet values within an Emergency Services IP Network, which 131 is distinct from the originating service provider networks, over 132 which emergency calls may be placed. 134 This document recommends that emergency calls from outside an 135 Emergency Services IP Network be assigned esnet.0. This document 136 makes no recommendations on what originating service provider 137 networks actually provide for resource priority other than to note 138 the obvious: emergency calls should receive some priority for 139 resources. 141 Whatever the network does with the RPH value, it is desirable to 142 protect it from manipulation and 144 [I-D.ietf-stir-rph-emergency-services] provides the mechanism to 145 accomplish that. 147 4. Emergency Call-backs 149 After an emergency call is placed, it is sometimes necessary for the 150 PSAP, or a responder, to call the caller back. This call is placed 151 by the authorities back to the original caller. [RFC7090] describes 152 the use of the SIP Priority header field, with the value "psap- 153 callback" to mark such calls and describes how called networks may 154 use that marking. RFC7090 does not describe any priority, and does 155 not mention use of the Resource Priority header field. There is no 156 protection against misuse of the SIP Priority field, and because, as 157 RFC7090 illustrates, it may affect routing, it is very desirable to 158 protect it from modification. 160 This document recommends that emergency calls-backs from authorities 161 outside an ESInet contain a Resource Priority header field and be 162 assigned esnet.0. This document makes no recommendations on what 163 service provider networks actually provide for resource priority 164 other than to note the obvious: emergency calls-backs should receive 165 some priority for resources. 167 Many countries are starting to adopt the emergency calling paradigms 168 promulgated by the IETF. For example, in North America, the [i3] 169 standard defines IP based emergency calling networks, drawing from 170 IETF work. In those systems, a PKI is being created, with a trusted 171 root, the "PSAP Credentialing Agency" (PCA). The PCA provides a root 172 of trust that could be used to sign call-backs protecting the SIP 173 Priority and Resource Priority header fields. 175 5. IANA Considerations 177 There are no actions requested of IANA in this document 179 6. Security Considerations 181 TBD 183 7. Acknowledgments 185 TBD 187 8. References 188 8.1. Normative References 190 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 191 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 192 May 2017, . 194 8.2. Informative References 196 [i3] NENA, "Detailed Functional and Interface Standards for the 197 NENA i3 Solution", September 2016, 198 . 201 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 202 Emergency and Other Well-Known Services", RFC 5031, 203 DOI 10.17487/RFC5031, January 2008, 204 . 206 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 207 Priority for the Session Initiation Protocol (SIP)", 208 RFC 4412, DOI 10.17487/RFC4412, February 2006, 209 . 211 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 212 Information Version 2 (SMIv2) MIB Modules to YANG 213 Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012, 214 . 216 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 217 Patel, "Public Safety Answering Point (PSAP) Callback", 218 RFC 7090, DOI 10.17487/RFC7090, April 2014, 219 . 221 [RFC7135] Polk, J., "Registering a SIP Resource Priority Header 222 Field Namespace for Local Emergency Communications", 223 RFC 7135, DOI 10.17487/RFC7135, May 2014, 224 . 226 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 227 Communications Services in Support of Emergency Calling", 228 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 229 . 231 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 232 Requirement Levels", BCP 14, RFC 2119, 233 DOI 10.17487/RFC2119, March 1997, 234 . 236 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 237 A., Peterson, J., Sparks, R., Handley, M., and E. 238 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 239 DOI 10.17487/RFC3261, June 2002, 240 . 242 [I-D.ietf-stir-rph-emergency-services] 243 Dolly, M. and C. Wendt, "Assertion Values for a Resource 244 Priority Header Claim in Support of Emergency Services 245 Networks", draft-ietf-stir-rph-emergency-services-00 (work 246 in progress), January 2020. 248 Author's Address 250 Brian Rosen 251 470 Conrad Dr 252 Mars, PA 16046 253 US 255 Phone: 256 Email: br@brianrosen.net