idnits 2.17.1 draft-kaplan-insipid-session-id-04.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2014) is 3690 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Replaces' is mentioned on line 114, but not defined == Missing Reference: 'SIP-Identity' is mentioned on line 115, but not defined == Missing Reference: 'Connected-identity' is mentioned on line 116, but not defined == Missing Reference: '0-9a-f' is mentioned on line 479, but not defined Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INSIPID Working Group H. Kaplan 3 Internet Draft Oracle 4 Intended status: Informational 5 Expires: September 10, 2014 March 10, 2014 7 A Session Identifier for the Session Initiation Protocol (SIP) 8 draft-kaplan-insipid-session-id-04 10 Abstract 12 This RFC, which contains the text of an individual Internet Draft 13 that was submitted originally to the DISPATCH Working Group, is 14 being published now as an Informational document to provide a 15 reference for later RFCs. The mechanism defined in this document 16 has been widely deployed, and is being followed in a backward- 17 compatible fashion for a new Standards Track RFC in the INSIPID 18 Working Group. The original Abstract follows. 20 There is a need for having a globally unique session identifier for 21 the same SIP session, which can be consistently maintained across 22 SIP Proxies, Back-to-Back User Agents (B2BUAs), and other SIP 23 middle-boxes, for the purpose of Troubleshooting. This draft 24 proposes a new SIP header to carry such a value: Session-ID. 26 Status of this Memo 28 This document is not an Internet Standards Track specification; it 29 is published for the historical record. 31 This Internet-Draft is submitted to IETF in full conformance with 32 the provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as 42 reference material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on September 10, 2014. 52 Copyright and License Notice 54 Copyright (c) 2014 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with 62 respect to this document. Code Components extracted from this 63 document must include Simplified BSD License text as described in 64 Section 4.e of the Trust Legal Provisions and are provided without 65 warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction................................................3 70 1.1. Requirements...........................................4 71 2. Terminology.................................................4 72 3. Overview of Operation.......................................4 73 4. Session-ID Behavior.........................................5 74 4.1. Generating a Session-ID value..........................5 75 4.2. UAC Behavior...........................................5 76 4.3. UAS Behavior...........................................6 77 4.4. Proxy Behavior.........................................6 78 4.5. B2BUA Behavior.........................................7 79 4.5.1 B2BUA Generation of New Session-ID 7 80 4.5.2 B2BUA Insertion of Saved Session-ID 8 81 5. Handling SIP Transfer Scenarios.............................8 82 5.1. Out-of-Dialog REFER....................................9 83 5.2. Refer-To URI...........................................9 84 5.3. Out-of-Dialog INVITE with Replaces.....................9 85 6. Session-ID Migration and Failure Scenarios.................10 86 7. New 'Session-ID' Header....................................10 87 7.1. Augmented BNF Definitions.............................10 88 8. Example Exchange...........................................11 89 9. Security Considerations....................................11 90 9.1. Security considerations for administrators............11 91 9.2. Security considerations for Session-ID extensions.....11 92 10. IANA Considerations........................................12 93 11. Acknowledgments............................................13 94 12. References.................................................13 95 12.1. Normative References..................................13 96 Author's Address.................................................13 97 Appendix A. Use-cases not in scope for Session-ID...............13 98 A.1. Dialog Correlation for SIP............................14 100 1. Introduction 102 This RFC, which contains the text of an individual Internet Draft 103 that was submitted originally to the DISPATCH Working Group, is 104 being published now as an Informational document to provide a 105 reference for later RFCs. The mechanism defined in this document 106 has been widely deployed, and is being followed in a backward- 107 compatible fashion for a new Standards Track RFC in the INSIPID 108 Working Group. 110 The SIP [RFC3261] Call-ID header value is a globally unique 111 identifier, mandatory in all requests/responses, which identifies 112 SIP messages belonging to the same dialog or registration. It 113 provides a portion of the SIP message dialog-matching criteria, and 114 is used in such things as [Replaces] headers and [dialog-events] 115 package for matching to dialogs, and in [SIP-Identity] and 116 [Connected-identity] as one of the inputs for signing. 118 In practice, the Call-ID is often changed by SIP Back-to-Back User 119 Agents (B2BUAs) and other such middle-boxes in the logical end-to- 120 end message path. A B2BUA logically represents a SIP User Agent 121 Server (UAS) and User Agent Client (UAC), and as such generates a 122 new Call-ID value for the dialog it creates on its UAC side; in fact 123 for some B2BUA scenarios the Call-ID *must* be changed for SIP to 124 function properly. 126 At the same time, there is a need for a unique, common, consistent 127 end-to-end identifier to help troubleshoot SIP sessions and message- 128 flows as they cross SIP nodes. Troubleshooting is more complicated 129 if multiple legs of the session are on different sides of B2BUAs, 130 due to the lack of a common identifier such as a Call-ID to tie the 131 legs together. Proprietary mechanisms are currently used to achieve 132 this goal. 134 Therefore, in order to provide an identifier that will not be 135 modified/replaced by B2BUAs, this draft proposes a new SIP Header 136 "Session-ID", and mandatory rules for the value of such a header. 137 The rules are designed to be such that the value in the Session-ID 138 header is not considered unsafe, private, or have any property that 139 would cause B2BUAs to change it. The goal of this draft is to 140 enable troubleshooting by providing a unique identifier for a given 141 session which can successfully cross B2BUAs, such as Application 142 Servers, Softswitches, Private Branch Exchanges (PBXs), Session 143 Border Controllers (SBCs), Feature Servers, etc. 145 1.1. Requirements 147 The following requirements drive the need for Session-ID: 149 REQ1: It must be possible for an administrator to use the identifier 150 to identify a set of dialogs which have a direct correlation with 151 each other such that they represent the same SIP session, with as 152 high a probability as possible. 154 REQ2: It must be possible to pass the identifier through SIP B2BUAs, 155 with as high a probability as possible. This requirement drives the 156 following requirements: 158 REQ2a: The identifier must not reveal any information related to any 159 SIP device or domain identity, including IP Address, port, hostname, 160 domain name, username, Address-of-Record, MAC address, IP address 161 family, transport type, etc. 163 REQ2b: The identifier must not reveal to the receiver of it that the 164 Call-ID, tags, or any other SIP header or body portion have been 165 changed by middle-boxes, with as high a probability as possible. 167 REQ2c: The identifier must not be used for anything at a SIP layer 168 to change the behavior of the SIP protocol. 170 2. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 176 This document uses the terms "header field" and "header field value" 177 following the definition of those terms in [RFC3261], which are not 178 interchangeable. The "header field" is the entire SIP header's 179 contents, including any parameters. The "header field value" is 180 only the field-value portion, which does not include header 181 parameters. 183 3. Overview of Operation 185 The general concept is that the UAC generating an out-of-dialog 186 request generates a new, pseudo-random, unique value that remains 187 constant for the duration of the transaction, any dialog created 188 from that request, or for a registration. The value is inserted in 189 a new Session-ID header field defined in this draft. The UAC and 190 UAS then reflect this header field value in all messages for the 191 duration of the dialog. In other words, the Session-ID provides a 192 value similar in nature to Call-ID, except one which crosses B2BUAs 193 and which has no sensitive information in it. 195 To aid in migration of deployments, a B2BUA or Proxy MAY also 196 generate and/or insert the value on behalf of a UAC or UAS, if one 197 or the other does not support this document's mechanism. 199 Although the Session-ID concept is similar to the Call-ID, it is not 200 used for message dialog-matching rules in RFC 3261, nor does it 201 change the Call-ID usage, nor does it replace the Call-ID value. 202 Instead this new header field provides an identifier for 203 troubleshooting uses only. 205 The format of the Session-ID value is restricted, both to avoid 206 detection of the system type which generated it, and to keep it a 207 hexadecimal representation such that it can be stored as a 128-bit 208 binary value in log records. 210 4. Session-ID Behavior 212 4.1. Generating a Session-ID value 214 This draft proposes the Session-ID header value be generated based 215 on a defined hash mechanism for creating a 128-bit pseudo-random 216 value, and encode it as its lower-case hex representation. The 217 reason for specifying the mechanism is two-fold: to make it 218 impossible to determine the manufacturer of the device which 219 generated it by looking at its format or value, and to allow devices 220 to generate the same value if they have the same private key. 222 The Session-ID value is generated by taking the Call-ID header 223 value, and SHA-1 hashing it based on [RFC2104] HMAC using a locally 224 generated pseudo-random 128-bit system secret key, to create a 128- 225 bit resultant HMAC value. The secret key makes the resultant HMAC 226 value not re-creatable by other parties, which is necessary to 227 prevent detection of Call-IDs being changed, as required by Req-2b. 228 Otherwise, middle-boxes may have motivation to remove the Session-ID 229 in order to hide the fact that they changed the Call-ID. 231 Per [RFC2104], the algorithm is thus HMAC-SHA-1-128(Call-ID_value, 232 secret_key), and the 128-bit result is encoded using lowercase 233 alphanumeric hex representation, as defined in the ABNF section of 234 this document. 236 In order to enable trouble-shooting of in-dialog messages, a 237 generator needs to remember or re-create the same Session-ID value 238 for the duration of a given dialog(s). This is described in more 239 detail in following sections of this document. 241 4.2. UAC Behavior 242 The rules for when a UAC generates a new Session-ID value are 243 similar as those for Call-ID value: a UAC supporting this document's 244 mechanism MUST generate a new unique Session-ID value whenever it 245 generates an out-of-dialog request, or for a new Registration. The 246 exception to this rule is for out-of-dialog REFER requests, or 247 INVITE with [RFC3891] Replaces header field, as described in section 248 5. 250 The UAC MUST re-use the same Session-ID value for in-dialog messages 251 as that of the original dialog-creating request, and for any out-of- 252 dialog request it retransmits or re-generates in response to a 3xx, 253 or it re-formulates due to failure responses. This follows the 254 rules in [RFC3261] for Call-ID generation. 256 Session-ID values in Registration "refreshes" - REGISTER requests 257 which are used to update the expiry time but not to register a new 258 contact - MUST use the same Session-ID value as previous REGISTER 259 requests. New Registrations, which add or change the Contact URI 260 for the AoR, but not simply to delete them, MUST use a new Session- 261 ID value. This follows the behavior of Call-ID per RFC 3261; it is 262 re-iterated here because some devices incorrectly change their Call- 263 ID value for every re-Registration, and MUST NOT do the same to the 264 Session-ID. 266 The UAC MUST include the Session-ID header field in every SIP 267 message it transmits. 269 4.3. UAS Behavior 271 A UAS compliant with this document MUST copy a received Session-ID 272 header field in a request, into responses and subsequent upstream 273 requests sent within the dialog. 275 If an out-of-dialog request is received without a Session-ID header 276 field, the UAS SHOULD generate a new one for subsequent use in the 277 transaction and dialog, as defined for a UAC, and use the same value 278 in all responses and upstream in-dialog requests for the same 279 dialog. 281 4.4. Proxy Behavior 283 A Proxy MUST NOT remove or modify the Session-ID header field it 284 receives, if one is in the message. By definition, an RFC 3261 285 compliant Proxy would not modify or remove such a header. 287 If the Proxy forks a request, it MUST copy the same Session-ID 288 header field into all the forked request copies. If the Proxy 289 recurses requests due to 3xx redirection, or regenerates requests 290 due to failures, it MUST use the same Session-ID header field as the 291 original request, just as the UAC does. 293 If the Proxy locally generates any response or request based on a 294 received request, including 100 Trying, it MUST insert any received 295 Session-ID header field from the original request into the response 296 message it locally creates. This is necessary for troubleshooting 297 purposes. 299 A Proxy compliant with this draft MAY generate a new Session-ID or 300 insert a previously saved one, if and only if none existed in a 301 received message, following the rules for doing so as a B2BUA 302 defined later. 304 4.5. B2BUA Behavior 306 A B2BUA compliant with this document MUST copy the Session-ID header 307 field it receives in requests as a UAS into the related requests it 308 generates as a UAC; and any Session-ID field it receives in 309 responses as a UAC into the correlated responses it generates as a 310 UAS. 312 If the B2BUA forks or creates multiple requests as a UAC, from a 313 request it received as a UAS, the B2BUA MUST copy the same Session- 314 ID header field it received into all the forks/requests. If the 315 B2BUA recurses requests due to 3xx redirection, or regenerates 316 requests due to failures, it MUST use the same Session-ID field, 317 just as the UAC does. 319 If the B2BUA locally generates any response or request based on a 320 received request, including 100 Trying, it MUST insert any received 321 Session-ID field from the original request into the response message 322 it locally creates. 324 A B2BUA MAY remember the received Session-ID value for the duration 325 of the transaction and dialog, for the purpose of re-insertion, in 326 case the far-end does not support this draft. 328 In all cases, if the SIP message received by a B2BUA contained a 329 Session-ID header field, a B2BUA compliant with this document MUST 330 NOT remove, modify or replace it as it "forwards" the message on the 331 other logical UA "side" of itself. 333 4.5.1 B2BUA Generation of New Session-ID 335 If an out-of-dialog request is received by a B2BUA compliant with 336 this document, and the request does *not* contain a Session-ID 337 header field, the B2BUA MAY generate a new one. The new Session-ID 338 value MUST be calculated based on the received Call-ID of the 339 received request, even if the B2BUA uses a different Call-ID value 340 for requests generated on its other "side(s)". It MUST then insert 341 it in any requests or responses it generates, as if it had actually 342 received the new Session-ID from the UAC, following the rules 343 previously defined for a B2BUA. This allows for a B2BUA to provide 344 a migration to Session-ID deployment, on behalf of upstream nodes 345 that do not yet support it. 347 As defined previously, if any received message already had a 348 Session-ID, a B2BUA compliant with this document would not replace 349 it. 351 4.5.2 B2BUA Insertion of Saved Session-ID 353 If a Session-ID was received in an out-of-dialog request, or the 354 B2BUA locally generated one because none existed, the B2BUA SHOULD 355 insert the same Session-ID field into all responses and upstream in- 356 dialog requests if and only if a Session-ID is not already in them. 357 This allows for a B2BUA to provide a migration to Session-ID 358 deployment, on behalf of downstream nodes that do not yet support 359 it. 361 5. Handling SIP Transfer Scenarios 363 The transfer or movement of SIP sessions represents a complication 364 for a Session-ID type mechanism. On the one hand, the replacement 365 SIP session represents a new one, and could reasonably be expected 366 to use a new Session-ID value; on the other hand, from a 367 troubleshooting and human user perspective, it is clearly related 368 to, if not just a continuation of, the previous session. Since the 369 purpose of this document's mechanism is to aid monitoring and 370 troubleshooting, and not used for actual SIP protocol mechanics, the 371 behavior defined in this section is to re-use the same Session-ID 372 value for the replacement SIP session. 374 In order to do so, the Session-ID of the "original" session is 375 transferred as well, in the Refer-To URI of a [RFC3515] REFER 376 request. Furthermore, out-of-dialog REFER and INVITE with [RFC3891] 377 Replaces requests use the appropriate Session-ID values. This 378 assumes, of course, that the UAs involved support the Session-ID 379 mechanism. If they do not, then it is possible for the Session-ID 380 to not be "carried forward" to the new SIP dialog. Unfortunately, 381 this means troubleshooting such dialogs is not improved/aided by 382 this document's mechanism; but it would not "break" anything at a 383 SIP layer. 385 It should also be noted that using the same Session-ID for the 386 transferred-to dialog means the same Session-ID now exists in two 387 independent dialogs, because the original one may well continue due 388 to the implicit Subscription usage created by a REFER - that 389 implicit Subscription based usage will continue to use the same 390 Session-ID as the new dialog created to the transferred-to party. 392 For the following sub-sections, the term "UA" is used for User 393 Agent. The language applies to the SIP device which creates the 394 request, whether it be a UA or B2BUA. 396 5.1. Out-of-Dialog REFER 398 A UA compliant with this document MUST use the same Session-ID 399 header field value for an out-of-dialog REFER request it generates, 400 as the original dialog the REFER is targeted to (i.e., as if the 401 REFER had been in-dialog). For example, if UA Bob has a SIP dialog 402 X to Alice, and Bob sends an out-of-dialog REFER to Alice to refer 403 her to Charlie, the Session-ID header field value of the REFER 404 request would be the same as that used in dialog X. 406 5.2. Refer-To URI 408 A UA compliant with this document MUST add the Session-ID header 409 field as an embedded header in the Refer-To header field URI of any 410 REFER request it generates, using the value of the session it is 411 referring to. For example, if UA Bob has a SIP dialog X to Alice 412 and dialog Y to Charlie, and Bob sends a REFER request to Alice to 413 refer her to Charlie, the Session-ID header field value embedded in 414 the Refer-To URI of the REFER request would be the same as that used 415 in dialog Y. 417 5.3. Out-of-Dialog INVITE with Replaces 419 When generating an out-of-dialog INVITE with [RFC3891] Replaces 420 header field, a UA compliant with this document MUST use the same 421 Session-ID header field value for the INVITE request as that used 422 for the dialog it is replacing, if it knows the value. Typically it 423 would know the value by having received it in the Refer-To header 424 field of a REFER, as described previously. For example, if UA Bob 425 has a SIP dialog X to Alice and dialog Y to Charlie, and Bob sends a 426 REFER request to Alice to refer her to Charlie, the Session-ID 427 header field value embedded in the Refer-To URI of the REFER request 428 would be the one used in dialog Y, which Alice would use as the 429 Session-ID header field value for her INVITE to Charlie. 431 If the UA does not know the Session-ID of the dialog it is 432 replacing, for example because it is not embedded in the Refer-To 433 URI of a received REFER, then it MUST use a new Session-ID value, 434 calculated using the mechanism as defined in section 4.1 with the 435 Call-ID of the INVITE. 437 6. Session-ID Migration and Failure Scenarios 439 SIP is already widely deployed on the Internet, and it is 440 impractical to expect all UAs to be upgraded to support this 441 document's mechanism in the near future. A solution for gradual 442 migration is necessary, which this document provides by allowing 443 B2BUAs or Proxies to perform the Session-ID generator and inserter 444 role. Even within those device types, it is impractical to expect 445 all B2BUAs to support this mechanism all at once, or any time in the 446 near future. Therefore, it is expected that some B2BUAs and/or UAs 447 will support generating and inserting Session-ID, while others will 448 not support Session-ID at all. 450 Due to the varying types of B2BUAs, such as PBXs, SBCs, Application 451 Servers, Feature Servers, and Softswitches of various flavors, and 452 the numerous SIP deployment models in use, there are going to be 453 cases in which Session-ID will fail to be a consistent value for all 454 related dialogs, or fail to successfully match. The goal of this 455 draft is to improve troubleshooting of current deployments as much 456 as possible - and in this author's opinion that is the best that can 457 be done given the constraints. 459 One example is for forked requests: if a UAC which does not support 460 this mechanism sends a request to a Proxy or B2BUA which also does 461 not support this mechanism, each fork could reach B2BUAs or UASs 462 which *do* support this mechanism. In such a case, each of those 463 forked-to B2BUA/UAS will generate unique Session-IDs and put them in 464 their responses, temporarily leading to multiple, different Session- 465 ID values for the same related early dialogs. Typically, the UAC 466 would eventually only accept one of the dialogs, and only one 467 Session-ID would remain. 469 7. New 'Session-ID' Header 471 This draft adds the "Session-ID" token to the definition of the 472 element "message-header" in the SIP message grammar. The Session-ID 473 header is a single-instance header. 475 7.1. Augmented BNF Definitions 477 Session-ID = "Session-ID" HCOLON sess-id 478 *( SEMI generic-param ) 479 sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] 481 NOTE: The sess-id value is technically case-INSENSITIVE, but note 482 that only lower-case characters are allowed. 484 See the Security Considerations section for discussion about using 485 header parameters in Session-ID header fields. 487 8. Example Exchange 489 In the following example, Alice initiates a call to Bob. Alice 490 generates a Session-ID header in the out-of-dialog INVITE. 492 Alice generates the following: (note: much has been left out for 493 simplicity) 494 INVITE sip:bob@example.com SIP/2.0 495 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 496 From: Alice ;tag=1234567 497 To: Bob 498 Call-Id: 123456mcmxcix@1.2.3.4 499 Session-ID: f81d4fae7dec11d0a76500a0c91e6bf6 500 CSeq: 1 INVITE 501 Contact: 503 9. Security Considerations 505 There are several security considerations surrounding this 506 document's mechanism. 508 The Session-ID generation algorithm should provide a reasonably 509 random 32-character Session-ID value, to avoid collisions, and would 510 not let one re-create the original Call-ID. 512 There is no known security issue with viewing or modifying the 513 Session-ID, other than to hamper troubleshooting efforts. 515 9.1. Security considerations for administrators 517 The requirement for the Session-ID is to be an identifier which 518 cannot be used by a recipient to identify if the Call-ID has been 519 changed by middle-boxes. As such, a UAS/UAC cannot detect the 520 original Call-ID, nor whether it has been changed, and thus should 521 not cause administrators concern to be "passed through". 523 9.2. Security considerations for Session-ID extensions 525 The Session-ID's value is created from the Call-ID using a hashing 526 mechanism based on [RFC2104], using SHA-1 and a secret key known 527 only to the system generating the Session-ID. Because the algorithm 528 is defined in this document, it should be fairly secure from 529 detecting the generator of the Session-ID, in terms of manufacturer 530 or code base. 532 The Session-ID generation algorithm should provide a reasonably 533 random 128-bit Session-ID value, to avoid collisions, and would not 534 let one re-create the original Call-ID. The secret key MUST only be 535 used for the Session-ID mechanism, in case a weakness is found which 536 reveals the key. One such weakness may be that a UAC generates one 537 or more Call-IDs which have a property that makes determining the 538 key more likely. 540 In general, B2BUA behavior cannot be dictated by standards. They do 541 whatever their owners/operators wish them to do, or whatever is 542 necessary to make their applications work. This document attempts 543 to normatively specify some B2BUA behavior, by creating a SIP header 544 value for which the properties are such that B2BUAs should have no 545 legitimate reason to interfere. This effectively creates a 546 "promise" that future uses of this Session-ID header field, 547 including its value *and* any future defined parameters, maintain 548 this benign property. Any future extensions to the Session-ID 549 mechanism and header field MUST maintain this property, or else 550 B2BUAs will begin to modify it again or remove it, and its value 551 will be lost. 553 Manufacturers of SIP devices should note that there is no guarantee 554 that a B2BUA will not inspect the Session-ID header field, and 555 remove it if it does not comply with this document's value 556 restrictions. Any Session-ID header parameters MUST be registered 557 with IANA and documented in IETF RFCs, pursuant to the requirements 558 of [RFC3968]. 560 10. IANA Considerations 562 This document asks IANA to register a new SIP header field named 563 'Session-ID', pursuant to the registration policies for such in 564 [RFC5727]. This is a single-instance header field, and is 565 appropriate for any SIP message, of any Method type, in any request 566 or response. 568 The ABNF rules for this new header allow for header parameters, 569 however they must be registered following the rules of [RFC3968], as 570 required by [RFC5727]. 572 This registration is intended to be temporary. The author expects 573 that a standards-track definition of Session-ID will be published at 574 a future date. Assuming such a document is published, it will 575 replace this registration with a reference to itself, at which point 576 this document will no longer be referenced by IANA. 578 11. Acknowledgments 580 Thanks to Raphael Coeffic, Bob Penfield, Dale Worley, Paul Kyzivat, 581 Ian Elz, Marco Stura, Martin Dolly, Martin Huelsemann, Laura Liess 582 and Adam Roach for their input. 584 12. References 586 12.1. Normative References 588 [RFC2104] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed- 589 Hashing for Message Authentication", RFC 2104, February 1997. 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", RFC 2119, March 1997. 594 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 595 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 596 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 598 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 599 Method", RFC 3515, April 2003. 601 [RFC3891] Mahy, R., Biggs, B., Dean, R., "The Session Initiation 602 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 604 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 605 (IANA) Header Field Parameter Registry for the Session 606 Initiation Protocol (SIP)", RFC 3968, December 2004. 608 [RFC5727] Peterson, J., Jennings, C., Sparks, R., "Change Process 609 for the Session Initiation Protocol (SIP) and the Real-time 610 Applications and Infrastructure Area", RFC 5727, March 2010. 612 Author's Address 614 Hadriel Kaplan 615 Oracle 616 Email: hadriel.kaplan@oracle.com 618 Appendix A. Use-cases not in scope for Session-ID 620 It is very tempting to use a header field value such as that 621 provided by Session-ID, for other purposes than troubleshooting. In 622 a previous draft for this same Session-ID concept, the proposal 623 included other uses; but these were removed because any use-case 624 other than troubleshooting can easily lead to a B2BUA needing to 625 change the value, in certain cases. That would defeat the 626 troubleshooting value of Session-ID. This section discusses such 627 use-cases and explains why they are potentially harmful. 629 A.1. Dialog Correlation for SIP 631 Although Session-ID does provide a means to correlate separate SIP 632 dialogs, messages, and transactions, it does so at a higher layer 633 than SIP. It does not replace the mechanics of SIP using the Call- 634 ID and To/From tags of SIP messages to correlate SIP dialogs, nor in 635 other uses such as Replaces headers or dialog-event packages. It is 636 tempting, however, to use it for exactly that purpose in certain 637 cases. 639 For example, suppose a call transfer case where Alice calls Bob 640 through B2BUA-1. Bob then calls Charlie, and sends Charlie a REFER 641 with embedded Replaces, to make Charlie send an INVITE with Replaces 642 header to Alice, to replace the Alice-Bob session. If Charlie uses 643 a different B2BUA-2 to reach Alice, the INVITE with Replaces will 644 fail, because the Call-ID/tags won't match anything B2BUA-2 or Alice 645 knows about. 647 +-----+ +-------+ +-------+ +-----+ +-------+ 648 |Alice| |B2BUA-1| |B2BUA-2| | Bob | |Charlie| 649 +-----+ +-------+ +-------+ +-----+ +-------+ 650 | | | | | 651 |INVITE | | | | 652 |callid:1a |callid:1b | | | 653 |----------->|----------------------->|INVITE | 654 |sessid:1 |sessid:1 | |callid:2a | 655 | | | |----------->| 656 | | | |sessid:2 | 657 | | | | | 658 | | | |REFER | 659 | | | |referto:1b | 660 | | | |----------->| 661 | | | | | 662 | | | | INVITE| 663 | | | | replaces:1b| 664 | | X<-----------------------| 665 | | INVITE| | sessid:1| 666 | | replaces:1b| | | 667 X<------------------------| | | 668 | | sessid:1| | | 669 Example-1: call transfer case 671 If, on the other hand, Alice were to use the Session-ID value for 672 correlation, she would see it matches her dialog with Bob (assuming 673 the Session-ID were passed along in the Refer-To and Replaces info). 675 There are problems with this approach, however. The first problem 676 is, by not sending the INVITE with Replaces to B2BUA-1, B2BUA-1 is 677 in an incorrect state; the dialog is getting replaced, and the B2BUA 678 doesn't know it. 680 A second issue is the Session-ID doesn't identify enough information 681 to replace a dialog. Imagine there were a third B2BUA, such as a 682 SoftSwitch, between Alice and B2BUA-1 and B2BUA-2, and the INVITE 683 with Replaces reached the SoftSwitch before Alice. The SoftSwitch 684 won't know which "side" the INVITE is replacing. The To/From tags 685 no longer match anything the SoftSwitch knows about, so it can't 686 figure out if the INVITE with Replaces is replacing the dialog from 687 SoftSwitch to Alice, or the one to Bob. If we try to fix this by 688 creating a tag-type value pair for Session-ID, we're back to devices 689 changing those tag values and defeating the matching property. 691 Another example is based on 3GPP 24.605 annex A.2.2. Alice has a 692 call with Bob through multiple B2BUA's and an Application Server. 693 The dialogs of that call all have the same session-id, but unique 694 call-id/tags. 696 Alice wants to invoke a 3rd party conference facility in the AS, and 697 reference the call she has with Bob for that. In this particular 698 3gpp scenario, to do that Alice sends a new INVITE to the AS with a 699 resource-list body (a la RFC 5366) containing the call information 700 for the original call. This is the "RL" piece in the 701 diagram. It has the calli-d/tags as well, but they'll be wrong when 702 received at the AS. 704 The AS processes that list, can't match the callid/tags in the 705 resource-lit but does match the session-id, and sends a re-INVITE to 706 party B within the original call's dialog. 708 +-----+ +-------+ +----+ +-------+ +-----+ 709 |Alice| |B2BUA-1| | AS | |B2BUA-2| | Bob | 710 +-----+ +-------+ +----+ +-------+ +-----+ 711 | | | | | 712 |INVITE | | | | 713 |callid:1a |callid:1b |callid:1c |callid:1d | 714 |----------->|----------->|---------->|----------->| 715 |sessid:1 |sessid:1 |sessid:1 |sessid:1 | 716 | | | | | 717 |INVITE | | | | 718 |callid:2a |callid:2b | | | 719 |----------->|----------->| | | 720 |sessid:2 |sessid:2 |re-INVITE | | 721 |RL|RL|callid:1c |callid:1d | 722 | | |---------->|----------->| 723 | | |sessid:1 |sessid:1 | 724 | | | | | 725 Example-2: Resource List