diff options
Diffstat (limited to 'doc/rfc/rfc7976.txt')
| -rw-r--r-- | doc/rfc/rfc7976.txt | 451 |
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc7976.txt b/doc/rfc/rfc7976.txt new file mode 100644 index 0000000..ef06c5d --- /dev/null +++ b/doc/rfc/rfc7976.txt @@ -0,0 +1,451 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Holmberg +Request for Comments: 7976 N. Biondic +Updates: 7315 Ericsson +Category: Informational G. Salgueiro +ISSN: 2070-1721 Cisco + September 2016 + + + Updates to Private Header (P-Header) Extension Usage + in Session Initiation Protocol (SIP) Requests and Responses + +Abstract + + The Third Generation Partnership Project (3GPP) has identified cases + where different SIP private header extensions referred to as "P-" + header fields, and defined in RFC 7315, need to be included in SIP + requests and responses currently not allowed according to RFC 7315. + This document updates RFC 7315, in order to allow inclusion of the + affected "P-" header fields in such requests and responses. + + This document also makes updates for RFC 7315 in order to fix + misalignments that occurred when RFC 3455 was updated and obsoleted + by RFC 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; 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 + http://www.rfc-editor.org/info/rfc7976. + + + + + + + + + + + + +Holmberg, et al. Informational [Page 1] + +RFC 7976 Updates to P-Header Usage September 2016 + + +Copyright Notice + + Copyright (c) 2016 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. Misalignments and 3GPP Use Cases . . . . . . . . . . . . . . 3 + 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Misalignments . . . . . . . . . . . . . . . . . . . . . . 3 + 2.3. 3GPP Use Cases . . . . . . . . . . . . . . . . . . . . . 4 + 2.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.3.2. P-Access-Network-Info . . . . . . . . . . . . . . . . 4 + 2.3.3. P-Charging-Vector . . . . . . . . . . . . . . . . . . 5 + 3. Updates to RFC 7315 . . . . . . . . . . . . . . . . . . . . . 6 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 + 5.2. Informative References . . . . . . . . . . . . . . . . . 8 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 + +1. 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 to RFC 7315. This document updates + RFC 7315, in order to allow inclusion of the affected "P-" header + fields in such requests and responses. + + This document also makes updates for RFC 7315 in order to fix + misalignments that occurred when RFC 3455 [RFC3455] was updated and + obsoleted by RFC 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 Cases + +2.1. General + + RFC 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 in Section 5.7 of that RFC are not aligned with the + definitions and usage of the SIP "P-" header fields specified in + Section 4. This section describes the misalignments that occurred + when RFC 3455 was updated and obsoleted by RFC 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 in RFC 7315. Therefore, it + is not considered a misalignment. + + Since RFC 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 to RFC 7315 in order to + support the use cases. + + Section 3 updates RFC 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 Cases + +2.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 in RFC 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 the + + + +Holmberg, 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, RFC + 7315 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-Vector + + RFC 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 to RFC 7315 + + This section implements the update to Section 5.7 of RFC 7315, in + order to implement the misalignment fixes and the 3GPP requirements + described in Section 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 2016 + + +4. 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. References + +5.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 2016 + + +5.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.com + + + + + + + + + + + +Holmberg, et al. Informational [Page 8] + |