Movatterモバイル変換

Internet Engineering Task Force (IETF)                       C. HolmbergRequest for Comments: 7976                                    N. BiondicUpdates:7315                                                   EricssonCategory: Informational                                     G. SalgueiroISSN: 2070-1721                                                    Cisco                                                          September 2016Updates to Private Header (P-Header) Extension Usagein Session Initiation Protocol (SIP) Requests and ResponsesAbstract   The Third Generation Partnership Project (3GPP) has identified cases   where different SIP private header extensions referred to as "P-"   header fields, and defined inRFC 7315, need to be included in SIP   requests and responses currently not allowed according toRFC 7315.   This document updatesRFC 7315, in order to allow inclusion of the   affected "P-" header fields in such requests and responses.   This document also makes updates forRFC 7315 in order to fix   misalignments that occurred whenRFC 3455 was updated and obsoleted   byRFC 7315.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; seeSection 2 of RFC 7841.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7976.Holmberg, et al.              Informational                     [Page 1]

RFC 7976                Updates to P-Header Usage         September 2016Copyright Notice   Copyright (c) 2016 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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 Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .22.  Misalignments and 3GPP Use Cases  . . . . . . . . . . . . . .32.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .32.2.  Misalignments . . . . . . . . . . . . . . . . . . . . . .32.3.  3GPP Use Cases  . . . . . . . . . . . . . . . . . . . . .42.3.1.  General . . . . . . . . . . . . . . . . . . . . . . .42.3.2.  P-Access-Network-Info . . . . . . . . . . . . . . . .42.3.3.  P-Charging-Vector . . . . . . . . . . . . . . . . . .53.  Updates toRFC 7315 . . . . . . . . . . . . . . . . . . . . .64.  Security Considerations . . . . . . . . . . . . . . . . . . .75.  References  . . . . . . . . . . . . . . . . . . . . . . . . .75.1.  Normative References  . . . . . . . . . . . . . . . . . .75.2.  Informative References  . . . . . . . . . . . . . . . . .8   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .8   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .81.  Introduction   The Third Generation Partnership Project (3GPP) has identified cases   where different Session Initiation Protocol (SIP) [RFC3261] private   header extensions referred to as "P-" header fields, and defined in   [RFC7315], need to be included in SIP requests and responses   currently not allowed according toRFC 7315.  This document updatesRFC 7315, in order to allow inclusion of the affected "P-" header   fields in such requests and responses.   This document also makes updates forRFC 7315 in order to fix   misalignments that occurred whenRFC 3455 [RFC3455] was updated and   obsoleted byRFC 7315.Holmberg, et al.              Informational                     [Page 2]

RFC 7976                Updates to P-Header Usage         September 2016   As the "P-" header fields are mainly used in (and in most cases, only   defined for) networks defined by the 3GPP, where the updates defined   in this document are already defined [TS.3GPP.24.229], the updates   are not seen to cause backward-compatibility concerns.2.  Misalignments and 3GPP Use Cases2.1.  GeneralRFC 7315 contains contradicting statements regarding the usage of SIP   "P-" header fields in SIP requests and responses, which leave the   presence of the SIP "P-" header fields in the SIP requests and   responses open to interpretation and different implementations.   Statements inSection 5.7 of that RFC are not aligned with the   definitions and usage of the SIP "P-" header fields specified inSection 4.  This section describes the misalignments that occurred   whenRFC 3455 was updated and obsoleted byRFC 7315, and how they are   fixed.   NOTE: In the case of the P-Called-Party-ID header field, allowing it   in PUBLISH requests was deliberately done inRFC 7315.  Therefore, it   is not considered a misalignment.   SinceRFC 7315 was published, 3GPP defined new use cases that require   the RFC to be updated.  This section describes the 3GPP use cases   behind the updates, and the updates needed toRFC 7315 in order to   support the use cases.Section 3 updatesRFC 7315, based on the misalignments and 3GPP use   cases.2.2.  Misalignments   The following updates are needed in order to fix the misalignments   between RFCs 7315 and 3455:   o  P-Associated-URI: Remove the statement that the header field can      appear in the SIP REGISTER method.   o  P-Called-Party-ID: Delete the statement that the P-Called-Party-ID      header field can appear in SIP responses.  Add a statement that      the P-Called-Party-ID header field can appear in the SIP REFER      method.   o  P-Visited-Network-ID: Delete the statement that the P-Visited-      Network-ID header field can appear in SIP responses.  Add a      statement that the P-Visited-Network-ID header field cannot appear      in the SIP NOTIFY, PRACK, INFO, and UPDATE methods.Holmberg, et al.              Informational                     [Page 3]

