idnits 2.17.1 draft-holmberg-dispatch-rfc7315-updates-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC7315, updated by this document, for RFC5378 checks: 2005-10-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 16, 2016) is 2810 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3455 (Obsoleted by RFC 7315) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Holmberg 3 Internet-Draft N. Biondic 4 Updates: 7315 (if approved) Ericsson 5 Intended status: Informational G. Salgueiro 6 Expires: February 17, 2017 Cisco 7 August 16, 2016 9 Updates to Private Header (P-Header) Extension Usage in Session 10 Initiation Protocol (SIP) Requests/Responses 11 draft-holmberg-dispatch-rfc7315-updates-09 13 Abstract 15 The 3rd-Generation Partnership Project 3GPP has identified cases 16 where different SIP private header extensions referred to as P- 17 header fields, defined in RFC 7315, need to be included in SIP 18 requests and responses currently not allowed according to RFC 7315. 19 This document updates RFC 7315, in order to allow inclusion of the 20 affected P- header fields in such requests and responses. 22 This document also makes updates for RFC 7315 in order to fix 23 misalignments that occurred when RFC 3455 was updated and obsoleted 24 by RFC 7315. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 17, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Misalignments and 3GPP use-cases . . . . . . . . . . . . . . 3 62 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Misalignments . . . . . . . . . . . . . . . . . . . . . . 3 64 2.3. 3GPP Use-cases . . . . . . . . . . . . . . . . . . . . . 4 65 2.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.3.2. P-Access-Network-Info . . . . . . . . . . . . . . . . 4 67 2.3.3. P-Charging-Vector . . . . . . . . . . . . . . . . . . 5 68 3. Updates to RFC 7315 . . . . . . . . . . . . . . . . . . . . . 6 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 72 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 8.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 The 3rd-Generation Partnership Project (3GPP) has identified cases 81 where different Session Initiation Protocol (SIP) [RFC3261] private 82 header extensions referred to as P- header fields, defined in RFC 83 7315 [RFC7315], need to be included in SIP requests and responses 84 currently not allowed according to RFC 7315. This document updates 85 RFC 7315, in order to allow inclusion of the affected P- header 86 fields in such requests and responses. 88 This document also makes updates for RFC 7315 in order to fix 89 misalignments that occurred when RFC 3455 [RFC3455] was updated and 90 obsoleted by RFC 7315. 92 As the P- header fields are mainly used in (and in most cases, only 93 defined for) networks defined by the 3rd-Generation Partnership 94 Project (3GPP), where the updates defined in this document are 95 already defined [TS.3GPP.24.229], the updates are not seen to cause 96 backward compatibility concerns. 98 2. Misalignments and 3GPP use-cases 100 2.1. General 102 RFC 7315 contains contradicting statements regarding the usage of SIP 103 P- header fields in SIP requests and responses, which leave the 104 presence of the SIP P- header fields in the SIP requests and 105 responses open to interpretation, and different implementations. 106 Statements in section 5.7 are not aligned with the definitions and 107 usage of the SIP P- header fields specified in section 4. This 108 section describes the misalignments that occurred when RFC 3455 was 109 updated and obsoleted by RFC 7315, and how they are fixed. 111 NOTE: In the case of the P-Called-Party-ID header field, allowing it 112 in PUBLISH requests was deliberately done in RFC 7315. It will 113 therefore not be considered a misalignment. 115 Since RFC 7315 was published, 3GPP defined new use-cases that require 116 the RFC to be updated. This section describes the 3GPP use-cases 117 behind the updates, and the updates needed to RFC 7315 in order to 118 support the use-cases. 120 Section 3 updates RFC 7315, based on the misalignments and 3GPP use- 121 cases. 123 2.2. Misalignments 125 The following updates are needed in order to fix the misalignments 126 between RFC 7315 and RFC 3455: 128 o P-Associated-URI: Remove statement that the header field can 129 appear in the SIP REGISTER method. 131 o P-Called-Party-ID: Delete statement that the P-Called-Party-ID 132 header field can appear in SIP responses. Add statement that the 133 P-Called-Party-ID header field can appear in the SIP REFER method. 135 o P-Visited-Network-ID: Delete statement that the P-Visited-Network- 136 ID header field can appear in SIP responses. Add statement that 137 the P-Visited-Network-ID header field cannot appear in the SIP 138 NOTIFY, PRACK, INFO and UPDATE methods. 140 o P-Access-Network-Info: Add statement that P-Access-Network-Info 141 header field can appear in SIP responses. 143 o P-Charging-Vector: Add statement that the P-Charging-Vector header 144 field can appear in SIP responses. Add statement that the P- 145 Charging-Vector header field can not appear in the SIP ACK method. 147 o P-Charging-Function-Addresses: Add statement that the P-Charging- 148 Function-Addresses header field can appear in SIP responses. 150 2.3. 3GPP Use-cases 152 2.3.1. General 154 The following updates are needed in order to implement the 3GPP use- 155 cases: 157 o P-Access-Network-Info: Add statement that the P-Access-Network- 158 Info header field can appear in the SIP ACK method when triggered 159 by a SIP 2xx response. 161 o P-Charging-Vector: Add statement that the P-Charging-Vector header 162 field can appear in the SIP ACK method when triggered by a SIP 2xx 163 response. 165 This following sections describe, for individual P- header fields, 166 the 3GPP use-cases that are the basis for the updates. The use-cases 167 are based on the procedures defined in [TS.3GPP.24.229]. 169 2.3.2. P-Access-Network-Info 171 The P-Access-Network-Info header field may contain the Network 172 Provided Location Information (NPLI). The Network Provided Location 173 Information (NPLI) is described in 3GPP TS 23.228 [TS.3GPP.23.228]. 175 A proxy in possession of appropriate information about the access 176 technology might insert a P-Access-Network-Info header field with its 177 own values. Such values are identified by the string "network- 178 provided" defined in RFC 7315. Based on operator policy and/or 179 roaming agreement, local time of visited network may be included. 181 The CDRs generated within IMS have to contain the NPLI in order to 182 guarantee correct billing. When an IMS Session is modified the NPLI 183 also needs to be stored as the location of the user at the time when 184 the session is modified may generate a charging event. In case of a 185 session modification event at IMS, the NPLI needs to be provided: 187 o when the bearer establishment is triggered, or 189 o at session release when the bearer deactivation is triggered, or 190 o when the bearer modification is triggered e.g. QoS modification 191 for the use of newly negotiated codec. 193 In some scenarios, the bearer modification may be triggered by the 194 proxy upon reception of an SDP answer within SIP 2xx response to the 195 SIP INVITE request. In such case the NPLI needs to be provided 196 within the SIP ACK request. However, RFC 7315 does not allow the 197 usage of the P-Access-Network-Info header field in SIP ACK request. 199 Upon reception of the SDP answer within SIP 2xx response on the SIP 200 INVITE request a proxy may initiate procedures to obtain the NPLI and 201 may include the P-Access-Network-Info header field with the NPLI in 202 the SIP ACK request. 204 The P-Access-Network-Info header field shall not be included in SIP 205 ACK requests triggered by non-2xx responses. 207 2.3.3. P-Charging-Vector 209 RFC 7315 defines an Inter Operator Identifier (IOI) to enable 210 different operators involved in a SIP dialog or a transaction outside 211 a dialog to identify each other by exchanging operator identification 212 information within the P-Charging-Vector header field. 214 In the interconnection scenarios in multi operator environments, 215 where one or more transit operators are between the originating and 216 terminating operator, the identities of the involved transit 217 operators are represented by a transit-ioi parameter of the P- 218 Charging-Vector header field. 220 Transit operators can be selected independently for each SIP method 221 and direction of request. A transit network will only have knowledge 222 of an individual SIP request and transit network selection will be an 223 independent decision for each request and could be made based on 224 load, cost, percentage, time of day, and more. For this reason, it 225 is necessary that the P-Charging-Vector header field, which carries 226 the transit IOI information, is included in each SIP request and 227 response. However, RFC 7315 does not allow the usage of the 228 P-Charging- Vector header field in SIP ACK request. 230 A SIP proxy that supports this extension and receives the SIP ACK 231 request may include a P-Charging-Vector header field in the SIP ACK 232 request. 234 The P-Charging-Vector header field shall not be included in SIP ACK 235 requests triggered by SIP non-2xx responses. 237 3. Updates to RFC 7315 239 This section implements the update to section 5.7 of RFC 7315, in 240 order to implement the misalignment fixes and the 3GPP requirements 241 described in Section 2. 243 Old text: 245 The P-Associated-URI header field can appear in SIP REGISTER method 246 and 2xx resonses. The P-Called-Party-ID header field can appear in 247 SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all 248 responses. The P-Visited-Network-ID header field can appear in all 249 SIP methods except ACK, BYE, and CANCEL and all responses. The 250 P-Access-Network-Info header field can appear in all SIP methods 251 except ACK and CANCEL. The P-Charging-Vector header field can appear 252 in all SIP methods except CANCEL. The P-Charging-Function-Addresses 253 header field can appear in all SIP methods except ACK and CANCEL. 255 New text: 257 The P-Associated-URI header field can appear in SIP REGISTER 258 2xx responses. The P-Called-Party-ID header field can appear in 259 SIP INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods. 260 The P-Visited-Network-ID header field can appear in all SIP methods 261 except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO and UPDATE. The 262 P-Access-Network-Info header field can appear in all SIP methods 263 and non-100 responses, except in CANCEL methods, CANCEL responses 264 and ACK methods triggered by non-2xx responses. The P-Charging-Vector 265 header field can appear in all SIP methods and non-100 responses, 266 except in CANCEL methods, CANCEL responses and ACK methods triggered 267 by non-2xx responses. The P-Charging-Function-Addresses header field 268 can appear in all SIP methods and non-100 responses, except in ACK 269 and CANCEL methods and CANCEL responses. 271 4. Security Considerations 273 The security considerations for these P- header fields are defined in 274 [RFC7315]. This specification allows some header fields to be 275 present in messages where they were previously not allowed, and the 276 security considerations and assumptions described in [RFC7315] (e.g. 277 regarding only sending information to trusted entities) also apply to 278 those messages. In addition, this specification also disallows some 279 header fields to be present in messages where they were previously 280 allowed. That does not cause any security issues, but 281 implementations need to be aware that implementations may not have 282 been updated according to this document, and take proper actions if a 283 header field occurs, or does not occur, in a message where it should 284 occur (or occurs in a message where it should not occur). This 285 document adds the ability to include P-Access-Network-Info in ACK 286 requests. As documented in [RFC7315], P-Access-Network-Info may 287 include privacy sensitive information, including the user's location. 288 The security and privacy considerations for P-Access-Network-Info in 289 ACK requests are similar to those for the other SIP requests 290 discussed in [RFC7315]. 292 5. IANA Considerations 294 This document makes no requests from IANA. 296 6. Acknowledgments 298 Thanks to Paul Kyzivat, Jean Mahoney, Ben Campbell and Adam Roach for 299 providing comments on the draft. 301 7. Change Log 303 [RFC EDITOR NOTE: Please remove this section when publishing] 305 Changes from draft-holmberg-dispatch-rfc7315-updates-08 307 o Editorial changes based on IESG review of Mirja Kuhlewind. 309 Changes from draft-holmberg-dispatch-rfc7315-updates-07 311 o Editorial changes in the Security Considerations based on secdir 312 comments from Steve Hanna. 314 o Editorial changes based on genart comments from Ralph Droms. 316 o Reference to 3GPP TS 23.228 based on genart comments from Ralph 317 Droms. 319 Changes from draft-holmberg-dispatch-rfc7315-updates-06 321 o Changes based on AD comments from Ben Campbell. 323 o - Additional text added to Security Considerations. 325 Changes from draft-holmberg-dispatch-rfc7315-updates-05 327 o Editorial changes based on comments from Adam Roach. 329 Changes from draft-holmberg-dispatch-rfc7315-updates-04 330 o - Errata removed. All changes defined as RFC 7315 updates. 332 o - Title changed. 334 o - Text added to the Security Considerations. 336 Changes from draft-holmberg-dispatch-rfc7315-updates-03 338 o - Minor editorial corrections. 340 Changes from draft-holmberg-dispatch-rfc7315-updates-02 342 o - Justification text for P-Charging-Vector update added. 344 Changes from draft-holmberg-dispatch-rfc7315-updates-01 346 o - Justification text for P-Access-Network-Info update added. 348 Changes from draft-holmberg-dispatch-rfc7315-updates-00 350 o - Title corrected. 352 8. References 354 8.1. Normative References 356 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 357 A., Peterson, J., Sparks, R., Handley, M., and E. 358 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 359 DOI 10.17487/RFC3261, June 2002, 360 . 362 [RFC7315] Jesske, R., Drage, K., and C. Holmberg, "Private Header 363 (P-Header) Extensions to the Session Initiation Protocol 364 (SIP) for the 3GPP", RFC 7315, DOI 10.17487/RFC7315, July 365 2014, . 367 [TS.3GPP.23.228] 368 3GPP, "IP multimedia call control protocol based on 369 Session Initiation Protocol (SIP) and Session Description 370 Protocol (SDP);Stage 3", 3GPP TS 23.228 13.6.0, June 2016. 372 [TS.3GPP.24.229] 373 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 374 TS 24.229 13.6.0, June 2016. 376 8.2. Informative References 378 [RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private 379 Header (P-Header) Extensions to the Session Initiation 380 Protocol (SIP) for the 3rd-Generation Partnership Project 381 (3GPP)", RFC 3455, DOI 10.17487/RFC3455, January 2003, 382 . 384 Authors' Addresses 386 Christer Holmberg 387 Ericsson 388 Hirsalantie 11 389 Jorvas 02420 390 Finland 392 Email: christer.holmberg@ericsson.com 394 Nevenka Biondic 395 Ericsson 396 Krapinska 45 397 Zagreb 10002 398 Croatia 400 Email: nevenka.biondic@ericsson.com 402 Gonzalo Salgueiro 403 Cisco Systems, Inc. 404 7200-12 Kit Creek Road 405 Research Triangle Park, NC 27709 406 US 408 Email: gsalguei@cisco.com