ECRIT Working Group M. Patel Internet-Draft Nortel Intended status: Standards Track May 7, 2009 Expires: November 8, 2009 SOS Uniform Resource Identifier (URI) Parameter for Marking of Session Initiation Protocol (SIP) Requests related to Emergency Services draft-patel-ecrit-sos-parameter-05.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 8, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document defines a new Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) parameter intended for marking SIP Patel Expires November 8, 2009 [Page 1] Internet-Draft SOS URI Parameter for SIP Emergency May 2009 registration requests related to emergency services. The usage of this new URI parameter complements the usage of the Service Uniform Resource Name (URN) and is not intended to replace it. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. The "sos" URI Parameter . . . . . . . . . . . . . . . . . . . . 4 4.1. REGISTER Request . . . . . . . . . . . . . . . . . . . . . 4 4.2. 2xx Response to REGISTER Request . . . . . . . . . . . . . 4 4.3. Backwards compatibility issues . . . . . . . . . . . . . . 4 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Patel Expires November 8, 2009 [Page 2] Internet-Draft SOS URI Parameter for SIP Emergency May 2009 1. Introduction One way to differentiate a SIP-based emergency call from an ordinary call is by the presence of the Service URN as defined in RFC 5031 [RFC5031] (and used in the IETF emergency services architecture described in PhoneBCP[I-D.ietf-ecrit-phonebcp]). The 3GPP IP Multimedia Subsystem (IMS) emergency services architecture, illustrated in 3GPP TS 23.167 [3GPP.23.167], specifies that the User Equipment (UE) performs emergency registration prior to or during the initiation of an emergency call. The circumstances where such an emergency registration is beneficial are listed below: - the UE is not registered with its home network; - the UE is currently registered but roaming (to ensure that the emergency call is handled in the visited network, as required by some jurisdictions). Emergency registration is possible only when the UE has sufficient credentials to register with its home network and can detect that an emergency session is initiated. Unfortunately, marking of the emergency registration can not be fulfilled by the use of the Service URN. In some countries, it is a regulatory requirement that devices be able to place emegency calls in circumstances where other calls may not be permitted. When a UAC issues an emergency marked REGISTER request it informs the registrar that the contact address and the address-of-record being registered are to be used for emergency calls, and roaming and barring restrictions should not be applied for the registered address-of-record. This document proposes a way to mark a REGISTER request as an emergency registration. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] 3. Requirements Req: It shall be possible to distinguish emergency registration from non-emergency registration. Patel Expires November 8, 2009 [Page 3] Internet-Draft SOS URI Parameter for SIP Emergency May 2009 4. The "sos" URI Parameter This section provides an overview of the proposed new URI parameter to be used for marking REGISTER requests related to emergency services. A new URI parameter "sos" is defined in this document. The "sos" parameter is appended to a URI consistent with RFC 3261 [RFC3261]. It is proposed that use of this URI parameter is restricted to the Contact header included in the REGISTER request (and the 2xx response to the REGISTER request) related to an emergency call only. The "sos" URI parameter MUST NOT be considered as a replacement for the Service URN for emergency calls originated by a UA. 4.1. REGISTER Request When the UA sends a REGISTER request for emergency registration, the "sos" URI parameter MUST be appended to the URI in the Contact header. This serves as an indication to the registrar that the request is for emergency registration. Example: Contact: "Alice" ;q=0.7; expires=3600 In the event that more than one Contact header field is included in the REGISTER request, only the contact addresses that include the "sos" URI parameter shall be considered as emergency registered contact addresses. 4.2. 2xx Response to REGISTER Request The "sos" URI parameter MUST be present in the Contact header in the 200 (OK) response sent by the registrar upon successful registration. The "sos" URI parameter is appended to the URI included in the Contact header, thus indicating to the UA that it needs to include this contact address in the Contact header of an INVITE for emergency call initiation. 4.3. Backwards compatibility issues The backwards compatibility scenario considered in this document is where a legacy registrar does not support the "sos" URI parameter. In this case, if the registrar receives a REGISTER request that includes the "sos" URI parameter in the Contact header, the registrar proceeds with registration procedures and silently ignores the URI- parameter in accordance with RFC 3261[RFC3261]. This ensures the user is registered and thus can successfully initiate an emergency Patel Expires November 8, 2009 [Page 4] Internet-Draft SOS URI Parameter for SIP Emergency May 2009 call. The drawback of proceeding with registration is if the address-of- record is for example barred or has roaming restrictions applied, then these restrictions will not be lifted and thus registration will be unsuccessful. This can limit the UAC's ability to successfully place an emergency call. If registration is successful, the 200 (OK) response from a legacy registrar is unlikely to include the "sos" URI parameter in the Contact header since this registration is treated as a non-emergency registration. 5. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 5234 [RFC5234]. The "sos" URI parameter is a "uri-parameter", as defined by RFC 3261[RFC3261]. uri-parameter =/ sos-param sos-param = "sos" 6. IANA Considerations This specification defines one new SIP URI parameter, as per the registry created by RFC 3969 [RFC3969] Parameter Name: sos Predefined Values: none Reference: [RFCXXXX] [NOTE TO IANA: Please replace XXXX with the RFC number of this specification.] 7. Security Considerations As an identifier, the "sos" parameter itself does not raise any particular security issues. The semantic described by the "sos" parameter are meant to be well-known so privacy considerations do not apply to the URI parameter. The main possibility of attack involves Patel Expires November 8, 2009 [Page 5] Internet-Draft SOS URI Parameter for SIP Emergency May 2009 use of the "sos" parameter to bypass the normal procedures in order to achieve fraudulent use of services or to bypass security procedures. The usage of this parameter as described in this document is purely for the purpose of the REGISTER request and hence in presence of user authentication it is ensured that the respective user can be held accountable. It is RECOMMENDED to log events of misuse of the "sos" URI parameter, for example by including it in a request or response not related to an emergency call. 8. Acknowledgements The author would like to thank Keith Drage, Milo Orsic, Deb Barclay, John-Luc Bakker, Andrew Allen, Hiroshi Ishikawa, Sean Schneyer, Peter Leis, Georg Mayer, Marvin Bienn, Ricky Kaura, Steve Norreys, Laura Liess, AC Mahendran, Roozbeh Atarius, Ramachandran Subramanian and Sandeep Sharma, Brian Rosen, Hannes Tschofenig, Christer Holmberg and Henning Schulzrinne for the discussions and contributions that led to this work. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC3969] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004. 9.2. Informative References [I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Patel Expires November 8, 2009 [Page 6] Internet-Draft SOS URI Parameter for SIP Emergency May 2009 draft-ietf-ecrit-phonebcp-09 (work in progress), March 2009. [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008. [3GPP.23.167] 3GPP, "IP Multimedia Subsystem (IMS) emergency sessions", 3GPP TS 23.167 7.11.0, December 2008. Author's Address Milan Patel Nortel Maidenhead Office Park, Westacott Way Maidenhead, Berkshire, UK Email: milanpa@nortel.com Patel Expires November 8, 2009 [Page 7]