RFC 7976                Updates to P-Header Usage         September 2016   o  P-Access-Network-Info: Add a statement that the P-Access-Network-      Info header field can appear in SIP responses.   o  P-Charging-Vector: Add a statement that the P-Charging-Vector      header field can appear in SIP responses.  Add a statement that      the P-Charging-Vector header field cannot appear in the SIP ACK      method.   o  P-Charging-Function-Addresses: Add a statement that the      P-Charging-Function-Addresses header field can appear in SIP      responses.2.3.  3GPP Use Cases2.3.1.  General   The following updates are needed in order to implement the 3GPP use   cases:   o  P-Access-Network-Info: Add statement that the P-Access-Network-      Info header field can appear in the SIP ACK method when triggered      by a SIP 2xx response.   o  P-Charging-Vector: Add statement that the P-Charging-Vector header      field can appear in the SIP ACK method when triggered by a SIP 2xx      response.   This following sections describe, for individual "P-" header fields,   the 3GPP use cases that are the basis for the updates.  The use cases   are based on the procedures defined in [TS.3GPP.24.229].2.3.2.  P-Access-Network-Info   The P-Access-Network-Info header field may contain the Network   Provided Location Information (NPLI).  The NPLI is described in   [TS.3GPP.23.228].   A proxy in possession of appropriate information about the access   technology might insert a P-Access-Network-Info header field with its   own values.  Such values are identified by the string "network-   provided" defined inRFC 7315.  Based on operator policy and/or   roaming agreement, the local time of the visited network may be   included.   The Call Data Records (CDRs) generated within the IP Multimedia   Subsystem (IMS) have to contain the NPLI in order to guarantee   correct billing.  When an IMS session is modified, the NPLI also   needs to be stored as the location of the user at the time when theHolmberg, et al.              Informational                     [Page 4]

RFC 7976                Updates to P-Header Usage         September 2016   session is modified may generate a charging event.  In case of a   session modification event at IMS, the NPLI needs to be provided:   o  when the bearer establishment is triggered, or   o  at session release when the bearer deactivation is triggered, or   o  when the bearer modification is triggered, e.g., a QoS      modification for the use of a newly negotiated codec.   In some scenarios, the bearer modification may be triggered by the   proxy upon reception of a Session Description Protocol (SDP) answer   within SIP 2xx response to the SIP INVITE request.  In such case, the   NPLI needs to be provided within the SIP ACK request.  However,RFC7315 does not allow the usage of the P-Access-Network-Info header   field in SIP ACK request.   Upon reception of the SDP answer within SIP 2xx response on the SIP   INVITE request, a proxy may initiate procedures to obtain the NPLI   and may include the P-Access-Network-Info header field with the NPLI   in the SIP ACK request.   The P-Access-Network-Info header field shall not be included in SIP   ACK requests triggered by non-2xx responses.2.3.3.  P-Charging-VectorRFC 7315 defines an Inter Operator Identifier (IOI) to enable   different operators involved in a SIP dialog or a transaction outside   a dialog to identify each other by exchanging operator identification   information within the P-Charging-Vector header field.   In the interconnection scenarios in multi-operator environments,   where one or more transit operators are between the originating and   terminating operator, the identities of the involved transit   operators are represented by a transit-ioi parameter of the   P-Charging-Vector header field.   Transit operators can be selected independently for each SIP method   and direction of request.  A transit network will only have knowledge   of an individual SIP request, and transit network selection will be   an independent decision for each request and could be made based on   load, cost, percentage, time of day, and other factors.  For this   reason, it is necessary that the P-Charging-Vector header field,   which carries the transit IOI information, is included in each SIP   request and response.  However,RFC 7315 does not allow the usage of   the P-Charging-Vector header field in the SIP ACK request.Holmberg, et al.              Informational                     [Page 5]

