<?xml<?xml version="1.0" encoding="UTF-8"?> encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?> subcompact="no"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes"?>
<rfc submissionType="IETF" category="info" docName="draft-atarius-dispatch-meid-urn-as-instanceid-08" consensus="yes" number="XXXX" ipr="trust200902">
<front>
<title abbrev="Using MEID abbrev="MEID URN as an Instance ID">Using the Mobile Equipment Identity (MEID)
Uniform Resource Name (URN) URN as an Instance ID
</title>
<!--[rfced] Throughout the document, we note the use of "instance-id",
which is not uniform with the use in the title of "Instance ID".
The companion (draft-atarius-dispatch-meid-urn-18) uses "instance
ID" in running text. Past RFC titles (e.g., RFC 7255) appear to
use "Instance ID" and the same throughout the text.
We have updated to use "Instance ID" throughout the text instead of
"instance-id" to match past use in RFCs. Please let us know any
objections.
-->
<author role="editor" fullname="Roozbeh Atarius" initials="R.A." surname="Atarius">
<address>
<email>
r_atarius@motorola.com
ratarius@motorola.com
</email>
</address>
</author>
<date month="June" month="August" year="2018"/>
<area>
RAI
</area>
<workgroup>
Dispatch Working Group
</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->
<keyword>example</keyword>
<abstract>
<t>
This specification document specifies how the
Uniform Resource Name (URN) namespace
reserved for the Third Generation
Partnership Project 2 (3GPP2)
identities and its Namespace Specific
String (NSS) for the Mobile Equipment
Identity (MEID) can be used as an instance-id. Its
Instance ID. The purpose of this Instance ID is to fulfill
the requirements for defining how a
specific URN needs to be constructed
and used in the "+sip.instance"
Contact header field parameter for
outbound behavior.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This specification document specifies how the
Uniform Resource Name (URN) namespace
reserved for Third Generation
Partnership Project 2 (3GPP2)
identities and its Namespace Specific
String (NSS) for the Mobile Equipment
Identity (MEID) as specified in draft-atarius-dispatch-meid-urn
RFC YYYY <xref target="refs.draft-atarius-dispatch-meid-urn"/>
target="RFCYYYY"/>
can be used as an instance-id Instance ID as
specified in RFC 5626 <xref
target="RFC5626"/> and also as used by
RFC 5627 <xref target="RFC5627"/>.
</t>
<t>
RFC 5626 <xref target="RFC5626"/>
specifies the "+sip.instance" Contact
header field parameter that contains a
URN as specified in RFC 8141 <xref
target="RFC8141"/>. The
instance-id Instance ID
uniquely identifies a specific User
Agent (UA) instance. This instance-id Instance ID
is used as specified in RFC 5626 <xref
target="RFC5626"/> so that the Session
Initiation Protocol (SIP) registrar
(as specified in RFC 3261 <xref
target="RFC3261"/>) can recognize that
the contacts from multiple
registrations correspond to the same
UA. The instance-id Instance ID is also used as
specified by RFC 5627 <xref
target="RFC5627"/> to create Globally
Routable User Agent URIs (GRUUs) that
can be used to uniquely address a UA
when multiple UAs are registered with
the same Address of Record (AoR).
</t>
<t>
RFC 5626 <xref target="RFC5626"/>
requires that a UA SHOULD create a
Universally Unique Identifier (UUID)
URN as specified in RFC 4122 <xref
target="RFC4122"/> as its instance-id Instance ID
but allows allow for the possibility to use
other URN schemes.
</t>
<figure>
<artwork><![CDATA[
]]></artwork>
</figure>
<t>
RFC 5626 <xref target="RFC5626"/> states:
</t>
<figure>
<artwork><![CDATA[
"If
<!--begin DNE text - quote from RFC 5626; accuracy confirmed.-->
<list><t>
If a URN scheme other than UUID is used, the UA MUST only
use URNs for which an RFC (from the IETF stream) defines how
the specific URN needs to be constructed and used in the
"+sip.instance" Contact header field parameter for outbound
behavior."
]]></artwork>
</figure>
behavior. </t></list></t>
<!--end DNE text -->
<t>
This specification
meets this requirement by specifying how the 3GPP2 MEID URN is used in the "+sip.instance" Contact
header field parameter for outbound behavior and draft-atarius-dispatch-meid-urn RFC YYYY
<xref target="refs.draft-atarius-dispatch-meid-urn"/> target="RFCYYYY"/> specifies how the 3GPP2 MEID URN is constructed.
</t>
<t>
The 3GPP2 MEID URN is a URN for the MEID a globally unique identifier
that identifies mobile devices used in the 3GPP2 networks.
The MEID allocation is managed by the 3GPP2
to ensure that the MEID values are globally unique. Details of the
formatting of the MEID as a URN are specified in
draft-atarius-dispatch-meid-urn
RFC YYYY
<xref target="refs.draft-atarius-dispatch-meid-urn"/> target="RFCYYYY"/>
and the definition of the MEID is contained
in 3GPP2 S.R0048-A <xref target="refs.S.R0048-A"/>.
</t>
</section>
<section title="Terminology">
<t>
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 RFC 8174 BCP 14 <xref target="RFC8174"/>. target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section title="Background">
<t>
Mobile communication has been rapidly
improved from low bit rate circuit
switched system low-bit-rate circuit-switched systems to the higher data rate
packet switched higher-data-rate packet-switched system. The packet switched
packet-switched system has added
the mobile capability of Internet Protocol
(IP)
connectivity and thereby connectivity; thereby, the IP
Multimedia Subsystem (IMS) have made SIP based
SIP-based calls and IP multimedia
sessions from mobile devices possible.
</t>
<t>
3GPP2 defines High Rate Packet Data (HRPD) with high data rates rates, and it dispenses with the
1x Circuit Switched (1xCS) infrastructure.
This means that with HRPD networks, voice calls will need to be conducted using IP and IMS.
However,
the transition to all IP, SIP-based IMS networks worldwide will take a great
many years from the time of this writing and mobile devices
will need to operate in both IP/SIP/IMS mode and circuit-switched mode.
<!--[rfced] This sentence is difficult to parse. Please clarify the
use of "the transition to all IP". If the proposed text does not
capture your intent, please let us know how to update.
Original:
However, the transition to all IP, SIP
based IMS networks worldwide will take a great many years from the
time of this writing and mobile devices will need to operate in both
IP/SIP/IMS mode and circuit switched mode.
Perhaps:
However, SIP-based IMS networks will take a great many years from the time of writing to transition to the use of all IP; mobile devices will need to operate in both IP/SIP/IMS mode and circuit-switched mode.
-->
This
means that calls and sessions
will need to be handed over between IP/SIP/IMS mode and circuit switched circuit-switched mode
mid-call or mid-session.
To achieve this this, the mobile
device needs to simultaneously communicate via both the IP/SIP/IMS domain and
the circuit switched circuit-switched domain.
</t>
<t>
To meet this need need, 3GPP2 has specified how to maintain voice session voice-session continuity
between the IP/SIP/IMS domain and the
circuit switched domain in 3GPP2 S.X0042-B <xref target="refs.S.X0042-B"/>.
</t>
<t>
<!--[rfced] This sentence is long and a bit convoluted. Please rephrase (and consider breaking into smaller sentences).
Original:
In order for the mobile device to access SIP/IMS voice service via
the circuit switched domain 3GPP2 has specified that Mobile Switching
Center (MSC) server either via IMS Media Gateway Control Function
(MGCF) or directly, if enhanced by SIP interface, controls mobile
voice call setup over the circuit switched radio access while
establishing the corresponding voice session in the core network
using SIP/IMS.
-->
<t>
In order for the mobile device to
access SIP/IMS voice service via the
circuit-switched domain, 3GPP2 has
specified that the Mobile Switching Center
(MSC) server either via IMS Media
Gateway Control Function (MGCF) or
directly, if enhanced by SIP
interface, controls mobile voice call
setup over the circuit switched radio
access while establishing the
corresponding voice session in the
core network using SIP/IMS. To enable
this, the mobile device MUST be
identified in both the 1xCS and IP/SIP/IMS
domains. The only mobile device
identifier that is transportable using
1xCS signaling is the MEID therefore MEID; therefore,
the instance-id Instance ID included by the MGCF
or the MSC server, server and the
instance-id Instance ID
directly included by the mobile device
both need to be based on the MEID.
</t>
<t>
Additionally in order to meet the
above requirements, the same MEID that
is obtained from the circuit switched circuit-switched
signaling by the MSC server needs to
be obtainable from SIP signaling so
that it can be determined that both
the SIP signaling and circuit switched circuit-switched
signaling originate from the same
mobile device.
</t>
</section>
<!--start here -->
<section title="3GPP2 Use Cases">
<t>
1. The
<t><list style="numbers">
<t>The mobile device includes its MEID
in the SIP REGISTER request so that
the SIP registrar can perform a check
of the Equipment Identity Register
(EIR) to verify if this mobile device
is allowed or barred from accessing
the network for non-emergency services
(e.g., because it has been stolen). If
the mobile device is not allowed to
access the network for non-emergency services
services, the SIP registrar can reject
the registration. Thus Thus, a barred mobile
device is prevented from accessing the
network for non-emergency services.
</t>
<t>
2.
The mobile device includes its MEID
in SIP INVITE requests used to
establish emergency sessions. This is
so that the Public Safety Answering
Point (PSAP) can obtain the MEID of
the mobile device for identification
purposes if required by regulations.
</t>
<t>
3.
The inclusion by the mobile device
of its MEID in SIP INVITE requests
used to establish emergency sessions
is also used in the cases of
unauthenticated emergency sessions to
enable the network to identify the
mobile device. This is especially
important if the unauthenticated
emergency session is handed over from
the packet switched packet-switched domain to the circuit switched
circuit-switched domain. In this
scenario
scenario, the MEID is the only
identifier that is common to both
domains. The Emergency Access Transfer
Function (EATF) (EATF), which coordinates the
call transfer between the domains, can
thus use the MEID to identify that the circuit switched
circuit-switched call is from the same
mobile device that was in the
emergency session in the packet switched packet-switched domain.
</t>
</t></list></t>
</section>
<section anchor="UAC" title="User Agent Client Procedures">
<t>
A single mode 3GPP2 User Agent Client (UAC)
(UAC), which uses only 3GPP2 technology
to transmit and receive voice or data data,
has an MEID as specified in 3GPP2
S.R0048-A <xref
target="refs.S.R0048-A"/>. The single
mode 3GPP2 UAC that is registering
with a 3GPP2 IMS network includes in
the "sip.instance" media feature tag
the 3GPP2 MEID URN according to the
syntax specified in
draft-atarius-dispatch-meid-urn
RFC YYYY <xref target="refs.draft-atarius-dispatch-meid-urn"/>
target="RFCYYYY"/>
when performing the registration
procedures specified in RFC 5626 <xref
target="RFC5626"/> or RFC 5627 <xref
target="RFC5627"/> or (or any other
procedure requiring the inclusion of
the "sip.instance" media feature tag. tag).
</t>
<t>
A UAC MUST NOT use the 3GPP2 MEID URN
as an instance-id Instance ID except when
registering with a 3GPP2 IMS
network. When a UAC is operating in
IMS mode mode, it will obtain the domain of
the carrier's IMS network to register
with, from the Universal Integrated
Circuit Card (UICC), pre-configuration,
preconfiguration, or the network at
the time of establishing the Packet
Data Protocol (PDP) context. These
three methods are carrier specific and
are only performed by the carrier IMS
networks. The UAC will also obtain
the address of the IMS edge proxy to
send the REGISTER request containing
the MEID using information elements in
the Attach response when it attempts
to connect to the carriers carrier's packet data
network. When registering with a
non-3GPP or non-3GPP2 IMS network network, a
UAC SHOULD use a
Universally Unique Identifier (UUID) UUID
as an instance-id Instance ID as
specified in RFC 5626 <xref
target="RFC5626"/>.
</t>
<t>
A UAC MUST NOT include the
"sip.instance" media feature tag
containing the 3GPP2 MEID URN in the
Contact header field of non-REGISTER
requests except when the request is
related to an emergency
session.
<!--[rfced] This sentence seems redundant. Note that a similar sentence occurs in the section that follows as well.
Original:
Regulatory requirements can
require the MEID to be provided to the
PSAP.
Perhaps:
Regulations can require that the MEID be provided to the PSAP.
-->
Regulatory requirements can
require the MEID to be provided to the
PSAP. Any future exceptions to this
prohibition require an RFC that
addresses how privacy is not violated
by such a usage.
</t>
</section>
<section anchor="UAS" title="User Agent Server Procedures">
<t>
A User Agent Server (UAS) MUST NOT
include its "sip.instance" media
feature tag containing the 3GPP2 MEID
URN in the Contact header field of
responses except when the response is
related to an emergency
session. Regulatory requirements can
require the MEID to be provided to the
PSAP. Any future exceptions to this
prohibition require an RFC that
addresses how privacy is not violated
by such a usage.
</t>
</section>
<section title="3GPP/3GPP2 SIP Registrar Procedures">
<t>
In 3GPP/3GPP2 IMS IMS, when the SIP Registrar
receives in the Contact header field a
"sip.instance" media feature tag
containing the 3GPP2 MEID URN according
to the syntax specified in draft-atarius-dispatch-meid-urn
RFC YYYY <xref target="refs.draft-atarius-dispatch-meid-urn"/>
target="RFCYYYY"/>,
the SIP registrar follows the procedures
specified in RFC 5626 <xref
target="RFC5626"/>. The MEID URN MAY be
validated as described in the
draft-atarius-dispatch-meid-urn
RFC YYYY <xref target="refs.draft-atarius-dispatch-meid-urn"/>.
target="RFCYYYY"/>.
If the UA indicates that it supports the
extension in RFC 5627 <xref
target="RFC5627"/> and the SIP Registrar
allocates a GRUU according to the
procedures specified in RFC 5627 <xref target="RFC5627"/>
target="RFC5627"/>, the
instance-id Instance ID MUST
be obfuscated when creating the "gr"
parameter in order not to reveal the
MEID to other UAs when the public GRUU
is included in non-REGISTER requests and
responses. 3GPP TS 24.229 <xref
target="refs.TS-24.229"/> subclause
5.4.7A.2 specifies the mechanism for
obfuscating the MEID when creating the
"gr" parameter.
</t>
</section>
<section anchor="IANA" title="IANA considerations">
<t>
This Considerations">
<t>This document defines has no items requiring action by IANA. IANA actions.
</t>
</section>
<section anchor="Security" title="Security considerations"> Considerations">
<t>
Since MEIDs MEIDs, like other formats of instance-ids
Instance IDs, can be correlated to a
user, they are personally identifiable
information and MUST be treated as
such. In particular, the "sip.instance"
media feature tag containing the 3GPP2
MEID URN MUST NOT be included in
requests or responses intended to
convey any level of anonymity, as this
could violate the users user's privacy. RFC
5626 <xref target="RFC5626"/> states "One states:
<!--Begin DNE text; quote from RFC 5626; quote verified -->
<list><t>
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".
identity.</t></list>
<!--End DNE text -->
The same concerns apply when
using the 3GPP2 MEID URN as an instance-id.
Instance ID. Publication of the 3GPP2
MEID URN to networks that the UA is not
attached to or the UA does not have a
service relationship with is a security breach and
breach; the "sip.instance" media
feature tag MUST NOT be forwarded by
the service provider's network elements
when forwarding requests or responses
towards the destination UA. The 3GPP2
MEID URN MUST NOT accidentally leak in
other contexts, such as and in
particular when application servers
subscribe to user registration state
using the event package defined in RFC
3680 <xref
target="RFC3680"/>. Additionally, an instance-id
Instance ID containing the 3GPP2 MEID
URN identifies a mobile device and not
a user. The instance-id Instance ID containing the
3GPP2 MEID URN MUST NOT be used alone
as an address for a user or as an
identification credential for a
user. The GRUU mechanism specified in
RFC 5627 <xref target="RFC5627"/>
provides a means to create URIs that
address the user at a specific device
or User Agent. UA.
</t>
<t>
Entities that log the instance-id Instance ID need
to protect them as personally
identifiable information. Regulatory
requirements can require carriers to
log SIP MEIDs.
</t>
<t>
In order to protect the "sip.instance"
media feature tag containing the 3GPP2
MEID URN from being tampered with,
those REGISTER requests containing the
3GPP2 MEID URN MUST be sent using a
security mechanism such as Transport
Layer Security (TLS) as specified in
RFC 4346 8446 <xref target="RFC4346"/> target="RFC8446"/> or
any other security mechanism that
provides equivalent levels of
protection such as hop-by-hop security
based upon IP Security (IPsec).
</t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>
This document draws heavily on draft-atarius-dispatch-meid-urn
<xref target="refs.draft-atarius-dispatch-meid-urn"/> and also on
the style and structure used in RFC 7255 <xref target="RFC7255"/>.
</t>
<t>
The author thanks for the detailed comments, provided by Andrew Allen.
</t>
</section>
</middle>
<back>
<references title="Normative references"> References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3680"?>
<?rfc include="reference.RFC.5626"?>
<?rfc include="reference.RFC.5627"?>
<?rfc include="reference.RFC.8141"?>
<?rfc include="reference.RFC.8174"?>
<!-- <?rfc include="reference.RFC.4346"?>; obsoleted by RFC 8446 -->
<!--[rfced] As RFC 4346 has been obsoleted by RFC 8446, we have updated the citation and corresponding reference entry to point to the latter document. Please let us know any objections. -->
<?rfc include="reference.RFC.4346"?> include="reference.RFC.8446"?>
<?rfc include="reference.RFC.4122"?>
<reference anchor="refs.draft-atarius-dispatch-meid-urn"> anchor='RFCYYYY' target='http://www.rfc-editor.org/info/rfcYYYY'>
<front>
<title>
A Uniform Resource Name
<title>A URN Namespace for the Device Identity and the Mobile Equipment Identity (MEID)
</title>
<author> (MEID)</title>
<author initials='R' surname='Atarius' fullname='Roozbeh Atarius'>
<organization abbrev="IETF">
Atarius, R.
</organization> />
</author>
<date month="January" year="2018" month='August' year='2018' />
<abstract><t>This document defines a Uniform Resource Name (URN) namespace for the Third Generation Partnership Project 2 (3GPP2) and a Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID). The structure of an MEID is 15 hexadecimal digits long and is defined in the Third Generation Partnership Project 2 (3GPP2) (see [S.R0048-A]) to uniquely identify each individual mobile equipment (e.g., a handset or mobile phone). The 3GPP2 has a requirement to be able to use an MEID as a URN. This document fulfills that requirement.</t></abstract>
</front>
<seriesInfo name="Internet Draft" value="draft-atarius-dispatch-meid-urn" name='RFC' value='YYYY' />
<seriesInfo name="DOI" value="10.17487/RFCYYYY"/>
</reference>
<reference anchor="refs.TS-24.229" target="ftp://ftp.3gpp.org/Specs/archive/24_series/24.229/" >
<front>
<title>
TS 24.229:
IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);
Stage 3 (Release 10)
</title>
<author>
<organization>
3GPP
</organization>
</author>
<date month="September" year="2013" />
</front>
<seriesInfo name="3GPP" value="24.229" />
<seriesInfo name="Version" value="10.13.0"/>
<seriesInfo name="Release" value="10" />
</reference>
</references>
<references title="Informative references"> References">
<?rfc include="reference.RFC.7255"?>
<reference anchor='refs.S.R0048-A'>
<front>
<title>
S.R0048-A:
3G Mobile Equipment Identifier (MEID) - Stage 1, Version 4.0
</title>
<author>
<organization>
3GPP2
</organization>
</author>
<date month="June" year="2005" />
</front>
<seriesInfo name="Stage" value="1"/>
<seriesInfo name="Version" value="4.0"/>
<seriesInfo name="3GPP2" value="S.R0048-A 4.0" value="S.R0048-A" />
<format type="PDF" target="http://www.3gpp2.org/Public_html/specs/S.R0048-A_v4.0_050630.pdf" />
</reference>
<!--[rfced] We were unable to find a 2013 version of the S.X0042-B. We found S.X0042-A. Please point us to the version where we can check the reference. -->
<reference anchor="refs.S.X0042-B">
<front>
<title>
S.X0042-B: Voice Call Continuity between IMS and Circuit Switched Systems - Version 1.0
</title>
<author>
<organization>
3GPP2
</organization>
</author>
<date month="December" year="2013" />
</front>
<seriesInfo name="Version" value="1.0"/>
<seriesInfo name="3GPP2" value="S.X0042-B 1.0" />
<format type="PDF" target="www.3gpp2.org/Public_html/specs/X.S0042-B_v1.0_20131206.pdf" />
</reference>
</references>
<section anchor="Acknowledgments" title="Acknowledgments" numbered="no">
<t>
This document draws heavily on
RFC YYYY <xref
target="RFCYYYY"/>
and also on the style and structure
used in RFC 7255 <xref
target="RFC7255"/>.
</t>
<t>
The author thanks Andrew Allen for the detailed
comments.
</t>
</section>
</back>
</rfc>