doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc7255.txt b/doc/rfc/rfc7255.txt
new file mode 100644
index 0000000..9411fb9
--- /dev/null
+++ b/doc/rfc/rfc7255.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     A. Allen, Ed.
+Request for Comments: 7255                                    Blackberry
+Category: Informational                                         May 2014
+ISSN: 2070-1721
+
+
+    Using the International Mobile station Equipment Identity (IMEI)
+             Uniform Resource Name (URN) as an Instance ID
+
+Abstract
+
+   This specification defines how the Uniform Resource Name (URN)
+   reserved for the Global System for Mobile Communications Association
+   (GSMA) identities and its sub-namespace for the International Mobile
+   station Equipment Identity (IMEI) can be used as an instance-id.  Its
+   purpose 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.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7255.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allen                         Informational                     [Page 1]
+
+RFC 7255            Using IMEI URN as an Instance ID            May 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 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
+   (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. Introduction ....................................................2
+   2. Terminology .....................................................3
+   3. Background ......................................................3
+   4. 3GPP Use Cases ..................................................5
+   5. User Agent Client Procedures ....................................5
+   6. User Agent Server Procedures ....................................6
+   7. 3GPP SIP Registrar Procedures ...................................6
+   8. Security Considerations .........................................7
+   9. Acknowledgements ................................................7
+   10. References .....................................................8
+      10.1. Normative References ......................................8
+      10.2. Informative References ....................................8
+
+1.  Introduction
+
+   This specification defines how the Uniform Resource Name (URN)
+   reserved for the Global System for Mobile Communications Association
+   (GSMA) identities and its sub-namespace for the International Mobile
+   station Equipment Identity (IMEI) as specified in RFC 7254 [1] can be
+   used as an instance-id as specified in RFC 5626 [2] and also as used
+   by RFC 5627 [3].
+
+   RFC 5626 [2] specifies the '+sip.instance' Contact header field
+   parameter that contains a URN as specified in RFC 2141 [4].  The
+   instance-id uniquely identifies a specific User Agent (UA) instance.
+   This instance-id is used as specified in RFC 5626 [2] so that the
+   Session Initiation Protocol (SIP) registrar (as specified in RFC 3261
+   [9]) can recognize that the contacts from multiple registrations
+   correspond to the same UA.  The instance-id is also used as specified
+
+
+
+
+
+Allen                         Informational                     [Page 2]
+
+RFC 7255            Using IMEI URN as an Instance ID            May 2014
+
+
+   by RFC 5627 [3] 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).
+
+   RFC 5626 [2] requires that a UA SHOULD create a Universally Unique
+   Identifier (UUID) URN as specified in RFC 4122 [6] as its instance-id
+   but allows for the possibility to use other URN schemes.  Per
+   RFC 5626, "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".  This
+   specification meets this requirement by specifying how the GSMA IMEI
+   URN is used in the '+sip.instance' Contact header field parameter for
+   outbound behavior, and RFC 7254 [1]  specifies how the GSMA IMEI URN
+   is constructed.
+
+   The GSMA IMEI is a URN for the IMEI -- a globally unique identifier
+   that identifies mobile devices used in the GSM, Universal Mobile
+   Telecommunications System (UMTS), and 3rd Generation Partnership
+   Project (3GPP) Long Term Evolution (LTE) networks.  The IMEI
+   allocation is managed by the GSMA to ensure that the IMEI values are
+   globally unique.  Details of the formatting of the IMEI as a URN are
+   specified in RFC 7254 [1], and the definition of the IMEI is
+   contained in 3GPP TS 23.003 [10].  Further details about the GSMA's
+   role in allocating the IMEI, and the IMEI allocation guidelines, can
+   be found in GSMA PRD TS.06 [11].
+
+2.  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 RFC 2119 [7].
+
+3.  Background
+
+   GSM, UMTS, and LTE capable mobile devices represent 90% of the mobile
+   devices in use worldwide.  Every manufactured GSM, UMTS, or LTE
+   mobile device has an allocated IMEI that uniquely identifies this
+   specific mobile device.  Among other things, in some regulatory
+   jurisdictions the IMEI is used to identify that a stolen mobile
+   device is being used, to help to identify the subscription that is
+   using it, and to prevent use of the mobile device.  While GSM was
+   originally a circuit switched system, enhancements such as the
+   General Packet Radio Service (GPRS) and UMTS have added IP data
+   capabilities that, along with the definition of the IP Multimedia
+   Subsystem (IMS), have made SIP-based calls and IP multimedia sessions
+   from mobile devices possible.
+
+
+
+
+Allen                         Informational                     [Page 3]
+
+RFC 7255            Using IMEI URN as an Instance ID            May 2014
+
+
+   The latest enhancement, known as LTE, introduces even higher data
+   rates and dispenses with the circuit switched infrastructure
+   completely.  This means that with LTE 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, and
+   mobile devices, being mobile, 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 mode mid-call or mid-session.  Also, since many existing GSM
+   and UMTS radio access networks are unable to support IP/SIP/IMS-based
+   voice services in a commercially acceptable manner, some sessions
+   could have some media types delivered via IP/IMS simultaneously with
+   voice media delivered via the circuit switched domain to the same
+   mobile device.  To achieve this, the mobile device needs to be
+   simultaneously attached via both the IP/SIP/IMS domain and the
+   circuit switched domain.
+
+   To meet this need, the 3GPP has specified how to maintain session
+   continuity between the IP/SIP/IMS domain and the circuit switched
+   domain in 3GPP TS 24.237 [12], and in 3GPP TS 24.292 [13] has
+   specified how to access IMS hosted services via both the IP/SIP/IMS
+   domain and the circuit switched domain.
+
+   In order for the mobile device to access SIP/IMS services via the
+   circuit switched domain, the 3GPP has specified a Mobile Switching
+   Center (MSC) server enhanced for IMS Centralized Services (ICS) and a
+   MSC server enhanced for Single Radio Voice Call Continuity (SR-VCC)
+   that control 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 MSC server enhanced for
+   ICS or the MSC server enhanced for SR-VCC performs SIP registration
+   on behalf of the mobile device, which is also simultaneously directly
+   registered with the IP/SIP/IMS domain.  The only mobile device
+   identifier that is transportable using GSM/UMTS/LTE signaling is the
+   IMEI; therefore, the instance-id included by the MSC server enhanced
+   for ICS or the MSC server enhanced for SR-VCC when acting on behalf
+   of the mobile device, and the instance-id directly included by the
+   mobile device, both need to be based on the IMEI.
+
+   Additionally, in order to meet the above requirements, the same IMEI
+   that is obtained from the 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 signaling
+   originate from the same mobile device.
+
+   For these reasons, 3GPP TS 24.237 [12] and 3GPP TS 24.292 [13]
+   already specify the use of the URN namespace for the GSMA IMEI URN as
+   specified in RFC 7254 [1] as the instance-id used by GSM/UMTS/LTE
+
+
+
+Allen                         Informational                     [Page 4]
+
+RFC 7255            Using IMEI URN as an Instance ID            May 2014
+
+
+   mobile devices, the MSC server enhanced for SR-VCC, and the MSC
+   server enhanced for ICS, for SIP/IMS registrations and emergency-
+   related SIP requests.
+
+4.  3GPP Use Cases
+
+   1.  The mobile device includes its IMEI in the SIP REGISTER request
+       so that the SIP registrar can perform a check of the Equipment
+       Identity Register (EIR) to verify whether this mobile device is
+       allowed to access the network for non-emergency services or is
+       barred from doing so (e.g., because the device has been stolen).
+       If the mobile device is not allowed to access the network for
+       non-emergency services, the SIP registrar can reject the
+       registration and thus prevent a barred mobile device from
+       accessing the network for non-emergency services.
+
+   2.  The mobile device includes its IMEI in SIP INVITE requests used
+       to establish emergency sessions.  This is so that the Public
+       Safety Answering Point (PSAP) can obtain the IMEI of the mobile
+       device for identification purposes if required by regulations.
+
+   3.  The IMEI that is included in SIP INVITE requests by the mobile
+       device and used to establish emergency sessions is also used in
+       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 domain to the circuit switched domain.  In this
+       scenario, the IMEI is the only identifier that is common to both
+       domains, so the Emergency Access Transfer Function (EATF) in the
+       network, which in such cases coordinates the transfer between
+       domains, can use the IMEI to determine that the circuit switched
+       call is from the same mobile device that was in the emergency
+       session in the packet switched domain.
+
+5.  User Agent Client Procedures
+
+   A User Agent Client (UAC) that has an IMEI as specified in 3GPP TS
+   23.003 [10] and that is registering with a 3GPP IMS network MUST
+   include in the "sip.instance" media feature tag the GSMA IMEI URN
+   according to the syntax specified in RFC 7254 [1] when performing the
+   registration procedures specified in RFC 5626 [2] or RFC 5627 [3], or
+   any other procedure requiring the inclusion of the "sip.instance"
+   media feature tag.  The UAC SHOULD NOT include the optional 'svn'
+   parameter in the GSMA IMEI URN in the "sip.instance" media feature
+   tag, since the software version can change as a result of upgrades to
+   the device firmware that would create a new instance-id.  Any future
+   non-zero values of the 'vers' parameter, or the future definition of
+   additional parameters for the GSMA IMEI URN that are intended to be
+
+
+
+Allen                         Informational                     [Page 5]
+
+RFC 7255            Using IMEI URN as an Instance ID            May 2014
+
+
+   used as part of an instance-id, will require that an update be made
+   to this RFC.  The UAC MUST provide character-by-character identical
+   URNs in each registration according to RFC 5626 [2].  Hence, any
+   optional or variable components of the URN (e.g., the 'vers'
+   parameter) MUST be presented with the same values and in the same
+   order in every registration as in the first registration.
+
+   A UAC MUST NOT use the GSMA IMEI URN as an instance-id, except when
+   registering with a 3GPP IMS network.  When a UAC is operating in IMS
+   mode, it will obtain from the Universal Integrated Circuit Card
+   (UICC) (commonly known as the SIM card) the domain of the network
+   with which to register.  This is a carrier's IMS network domain.  The
+   UAC will also obtain the address of the IMS edge proxy to send the
+   REGISTER request containing the IMEI using information elements in
+   the Attach response when it attempts to connect to the carrier's
+   packet data network.  When registering with a non-3GPP IMS network, a
+   UAC SHOULD use a UUID as an instance-id as specified in RFC 5626 [2].
+
+   A UAC MUST NOT include the "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.
+
+6.  User Agent Server Procedures
+
+   A User Agent Server (UAS) MUST NOT include its "sip.instance" media
+   feature tag containing the GSMA IMEI URN in the Contact header field
+   of responses, except when the response 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.
+
+7.  3GPP SIP Registrar Procedures
+
+   In 3GPP IMS, when the SIP registrar receives in the Contact header
+   field a "sip.instance" media feature tag containing the GSMA IMEI URN
+   according to the syntax specified in RFC 7254 [1] the SIP registrar
+   follows the procedures specified in RFC 5626 [2].  The IMEI URN MAY
+   be validated as described in RFC 7254 [1].  If the UA indicates that
+   it supports the extension in RFC 5627 [3] and the SIP registrar
+   allocates a public GRUU according to the procedures specified in
+   RFC 5627 [3], the instance-id MUST be obfuscated when creating the
+   'gr' parameter in order not to reveal the IMEI to other UAs when the
+
+
+
+
+Allen                         Informational                     [Page 6]
+
+RFC 7255            Using IMEI URN as an Instance ID            May 2014
+
+
+   public GRUU is included in non-REGISTER requests and responses.  3GPP
+   TS 24.229 [8] subclause 5.4.7A.2 specifies the mechanism for
+   obfuscating the IMEI when creating the 'gr' parameter.
+
+8.  Security Considerations
+
+   Because IMEIs, like other formats of instance-ids, can be correlated
+   to a user, they are personally identifiable information and therefore
+   MUST be treated in the same way as any other personally identifiable
+   information.  In particular, the "sip.instance" media feature tag
+   containing the GSMA IMEI URN MUST NOT be included in requests or
+   responses intended to convey any level of anonymity, as this could
+   violate the user's privacy.  RFC 5626 [2] states that "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".  The same concerns
+   apply when using the GSMA IMEI URN as an instance-id.  Publication of
+   the GSMA IMEI URN to networks to which the UA is not attached, or
+   with which the UA does not have a service relationship, is a security
+   breach, and 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.  Additionally, an
+   instance-id containing the GSMA IMEI URN identifies a mobile device
+   and not a user.  The instance-id containing the GSMA IMEI 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 [3]
+   provides a means to create URIs that address the user at a specific
+   device or User Agent.
+
+   Entities that log the instance-id need to protect them as personally
+   identifiable information.  Regulatory requirements can require that
+   carriers log SIP IMEIs.
+
+   In order to protect the "sip.instance" media feature tag containing
+   the GSMA IMEI URN from being tampered with, those REGISTER requests
+   containing the GSMA IMEI URN MUST be sent using a security mechanism
+   such as Transport Layer Security (TLS) (RFC 5246 [5]) or another
+   security mechanism that provides equivalent levels of protection such
+   as hop-by-hop security based upon IPsec.
+
+9.  Acknowledgements
+
+   The author would like to thank Paul Kyzivat, Dale Worley, Cullen
+   Jennings, Adam Roach, Keith Drage, Mary Barnes, Peter Leis, James Yu,
+   S. Moonesamy, Roni Even, and Tim Bray for reviewing this document and
+   providing their comments.
+
+
+
+
+
+Allen                         Informational                     [Page 7]
+
+RFC 7255            Using IMEI URN as an Instance ID            May 2014
+
+
+10.  References
+
+10.1.  Normative References
+
+   [1]  Montemurro, M., Ed., 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.
+
+   [2]  Jennings, C., Mahy, R., and F. Audet, "Managing Client-
+        Initiated Connections in the Session Initiation Protocol (SIP)",
+        RFC 5626, October 2009.
+
+   [3]  Rosenberg, J., "Obtaining and Using Globally Routable User Agent
+        URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC
+        5627, October 2009.
+
+   [4]  Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+   [5]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
+        Protocol Version 1.2", RFC 5246, August 2008.
+
+   [6]  Leach, P., Mealling, M., and R. Salz, "A Universally Unique
+        IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
+
+   [7]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [8]  3GPP, "IP multimedia call control protocol based on Session
+        Initiation Protocol (SIP) and Session Description Protocol
+        (SDP); Stage 3", 3GPP TS 24.229 (Release 8), March 2014,
+        <ftp://ftp.3gpp.org/Specs/archive/24_series/ 24.229/>.
+
+   [9]  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.
+
+10.2.  Informative References
+
+   [10] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003
+        (Release 8), March 2014, <ftp://ftp.3gpp.org/Specs/
+        archive/23_series/23.003/>.
+
+   [11] GSM Association, "IMEI Allocation and Approval Guidelines", PRD
+        TS.06 (DG06) Version 6.0, July 2011,
+        <http://www.gsma.com/newsroom/wp-content/uploads/2012/06/
+        ts0660tacallocationprocessapproved.pdf>.
+
+
+
+
+Allen                         Informational                     [Page 8]
+
+RFC 7255            Using IMEI URN as an Instance ID            May 2014
+
+
+   [12] 3GPP, "Mobile radio interface Layer 3 specification; Core
+        network protocols; Stage 3", 3GPP TS 24.237 (Release 8),
+        September 2013, <ftp://ftp.3gpp.org/Specs/archive/
+        24_series/24.237/>.
+
+   [13] 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem
+        Centralized Services (ICS); Stage 3", 3GPP TS 24.292 (Release
+        8), December 2013, <ftp://ftp.3gpp.org/Specs/
+        archive/24_series/24.292/>.
+
+Author's Address
+
+   Andrew Allen (editor)
+   Blackberry
+   1200 Sawgrass Corporate Parkway
+   Sunrise, Florida  33323
+   USA
+
+   EMail: aallen@blackberry.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allen                         Informational                     [Page 9]
+