Internet DRAFT - draft-allen-dispatch-poc-instanceid-usage
draft-allen-dispatch-poc-instanceid-usage
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]
