[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Dispatch Working Group                                     A. Allen, Ed.
Internet-Draft                                                Blackberry
Updates: 7255 (if approved)                                   A. Soloway
Intended status: Informational                                  Qualcomm
Expires: August 22, 2015                               February 18, 2015


 Session Initiation Protocol (SIP) Instance ID usage by the Open Mobile
                  Alliance Push-to-talk over Cellular
              draft-allen-dispatch-poc-instanceid-usage-02

Abstract

   This document describes how the SIP Instance ID as defined in RFC
   5626 [1] is used by the Open Mobile Alliance (OMA), for Push-to-talk
   over Cellular (PoC) and Push-to-Communicate for Public Safety (PCPS)
   and addresses security concerns with use of the SIP instance ID in
   non-register requests and responses.

   This document updates RFC 7255 [2] to allow the use of the
   International Mobile Equipment Identity (IMEI) as an instance ID in
   the Contact header field of non-register requests and responses by
   the OMA PoC and PCPS enablers for the purposes described in this
   document.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on August 22, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Allen & Soloway          Expires August 22, 2015                [Page 1]


Internet-Draft            PoC Instance ID usage            February 2015


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Overall Applicability . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Architectural Background  . . . . . . . . . . . . . . . . . .   4
   5.  Use of SIP Instance ID  . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Overall Applicability

   The procedures specified in this document makes certain assumptions
   regarding network topology and the existence of transitive trust.
   These assumptions are generally NOT APPLICABLE in the Internet as a
   whole.  The mechanisms specified here were designed to satisfy the
   requirements specified by the Open Mobile Alliance for Push-to-talk
   over Cellular and Push-to-Communicate for Public Safety.

2.  Introduction

   The Open Mobile Alliance(OMA)(http://www.openmobilealliance.org) has
   specified the Push-to-talk Over Cellular (PoC) and Push-to-
   Communicate for Public Safety enablers where the SIP protocol [3] is
   used to establish half duplex media sessions between different
   participants.  OMA completed the specification of the initial version
   of the PoC Enabler (OMA PoC 1.0) in 2006.  Enhanced versions of this
   enabler have been defined since then (OMA PoC 2.0 and OMA PoC 2.1)
   that add additional functionality.  Most recently OMA completed
   another update of the OMA PoC enabler for Push-To-Talk over 3GPP Long
   Term Evolution (LTE) networks as a baseline for the work now taking
   place in 3GPP on Mission Critical Push-To-Talk over LTE (MCPTT).  The
   updated version of the OMA PoC Enabler is known as OMA Push-to-
   Communicate for Public Safety (PCPS). 3GPP MCPTT is part of an
   initiative from Public Safety communities around the world to define
   a global standard for Broadband Public Safety networks, based on 3GPP



Allen & Soloway          Expires August 22, 2015                [Page 2]


Internet-Draft            PoC Instance ID usage            February 2015


   LTE and 3GPP Enhanced Packet Core (EPC) technology.  Public Safety
   Agencies in the United States, United Kingdom, several other European
   nations, as well as South Korea are planning to deploy MCPTT as a
   supplement to, and ultimately a replacement for, their existing 2nd
   Generation Push-To-Talk systems such as P25 (see TIA-102 [4]),
   Terrestrial Trunked Radio (TETRA)(see ETSI EN 300 392-1 [5]) and
   other 2nd Generation and analog Push-To-Talk systems.  The 3GPP MCPTT
   work is scheduled for completion at the end of 2015 with initial
   deployments of MCPTT expected in 2016.

   This document describes how the SIP Instance ID as defined in RFC
   5626 [1] is used by the OMA PoC and PCPS enablers and how security
   concerns with use of the SIP instance ID in non-register requests and
   responses are addressed by these enablers.

   The PoC and PCPS enablers allow a user of a PTT Terminal to establish
   a session to one or more PTT Terminals simultaneously, usually
   initiated by the initiating user pushing a button.

   OMA has defined an architecture to enable the support of the PoC and
   PCPS services based upon the use of PTT Servers within the network.
   The PoC and PCPS enablers cannot function without the support of
   these PTT Servers by the network.

3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [6].

   The term "PTT Server" (Push-to-talk Server), is introduced in this
   document.

   A "PTT Server" as referred to here is a SIP network server that
   performs the network based functions for the Push-To-Talk service.
   The PTT Server acts as a back-to-back UA (B2BUA) as defined in [3]
   when processing SIP requests and responses for establishing SIP Push-
   To-Talk sessions.  There can be one or more PTT Servers involved in a
   SIP Push-To-Talk session.  The PTT Server is called a PoC Server in
   the OMA architecture.

   The term "PTT Terminal" (Push-to-talk Terminal), is introduced in
   this document.

   A "PTT Terminal" as referred to here is a SIP User Agent (UA) in a
   mobile or fixed device used by a user of the Push-To-Talk service.
   The PTT Terminal is called a PoC Client in the OMA architecture.




Allen & Soloway          Expires August 22, 2015                [Page 3]


Internet-Draft            PoC Instance ID usage            February 2015


4.  Architectural Background

   The OMA PoC Architecture [7] utilizes PTT Servers within the network
   that can perform such roles as a conference focus [8], a real-time
   transport protocol (RTP) translator, floor control, or a network
   policy enforcement server.  There can be more than one PTT server in
   the signaling path for the session, particularly when multiple
   domains are involved in the session.  Section 6.1.3 of the OMA PoC
   Architecture [7] defines the functions of the PTT Servers (known in
   OMA terminology as PoC Servers).  Two roles for the PTT Servers are
   defined, the Participating PoC Function and the Controlling PoC
   Function.  Each PTT Terminal is assigned a PTT Server that performs
   the Participating PoC Function.  When the PTT Terminal originates a
   PTT Session the assigned PTT Server performs the Originating
   Participating PoC Function.  When the PTT Terminal is invited to a
   PTT Session the assigned PTT Server performs the Terminating
   Participating PoC Function.  The Controlling PoC Function performs
   floor control (know as Talk/Media Burst Control) and acts as the
   conference focus for group PTT Sessions.  For 1-1 and adhoc group PTT
   Sessions the Originating Participating PoC Function and the
   Controlling PoC Function roles are always combined within the same
   PTT Server.  For Pre-arranged group and Chat group PTT Sessions the
   Controlling PoC Function is the PTT Server that hosts the Conference
   URI that is used for the Pre-arranged group or Chat group.

   When a PTT Session is established SIP requests are sent by the PTT
   Terminal to the PTT Server performing the Originating Participating
   PoC Function which acts as a B2BUA and then originates a new SIP
   request which is sent to the PTT Server preforming the Controlling
   PoC Function which acting as a B2BUA then originates a new SIP
   request towards each of the PTT Terminal invited to the PTT Session
   which are routed to the PTT Server performing the Terminating
   Participating PoC Function for the invited PTT Terminal(s).  The PTT
   Server performing the Terminating Participating PoC Function also
   acts as B2BUA and originates a new SIP request to the PTT Terminal.

   The PTT Server performing the Participating PoC Function provides
   various features to the PTT Terminal that it serves.  In order to
   support these features the PTT Server performing the Participating
   PoC Function needs to obtain various user configurable settings (e.g.
   the current answer mode) from the PTT Terminal.  To do this an event
   package to indicate these PoC Service Settings was defined in [9].
   Immediatly after completing SIP registration the PTT Terminal sends a
   SIP PUBLISH request [10] containing the PoC Service settings event
   package to the PTT Server performing the Participating PoC Function.
   As well as delivering the PoC Service Settings to enable and
   configure various features the SIP PUBLISH request acts as a kind of
   implicit registration of the PTT Terminal with the PTT Server



Allen & Soloway          Expires August 22, 2015                [Page 4]


Internet-Draft            PoC Instance ID usage            February 2015


   performing the Participating PoC Function.  The receipt of a 200 OK
   response from the PTT Server informs the PTT Terminal that the PoC
   Service is supported by the network.  If a 200 OK response to the SIP
   PUBLISH request is not received from the PTT Server the PTT Terminal
   will not initiate any PTT Sessions.

5.  Use of SIP Instance ID

   OMA PoC has been developed in phases.  The first phase was OMA PoC
   1.0 and was later enhanced as OMA PoC 2.0.  Additional enhancements
   were added as part of OMA PoC 2.1 and then the enabler was updated
   for use over 3GPP LTE as OMA PCPS.  One of the enhancements in OMA
   PoC 2.0 is the support of multiple PoC Addresses by the PTT Terminal
   and the support of multiple PTT Terminals registering with the same
   PoC Address.  The PoC Address is a Public User Identity that is
   registered as an address of record (AoR).  The PTT Server performing
   the Participating PoC Function needs to be aware of how many PTT
   Sessions are established with a particular PTT Terminal in order for
   certain features such a simultaneous PoC Sessions to work correctly.
   Supporting multiple PoC Addresses and multiple PTT Terminals
   registering with the same PoC Address complicates the monitoring of
   how many PTT Sessions are established with a particular PTT Terminal
   by the PTT Server.  Since now the PTT Server needs to know which PTT
   Sessions are established to which PTT Terminal even when the PTT
   Terminal has multiple PTT sessions established to different PoC
   Addresses or when different PTT Terminals sharing the same PoC
   Address are involved in separate PTT Sessions.  Therefore in order to
   support multiple PoC Addresses and multiple PTT Terminals registering
   with the same PoC Address the PTT Server performing the Participating
   PoC Function needs to know which PTT Terminal is involved in which
   PTT Sessions and the relationship between PTT Terminals and PoC
   Addresses.

   To do this the PTT Terminal includes in both the SIP REGISTER request
   and in the PoC Service Settings the SIP Instance ID defined in RFC
   5626 [1].  The PTT Terminal will also send a SIP PUBLISH request
   containing the PoC Service Settings event package for each registered
   PoC Address.  This way the PTT Server performing the Participating
   PoC Function is made aware of the relationship between the instances
   of PTT Terminals and PoC Addresses.  By subscribing to the
   Registration Event Package defined in [11] the PTT Server can also
   determine if multiple PTT Terminals share the same PoC Address and
   the SIP Instance IDs of those PTT Terminals sharing the same PoC
   Address.

   In order for the PTT Server performing the Participating PoC Function
   to be made aware of which PTT Sessions are on which PTT Terminals the
   PTT Terminal includes the SIP Instance ID in the Contact header field



Allen & Soloway          Expires August 22, 2015                [Page 5]


Internet-Draft            PoC Instance ID usage            February 2015


   of SIP requests and SIP responses related to PTT Sessions.  In order
   to address privacy concerns with providing the SIP Instance ID to
   other parties the PTT Server performing the Participating PoC
   Function does not include the SIP Instance ID in the requests and
   responses that it sends towards the remote party.

   In parallel to the development of OMA PoC, 3GPP has continued to
   enhance the IP Multimedia Subsystem (IMS) which is a SIP based
   network which can be used to deploy OMA PoC and PCPS for mobile
   networks. 3GPP TS 24.229 [12] makes using the IMEI URN defined in RFC
   7254 [13] as the SIP Instance ID (see RFC 7255 [2]) mandatory for
   3GPP mobile terminals from 3GPP release 10.  However RFC 7255 [2]
   does not allow inclusion of the IMEI as the SIP Instance ID in the
   Contact header field of non-register requests or responses except
   when the request or response is related to an emergency session.
   Thus when OMA PoC or PCPS enablers are deployed on 3GPP terminals
   compliant with 3GPP release 10 or later the use of the SIP Instance
   ID by OMA PoC and PCPS will not comply with the requirements of RFC
   7255 [2].

6.  Security Considerations

   The instance ID is personally identifiable information that can be
   associated with a user and therefore could reveal the identity of a
   caller if included in anonymous requests.  RFC 5626 [1] states "One
   case where a UA could prefer to omit the "sip.instance" media feature
   tag is when it is making an anonymous request or some other privacy
   concern requires that the UA not reveal its identity".  OMA PoC
   depends on 3GPP IP Multimedia Subsystem (IMS) and 3GPP have defined
   use of the IMEI as an instance ID as defined in RFC 7255 [2] and in
   RFC 7254 [13].  The same privacy concerns apply when using the IMEI
   URN as an instance ID.

   RFC 7255 [2] states "A UAC MUST NOT include its "sip.instance" media
   feature tag containing the GSMA IMEI URN in the Contact header field
   of non-REGISTER requests, except when the request is related to an
   emergency session.  Regulatory requirements can require that the IMEI
   be provided to the PSAP.  Any future exceptions to this prohibition
   will require the publication of an RFC that addresses how privacy is
   not violated by such usage".  RFC 7255 [2] also makes a similar
   prohibition on the use of the "sip.instance" media feature tag
   containing the GSMA IMEI URN in the Contact header field of responses
   without publication of an RFC that addresses how privacy is not
   violated by such usage.  The OMA PoC usage of the instance ID as
   defined in this document adds an additional exception to the usage of
   "sip.instance" media feature tag containing the GSMA IMEI URN in the
   Contact header field of non-register requests and responses.  Since
   the PTT Server performing the Participating PoC Function does not



Allen & Soloway          Expires August 22, 2015                [Page 6]


Internet-Draft            PoC Instance ID usage            February 2015


   include the Instance ID in requests and responses that it generates
   and sends towards the remote party the privacy concerns with
   including the Instance ID in the Contact header field of non-register
   requests and responses are addressed.

7.  Acknowledgements

   The author would like to thank TBD.

8.  Informative References

   [1]        Jennings, C., Mahy, R., and F. Audet, "Managing Client-
              Initiated Connections in the Session Initiation Protocol
              (SIP)", RFC 5626, October 2009.

   [2]        Allen, A., "Using the International Mobile station
              Equipment Identity (IMEI) Uniform Resource Name (URN) as
              an Instance ID", RFC 7255, May 2014.

   [3]        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.

   [4]        TIA, , "Project 25 TIA-102: Documentation Suite Overview",
              TSB 102, Edition B, June 2012.

   [5]        ETSI, , "Terrestrial Trunked Radio (TETRA);Voice plus Data
              (V+D);Part 1: General network design", EN 300 392-2,
              v1.4.1 (2009-01), January 2009.

   [6]        Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [7]        OMA, , "Push-To-Talk over Cellular - Architecture", OMA-
              AD-PoC V2_0, 20110802 A, August 2011.

   [8]        Rosenberg, J., "A Framework for Conferencing with the
              Session Initiation Protocol (SIP)", RFC 4353, February
              2006.

   [9]        Garcia-Martin, M., "A Session Initiation Protocol (SIP)
              Event Package and Data Format for Various Settings in
              Support for the Push-to-Talk over Cellular (PoC) Service",
              RFC 4354, January 2006.

   [10]       Niemi, A., "Session Initiation Protocol (SIP) Extension
              for Event State Publication", RFC 3903, October 2004.



Allen & Soloway          Expires August 22, 2015                [Page 7]


Internet-Draft            PoC Instance ID usage            February 2015


   [11]       Rosenberg, J., "A Session Initiation Protocol (SIP) Event
              Package for Registrations", RFC 3680, March 2004.

   [12]       3GPP, , "TS 24.229: IP multimedia call control protocol
              based on Session Initiation Protocol (SIP) and Session
              Description Protocol (SDP); Stage 3 (Release 10)", 3GPP
              24.229, December 2014, <ftp://ftp.3gpp.org/Specs/
              archive/24_series/24.229/>.

   [13]       Montemurro, M., Allen, A., McDonald, D., and P. Gosden, "A
              Uniform Resource Name Namespace for the Global System for
              Mobile Communications Association (GSMA) and the
              International Mobile station Equipment Identity (IMEI)",
              RFC 7254, May 2014.

Authors' Addresses

   Andrew Allen (editor)
   Blackberry
   1200 Sawgrass Corporate Parkway
   Sunrise, Florida  33323
   USA

   Phone: unlisted
   Fax:   unlisted
   Email: aallen@blackberry.com


   Alan Soloway
   Qualcomm
   5775 Morehouse Drive
   San Diego, California  92121
   USA

   Phone: unlisted
   Fax:   unlisted
   Email: asoloway@qti.qualcomm.com














Allen & Soloway          Expires August 22, 2015                [Page 8]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/