idnits 2.17.1 draft-ietf-insipid-session-id-reqts-08.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 (July 29, 2013) is 3923 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: January 29, 2014 Cisco Systems 6 Laura Liess 7 Deutsche Telekom 8 Hadriel Kaplan 9 Oracle 10 July 29, 2013 12 Requirements for an End-to-End Session Identification in 13 IP-Based Multimedia Communication Networks 14 draft-ietf-insipid-session-id-reqts-08.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 January 29, 2014. 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.............8 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 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 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 [4], 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) [7] 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 a REFER request or a re-INVITE 204 request 206 The following are not considered communication sessions: 208 o A call between any two user agents wherein two or more user 209 agents are engaged in a conference call via a conference focus 211 o Each call between the user agent and the conference focus 212 would be a communication session 214 o Each communication session is a distinct communication 215 session 217 o A call between three user agents (e.g., Alice, Bob, and Carol) 218 wherein the first user agent (Alice) ad hoc conferences the 219 other two user agents (Bob and Carol) 221 o The call between Alice and Bob would be one communication 222 session 224 o The call between Alice and Carol would be a different 225 communication session 227 3.3. End-to-End 229 The term "end-to-end" in this document means the communication 230 session from the point of origin, passing through any number of 231 intermediaries, to the ultimate point of termination. It is 232 recognized that legacy devices may not support the end-to-end session 233 identifier, though an identifier might be created by an intermediary 234 when it is absent from the session signaling. 236 4. Session Identifier Use Cases 238 4.1. End-to-end identification of a communication session 240 For SIP messaging that either does not involve SIP servers or only 241 involves SIP proxies, the Call-ID header field value sufficiently 242 identifies each SIP message within a transaction or dialog. This is 243 not the case when either B2BUAs or SBCs are in the signaling path 244 between UAs. Therefore, we need the ability to identify each 245 communication session through a single SIP header field regardless of 246 which type of SIP servers are in the signaling path between UAs. For 247 messages that create a dialog, each message within the same dialog 248 MUST use the same session identifier. 250 Derived Requirements: All Requirements in Section 5 252 4.2. Protocol Interworking 254 A communication session might originate in an H.323 [2] endpoint and 255 pass through a Session Border Controller before ultimately reaching a 256 terminating SIP user agent. Likewise, a call might originate on a SIP 257 user agent and terminate on an H.323 endpoint. It MUST be possible to 258 identify such sessions end-to-end across the plurality of devices, 259 networks, or administrative domains. 261 It is expected that the ITU-T will define protocol elements for H.323 262 to make the end-to-end signaling possible. 264 Derived Requirements: REQ5, REQ7 266 4.3. Traffic Monitoring 268 UA A and UA B communicate using SIP messaging with a SIP B2BUA acting 269 as a middlebox which belongs to a SIP service provider. For privacy 270 reasons, the B2BUA changes the SIP header fields that reveal 271 information related to the SIP users, device or domain identity. The 272 service provider uses an external device to monitor and log all SIP 273 traffic coming to and from the B2BUA. In the case of failures 274 reported by the customer or when security issue arise (e.g. theft of 275 service), the service provider has to analyze the logs from the past 276 several days or weeks and correlates those messages which were 277 messages for a single end-to-end SIP session. 279 For this scenario, we must consider three particular use cases: 281 a) The UAs A and B support the end-to-end Session Identifier. 283 Derived Requirements: REQ1, REQ3, REQ4, REQ6. 285 b) Only the UA A supports the end-to-end Session Identifier, the UA 286 B does not. 288 Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6. 290 c) UA A and UA B do not support the end-to-end Session Identifier. 292 Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6 294 4.4. Tracking transferred sessions 296 It is difficult to track which SIP messages where involved in the 297 same call across transactions, especially when invoking supplementary 298 services such as call transfer or call join. There exists a need for 299 the ability to track communication sessions as they are transferred, 300 one side at a time, until completion of the session (i.e., until a 301 BYE is sent). 303 Derived Requirements: REQ1, REQ2, REQ9 305 4.5. Session Signal Logging 307 An after-the-fact search of SIP messages to determine which messages 308 were part of the same transaction or call is difficult when B2BUAs 309 and SBCs are involved in the signaling between UAs. Mapping more 310 than one Call-ID together can be challenging because all of the 311 values in SIP header fields on one side of the B2BUA or SBC will 312 likely be different than those on the other side. If multiple B2BUAs 313 and/or SBCs are in the signaling path, more than two sets of header 314 field values will exist, creating more of a challenge. Creating a 315 common header field value through all SIP entities will greatly 316 reduce any challenge for the purposes of debugging, communication 317 tracking (such as for security purposes in case of theft of service), 318 etc. 320 Derived Requirements: REQ1, REQ3, REQ5, REQ6 322 4.6. Identifier Syntax 324 A syntax that is too restrictive (e.g., one that allows special 325 characters or a very long identifier) would make it difficult to 326 encode the identifier in other protocols. Therefore, the syntax of 327 the identifier should be reasonably restrictive. 329 Derived Requirements: REQ8 331 4.7. 3PCC Use Case 333 Third party call control refers to the ability of an entity to create 334 a call in which communication is actually between two or more 335 parties. For example, a B2BUA acting as a third party controller 336 could establish a call between two SIP UA's using 3PCC procedures as 337 described in section 4.1 of RFC 3725 [7], the flow for which is 338 reproduced below. 340 A Controller B 341 |(1) INVITE no SDP | | 342 |<------------------| | 343 |(2) 200 offer1 | | 344 |------------------>| | 345 | |(3) INVITE offer1 | 346 | |------------------>| 347 | |(4) 200 OK answer1 | 348 | |<------------------| 349 | |(5) ACK | 350 | |------------------>| 351 |(6) ACK answer1 | | 352 |<------------------| | 353 |(7) RTP | | 354 |.......................................| 356 Figure 2 - Session-ID 3PCC Scenario 358 Such a flow must result in a single session identifier being used for 359 the communication session between UA A and UA B. This use case does 360 not extend to three SIP UAs. 362 Derived Requirements: REQ9 364 5. Requirements for the End-to-End Session Identifier 366 The following requirements are derived from the use cases and 367 additional constraints regarding the construction of the identifier. 369 REQ1: It must be possible for an administrator or an external device 370 which monitors the SIP-traffic to use the identifier to identify 371 those dialogs, transactions and messages which were at some point in 372 time components of a single end-to-end SIP session (e.g., parts of 373 the same call). 375 REQ2: It must be possible to correlate two end-to-end sessions when a 376 session is transferred or if two different sessions are joined 377 together via an intermediary (e.g., a PBX). 379 REQ3: The solution must require that the identifier, if present, pass 380 unchanged through SIP B2BUAs or other intermediaries. 382 REQ4: The identifier must not reveal any information related to any 383 SIP user, device or domain identity. This includes any IP Address, 384 port, hostname, domain name, username, Address-of-Record, MAC 385 address, IP address family, transport type, subscriber ID, Call-ID, 386 tags, or other SIP header field or body parts. 388 REQ5: It must be possible to identity SIP traffic with an end-to-end 389 session identifier from and to end devices that do not support this 390 new identifier, such as by allowing an intermediary to inject an 391 identifier into the session signaling. 393 REQ6: The identifier should be unique in time and space, similar to 394 the Call-ID. 396 REQ7: The identifier should be constructed in such a way as to make 397 it suitable for transmission in SIP [1] and H.323 [2]. 399 REQ8: The identifier should use a restricted syntax and length so as 400 to allow the identifier to be used in other protocols. 402 REQ9: It must be possible to correlate two end-to-end sessions when 403 the sessions are created by a third party controller using 3PCC 404 procedures shown in Figure 1 of RFC 3725 [7]. 406 6. Related Work in other Standards Organizations 408 6.1. Coordination with the ITU-T 410 IP multimedia networks are often comprised of a mix of session 411 protocols like SIP [1] and H.323 [2]. A benefit of the Session 412 Identifier is that it uniquely identifies a communication session 413 end-to-end across session protocol boundaries. Therefore, the need 414 for coordinated standardization activities across Standards 415 Development Organizations (SDOs) is imperative. 417 To facilitate this, a parallel effort is underway in the ITU-T to 418 introduce the Session Identifier for H.323. The ITU-T SG16 has 419 approved contribution C.552 [5] as a work item with the intent that 420 it be a coordinated and synchronized effort between the ITU-T and the 421 IETF. 423 6.2. Requirements within 3GPP 425 3GPP identified in their Release 9 the need for a Session Identifier 426 for operation and maintenance purposes to correlate flows in an end- 427 to-end communication session. 3GPP TS24.229 [6] points to the fact 428 that the Session Identifier can be used to correlate SIP messages 429 belonging to the same session. In the case where signaling passes 430 through SIP entities like B2BUAs, the end-to-end session identifier 431 indicates that these dialogs belong to the same end-to-end SIP 432 communication session. 434 7. Security Considerations 436 The security vulnerabilities, attacks, and threat models affecting 437 other similar SIP identifiers are well documented in RFC 3261 and are 438 equally applicable to the end-to-end session identifier and subject 439 to the same mitigating security best practices. 441 An end-to-end identifier, if not properly constructed, could provide 442 confidential information that would allow one to identify the 443 individual, device, or domain initiating or terminating a 444 communication session. In adherence with REQ4, the solution produced 445 in accordance with these requirements MUST take appropriate measures 446 to properly secure and obfuscate sensitive or private information 447 that might allow one to identify a person, device, or domain. This 448 means that information elements such as the MAC address or IP address 449 MUST NOT be used when constructing the end-to-end session identifier. 450 It is outside the scope of this document to specify the 451 implementation details of such security and privacy measures. Those 452 details may vary with the specific construction mechanism selected 453 for the end-to-end session identifier and, therefore, will be 454 discussed in suitable detail in the solution document specifying the 455 actual end-to-end identifier. 457 A key security consideration is to ensure that an attacker cannot 458 surreptitiously spoof the identifier and effectively render it 459 useless to diagnostic equipment that cannot properly correlate 460 signaling messages due to the duplicate session identifiers that 461 exist in the same space and time. In accordance with REQ6, this end- 462 to-end identifier MUST be sufficiently long and random to prevent it 463 from being guessable as well as avoid collision with another 464 identifier. There should also be sufficient verification by any 465 application using the end-to-end session identifier to ensure its 466 integrity. The secure transport of the identifier, need for 467 authentication, encryption, etc. should be appropriately evaluated 468 based on the network infrastructure, transport domain and usage 469 scenarios for the end-to-end session identifier. 471 8. IANA Considerations 473 There are no IANA considerations associated with this document. 475 9. Acknowledgments 477 The authors would like to acknowledge Paul Kyzivat, Christer 478 Holmberg, Charles Eckel, Andy Hutton, Salvatore Loreto, Keith Drage, 479 Chris Pearce for their contribution and collaboration in developing 480 this document. 482 This document was prepared using 2-Word-v2.0.template.dot. 484 10. Contributors 486 Two other people originally participated as co-authors and provided 487 substantial contributions to this document, namely Roland Jesske, 488 Parthasarathi Ravindran. 490 11. References 492 11.1. Normative References 494 [1] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 495 3261, June 2002. 497 [2] Recommendation ITU-T H.323, "Packet-based multimedia 498 communications systems", December 2009. 500 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 501 Levels", BCP 14, RFC 2119, March 1997. 503 11.2. Informative References 505 [4] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real- 506 Time Applications", RFC 3550, July 2003. 508 [5] International Telecommunications Union, "End-to-End Session 509 Identifier for IP-based Multimedia Communication Systems", 510 March 2011, ITU-T Contribution C.552, http://ftp3.itu.int/av- 511 arch/avc-site/2009-2012/1103_Gen/SessionID.zip. 513 [6] 3GPP TS 24.229, "IP multimedia call control protocol based on 514 Session Initiation Protocol (SIP) and Session Description 515 Protocol (SDP); Stage 3". 517 [7] Rosenberg, J., Peterson, J., Schulzrinne, H., Camarillo, G., 518 "Best Current Practices for Third Party Call Control (3pcc) in 519 the Session Initiation Protocol (SIP)", RFC 3725, April 2004. 521 Author's Addresses 523 Paul E. Jones 524 Cisco Systems, Inc. 525 7025 Kit Creek Rd. 526 Research Triangle Park, NC 27709 527 USA 529 Phone: +1 919 476 2048 530 Email: paulej@packetizer.com 531 IM: xmpp:paulej@packetizer.com 533 Hadriel Kaplan 534 Oracle 535 71 Third Ave. 536 Burlington, MA 01803, USA 538 Email: hadriel.kaplan@oracle.com 540 Laura Liess 541 Deutsche Telekom NP 542 64295 Darmstadt 543 Heinrich-Hertz-Str. 3-7 544 Germany 546 Phone: +49 6151 268 2761 547 Email: laura.liess.dt@gmail.com 549 James Polk 550 Cisco Systems, Inc. 551 3913 Treemont Circle 552 Colleyville, Texas, 553 USA 555 Phone: +1 817 271 3552 556 Email: jmpolk@cisco.com 557 IM: xmpp:jmpolk@cisco.com 559 Gonzalo Salgueiro 560 Cisco Systems, Inc. 561 7025 Kit Creek Rd. 562 Research Triangle Park, NC 27709 563 USA 565 Phone: +1 919 392 3266 566 Email: gsalguei@cisco.com 567 IM: xmpp:gsalguei@cisco.com