Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests/Responses

The 3rd-Generation Partnership Project (3GPP) has identified cases where different Session Initiation Protocol (SIP) private header extensions referred to as P- header fields, 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. As the P- header fields are mainly used in (and in most cases, only defined for) networks defined by the 3rd-Generation Partnership Project (3GPP), where the updates defined in this document are already defined , the updates are not seen to cause backward compatibility concerns.

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 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 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. It will therefore not be 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. updates RFC 7315, based on the misalignments and 3GPP use-cases.

The following updates are needed in order to fix the misalignments between RFC 7315 and RFC 3455: P-Associated-URI: Remove statement that the header field can appear in the SIP REGISTER method. P-Called-Party-ID: Delete statement that the header field can appear in SIP responses. Add statement that the P-Called-Party-ID header field can appear in the SIP REFER method. P-Visited-Network-ID: Delete statement that the header field can appear in SIP responses. Add statement that the P-Visited-Network-ID header field cannot appear in the SIP NOTIFY, PRACK, INFO and UPDATE methods. P-Access-Network-Info: Add statement that header field can appear in SIP responses. P-Charging-Vector: Add statement that the header field can appear in SIP responses. Add statement that the header field can not appear in the SIP ACK method. P-Charging-Function-Addresses: Add statement that the P-Charging-Function-Addresses header field can appear in SIP responses.

The following updates are needed in order to implement the 3GPP use-cases: P-Access-Network-Info: Add statement that the header field can appear in the SIP ACK method when triggered by a SIP 2xx response. P-Charging-Vector: Add statement that the 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 base for the updates.

The P-Access-Network-Info header field may contain the Network provided Location information (NPLI). The Network Provided Location Information (NPLI) is described in 3GPP TS 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, local time of visited network may be included. The CDRs generated within 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 session is modified may generate a charging event. In case of a session modification event at IMS, the NPLI needs to be provided: when the bearer establishment is triggered, or at session release when the bearer deactivation is triggered, or when the bearer modification is triggered e.g. QoS modification for the use of newly negotiated codec. In some scenarios, the bearer modification may be triggered by the proxy upon reception of an 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.

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 more. 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 SIP ACK request. 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.

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 .

The security considerations for these P- header fields are defined in . This specification allows some header fields to be present in messages where they were previously not allowed, and the security considerations and assumptions (e.g. regarding only sending information to trusted entities) also to those messages. In addition, this specification also disallow some header fields to be present in message where they were previously allowed. That does not cause any security issues, but implementations need to be aware that implementations may not have been updated according to this document, and take proper actions if a header field occur, 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 , 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 .

This document makes no requests from IANA.

Thanks to Paul Kyzivat, Jean Mahoney, Ben Campbell and Adam Roach for providing comments on the draft.

[RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-holmberg-dispatch-rfc7315-updates-06 Changes based on AD comments from Ben Campbell. - Additional text added to Security Considerations. Changes from draft-holmberg-dispatch-rfc7315-updates-05 Editorial changes based on comments from Adam Roach. Changes from draft-holmberg-dispatch-rfc7315-updates-04 - Errata removed. All changes defined as RFC 7315 updates. - Title changed. - Text added to the Security Considerations. Changes from draft-holmberg-dispatch-rfc7315-updates-03 - Minor editorial corrections. Changes from draft-holmberg-dispatch-rfc7315-updates-02 - Justification text for P-Charging-Vector update added. Changes from draft-holmberg-dispatch-rfc7315-updates-01 - Justification text for P-Access-Network-Info update added. Changes from draft-holmberg-dispatch-rfc7315-updates-00 - Title corrected.