idnits 2.17.1 draft-ietf-insipid-session-id-reqts-11.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 -- The document date (February 8, 2014) is 3730 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Paul E. Jones 3 Internet Draft Gonzalo Salgueiro 4 Intended status: Informational James Polk 5 Expires: August 8, 2014 Cisco Systems 6 Laura Liess 7 Deutsche Telekom 8 Hadriel Kaplan 9 Oracle 10 February 8, 2014 12 Requirements for an End-to-End Session Identification in 13 IP-Based Multimedia Communication Networks 14 draft-ietf-insipid-session-id-reqts-11.txt 16 Abstract 18 This document specifies the requirements for an end-to-end session 19 identifier in IP-based multimedia communication networks. This 20 identifier would enable endpoints, intermediate devices, and 21 management and monitoring systems to identify a session end-to-end 22 across multiple SIP devices, hops, and administrative domains. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 8, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction...................................................2 59 2. Conventions used in this document..............................3 60 3. Terminology....................................................3 61 3.1. What does the Session Identifier Identify?................3 62 3.2. Communication Session.....................................4 63 3.3. End-to-End................................................5 64 4. Session Identifier Use Cases...................................5 65 4.1. End-to-end identification of a communication session......5 66 4.2. Protocol Interworking.....................................6 67 4.3. Traffic Monitoring........................................6 68 4.4. Tracking transferred sessions.............................6 69 4.5. Session Signal Logging....................................7 70 4.6. Identifier Syntax.........................................7 71 4.7. 3PCC Use Case.............................................7 72 5. Requirements for the End-to-End Session Identifier.............8 73 6. Related Work in other Standards Organizations..................9 74 6.1. Coordination with the ITU-T...............................9 75 6.2. Requirements within 3GPP..................................9 76 7. Security Considerations........................................9 77 8. IANA Considerations...........................................10 78 9. Acknowledgments...............................................10 79 10. Contributors.................................................10 80 11. References...................................................10 81 11.1. Normative References....................................10 82 11.2. Informative References..................................10 83 Author's Addresses...............................................12 85 1. Introduction 87 IP-based multimedia communication systems like SIP [1] and H.323 [2] 88 have the concept of a "call identifier" that is globally unique. The 89 identifier is intended to represent an end-to-end communication 90 session from the originating device to the terminating device. Such 91 an identifier is useful for troubleshooting, session tracking, and so 92 forth. 94 Unfortunately, there are a number of factors that mean that the 95 current call identifiers defined in SIP and H.323 are not suitable 96 for end-to-end session identification. Perhaps most significant is 97 the fact that the syntax for the call identifier in SIP and H.323 is 98 different between the two protocols. This important fact makes it 99 impossible for call identifiers to be exchanged end-to-end when a 100 network uses both of these session protocols. 102 Another reason why the current call identifiers are not suitable to 103 identify the session end-to-end is that in real-world deployments 104 devices like Back-to-Back User Agents (B2BUAs) often change the 105 values as the session signaling passes through. This is true even 106 when a single session protocol is employed and not a byproduct of 107 protocol interworking. 109 Lastly, identifiers that might have been used to identify a session 110 end-to-end fail to meet that need when sessions are manipulated 111 through supplementary service interactions. For example, when a 112 session is transferred or if a private branch exchange (PBX) joins or 113 merges two communication sessions together locally, the end-to-end 114 properties of currently-defined identifiers are lost. 116 This document specifies the requirements for an end-to-end session 117 identifier in IP-based multimedia communication networks. This 118 identifier would enable endpoints, intermediate devices, and 119 management and monitoring systems to identify a session end-to-end 120 across multiple SIP devices, hops, and administrative domains. 122 2. Conventions used in this document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [3] when they 127 appear in ALL CAPS. These words may also appear in this document in 128 lower case as plain English words, absent their normative meanings. 130 3. Terminology 132 3.1. What does the Session Identifier Identify? 134 The identifier this document places requirements on, the session 135 identifier, identifies a set of signaling messages associated with 136 exactly two endpoints which, from each endpoint's perspective, are 137 related to a single invocation of a communication application. 139 How the endpoints determine which signaling messages share a given 140 identifier (that is, what constitutes a single invocation of a 141 communication application) is intentionally left loosely defined. 143 The term "call" is often used as an example of such an invocation for 144 voice and video communication, but different protocols and 145 deployments define the scope of a "call" in different ways. For 146 instance, some systems would associate all of the activity between 147 all three parties involved in a transfer a single "call". 149 Similarly, the term "session" is often used as an example of such an 150 invocation, but this term is overloaded to describe both signaling 151 and media level interaction. A single invocation of the 152 communication application, as described above, may involve multiple 153 RTP "sessions" as described by RFC 3550 [4], possibly even multiple 154 concurrent sessions. 156 In this document, unless otherwise qualified, the term "communication 157 session", or simply "session", will refer only to the set of 158 signaling messages identified by the common session identifier. That 159 is, a "session" is a set of signaling messages associated with 160 exactly two endpoints that, from each endpoint's perspective, are 161 related to a single invocation of a communication application. 163 The requirements in this document put some constraints on what an 164 endpoint will consider the same, or a different, invocation of a 165 communication session. They also ensure that related sessions (as 166 this document is using the term) can be correlated using only the 167 session identifiers for each session. Again, what constitutes a 168 "related" session is intentionally left loosely defined. 170 The definition considers messages associated with exactly two 171 endpoints instead of messages sent between two endpoints to allow for 172 intermediaries that create messages on an endpoint's behalf. It is 173 possible that an endpoint may not see all of the messages in a 174 session (as this document is using the term) associated with it. 176 This definition, and the requirements in this document that put some 177 constraint on what an endpoint should consider the same, or a 178 different, invocation of a communication session facilitates 179 specifying an identifier that allows the two endpoints to use two 180 entirely different protocols (hence potentially have different ideas 181 of what a single invocation means) or use two applications that have 182 a different idea of what a single invocation means. 184 3.2. Communication Session 186 A communication session may exist between two SIP user agents and 187 that may pass through one or more intermediary devices, including 188 B2BUAs or SIP proxies. For example: 190 UA-A Middlebox(es) UA-B 191 SIP message(s) -------[]---[]-------> SIP message(s) 192 SIP message(s) <-----[]---[]------- SIP message(s) 194 Figure 1 - Communication Session through Middlebox(es) 196 The following are examples of acceptable communication sessions as 197 described in Section 3.1 and are not exhaustive: 199 o A call directly between two user agents 201 o A call between two user agents with one or more SIP middleboxes 202 in the signaling path 204 o A call between two user agents that was initiated using third- 205 party call control (3PCC) [6] 207 o A call between two user agents (e.g., between Alice and Carol) 208 that results from a different communication session (e.g., Alice 209 and Bob) wherein one of those user agents (Alice) is transferred 210 to another user agent (Carol) using a REFER request or a re- 211 INVITE request 213 The following are not considered communication sessions: 215 o A call between any two user agents wherein two or more user 216 agents are engaged in a conference call via a conference focus: 218 o each call between the user agent and the conference focus 219 would be a communication session, and 221 o each of these is a distinct communication session. 223 o A call between three user agents (e.g., Alice, Bob, and Carol) 224 wherein the first user agent (Alice) ad hoc conferences the 225 other two user agents (Bob and Carol) 227 o The call between Alice and Bob would be one communication 228 session. 230 o The call between Alice and Carol would be a different 231 communication session. 233 3.3. End-to-End 235 The term "end-to-end" in this document means the communication 236 session from the point of origin, passing through any number of 237 intermediaries, to the ultimate point of termination. It is 238 recognized that legacy devices may not support the end-to-end session 239 identifier. Since such an endpoint will not create a session 240 identifier, an intermediary device that supports this identifier can 241 inject an identifier into the session signaling. 243 4. Session Identifier Use Cases 245 4.1. End-to-end identification of a communication session 247 For SIP messaging that either does not involve SIP servers or only 248 involves SIP proxies, the Call-ID header field value sufficiently 249 identifies each SIP message within a transaction (see Section 17 of 250 [1]) or dialog (see Section 12 of [1]). This is not the case when 251 either B2BUAs or Session Border Controllers (SBCs) [7] are in the 252 signaling path between User Agents (UAs). Therefore, we need the 253 ability to identify each communication session through a single SIP 254 header field regardless of which type of SIP servers are in the 255 signaling path between UAs. For messages that create a dialog, each 256 message within the same dialog MUST use the same session identifier. 258 Derived Requirements: All Requirements in Section 5 260 4.2. Protocol Interworking 262 A communication session might originate in an H.323 [2] endpoint and 263 pass through an SBC before ultimately reaching a terminating SIP user 264 agent. Likewise, a call might originate on a SIP user agent and 265 terminate on an H.323 endpoint. It MUST be possible to identify such 266 sessions end-to-end across the plurality of devices, networks, or 267 administrative domains. 269 It is anticipated that the ITU-T will define protocol elements for 270 H.323 to make the end-to-end signaling possible. 272 Derived Requirements: REQ5, REQ7 274 4.3. Traffic Monitoring 276 UA A and UA B communicate using SIP messaging with a SIP B2BUA acting 277 as a middlebox which belongs to a SIP service provider. For privacy 278 reasons, the B2BUA changes the SIP header fields that reveal 279 information related to the SIP users, device or domain identities. 280 The service provider uses an external device to monitor and log all 281 SIP traffic coming to and from the B2BUA. In the case of failures 282 reported by the customer or when security issues arise (e.g. theft of 283 service), the service provider has to analyze the logs from the past 284 several days or weeks and correlates those messages which were 285 messages for a single end-to-end SIP session. 287 For this scenario, we must consider three particular use cases: 289 a) The UAs A and B support the end-to-end session identifier. 291 Derived Requirements: REQ1, REQ3, REQ4, REQ6. 293 b) Only the UA A supports the end-to-end session identifier, the UA 294 B does not. 296 Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6. 298 c) UA A and UA B do not support the end-to-end session identifier. 300 Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6 302 4.4. Tracking transferred sessions 304 It is difficult to track which SIP messages were involved in the same 305 call across transactions, especially when invoking supplementary 306 services such as call transfer or call join. There exists a need for 307 the ability to track communication sessions as they are transferred, 308 one side at a time, until completion of the session (i.e., until a 309 BYE is sent). 311 Derived Requirements: REQ1, REQ2, REQ9 313 4.5. Session Signal Logging 315 An after-the-fact search of SIP messages to determine which messages 316 were part of the same transaction or call is difficult when B2BUAs 317 and SBCs are involved in the signaling between UAs. Mapping more 318 than one Call-ID together can be challenging because all of the 319 values in SIP header fields on one side of the B2BUA or SBC will 320 likely be different than those on the other side. If multiple B2BUAs 321 and/or SBCs are in the signaling path, more than two sets of header 322 field values will exist, creating more of a challenge. Creating a 323 common header field value through all SIP entities will greatly 324 reduce any challenge for the purposes of debugging, communication 325 tracking (such as for security purposes in case of theft of service), 326 etc. 328 Derived Requirements: REQ1, REQ3, REQ5, REQ6 330 4.6. Identifier Syntax 332 A syntax that is too lax (e.g., one that allows special characters or 333 a very long identifier) would make it difficult to encode the 334 identifier in other protocols. Therefore, the syntax of the 335 identifier should be reasonably constrained. 337 Derived Requirements: REQ8 339 4.7. 3PCC Use Case 341 Third party call control refers to the ability of an entity to create 342 a call in which communication is actually between two or more parties 343 other than the one setting up the call. For example, a B2BUA acting 344 as a third party controller could establish a call between two SIP 345 UA's using 3PCC procedures as described in section 4.1 of RFC 3725 346 [6], the flow for which is reproduced below. 348 A Controller B 349 |(1) INVITE no SDP | | 350 |<------------------| | 351 |(2) 200 offer1 | | 352 |------------------>| | 353 | |(3) INVITE offer1 | 354 | |------------------>| 355 | |(4) 200 OK answer1 | 356 | |<------------------| 357 | |(5) ACK | 358 | |------------------>| 359 |(6) ACK answer1 | | 360 |<------------------| | 361 |(7) RTP | | 362 |.......................................| 364 Figure 2 - Session Identifier 3PCC Scenario 366 Such a flow must result in a single session identifier being used for 367 the communication session between UA A and UA B. This use case does 368 not extend to three SIP UAs. 370 Derived Requirements: REQ9 372 5. Requirements for the End-to-End Session Identifier 374 The following requirements are derived from the use cases and 375 additional constraints regarding the construction of the identifier. 377 REQ1: It MUST be possible for an administrator or an external device 378 which monitors the SIP-traffic to use the identifier to identify 379 those dialogs, transactions and messages which were at some point in 380 time components of a single end-to-end SIP session (e.g., parts of 381 the same call). 383 REQ2: It MUST be possible to correlate two end-to-end sessions when a 384 session is transferred or if two different sessions are joined 385 together via an intermediary (e.g., a PBX). 387 REQ3: The solution MUST require that the identifier, if present, pass 388 unchanged through SIP B2BUAs or other intermediaries. 390 REQ4: The identifier MUST NOT reveal any information related to any 391 SIP user, device or domain identity. Additionally, it MUST NOT be 392 possible to correlate a set of session identifiers produced over a 393 period of time with one another, or with a particular user or device. 394 This includes any IP Address, port, hostname, domain name, username, 395 Address-of-Record, MAC address, IP address family, transport type, 396 subscriber ID, Call-ID, tags, or other SIP header field or body 397 parts. 399 REQ5: It MUST be possible to identity SIP traffic with an end-to-end 400 session identifier from and to end devices that do not support this 401 new identifier, such as by allowing an intermediary to inject an 402 identifier into the session signaling. 404 REQ6: The identifier SHOULD be unique in time and space, similar to 405 the Call-ID. 407 REQ7: The identifier SHOULD be constructed in such a way as to make 408 it suitable for transmission in SIP [1] and H.323 [2]. 410 REQ8: The identifier SHOULD use a restricted syntax and length so as 411 to allow the identifier to be used in other protocols. 413 REQ9: It MUST be possible to correlate two end-to-end sessions when 414 the sessions are created by a third party controller using 3PCC 415 procedures shown in Figure 1 of RFC 3725 [6]. 417 6. Related Work in other Standards Organizations 419 6.1. Coordination with the ITU-T 421 IP multimedia networks are often comprised of a mix of session 422 protocols like SIP [1] and H.323 [2]. A benefit of the session 423 identifier is that it uniquely identifies a communication session 424 end-to-end across session protocol boundaries. Therefore, the need 425 for coordinated standardization activities across Standards 426 Development Organizations (SDOs) is imperative. 428 To facilitate this, a parallel effort is underway in the ITU-T to 429 introduce the session identifier for H.323 in such a way as to be 430 interoperable with the procedures defined by the IETF. 432 6.2. Requirements within 3GPP 434 3GPP identified in their Release 9 the need for a session identifier 435 for operation and maintenance purposes to correlate flows in an end- 436 to-end communication session. 3GPP TS24.229 [5] points to the fact 437 that the session identifier can be used to correlate SIP messages 438 belonging to the same session. In the case where signaling passes 439 through SIP entities like B2BUAs, the end-to-end session identifier 440 indicates that these dialogs belong to the same end-to-end SIP 441 communication session. 443 7. Security Considerations 445 The security vulnerabilities, attacks, and threat models affecting 446 other similar SIP identifiers are well documented in RFC 3261 and are 447 equally applicable to the end-to-end session identifier and subject 448 to the same mitigating security best practices. Further, storage of 449 the Session Identifier in a log file is also subject to the security 450 considerations specified in RFC 6872 [8]. 452 An end-to-end identifier, if not properly constructed, could provide 453 confidential information that would allow one to identify the 454 individual, device, or domain initiating or terminating a 455 communication session. In adhering to REQ4, the solution produced in 456 accordance with these requirements MUST take appropriate measures to 457 properly secure and obfuscate sensitive or private information that 458 might allow one to identify a person, device, or domain. This means 459 that the end-to-end session identifier MUST NOT reveal information 460 elements such as the MAC address or IP address. It is outside the 461 scope of this document to specify the implementation details of such 462 security and privacy measures. Those details may vary with the 463 specific construction mechanism selected for the end-to-end session 464 identifier and, therefore, will be discussed in suitable detail in 465 the solution document specifying the actual end-to-end identifier. 467 A key security consideration is to ensure that an attacker cannot 468 surreptitiously spoof the identifier and effectively render it 469 useless to diagnostic equipment that cannot properly correlate 470 signaling messages due to the duplicate session identifiers that 471 exist in the same space and time. In accordance with REQ6, this end- 472 to-end identifier MUST be sufficiently long and random to prevent it 473 from being guessable as well as avoid collision with another 474 identifier. The secure transport of the identifier, need for 475 authentication, encryption, etc. should be appropriately evaluated 476 based on the network infrastructure, transport domain and usage 477 scenarios for the end-to-end session identifier. 479 8. IANA Considerations 481 There are no IANA considerations associated with this document. 483 9. Acknowledgments 485 The authors would like to acknowledge Paul Kyzivat, Christer 486 Holmberg, Charles Eckel, Andy Hutton, Salvatore Loreto, Keith Drage, 487 Chris Pearce for their contribution and collaboration in developing 488 this document. 490 This document was prepared using 2-Word-v2.0.template.dot. 492 10. Contributors 494 Two other people originally participated as co-authors and provided 495 substantial contributions to this document, namely Roland Jesske, 496 Parthasarathi Ravindran. 498 11. References 500 11.1. Normative References 502 [1] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 503 3261, June 2002. 505 [2] Recommendation ITU-T H.323, "Packet-based multimedia 506 communications systems", December 2009. 508 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 509 Levels", BCP 14, RFC 2119, March 1997. 511 11.2. Informative References 513 [4] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real- 514 Time Applications", RFC 3550, July 2003. 516 [5] 3GPP TS 24.229, "IP multimedia call control protocol based on 517 Session Initiation Protocol (SIP) and Session Description 518 Protocol (SDP); Stage 3". 520 [6] Rosenberg, J., Peterson, J., Schulzrinne, H., Camarillo, G., 521 "Best Current Practices for Third Party Call Control (3pcc) in 522 the Session Initiation Protocol (SIP)", RFC 3725, April 2004. 524 [7] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., 525 and M. Bhatia, "Requirements from Session Initiation Protocol 526 (SIP) Session Border Control (SBC) Deployments", RFC 5853, 527 April 2010. 529 [8] Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., Festor, O., 530 "The Common Log Format (CLF) for the Session Initiation 531 Protocol (SIP): Framework and Information Mode", RFC 6872, 532 February 2013. 534 Author's Addresses 536 Paul E. Jones 537 Cisco Systems, Inc. 538 7025 Kit Creek Rd. 539 Research Triangle Park, NC 27709 540 USA 542 Phone: +1 919 476 2048 543 Email: paulej@packetizer.com 544 IM: xmpp:paulej@packetizer.com 546 Hadriel Kaplan 547 Oracle 548 71 Third Ave. 549 Burlington, MA 01803, USA 551 Email: hadriel.kaplan@oracle.com 553 Laura Liess 554 Deutsche Telekom NP 555 64295 Darmstadt 556 Heinrich-Hertz-Str. 3-7 557 Germany 559 Phone: +49 6151 268 2761 560 Email: laura.liess.dt@gmail.com 562 James Polk 563 Cisco Systems, Inc. 564 3913 Treemont Circle 565 Colleyville, Texas, 566 USA 568 Phone: +1 817 271 3552 569 Email: jmpolk@cisco.com 570 IM: xmpp:jmpolk@cisco.com 572 Gonzalo Salgueiro 573 Cisco Systems, Inc. 574 7025 Kit Creek Rd. 575 Research Triangle Park, NC 27709 576 USA 578 Phone: +1 919 392 3266 579 Email: gsalguei@cisco.com 580 IM: xmpp:gsalguei@cisco.com