idnits 2.17.1 draft-polk-local-emergency-rph-namespace-05.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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 (February 22, 2013) is 4053 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5031' is defined on line 361, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-rosen-rph-reg-policy-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Polk 3 Internet-Draft Cisco Systems 4 Intended status: Informational February 22, 2013 5 Expires: August 26, 2013 7 IANA Registering a SIP Resource Priority Header Field Namespace for 8 Local Emergency Communications 9 draft-polk-local-emergency-rph-namespace-05.txt 11 Abstract 13 This document creates the new Session Initiation Protocol (SIP) 14 Resource Priority header field namespace 'esnet' for local emergency 15 session establishment to a public safety answering point (PSAP), 16 between PSAPs, and between a PSAP and first responders and their 17 organizations, and places this namespace in the IANA registry. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 26, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Rules of Usage of the Resource Priority Header field . . . . . 4 55 3. "esnet" Namespace Definition . . . . . . . . . . . . . . . . . 7 56 3.1. Namespace Definition Rules and Guidelines . . . . . . . . 7 57 3.2. The 'esnet' Namespace . . . . . . . . . . . . . . . . . . 7 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 59 4.1. IANA Resource-Priority Namespace Registration . . . . . . 8 60 4.2. IANA Priority-Value Registrations . . . . . . . . . . . . 8 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 63 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 This document creates the new Session Initiation Protocol (SIP) 69 Resource Priority header (RPH) field namespace 'esnet' for local 70 emergency usage and places this namespace in the IANA registry. The 71 SIP Resource-Priority header field is defined in RFC 4412 [RFC4412]. 72 The new 'esnet' namespace is to be used for inbound calls towards a 73 public safety answering point (PSAP), between PSAPs, and between a 74 PSAP and first responders or their organizations within managed IP 75 networks. This namespace is not for use on the open public Internet 76 because it can be trivially forged. 78 Adding a RPH with the 'esnet' namespace can be differentiated from 79 the marking of an emergency call using a service urn as defined in 80 RFC 5031 in that the RPH specifically requests preferential treatment 81 in networks which honor it, while the marking merely identifies an 82 emergency call without necessarily affecting resources allocated to 83 it. It is appropriate to use both where applicable. RPH with 84 'esnet' may also be used within public safety networks for SIP 85 sessions that are not emergency calls and thus not marked per RFC 86 5031. 88 This new namespace is included in SIP requests to provide an explicit 89 priority indication within controlled environments, such as an IMS 90 infrastructure or Emergency Services network (ESInet) where misuse 91 can be reduced to an acceptable level because these types of networks 92 have controls in place. The function facilitates differing treatment 93 of emergency SIP requests according to local policy, or more likely, 94 a contractual agreement between the network organizations. This 95 indication is used solely to differentiate certain SIP requests, 96 transactions or dialogs, from other SIP requests, transactions or 97 dialogs that do not have the need for priority treatment. If there 98 are differing, yet still understandable and valid Resource-Priority 99 header values in separate SIP requests, then this indication can be 100 used by local policy to determine which SIP request, transaction or 101 dialog receives which treatment (likely better or worse than 102 another). 104 Application Service Providers (ASP) securely connected to an ESInet 105 may have sufficient controls policing the header, and a trust 106 relationship with the entities inside the ESInet. SIP requests from 107 such ASPs could make use of this 'esnet' namespace for appropriate 108 treatment when requests are passed from the ASP to the ESInet. 110 The 'esnet' namespace may also be used on calls from a PSAP or other 111 public safety agency on an ESInet towards a private or public 112 network, ASP or UA ("call back") when priority is needed. Again, the 113 request for priority is not for use on the public Internet due to the 114 ease of forging the header. 116 This document merely creates the namespace, per the rules within 117 [RFC4412] as updated by [I-D.rosen-rph-reg-policy], necessitating 118 IETF review for IANA registering new RPH namespaces and their 119 relative priority-value order. 121 There is the possibility that within emergency services networks a 122 Multilevel Precedence and Preemption (MLPP)-like behavior can be 123 achieved (likely without the 'preemption' part), provided local 124 policy supports enabling this function. For example, calls placed 125 between law enforcement agents could be marked similarly to MLPP 126 systems used by military networks, and some of those calls could be 127 handled with higher priority than an emergency call from an ordinary 128 user. Therefore the 'esnet' namespace is given five priority-levels 129 instead of just one. MLPP-like SIP signaling is not defined in this 130 document for 911/112/999 style emergency calling, but it is not 131 prevented either. 133 Within the ESInet, there will be emergency calls requiring different 134 treatments, according to the type of call. Does a citizen's call to 135 a PSAP require the same, a higher or a lower relative priority than a 136 PSAP's call to a police department, or the police chief? What about 137 either relative to a call from within the ESInet to a national 138 government's department responsible for public safety, disaster 139 relief, national security/defense, etc.? For these additional 140 reasons, the 'esnet' namespace was given multiple priority levels. 142 This document does not define any of these behaviors, outside of 143 reminding readers that the rules of RFC 4412 apply - though examples 144 of usage are included for completeness. This document IANA registers 145 the 'esnet' RPH namespace for use within any emergency services 146 networks, not just of those from citizens to PSAPs. 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 2. Rules of Usage of the Resource Priority Header field 154 This document retains the behaviors of the SIP Resource Priority 155 header field, defined in [RFC4412], during the treatment options 156 surrounding this new 'esnet' namespace. The usage of the 'esnet' 157 namespace does not have a 'normal', or routine call level, given the 158 environment this is to be used within (i.e., within an ESInet). That 159 is left for local jurisdictions to define within their respective 160 parts of the ESInet, which could be islands of local administration. 162 The 'esnet' namespace MUST only be used where at least one end of the 163 signaling, setting aside the placement of B2BUAs, is within a local 164 emergency organization. In other words, if either the originating 165 human caller's UA, or the destination human callee's UA is part of 166 the local emergency organization, this is a valid use of 'esnet'. 168 The 'esnet' namespace has 5 priority-values, in a specified relative 169 priority order, and is registered as a queue-based namespace in 170 compliance with [RFC4412]. SIP entities that support preemption 171 treatment (see Section 5 of [RFC4412]) can be configured according to 172 local policy. Display names for the 'esnet' values displayed can 173 likewise be set according to local policy. 175 The following network diagram provides one example of local policy 176 choices for the use of the 'esnet' namespace: 178 |<-'esnet' namespace->| 179 | is used | 180 'esnet' namespace | ,-------. 181 usage out of scope | ,' `. 182 |<------------>|<---'esnet' namespace ---->| / \ 183 +----+ | can be used +-----+ | ESInet | 184 | UA |--- | --------------------|Proxy|-+ ------ | 185 +----+ \ | / +-----+ | | 186 \ ,-------+ ,-------. | | +------+ | 187 +----+ ,' `. ,' `. | | |PSAP-1| | 188 | UA |--- / User \ / Application \ | | +------+ | 189 +----+ ( Network +---+ Service )| | | 190 \ / \ Provider / | | +------+ | 191 +----+ /`. ,' `. .+-----+ | |PSAP-2| | 192 | UA |---- '-------' '-------' |Proxy|-+ +------+ | 193 +----+ | +-----+ | | 194 | | | | 195 +----+ | +-----+ | +------+ | 196 | UA |--- | --------------------|Proxy|-+ |PSAP-3| | 197 +----+ \ | / +-----+ | +------+ | 198 \ ,-------+ ,-------. | | | 199 +----+ ,' `. ,' `. | | | 200 | UA |--- / User \ / Application \ | | +------+ | 201 +----+ ( Network +---+ Service )| | |PSAP-4| | 202 \ / \ Provider / | | +------+ | 203 +----+ /`. ,' `. .+-----+ | | 204 | UA |---- '-------' '-------' |Proxy|-+ ANY can | 205 +----+ | +-----+ | xfer/call | 206 | | \ | | | / 207 `. | | | ,' 208 '-|-|-|-' 209 | | | 210 Police <--------------+ | | 211 Fire <----------+ | 212 National Agency <-------+ 214 A possible network architecture using 'esnet' namespace 216 In Figure 1., the 'esnet' namespace is used within the ESInet on the 217 right side of the diagram. How it is specifically utilized is out of 218 scope for this document, and left to local jurisdictions to define. 219 Whether preemption is implemented in the ESInet and the values 220 displayed to the ESInet users, is likewise out of scope. Adjacent 221 ASPs to the ESInet may have a trust relationship that includes 222 allowing this/these neighboring ASP(s) to use the 'esnet' namespace 223 to differentiate SIP requests and dialogs within the ASP's network. 224 The exact mapping between the internal and external sides of the edge 225 proxy at the ESInet boundaries is out of scope of this document. 227 3. "esnet" Namespace Definition 229 The 'esnet' namespace is not generic for all emergencies because 230 there are a lot of different kinds of emergencies, some on a military 231 scale ([RFC4412] defines 3 of these), some on a national scale 232 ([RFC4412] defines 2 of these), some on an international scale. Each 233 type of emergency can also have its own namespace(s), and although 234 there are many defined for other uses, more are possible - so the 235 911/112/999 style of public user emergency calling for police or fire 236 or ambulance (etc) does not have a monopoly on the word "emergency". 238 The namespace 'esnet' has been chosen, roughly to stand for 239 "Emergency Services NETwork", for a citizen's call for help from a 240 public authority type of organization. This namespace will also be 241 used for communications between emergency authorities, and MAY be 242 used for emergency authorities calling public citizens. An example 243 of the latter is a PSAP operator calling back someone who previously 244 called 911/112/999 and the communication was terminated before it - 245 in the PSAP operator's judgment - should have been. 247 Here is an example of a Resource-Priority header field using the 248 'esnet' namespace: 250 Resource-Priority: esnet.0 252 3.1. Namespace Definition Rules and Guidelines 254 This specification defines one unique namespace for emergency calling 255 scenarios, 'esnet', constituting its registration with IANA. This 256 IANA registration contains the facets defined in Section 9 of 257 [RFC4412]. 259 3.2. The 'esnet' Namespace 261 Per the rules of [RFC4412], each namespace has a finite set of 262 relative priority-value(s), listed (below) from lowest priority to 263 highest priority. In an attempt to not limit this namespace's use in 264 the future, more than one priority-value is assigned to the 'esnet' 265 namespace. This document does not recommend which Priority-value is 266 used where in which situation or scenario. That is for another 267 document to specify. To be effective, the choice within a national 268 jurisdiction needs to be coordinated by all sub-jurisdictions to 269 maintain uniform SIP behavior throughout an emergency calling system 270 of that nation 272 The relative priority order for the 'esnet' namespace is as follows: 274 (lowest) esnet.0 275 esnet.1 276 esnet.2 277 esnet.3 278 (highest) esnet.4 280 The 'esnet' namespace will have priority queuing registrations for 281 these levels per Section 4.5.2 of [RFC4412]. Although no preemption 282 is specified in this document for any levels of esnet, local 283 jurisdiction(s) MAY configure their SIP infrastructure to use this 284 namespace with preemption, as defined in RFC 4412. 286 The remaining rules originated in RFC 4412 apply with regard to an RP 287 actor who understands more than one namespace, and is must maintain 288 its locally significant relative priority order. 290 4. IANA Considerations 292 4.1. IANA Resource-Priority Namespace Registration 294 Within the "Resource-Priority Namespaces" of the sip-parameters 295 section of IANA (created by [RFC4412]), the following entries will be 296 added to this table: 298 Intended New warn- New resp. 299 Namespace Levels Algorithm code code Reference 300 --------- ------ -------------- --------- --------- --------- 301 esnet 5 queue no no [This doc] 303 4.2. IANA Priority-Value Registrations 305 Within the Resource-Priority Priority-values registry of the sip- 306 parameters section of IANA, the following (below) is to be added to 307 the table: 309 Namespace: esnet 310 Reference: (this document) 311 Priority-Values (least to greatest): "0", "1","2", "3", "4" 313 5. Security Considerations 315 The Security considerations that apply to RFC 4412 [RFC4412] apply 316 here. 318 For networks that act on the SIP Resource-Priority header field, 319 incorrect use of namespaces can result in traffic that should have 320 been given preferential treatment not be given it and vice versa. 321 This document does not define a use case where an endpoint outside 322 the ESInet marks its call for preferential treatment. Protections 323 need to be taken to prevent granting preferential treatment to 324 unauthorized users not calling for emergency help even if they are in 325 the ESInet, as well as to prevent misuse by callers outside the 326 ESInet. 328 A simple means of preventing this usage is to not allow 'esnet' 329 marked traffic to get preferential treatment unless the destination 330 is towards the local/regional ESInet. This is not a consideration 331 for internetwork traffic within the ESInet, or generated out of the 332 ESInet. 911/112/999 type of calling is fairly local in nature, with a 333 finite number of URIs that are likely to be considered valid within a 334 portion of a network receiving SIP signaling. 336 This namespace is not intended for use on the Internet because of the 337 difficulty in detecting abuse, specifically, it can trivially be 338 forged and used on a non-emergency session to obtain resource 339 priority. Some networks may determine that it can reasonably prevent 340 abuse and/or the consequences of undetected abuse is not significant. 341 In such cases, use of esnet MAY be allowed. 343 6. Acknowledgements 345 Thanks to Ken Carlberg, Janet Gunn, Fred Baker and Keith Drage for 346 help and encouragement with this effort. Thanks to Henning 347 Schulzrinne, Ted Hardie, Hannes Tschofenig, Janet Gunn and Marc 348 Linsner for constructive comments. A big thanks to Robert Sparks for 349 being patient with the author and Brian Rosen for completing the 350 final edits. 352 7. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 358 Priority for the Session Initiation Protocol (SIP)", 359 RFC 4412, February 2006. 361 [RFC5031] H. Schulzrinne, "A Uniform Resource Name (URN) for 362 Emergency and Other Well-Known Services", RFC 5031, 363 January 2008 365 [I-D.rosen-rph-reg-policy] 366 Rosen, B., "Resource Priority Header (RPH) Registry 367 Management Policy to IETF Review", 368 draft-rosen-rph-reg-policy-00 (work in progress), 369 February 2013. 371 Author's Address 373 James Polk 374 Cisco Systems 375 3913 Treemont Circle 376 Colleyville, TX 76034 377 USA 379 Phone: +1-817-271-3552 380 Email: jmpolk@cisco.com