RFC 7976                Updates to P-Header Usage         September 2016   A SIP proxy that supports this extension and receives the SIP ACK   request may include a P-Charging-Vector header field in the SIP ACK   request.   The P-Charging-Vector header field shall not be included in SIP ACK   requests triggered by SIP non-2xx responses.3.  Updates toRFC 7315   This section implements the update toSection 5.7 of RFC 7315, in   order to implement the misalignment fixes and the 3GPP requirements   described inSection 2.   Old text:   The P-Associated-URI header field can appear in SIP REGISTER method   and 2xx resonses [sic].  The P-Called-Party-ID header field can   appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE   methods and all responses.  The P-Visited-Network-ID header field can   appear in all SIP methods except ACK, BYE, and CANCEL and all   responses.  The P-Access-Network-Info header field can appear in all   SIP methods except ACK and CANCEL.  The P-Charging-Vector header   field can appear in all SIP methods except CANCEL.  The   P-Charging-Function-Addresses header field can appear in all SIP   methods except ACK and CANCEL.   New text:   The P-Associated-URI header field can appear in SIP REGISTER 2xx   responses.  The P-Called-Party-ID header field can appear in the SIP   INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods.  The   P-Visited-Network-ID header field can appear in all SIP methods   except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO, and UPDATE.  The   P-Access-Network-Info header field can appear in all SIP methods and   non-100 responses, except in CANCEL methods, CANCEL responses, and   ACK methods triggered by non-2xx responses.  The P-Charging-Vector   header field can appear in all SIP methods and non-100 responses,   except in CANCEL methods, CANCEL responses, and ACK methods triggered   by non-2xx responses.  The P-Charging-Function-Addresses header field   can appear in all SIP methods and non-100 responses, except in CANCEL   methods, CANCEL responses, and ACK methods.Holmberg, et al.              Informational                     [Page 6]

RFC 7976                Updates to P-Header Usage         September 20164.  Security Considerations   The security considerations for these "P-" header fields are defined   in [RFC7315].  This specification allows some header fields to be   present in messages where they were previously not allowed, and the   security considerations and assumptions described in [RFC7315] (e.g.,   regarding only sending information to trusted entities) also apply to   those messages.  In addition, this specification also disallows some   header fields to be present in messages where they were previously   allowed.  That does not cause any security issues, but implementors   need to be aware that implementations may not have been updated   according to this document, and take proper actions if a header field   occurs, or does not occur, in a message where it should occur (or   occurs in a message where it should not occur).  This document adds   the ability to include P-Access-Network-Info in ACK requests.  As   documented in [RFC7315], P-Access-Network-Info may include privacy   sensitive information, including the user's location.  The security   and privacy considerations for P-Access-Network-Info in ACK requests   are similar to those for the other SIP requests discussed in   [RFC7315].5.  References5.1.  Normative References   [RFC3261]  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,              <http://www.rfc-editor.org/info/rfc3261>.   [RFC7315]  Jesske, R., Drage, K., and C. Holmberg, "Private Header              (P-Header) Extensions to the Session Initiation Protocol              (SIP) for the 3GPP",RFC 7315, DOI 10.17487/RFC7315, July              2014, <http://www.rfc-editor.org/info/rfc7315>.   [TS.3GPP.23.228]              3GPP, "IP multimedia call control protocol based on              Session Initiation Protocol (SIP) and Session Description              Protocol (SDP); Stage 3", 3GPP TS 23.228 13.6.0, June              2016, <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.   [TS.3GPP.24.229]              3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP              TS 24.229 13.6.0, June 2016,              <http://www.3gpp.org/ftp/Specs/html-info/24229.htm>.Holmberg, et al.              Informational                     [Page 7]

RFC 7976                Updates to P-Header Usage         September 20165.2.  Informative References   [RFC3455]  Garcia-Martin, M., Henrikson, E., and D. Mills, "Private              Header (P-Header) Extensions to the Session Initiation              Protocol (SIP) for the 3rd-Generation Partnership Project              (3GPP)",RFC 3455, DOI 10.17487/RFC3455, January 2003,              <http://www.rfc-editor.org/info/rfc3455>.Acknowledgments   Thanks to Paul Kyzivat, Jean Mahoney, Ben Campbell, and Adam Roach   for providing comments on the document.Authors' Addresses   Christer Holmberg   Ericsson   Hirsalantie 11   Jorvas  02420   Finland   Email: christer.holmberg@ericsson.com   Nevenka Biondic   Ericsson   Krapinska 45   Zagreb  10002   Croatia   Email: nevenka.biondic@ericsson.com   Gonzalo Salgueiro   Cisco Systems, Inc.   7200-12 Kit Creek Road   Research Triangle Park, NC  27709   United States of America   Email: gsalguei@cisco.comHolmberg, et al.              Informational                     [Page 8]