doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc8465.txt b/doc/rfc/rfc8465.txt
new file mode 100644
index 0000000..aaad3d6
--- /dev/null
+++ b/doc/rfc/rfc8465.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   R. Atarius, Ed.
+Request for Comments: 8465                                September 2018
+Category: Informational
+ISSN: 2070-1721
+
+
+    Using the Mobile Equipment Identity (MEID) URN as an Instance ID
+
+Abstract
+
+   This 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.  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.
+
+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 candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8465.
+
+Copyright Notice
+
+   Copyright (c) 2018 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
+   (https://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.
+
+
+
+Atarius                       Informational                     [Page 1]
+
+RFC 8465               MEID URN as an Instance ID         September 2018
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   4.  3GPP2 Use Cases . . . . . . . . . . . . . . . . . . . . . . .   4
+   5.  User Agent Client Procedures  . . . . . . . . . . . . . . . .   5
+   6.  User Agent Server Procedures  . . . . . . . . . . . . . . . .   5
+   7.  3GPP/3GPP2 SIP Registrar Procedures . . . . . . . . . . . . .   5
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
+     10.1.  Normative References . . . . . . . . . . . . . . . . . .   7
+     10.2.  Informative References . . . . . . . . . . . . . . . . .   8
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8
+
+1.  Introduction
+
+   This 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 RFC 8464 [10] can be used
+   as an Instance ID as specified in RFC 5626 [4] and also as used by
+   RFC 5627 [5].
+
+   RFC 5626 [4] specifies the "+sip.instance" Contact header field
+   parameter that contains a URN as specified in RFC 8141 [6].  The
+   Instance ID uniquely identifies a specific User Agent (UA) instance.
+   This Instance ID is used as specified in RFC 5626 [4] so that the
+   Session Initiation Protocol (SIP) registrar (as specified in RFC 3261
+   [2]) can recognize that the contacts from multiple registrations
+   correspond to the same UA.  The Instance ID is also used as specified
+   by RFC 5627 [5] 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 [4] requires that a UA SHOULD create a Universally Unique
+   Identifier (UUID) URN as specified in RFC 4122 [9] as its Instance ID
+   but allow for the possibility to use other URN schemes.
+
+   RFC 5626 [4] states:
+
+      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.
+
+
+
+
+Atarius                       Informational                     [Page 2]
+
+RFC 8465               MEID URN as an Instance ID         September 2018
+
+
+   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 RFC 8464 [10] specifies how the
+   3GPP2 MEID URN is constructed.
+
+   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 RFC 8464 [10] and the definition of the MEID is
+   contained in 3GPP2 S.R0048-A [13].
+
+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 [1] [7] when, and only when, they appear in all capitals, as
+   shown here.
+
+3.  Background
+
+   Mobile communication has been rapidly improved from low-bit-rate
+   circuit-switched systems to the higher-data-rate packet-switched
+   system.  The packet-switched system has added the mobile capability
+   of Internet Protocol (IP) connectivity; thereby, the IP Multimedia
+   Subsystem (IMS) have made SIP-based calls and IP multimedia sessions
+   from mobile devices possible.
+
+   3GPP2 defines High Rate Packet Data (HRPD) with high data 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, 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 mode mid-call or mid-session.  To achieve this, the mobile
+   device needs to simultaneously communicate via both the IP/SIP/IMS
+   domain and the circuit-switched domain.
+
+   To meet this need, 3GPP2 has specified how to maintain voice-session
+   continuity between the IP/SIP/IMS domain and the circuit-switched
+   domain in 3GPP2 S.X0042-A [14].
+
+   In order for the mobile device to access SIP/IMS voice service via
+   the circuit-switched domain, 3GPP2 has specified that a Mobile
+   Switching Center (MSC) server will control mobile voice call setup
+
+
+
+Atarius                       Informational                     [Page 3]
+
+RFC 8465               MEID URN as an Instance ID         September 2018
+
+
+   over the circuit-switched radio access while establishing the
+   corresponding voice session in the core network using SIP/IMS.  The
+   specified MSC server operates either via an IMS Media Gateway Control
+   Function (MGCF) or directly if it is enhanced by SIP interface.  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, the
+   Instance ID included by the MGCF or the MSC server and the Instance
+   ID directly included by the mobile device both need to be based on
+   the MEID.
+
+   Additionally in order to meet the above requirements, the same MEID
+   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.
+
+4.  3GPP2 Use Cases
+
+   1.  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, the SIP registrar can reject the registration.  Thus, a
+       barred mobile device is prevented from accessing the network for
+       non-emergency services.
+
+   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.
+
+   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 domain to the circuit-switched domain.  In this
+       scenario, the MEID is the only identifier that is common to both
+       domains.  The Emergency Access Transfer Function (EATF), which
+       coordinates the call transfer between the domains, can thus use
+       the MEID to identify that the circuit-switched call is from the
+       same mobile device that was in the emergency session in the
+       packet-switched domain.
+
+
+
+
+
+Atarius                       Informational                     [Page 4]
+
+RFC 8465               MEID URN as an Instance ID         September 2018
+
+
+5.  User Agent Client Procedures
+
+   A single mode 3GPP2 User Agent Client (UAC), which uses only 3GPP2
+   technology to transmit and receive voice or data, has an MEID as
+   specified in 3GPP2 S.R0048-A [13].  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 RFC 8464 [10] when performing the registration
+   procedures specified in RFC 5626 [4] or RFC 5627 [5] (or any other
+   procedure requiring the inclusion of the "sip.instance" media feature
+   tag).
+
+   A UAC MUST NOT use the 3GPP2 MEID URN as an Instance ID except when
+   registering with a 3GPP2 IMS network.  When a UAC is operating in IMS
+   mode, it will obtain the domain of the carrier's IMS network to
+   register with, from the Universal Integrated Circuit Card (UICC),
+   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 carrier's
+   packet data network.  When registering with a non-3GPP or non-3GPP2
+   IMS network, a UAC SHOULD use a UUID as an Instance ID as specified
+   in RFC 5626 [4].
+
+   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.  Regulations can require that the MEID be provided to the
+   PSAP.  Any future exceptions to this prohibition require 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 3GPP2 MEID URN in the Contact header field
+   of responses except when the response is related to an emergency
+   session.  Regulations 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 usage.
+
+7.  3GPP/3GPP2 SIP Registrar Procedures
+
+   In 3GPP/3GPP2 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 RFC 8464 [10], the SIP
+   registrar follows the procedures specified in RFC 5626 [4].  The MEID
+
+
+
+Atarius                       Informational                     [Page 5]
+
+RFC 8465               MEID URN as an Instance ID         September 2018
+
+
+   URN MAY be validated as described in the RFC 8464 [10].  If the UA
+   indicates that it supports the extension in RFC 5627 [5] and the SIP
+   Registrar allocates a GRUU according to the procedures specified in
+   RFC 5627 [5], the 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 [11] subclause 5.4.7A.2 specifies the mechanism for
+   obfuscating the MEID when creating the "gr" parameter.
+
+8.  IANA Considerations
+
+   This document has no IANA actions.
+
+9.  Security Considerations
+
+   Since MEIDs, like other formats of 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 user's privacy.  RFC 5626 [4] 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.
+
+   The same concerns apply when using the 3GPP2 MEID URN as an 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; 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 [3].  Additionally,
+   an Instance ID containing the 3GPP2 MEID URN identifies a mobile
+   device and not a user.  The 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 [5] provides a means to create URIs that address the user
+   at a specific device or UA.
+
+   Entities that log the Instance ID need to protect them as personally
+   identifiable information.  Regulations can require carriers to log
+   SIP MEIDs.
+
+
+
+
+
+Atarius                       Informational                     [Page 6]
+
+RFC 8465               MEID URN as an Instance ID         September 2018
+
+
+   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 8446 [8]
+   or any other security mechanism that provides equivalent levels of
+   protection such as hop-by-hop security based upon IP Security
+   (IPsec).
+
+10.  References
+
+10.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
+        <https://www.rfc-editor.org/info/rfc2119>.
+
+   [2]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+        Peterson, J., Sparks, R., Handley, M., and E.  Schooler, "SIP:
+        Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261,
+        June 2002, <https://www.rfc-editor.org/info/rfc3261>.
+
+   [3]  Rosenberg, J., "A Session Initiation Protocol (SIP) Event
+        Package for Registrations", RFC 3680, DOI 10.17487/RFC3680,
+        March 2004, <https://www.rfc-editor.org/info/rfc3680>.
+
+   [4]  Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing
+        Client-Initiated Connections in the Session Initiation Protocol
+        (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009,
+        <https://www.rfc-editor.org/info/rfc5626>.
+
+   [5]  Rosenberg, J., "Obtaining and Using Globally Routable User Agent
+        URIs (GRUUs) in the Session Initiation Protocol (SIP)",
+        RFC 5627, DOI 10.17487/RFC5627, October 2009,
+        <https://www.rfc-editor.org/info/rfc5627>.
+
+   [6]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)",
+        RFC 8141, DOI 10.17487/RFC8141, April 2017,
+        <https://www.rfc-editor.org/info/rfc8141>.
+
+   [7]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
+        Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
+        <https://www.rfc-editor.org/info/rfc8174>.
+
+   [8]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+        Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+        <https://www.rfc-editor.org/info/rfc8446>.
+
+
+
+
+
+Atarius                       Informational                     [Page 7]
+
+RFC 8465               MEID URN as an Instance ID         September 2018
+
+
+   [9]  Leach, P., Mealling, M., and R. Salz, "A Universally Unique
+        IDentifier (UUID) URN Namespace", RFC 4122,
+        DOI 10.17487/RFC4122, July 2005,
+        <https://www.rfc-editor.org/info/rfc4122>.
+
+   [10] Atarius, R., "A URN Namespace for Device Identity and Mobile
+        Equipment Identity (MEID)", RFC 8464, DOI 10.17487/RFC8464,
+        September 2018, <https://www.rfc-editor.org/info/rfc8464>.
+
+   [11] 3GPP, "IP multimedia call control protocol based on Session
+        Initiation Protocol (SIP) and Session Description Protocol
+        (SDP); Stage 3", 3GPP 24.229, Version 10.13.0, Release 10,
+        September 2013,
+        <ftp://ftp.3gpp.org/Specs/archive/24_series/24.229/>.
+
+10.2.  Informative References
+
+   [12] Allen, A., Ed., "Using the International Mobile station
+        Equipment Identity (IMEI) Uniform Resource Name (URN) as an
+        Instance ID", RFC 7255, DOI 10.17487/RFC7255, May 2014,
+        <https://www.rfc-editor.org/info/rfc7255>.
+
+   [13] 3GPP2, "3G Mobile Equipment Identifier (MEID) - Stage 1, Version
+        4.0", Stage 1, Version 4.0, 3GPP2 S.R0048-A, June 2005.
+
+   [14] 3GPP2, "Voice Call Continuity between IMS and Circuit Switched
+        Systems - Version 1.0", Version 1.0, 3GPP2 S.X0042-A 1.0, August
+        2008, <https://www.3gpp2.org/Public_html/Specs/
+        X.S0042-A_v1.0_080904.pdf>.
+
+Acknowledgments
+
+   This document draws heavily on RFC 8464 [10] and also on the style
+   and structure used in RFC 7255 [12].
+
+   The author thanks Andrew Allen for the detailed comments.
+
+Author's Address
+
+   Roozbeh Atarius (editor)
+
+   Email: ratarius@motorola.com
+
+
+
+
+
+
+
+
+
+Atarius                       Informational                     [Page 8]
+