Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses
draft-holmberg-dispatch-rfc7315-updates-09
The information below is for an old version of the document that is already published as an RFC.
| Document | Type | RFC Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Christer Holmberg , Nevenka Biondic , Gonzalo Salgueiro | ||
| Last updated | 2018-12-20 (Latest revision 2016-08-16) | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| Reviews |
SECDIR Last Call review
(of
-07)
Has Nits
GENART Last Call review
(of
-07)
Ready with Nits
|
||
| Stream | WG state | (None) | |
| Document shepherd | Jean Mahoney | ||
| Shepherd write-up | Show Last changed 2016-05-18 | ||
| IESG | IESG state | RFC 7976 (Informational) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Ben Campbell | ||
| Send notices to | (None) | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA action state | No IANA Actions |
draft-holmberg-dispatch-rfc7315-updates-09
Network Working Group C. Holmberg
Internet-Draft N. Biondic
Updates: 7315 (if approved) Ericsson
Intended status: Informational G. Salgueiro
Expires: February 17, 2017 Cisco
August 16, 2016
Updates to Private Header (P-Header) Extension Usage in Session
Initiation Protocol (SIP) Requests/Responses
draft-holmberg-dispatch-rfc7315-updates-09
Abstract
The 3rd-Generation Partnership Project 3GPP has identified cases
where different 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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 17, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Holmberg, et al. Expires February 17, 2017 [Page 1]
Internet-Draft 7315 Updates August 2016
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 . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The 3rd-Generation Partnership Project (3GPP) has identified cases
where different Session Initiation Protocol (SIP) [RFC3261] private
header extensions referred to as P- header fields, defined in RFC
7315 [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.
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
Holmberg, et al. Expires February 17, 2017 [Page 2]
Internet-Draft 7315 Updates August 2016
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 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.
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 RFC 7315 and RFC 3455:
o P-Associated-URI: Remove statement that the header field can
appear in the SIP REGISTER method.
o P-Called-Party-ID: Delete statement that the P-Called-Party-ID
header field can appear in SIP responses. Add statement that the
P-Called-Party-ID header field can appear in the SIP REFER method.
o P-Visited-Network-ID: Delete statement that the P-Visited-Network-
ID 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.
o P-Access-Network-Info: Add statement that P-Access-Network-Info
header field can appear in SIP responses.
Holmberg, et al. Expires February 17, 2017 [Page 3]
Internet-Draft 7315 Updates August 2016
o P-Charging-Vector: Add statement that the P-Charging-Vector header
field can appear in SIP responses. Add statement that the P-
Charging-Vector header field can not appear in the SIP ACK method.
o P-Charging-Function-Addresses: Add 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 Network Provided Location
Information (NPLI) is described in 3GPP TS 23.228 [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, 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:
o when the bearer establishment is triggered, or
o at session release when the bearer deactivation is triggered, or
Holmberg, et al. Expires February 17, 2017 [Page 4]
Internet-Draft 7315 Updates August 2016
o 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.
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 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.
Holmberg, et al. Expires February 17, 2017 [Page 5]
Internet-Draft 7315 Updates August 2016
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. 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
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 ACK
and CANCEL methods and CANCEL responses.
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
implementations need to be aware that implementations may not have
Holmberg, et al. Expires February 17, 2017 [Page 6]
Internet-Draft 7315 Updates August 2016
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. IANA Considerations
This document makes no requests from IANA.
6. Acknowledgments
Thanks to Paul Kyzivat, Jean Mahoney, Ben Campbell and Adam Roach for
providing comments on the draft.
7. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-holmberg-dispatch-rfc7315-updates-08
o Editorial changes based on IESG review of Mirja Kuhlewind.
Changes from draft-holmberg-dispatch-rfc7315-updates-07
o Editorial changes in the Security Considerations based on secdir
comments from Steve Hanna.
o Editorial changes based on genart comments from Ralph Droms.
o Reference to 3GPP TS 23.228 based on genart comments from Ralph
Droms.
Changes from draft-holmberg-dispatch-rfc7315-updates-06
o Changes based on AD comments from Ben Campbell.
o - Additional text added to Security Considerations.
Changes from draft-holmberg-dispatch-rfc7315-updates-05
o Editorial changes based on comments from Adam Roach.
Changes from draft-holmberg-dispatch-rfc7315-updates-04
Holmberg, et al. Expires February 17, 2017 [Page 7]
Internet-Draft 7315 Updates August 2016
o - Errata removed. All changes defined as RFC 7315 updates.
o - Title changed.
o - Text added to the Security Considerations.
Changes from draft-holmberg-dispatch-rfc7315-updates-03
o - Minor editorial corrections.
Changes from draft-holmberg-dispatch-rfc7315-updates-02
o - Justification text for P-Charging-Vector update added.
Changes from draft-holmberg-dispatch-rfc7315-updates-01
o - Justification text for P-Access-Network-Info update added.
Changes from draft-holmberg-dispatch-rfc7315-updates-00
o - Title corrected.
8. References
8.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.
[TS.3GPP.24.229]
3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP
TS 24.229 13.6.0, June 2016.
Holmberg, et al. Expires February 17, 2017 [Page 8]
Internet-Draft 7315 Updates August 2016
8.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>.
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
US
Email: gsalguei@cisco.com
Holmberg, et al. Expires February 17, 2017 [Page 9]