idnits 2.17.1 draft-ietf-insipid-session-id-reqts-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 4, 2013) is 3825 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: May 4, 2014 Cisco Systems 6 Laura Liess 7 Deutsche Telekom 8 Hadriel Kaplan 9 Oracle 10 November 4, 2013 12 Requirements for an End-to-End Session Identification in 13 IP-Based Multimedia Communication Networks 14 draft-ietf-insipid-session-id-reqts-09.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 May 4, 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 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 by 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) [7] 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, though an identifier might be created by an intermediary 240 when it is absent from the session signaling. 242 4. Session Identifier Use Cases 244 4.1. End-to-end identification of a communication session 246 For SIP messaging that either does not involve SIP servers or only 247 involves SIP proxies, the Call-ID header field value sufficiently 248 identifies each SIP message within a transaction (see Section 17 of 249 [1]) or dialog (see Section 12 of [1]). This is not the case when 250 either B2BUAs or Session Border Controllers (SBCs) [8] are in the 251 signaling path between User Agents (UAs). Therefore, we need the 252 ability to identify each communication session through a single SIP 253 header field regardless of which type of SIP servers are in the 254 signaling path between UAs. For messages that create a dialog, each 255 message within the same dialog MUST use the same session identifier. 257 Derived Requirements: All Requirements in Section 5 259 4.2. Protocol Interworking 261 A communication session might originate in an H.323 [2] endpoint and 262 pass through an SBC before ultimately reaching a terminating SIP user 263 agent. Likewise, a call might originate on a SIP user agent and 264 terminate on an H.323 endpoint. It MUST be possible to identify such 265 sessions end-to-end across the plurality of devices, networks, or 266 administrative domains. 268 It is expected that the ITU-T will define protocol elements for H.323 269 to make the end-to-end signaling possible. 271 Derived Requirements: REQ5, REQ7 273 4.3. Traffic Monitoring 275 UA A and UA B communicate using SIP messaging with a SIP B2BUA acting 276 as a middlebox which belongs to a SIP service provider. For privacy 277 reasons, the B2BUA changes the SIP header fields that reveal 278 information related to the SIP users, device or domain identities. 279 The service provider uses an external device to monitor and log all 280 SIP traffic coming to and from the B2BUA. In the case of failures 281 reported by the customer or when security issues arise (e.g. theft of 282 service), the service provider has to analyze the logs from the past 283 several days or weeks and correlates those messages which were 284 messages for a single end-to-end SIP session. 286 For this scenario, we must consider three particular use cases: 288 a) The UAs A and B support the end-to-end session identifier. 290 Derived Requirements: REQ1, REQ3, REQ4, REQ6. 292 b) Only the UA A supports the end-to-end session identifier, the UA 293 B does not. 295 Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6. 297 c) UA A and UA B do not support the end-to-end session identifier. 299 Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6 301 4.4. Tracking transferred sessions 303 It is difficult to track which SIP messages where involved in the 304 same call across transactions, especially when invoking supplementary 305 services such as call transfer or call join. There exists a need for 306 the ability to track communication sessions as they are transferred, 307 one side at a time, until completion of the session (i.e., until a 308 BYE is sent). 310 Derived Requirements: REQ1, REQ2, REQ9 312 4.5. Session Signal Logging 314 An after-the-fact search of SIP messages to determine which messages 315 were part of the same transaction or call is difficult when B2BUAs 316 and SBCs are involved in the signaling between UAs. Mapping more 317 than one Call-ID together can be challenging because all of the 318 values in SIP header fields on one side of the B2BUA or SBC will 319 likely be different than those on the other side. If multiple B2BUAs 320 and/or SBCs are in the signaling path, more than two sets of header 321 field values will exist, creating more of a challenge. Creating a 322 common header field value through all SIP entities will greatly 323 reduce any challenge for the purposes of debugging, communication 324 tracking (such as for security purposes in case of theft of service), 325 etc. 327 Derived Requirements: REQ1, REQ3, REQ5, REQ6 329 4.6. Identifier Syntax 331 A syntax that is too restrictive (e.g., one that allows special 332 characters or a very long identifier) would make it difficult to 333 encode the identifier in other protocols. Therefore, the syntax of 334 the identifier should be reasonably restrictive. 336 Derived Requirements: REQ8 338 4.7. 3PCC Use Case 340 Third party call control refers to the ability of an entity to create 341 a call in which communication is actually between two or more parties 342 other than the one setting up the call. For example, a B2BUA acting 343 as a third party controller could establish a call between two SIP 344 UA's using 3PCC procedures as described in section 4.1 of RFC 3725 345 [7], the flow for which is reproduced below. 347 A Controller B 348 |(1) INVITE no SDP | | 349 |<------------------| | 350 |(2) 200 offer1 | | 351 |------------------>| | 352 | |(3) INVITE offer1 | 353 | |------------------>| 354 | |(4) 200 OK answer1 | 355 | |<------------------| 356 | |(5) ACK | 357 | |------------------>| 358 |(6) ACK answer1 | | 359 |<------------------| | 360 |(7) RTP | | 361 |.......................................| 363 Figure 2 - Session Identifier 3PCC Scenario 365 Such a flow must result in a single session identifier being used for 366 the communication session between UA A and UA B. This use case does 367 not extend to three SIP UAs. 369 Derived Requirements: REQ9 371 5. Requirements for the End-to-End Session Identifier 373 The following requirements are derived from the use cases and 374 additional constraints regarding the construction of the identifier. 376 REQ1: It must be possible for an administrator or an external device 377 which monitors the SIP-traffic to use the identifier to identify 378 those dialogs, transactions and messages which were at some point in 379 time components of a single end-to-end SIP session (e.g., parts of 380 the same call). 382 REQ2: It must be possible to correlate two end-to-end sessions when a 383 session is transferred or if two different sessions are joined 384 together via an intermediary (e.g., a PBX). 386 REQ3: The solution must require that the identifier, if present, pass 387 unchanged through SIP B2BUAs or other intermediaries. 389 REQ4: The identifier must not reveal any information related to any 390 SIP user, device or domain identity. This includes any IP Address, 391 port, hostname, domain name, username, Address-of-Record, MAC 392 address, IP address family, transport type, subscriber ID, Call-ID, 393 tags, or other SIP header field or body parts. 395 REQ5: It must be possible to identity SIP traffic with an end-to-end 396 session identifier from and to end devices that do not support this 397 new identifier, such as by allowing an intermediary to inject an 398 identifier into the session signaling. 400 REQ6: The identifier should be unique in time and space, similar to 401 the Call-ID. 403 REQ7: The identifier should be constructed in such a way as to make 404 it suitable for transmission in SIP [1] and H.323 [2]. 406 REQ8: The identifier should use a restricted syntax and length so as 407 to allow the identifier to be used in other protocols. 409 REQ9: It must be possible to correlate two end-to-end sessions when 410 the sessions are created by a third party controller using 3PCC 411 procedures shown in Figure 1 of RFC 3725 [7]. 413 6. Related Work in other Standards Organizations 415 6.1. Coordination with the ITU-T 417 IP multimedia networks are often comprised of a mix of session 418 protocols like SIP [1] and H.323 [2]. A benefit of the session 419 identifier is that it uniquely identifies a communication session 420 end-to-end across session protocol boundaries. Therefore, the need 421 for coordinated standardization activities across Standards 422 Development Organizations (SDOs) is imperative. 424 To facilitate this, a parallel effort is underway in the ITU-T to 425 introduce the session identifier for H.323. The ITU-T SG16 has 426 approved contribution C.552 [5] as a work item with the intent that 427 it be a coordinated and synchronized effort between the ITU-T and the 428 IETF. 430 6.2. Requirements within 3GPP 432 3GPP identified in their Release 9 the need for a session identifier 433 for operation and maintenance purposes to correlate flows in an end- 434 to-end communication session. 3GPP TS24.229 [6] points to the fact 435 that the session identifier can be used to correlate SIP messages 436 belonging to the same session. In the case where signaling passes 437 through SIP entities like B2BUAs, the end-to-end session identifier 438 indicates that these dialogs belong to the same end-to-end SIP 439 communication session. 441 7. Security Considerations 443 The security vulnerabilities, attacks, and threat models affecting 444 other similar SIP identifiers are well documented in RFC 3261 and are 445 equally applicable to the end-to-end session identifier and subject 446 to the same mitigating security best practices. 448 An end-to-end identifier, if not properly constructed, could provide 449 confidential information that would allow one to identify the 450 individual, device, or domain initiating or terminating a 451 communication session. In adhering to REQ4, the solution produced in 452 accordance with these requirements MUST take appropriate measures to 453 properly secure and obfuscate sensitive or private information that 454 might allow one to identify a person, device, or domain. This means 455 that information elements such as the MAC address or IP address MUST 456 NOT be used when constructing the end-to-end session identifier. It 457 is outside the scope of this document to specify the implementation 458 details of such security and privacy measures. Those details may 459 vary with the specific construction mechanism selected for the end- 460 to-end session identifier and, therefore, will be discussed in 461 suitable detail in the solution document specifying the actual end- 462 to-end identifier. 464 A key security consideration is to ensure that an attacker cannot 465 surreptitiously spoof the identifier and effectively render it 466 useless to diagnostic equipment that cannot properly correlate 467 signaling messages due to the duplicate session identifiers that 468 exist in the same space and time. In accordance with REQ6, this end- 469 to-end identifier MUST be sufficiently long and random to prevent it 470 from being guessable as well as avoid collision with another 471 identifier. There should also be sufficient verification by any 472 application using the end-to-end session identifier to ensure its 473 integrity. The secure transport of the identifier, need for 474 authentication, encryption, etc. should be appropriately evaluated 475 based on the network infrastructure, transport domain and usage 476 scenarios for the end-to-end session identifier. 478 8. IANA Considerations 480 There are no IANA considerations associated with this document. 482 9. Acknowledgments 484 The authors would like to acknowledge Paul Kyzivat, Christer 485 Holmberg, Charles Eckel, Andy Hutton, Salvatore Loreto, Keith Drage, 486 Chris Pearce for their contribution and collaboration in developing 487 this document. 489 This document was prepared using 2-Word-v2.0.template.dot. 491 10. Contributors 493 Two other people originally participated as co-authors and provided 494 substantial contributions to this document, namely Roland Jesske, 495 Parthasarathi Ravindran. 497 11. References 499 11.1. Normative References 501 [1] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 502 3261, June 2002. 504 [2] Recommendation ITU-T H.323, "Packet-based multimedia 505 communications systems", December 2009. 507 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 508 Levels", BCP 14, RFC 2119, March 1997. 510 11.2. Informative References 512 [4] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real- 513 Time Applications", RFC 3550, July 2003. 515 [5] International Telecommunications Union, "End-to-End Session 516 Identifier for IP-based Multimedia Communication Systems", 517 March 2011, ITU-T Contribution C.552, http://ftp3.itu.int/av- 518 arch/avc-site/2009-2012/1103_Gen/SessionID.zip. 520 [6] 3GPP TS 24.229, "IP multimedia call control protocol based on 521 Session Initiation Protocol (SIP) and Session Description 522 Protocol (SDP); Stage 3". 524 [7] Rosenberg, J., Peterson, J., Schulzrinne, H., Camarillo, G., 525 "Best Current Practices for Third Party Call Control (3pcc) in 526 the Session Initiation Protocol (SIP)", RFC 3725, April 2004. 528 [8] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., 529 and M. Bhatia, "Requirements from Session Initiation Protocol 530 (SIP) Session Border Control (SBC) Deployments", RFC 5853, 531 April 2010. 533 Author's Addresses 535 Paul E. Jones 536 Cisco Systems, Inc. 537 7025 Kit Creek Rd. 538 Research Triangle Park, NC 27709 539 USA 541 Phone: +1 919 476 2048 542 Email: paulej@packetizer.com 543 IM: xmpp:paulej@packetizer.com 545 Hadriel Kaplan 546 Oracle 547 71 Third Ave. 548 Burlington, MA 01803, USA 550 Email: hadriel.kaplan@oracle.com 552 Laura Liess 553 Deutsche Telekom NP 554 64295 Darmstadt 555 Heinrich-Hertz-Str. 3-7 556 Germany 558 Phone: +49 6151 268 2761 559 Email: laura.liess.dt@gmail.com 561 James Polk 562 Cisco Systems, Inc. 563 3913 Treemont Circle 564 Colleyville, Texas, 565 USA 567 Phone: +1 817 271 3552 568 Email: jmpolk@cisco.com 569 IM: xmpp:jmpolk@cisco.com 571 Gonzalo Salgueiro 572 Cisco Systems, Inc. 573 7025 Kit Creek Rd. 574 Research Triangle Park, NC 27709 575 USA 577 Phone: +1 919 392 3266 578 Email: gsalguei@cisco.com 579 IM: xmpp:gsalguei@cisco.com