idnits 2.17.1 draft-ietf-insipid-session-id-reqts-07.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 (June 12, 2013) is 3968 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '4' is defined on line 503, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: December 12, 2013 Cisco Systems 6 Laura Liess 7 Deutsche Telekom 8 Hadriel Kaplan 9 Acme Packet 10 June 12, 2013 12 Requirements for an End-to-End Session Identification in 13 IP-Based Multimedia Communication Networks 14 draft-ietf-insipid-session-id-reqts-07.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 December 12, 2013. 41 Copyright Notice 43 Copyright (c) 2013 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-ID 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.....................................5 67 4.3. Traffic Monitoring........................................6 68 4.4. Tracking transferred sessions.............................6 69 4.5. Session Signal Logging....................................6 70 4.6. Identifier Syntax.........................................7 71 4.7. 3PCC Use Case.............................................7 72 5. Requirements for the End-to-End Session Identifier.............7 73 6. Related Work in other Standards Organizations..................8 74 6.1. Coordination with the ITU-T...............................8 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...............................................11 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 represents 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 contribute to the 95 fact that the current call identifiers defined in SIP and H.323 are 96 not suitable for end-to-end session identification. Perhaps most 97 significant is the fact that the syntax for the call identifier in 98 SIP and H.323 is different between the two protocols. This important 99 fact makes it impossible for call identifiers to be exchanged end-to- 100 end when a network utilizes one or more 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 often change the values as the 105 session signaling passes through. This is true even when a single 106 session protocol is employed and not a byproduct of protocol 107 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 PBX joins or merges two communication 113 sessions together locally, the end-to-end properties of currently- 114 defined identifiers are lost. 116 2. Conventions used in this document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [3] when they 121 appear in ALL CAPS. These words may also appear in this document in 122 lower case as plain English words, absent their normative meanings. 124 3. Terminology 126 3.1. What does the Session-ID Identify? 128 The identifier this document places requirements on, the Session 129 Identifier, identifies a set of signaling messages associated with 130 exactly two endpoints that, from each endpoint's perspective, are 131 related to a single invocation of a communication application. 133 How the endpoints determine which signaling messages share a given 134 identifier (that is, what constitutes a single invocation of a 135 communication application) is intentionally left loosely defined. 137 The term "call" is often used as an example of such an invocation for 138 voice and video communication, but different protocols and 139 deployments define the scope of a "call" in different ways. For 140 instance, some systems would associate all of the activity between 141 all three parties involved in a transfer a single "call". 143 Similarly, the term "session" is often used as an example of such an 144 invocation, but this term is overloaded to describe both signaling 145 and media level interaction. A single invocation of the 146 communication application, as described above, may involve multiple 147 RTP "sessions" as described by RFC 3550, possibly even multiple 148 concurrent sessions. 150 In this document, unless otherwise qualified, the term "communication 151 session", or simply "session", will refer only to the set of 152 signaling messages identified by the common Session-ID identifier. 153 That is, a "session" is a set of signaling messages associated with 154 exactly two endpoints that, from each endpoint's perspective, are 155 related to a single invocation of a communication application. 157 The requirements in this document put some constraint on what an 158 endpoint will consider the same, or a different, invocation of a 159 communication session. They also ensure that related sessions (as 160 this document is using the term) can be correlated using only the 161 session identifiers for each session. Again, what constitutes a 162 "related" session is intentionally left loosely defined. 164 The definition speaks of messages associated with exactly two 165 endpoints instead of messages sent between two endpoints to allow for 166 intermediaries that create messages on an endpoint's behalf. It is 167 possible that an endpoint may not see all of the messages in a 168 session (as this document is using the term) associated with it. 170 This definition, and the requirements in this document that put some 171 constraint on what an endpoint should consider the same, or a 172 different, invocation of a communication session facilitates 173 specifying an identifier that allows the two endpoints to use two 174 entirely different protocols (hence potentially have different ideas 175 of what a single invocation means) or use two applications that have 176 a different idea of what a single invocation means. 178 3.2. Communication Session 180 A communication session may exist between two SIP user agents and 181 that may pass through one or more intermediary devices, including 182 B2BUAs or SIP proxies. For example: 184 A Middlebox(es) B 185 SIP message(s) ---------------------> SIP message(s) 186 SIP message(s) <------------------- SIP message(s) 188 Figure 1 - Communication Session through Middlebox(es) 190 The following are examples of acceptable communication sessions: 192 o A call directly between two user agents 194 o A call between two user agents with one or more SIP middleboxes 195 in the signaling path 197 o A call between two user agents that was initiated using third- 198 party call control (3PCC) 200 o A call between two user agents (e.g., Alice and Carol) that 201 results from a different communication session (e.g., Alice and 202 Bob) wherein one of those user agents (Alice) is transferred to 203 another user agent (Carol) using REFER or re-INVITE 205 The following are not considered communication sessions: 207 o A call between any two user agents wherein two or more user 208 agents are engaged in a conference call via a conference focus 209 o Each call between the user agent and the conference focus 210 would be a communication session 212 o Each communication session is a distinct communication 213 session 215 o A call between three user agents (e.g., Alice, Bob, and Carol) 216 wherein the first user agent (Alice) ad hoc conferences the 217 other two user agents (Bob and Carol) 219 o The call between Alice and Bob would be one communication 220 session 222 o The call between Alice and Carol would be a different 223 communication session 225 3.3. End-to-End 227 The term "end-to-end" in this document means the communication 228 session from the point of origin, passing through any number of 229 intermediaries, to the ultimate point of termination. It is 230 recognized that legacy devices may not support the end-to-end session 231 identifier, though an identifier might be created by an intermediary 232 when it is absent from the session signaling. 234 4. Session Identifier Use Cases 236 4.1. End-to-end identification of a communication session 238 For SIP messaging that either does not involve SIP servers or only 239 involves SIP proxies, the Call-ID header value sufficiently 240 identifies each SIP message within a transaction or dialog. This is 241 not the case when either B2BUAs or SBCs are in the signaling path 242 between UAs. Therefore, we need the ability to identify each 243 communication session through a single SIP header-value regardless of 244 which type of SIP servers are in the signaling path between UAs. For 245 messages that create a dialog, each message within the same dialog 246 MUST use the same session identifier. 248 Derived Requirements: All Requirements in Section 5 250 4.2. Protocol Interworking 252 A communication session might originate in an H.323 endpoint and pass 253 through a Session Border Controller before ultimately reaching a 254 terminating SIP user agent. Likewise, a call might originate on a SIP 255 user agent and terminate on an H.323 endpoint. It MUST be possible to 256 identify such sessions end-to-end across the plurality of devices, 257 networks, or administrative domains. 259 It is expected that the ITU-T will define protocol elements for H.323 260 to make the end-to-end signaling possible. 262 Derived Requirements: REQ5, REQ7 264 4.3. Traffic Monitoring 266 UA A and UA B communicate using SIP messaging with a SIP B2BUA acting 267 as a middlebox which belongs to a SIP service provider. For privacy 268 reasons, the B2BUA changes the SIP headers that reveal information 269 related to the SIP users, device or domain identity. The service 270 provider uses an external device to monitor and log all SIP traffic 271 coming to and from the B2BUA. In the case of failures reported by 272 the customer or when security issue arise (e.g. theft of service), 273 the service provider has to analyze the logs from the past several 274 days or weeks and correlates those messages which were messages for a 275 single end-to-end SIP session. 277 For this scenario, we must consider three particular use cases: 279 a) The UAs A and B support the end-to-end Session Identifier. 281 Derived Requirements: REQ1, REQ3, REQ4, REQ6. 283 b) Only the UA A supports the end-to-end Session Identifier, the UA 284 B does not. 286 Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6. 288 c) UA A and UA B do not support the end-to-end Session Identifier. 290 Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6 292 4.4. Tracking transferred sessions 294 It is difficult to track which SIP messages where involved in the 295 same call across transactions, especially when invoking supplementary 296 services such as call transfer or call join. There exists a need for 297 the ability to track communication sessions as they are transferred, 298 one side at a time, until completion of the session (i.e., until a 299 BYE is sent). 301 Derived Requirements: REQ1, REQ2, REQ9 303 4.5. Session Signal Logging 305 An after-the-fact search of SIP messages to determine which messages 306 were part of the same transaction or call is difficult when B2BUAs 307 and SBCs are involved in the signaling between UAs. Mapping more 308 than one Call-ID together can be challenging because all of the 309 values in SIP headers on one side of the B2BUA or SBC will likely be 310 different than those on the other side. If multiple B2BUAs and/or 311 SBCs are in the signaling path, more than two sets of header values 312 will exist, creating more of a challenge. Creating a common header 313 value through all SIP entities will greatly reduce any challenge for 314 the purposes of debugging, communication tracking (such as for 315 security purposes in case of theft of service), etc. 317 Derived Requirements: REQ1, REQ3, REQ5, REQ6 319 4.6. Identifier Syntax 321 A syntax that is too restrictive (e.g., one that allows special 322 characters or a very long identifier) would make it difficult to 323 encode the identifier in other protocols. Therefore, the syntax of 324 the identifier should be reasonably restrictive. 326 Derived Requirements: REQ8 328 4.7. 3PCC Use Case 330 Third party call control refers to the ability of an entity to create 331 a call in which communication is actually between two or more 332 parties. For example, a B2BUA acting as a third party controller 333 could establish a call between two SIP UA's using 3PCC procedures as 334 described in section 4.1 of RFC 3725 [7], the flow for which is 335 reproduced below. 337 A Controller B 338 |(1) INVITE no SDP | | 339 |<------------------| | 340 |(2) 200 offer1 | | 341 |------------------>| | 342 | |(3) INVITE offer1 | 343 | |------------------>| 344 | |(4) 200 OK answer1 | 345 | |<------------------| 346 | |(5) ACK | 347 | |------------------>| 348 |(6) ACK answer1 | | 349 |<------------------| | 350 |(7) RTP | | 351 |.......................................| 353 Figure 2 - Session-ID 3PCC Scenario 355 Such a flow must result in a single session identifier being used for 356 the communication session between UA A and UA B. This use case does 357 not extend to three SIP UAs. 359 Derived Requirements: REQ9 361 5. Requirements for the End-to-End Session Identifier 363 The following requirements are derived from the use cases and 364 additional constraints regarding the construction of the identifier. 366 REQ1: It must be possible for an administrator or an external device 367 which monitors the SIP-traffic to use the identifier to identify 368 those dialogs, transactions and messages which were at some point in 369 time components of a single end-to-end SIP session (e.g., parts of 370 the same call). 372 REQ2: It must be possible to correlate two end-to-end sessions when a 373 session is transferred or if two different sessions are joined 374 together via an intermediary (e.g., a PBX). 376 REQ3: The solution must require that the identifier, if present, pass 377 unchanged through SIP B2BUAs or other intermediaries. 379 REQ4: The identifier must not reveal any information related to any 380 SIP user, device or domain identity. This includes any IP Address, 381 port, hostname, domain name, username, Address-of-Record, MAC 382 address, IP address family, transport type, subscriber ID, Call-ID, 383 tags, or other SIP header or body parts. 385 REQ5: It must be possible to identity SIP traffic with an end-to-end 386 session identifier from and to end devices that do not support this 387 new identifier, such as by allowing an intermediary to inject an 388 identifier into the session signaling. 390 REQ6: The identifier should be unique in time and space, similar to 391 the Call-ID. 393 REQ7: The identifier should be constructed in such a way as to make 394 it suitable for transmission in SIP and H.323. 396 REQ8: The identifier should use a restricted syntax and length so as 397 to allow the identifier to be used in other protocols. 399 REQ9: It must be possible to correlate two end-to-end sessions when 400 the sessions are created by a third party controller using 3PCC 401 procedures shown in Figure 1 of RFC 3725 [7]. 403 6. Related Work in other Standards Organizations 405 6.1. Coordination with the ITU-T 407 IP multimedia networks are often comprised of a mix of session 408 protocols like SIP and H.323. A benefit of the Session Identifier is 409 that it uniquely identifies a communication session end-to-end across 410 session protocol boundaries. Therefore, the need for coordinated 411 standardization activities across Standards Development Organizations 412 (SDOs) is imperative. 414 To facilitate this, a parallel effort is underway in the ITU-T to 415 introduce the Session Identifier for the H.323 protocol. The ITU-T 416 SG16 has approved contribution C.552 [5] as a work item with the 417 intent that it be a coordinated and synchronized effort between the 418 ITU-T and the IETF. 420 6.2. Requirements within 3GPP 422 3GPP identified in their Release 9 the need for a Session Identifier 423 for O&M purposes to correlate flows in an end-to-end communication 424 session. TS24.229 (IP multimedia call control protocol based on 425 Session Initiation Protocol (SIP) and Session Description Protocol 426 (SDP)) [6] points to the fact that the Session Identifier can be used 427 to correlate SIP messages belonging to the same session. In the case 428 where signaling passes through SIP entities like B2BUAs, the end-to- 429 end session identifier indicates that these dialogs belong to the 430 same end-to-end SIP communication session. 432 7. Security Considerations 434 The security vulnerabilities, attacks, and threat models affecting 435 other similar SIP identifiers are well documented in RFC 3261 and are 436 equally applicable to the end-to-end session identifier and subject 437 to the same mitigating security best practices. 439 An end-to-end identifier, if not properly constructed, could provide 440 confidential information that would allow one to identify the 441 individual, device, or domain initiating or terminating a 442 communication session. In adherence with REQ4, the solution produced 443 in accordance with these requirements MUST take appropriate measures 444 to properly secure and obfuscate sensitive or private information 445 that might allow one to identify a person, device, or domain. This 446 means that information elements such as the MAC address or IP address 447 MUST NOT be used when constructing the end-to-end session identifier. 448 It is outside the scope of this document to specify the 449 implementation details of such security and privacy measures. Those 450 details may vary with the specific construction mechanism selected 451 for the end-to-end session identifier and, therefore, will be 452 discussed in suitable detail in the solution document specifying the 453 actual end-to-end identifier. 455 A key security consideration is to ensure that an attacker cannot 456 surreptitiously spoof the identifier and effectively render it 457 useless to diagnostic equipment that cannot properly correlate 458 signaling messages due to the duplicate session identifiers that 459 exist in the same space and time. In accordance with REQ6, this end- 460 to-end identifier MUST be sufficiently long and random to prevent it 461 from being guessable as well as avoid collision with another 462 identifier. There should also be sufficient verification by any 463 application utilizing the end-to-end session identifier to ensure its 464 integrity. The secure transport of the identifier, need for 465 authentication, encryption, etc. should be appropriately evaluated 466 based on the network infrastructure, transport domain and usage 467 scenarios for the end-to-end session identifier. 469 8. IANA Considerations 471 There are no IANA considerations associated with this document. 473 9. Acknowledgments 475 The authors would like to acknowledge Paul Kyzivat, Christer 476 Holmberg, Charles Eckel, Andy Hutton, Salvatore Loreto, Keith Drage, 477 Chris Pearce for their contribution and collaboration in developing 478 this document. 480 This document was prepared using 2-Word-v2.0.template.dot. 482 10. Contributors 484 Two other people originally participated as co-authors and provided 485 substantial contributions to this document, namely Roland Jesske, 486 Parthasarathi Ravindran. 488 11. References 490 11.1. Normative References 492 [1] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 493 3261, June 2002. 495 [2] Recommendation ITU-T H.323, "Packet-based multimedia 496 communications systems", December 2009. 498 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 499 Levels", BCP 14, RFC 2119, March 1997. 501 11.2. Informative References 503 [4] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real- 504 Time Applications", RFC 3550, July 2003. 506 [5] International Telecommunications Union, "End-to-End Session 507 Identifier for IP-based Multimedia Communication Systems", 508 March 2011, ITU-T Contribution C.552, http://ftp3.itu.int/av- 509 arch/avc-site/2009-2012/1103_Gen/SessionID.zip. 511 [6] 3GPP, "IP multimedia call control protocol based on Session 512 Initiation Protocol (SIP) and Session Description Protocol 513 (SDP); Stage 3", 3GPP TS 24.229 10.3.0, April 2011. 515 [7] Rosenberg, J., Peterson, J., Schulzrinne, H., Camarillo, G., 516 "Best Current Practices for Third Party Call Control (3pcc) in 517 the Session Initiation Protocol (SIP)", RFC 3725, April 2004. 519 Author's Addresses 521 Paul E. Jones 522 Cisco Systems, Inc. 523 7025 Kit Creek Rd. 524 Research Triangle Park, NC 27709 525 USA 527 Phone: +1 919 476 2048 528 Email: paulej@packetizer.com 529 IM: xmpp:paulej@packetizer.com 531 Hadriel Kaplan 532 Acme Packet 533 71 Third Ave. 534 Burlington, MA 01803, USA 536 Email: hkaplan@acmepacket.com 538 Laura Liess 539 Deutsche Telekom NP 540 64295 Darmstadt 541 Heinrich-Hertz-Str. 3-7 542 Germany 544 Phone: +49 6151 268 2761 545 Email: laura.liess.dt@gmail.com 547 James Polk 548 Cisco Systems, Inc. 549 3913 Treemont Circle 550 Colleyville, Texas, 551 USA 553 Phone: +1 817 271 3552 554 Email: jmpolk@cisco.com 555 IM: xmpp:jmpolk@cisco.com 557 Gonzalo Salgueiro 558 Cisco Systems, Inc. 559 7025 Kit Creek Rd. 560 Research Triangle Park, NC 27709 561 USA 563 Phone: +1 919 392 3266 564 Email: gsalguei@cisco.com 565 IM: xmpp:gsalguei@cisco.com