idnits 2.17.00 (12 Aug 2021) /tmp/idnits18414/draft-patel-ecrit-sos-parameter-11.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 9, 2010) is 4210 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) == Missing Reference: 'RFCXXXX' is mentioned on line 239, but not defined == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT Working Group M. Patel 3 Internet-Draft InterDigital Communications 4 Intended status: Standards Track November 9, 2010 5 Expires: May 13, 2011 7 SOS Uniform Resource Identifier (URI) Parameter for Marking of Session 8 Initiation Protocol (SIP) Requests related to Emergency Services 9 draft-patel-ecrit-sos-parameter-11.txt 11 Abstract 13 This document defines a new Session Initiation Protocol (SIP) Uniform 14 Resource Identifier (URI) parameter intended for marking SIP 15 registration requests related to emergency calls and allow admission 16 control to ensure successful initiation of emergency calls. The 17 usage of this new URI parameter complements the usage of the Service 18 Uniform Resource Name (URN) and is not intended to replace it. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 13, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. The "sos" URI Parameter . . . . . . . . . . . . . . . . . . . . 4 58 4.1. REGISTER Request . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. 2xx Response to REGISTER Request . . . . . . . . . . . . . 5 60 4.3. Backwards compatibility issues . . . . . . . . . . . . . . 5 61 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 One way to differentiate a SIP-based emergency call from an ordinary 73 call is by the presence of the Service URN as defined in RFC 5031 74 [RFC5031] (and used in the IETF emergency services architecture 75 described in PhoneBCP[I-D.ietf-ecrit-phonebcp]). The 3GPP IP 76 Multimedia Subsystem (IMS) emergency services architecture, 77 illustrated in 3GPP TS 23.167 [3GPP.23.167], specifies that the User 78 Equipment (UE) needs to perform emergency registration prior to or 79 during the initiation of an emergency call. 81 In some countries, it is a regulatory requirement that devices be 82 able to place emergency calls in circumstances where other calls may 83 not be permitted. When a UAC issues an emergency marked REGISTER 84 request it indicates to the registrar that roaming and barring 85 restrictions should not be applied for the registered address-of- 86 record in order to successfully initiate an emergency session. 87 Furthermore, distinguishing emergency registration from non-emergency 88 registration allows the registrar to ensure that the contact address 89 associated with previous registration of the address-of-record 90 included in the emergency REGISTER request is not replaced. 92 Emergency registration is possible only when the UE has sufficient 93 credentials to register with its home network and can detect that an 94 emergency session is initiated. Unfortunately, marking of the 95 emergency registration cannot be fulfilled by the use of the Service 96 URN. The circumstances where such an emergency registration is 97 beneficial are listed below: 99 - the UE is not registered with its home network; 101 - the UE is currently registered but roaming (to ensure that the 102 emergency call is handled in the visited network, as required by some 103 jurisdictions). 105 This document concentrates on a use case defined by 3GPP as described 106 above. However, the solution proposed does not preclude other 107 systems that require emergency registration to occur prior to placing 108 an emergency call, to ensure that any subscription related 109 restrictions are removed to allow successful initiation of emergency 110 calls. 112 This document proposes a way to mark a REGISTER request as an 113 emergency registration. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119] 121 3. Requirements 123 Req: Where emergency registration is required prior to placing an 124 emergency call, it shall be possible to distinguish emergency 125 registration from non-emergency registration. 127 4. The "sos" URI Parameter 129 This section provides an overview of the proposed new URI parameter 130 to be used for marking REGISTER requests related to emergency 131 services. 133 A new URI parameter "sos" is defined in this document. The "sos" 134 parameter is appended to a URI consistent with RFC 3261 [RFC3261]. 135 It is proposed that use of this URI parameter is restricted to the 136 Contact header included in the REGISTER request (and the 2xx response 137 to the REGISTER request) related to an emergency call only. 139 Inclusion of the "sos" URI parameter in a REGISTER request SHALL 140 indicate that the REGISTER request pertains to emergency 141 registration. The "sos" URI parameter MUST NOT be considered as a 142 replacement for the Service URN for emergency calls originated by a 143 UA. 145 4.1. REGISTER Request 147 In networks where the UA sends a REGISTER request for emergency 148 registration prior to placing an emergency call, the "sos" URI 149 parameter MUST be appended to the URI in the Contact header. This 150 serves as an indication to the registrar that the request is for 151 emergency registration thus requesting the registrar to not apply any 152 restrictions to the user's service which might prevent emergency 153 calls from successfully being initiated. 155 Example: 157 Contact: "Alice" ;q=0.7; expires=3600 159 In the event that more than one Contact header field is included in 160 the REGISTER request, only the contact addresses that include the 161 "sos" URI parameter shall be considered as emergency registered 162 contact addresses. 164 The "sos" URI parameter MUST NOT be included in non-REGISTER 165 requests, and MUST NOT be included in REGISTER requests that do not 166 pertain to emergency calls. 168 4.2. 2xx Response to REGISTER Request 170 If the registrar receives a REGISTER request that includes the "sos" 171 URI parameter in the Contact header field, the registrar MUST include 172 the "sos" URI parameter in the Contact header field in the 200 (OK) 173 response sent by the registrar upon successful registration. The 174 "sos" URI parameter is appended to the URI included in the Contact 175 header. 177 4.3. Backwards compatibility issues 179 The backwards compatibility scenario considered in this document is 180 where a legacy registrar does not support the "sos" URI parameter. 181 In this case, if the registrar receives a REGISTER request that 182 includes the "sos" URI parameter in the Contact header field, the 183 registrar proceeds with registration procedures and silently ignores 184 the URI-parameter in accordance with RFC 3261[RFC3261]. This ensures 185 the user is registered and thus can successfully initiate an 186 emergency call. 188 The drawback of proceeding with registration is if the address-of- 189 record is for example barred or has roaming restrictions applied, 190 then these restrictions will not be lifted and thus registration will 191 be unsuccessful. This can limit the UAC's ability to successfully 192 place an emergency call. 194 If registration is successful, the 200 (OK) response from a legacy 195 registrar includes the "sos" URI parameter in the Contact header 196 field. Thus the UA is unaware that the registrar does not support 197 the "sos" URI parameter. Providing the registration was successful, 198 the UA's ability to place an emergency call is not compromised. The 199 UA need not know that the registrar does not support the URI 200 parameter. 202 The consequence of the registrar not supporting the "sos" URI 203 parameter, in addition to the drawback pertaining to restrictions 204 applied to the address-of-record, are as follows: 206 - the risk of the registrar overwriting previous registrations of the 207 registered address-of-record, and thus disrupting any on-going non- 208 emergency sessions associated with the UA, its address-of-record and 209 previously registered contact address. 211 - incoming calls, such as a PSAP call back (to a previously made 212 emergency call) to the registered address-of-record might not be 213 routed correctly to the UA that placed the emergency call, due to not 214 suppressing any network based services such as call forwarding, or UA 215 based services which can divert the call elsewhere, or if the 216 address-of-record is associated to more than one contact address. 218 5. Formal Syntax 220 The following syntax specification uses the augmented Backus-Naur 221 Form (BNF) as described in RFC 5234 [RFC5234]. 223 The "sos" URI parameter is a "uri-parameter", as defined by RFC 224 3261[RFC3261]. 226 uri-parameter =/ sos-param 228 sos-param = "sos" 230 6. IANA Considerations 232 This specification defines one new SIP URI parameter, as per the 233 registry created by RFC 3969 [RFC3969] 235 Parameter Name: sos 237 Predefined Values: none 239 Reference: [RFCXXXX] 241 [NOTE TO IANA: Please replace XXXX with the RFC number of this 242 specification.] 244 7. Security Considerations 246 As an identifier, the "sos" parameter itself does not raise any 247 particular security issues. The semantics described by the "sos" 248 parameter are meant to be well-known so privacy considerations do not 249 apply to the URI parameter. The main possibility of attack involves 250 use of the "sos" parameter to bypass the normal procedures in order 251 to achieve fraudulent use of services or to bypass security 252 procedures. The usage of this parameter as described in this 253 document is purely for the purpose of the REGISTER request and hence 254 in presence of user authentication it is ensured that the respective 255 user can be held accountable. 257 It is RECOMMENDED to log events of misuse of the "sos" URI parameter, 258 for example by including it in a request or response not related to 259 an emergency call. 261 Emergency registration can result in removing restrictions for 262 roaming and/or barring of services. Misuse of the emergency 263 registered AoR and contact address can be identified within the 264 network and thus requests for unauthorized service will be rejected. 265 Thus, no security considerations related to hijacking of services are 266 foreseen as a result of applying a marking of emergency registrations 267 through the use of a SIP URI parameter. 269 8. Acknowledgements 271 The author would like to thank Keith Drage, Milo Orsic, Deb Barclay, 272 John-Luc Bakker, Andrew Allen, Hiroshi Ishikawa, Sean Schneyer, Peter 273 Leis, Georg Mayer, Marvin Bienn, Ricky Kaura, Steve Norreys, Laura 274 Liess, AC Mahendran, Roozbeh Atarius, Ramachandran Subramanian and 275 Sandeep Sharma, Brian Rosen, Hannes Tschofenig, Christer Holmberg and 276 Henning Schulzrinne for the discussions and contributions that led to 277 this work. 279 9. References 281 9.1. Normative References 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, March 1997. 286 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 287 A., Peterson, J., Sparks, R., Handley, M., and E. 288 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 289 June 2002. 291 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 292 Specifications: ABNF", STD 68, RFC 5234, January 2008. 294 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 295 (IANA) Uniform Resource Identifier (URI) Parameter 296 Registry for the Session Initiation Protocol (SIP)", 297 BCP 99, RFC 3969, December 2004. 299 9.2. Informative References 301 [I-D.ietf-ecrit-phonebcp] 302 Rosen, B. and J. Polk, "Best Current Practice for 303 Communications Services in support of Emergency Calling", 304 draft-ietf-ecrit-phonebcp-16 (work in progress), 305 October 2010. 307 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 308 Emergency and Other Well-Known Services", RFC 5031, 309 January 2008. 311 [3GPP.23.167] 312 3GPP, "IP Multimedia Subsystem (IMS) emergency sessions", 313 3GPP TS 23.167 10.1.0, September 2010. 315 Author's Address 317 Milan Patel 318 InterDigital Communications 320 Email: Milan.Patel@interdigital.com