idnits 2.17.1 draft-ietf-insipid-session-id-reqts-05.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 25, 2013) is 4070 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '4' is defined on line 436, 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: August 25, 2013 Cisco Systems 6 Laura Liess 7 Deutsche Telekom 8 Hadriel Kaplan 9 Acme Packet 10 February 25, 2013 12 Requirements for an End-to-End Session Identification in 13 IP-Based Multimedia Communication Networks 14 draft-ietf-insipid-session-id-reqts-05.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 25, 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 4. Session Identifier Use Cases...................................5 62 4.1. End-to-end identification of a communication session......5 63 4.2. Protocol Interworking.....................................5 64 4.3. Traffic Monitoring........................................5 65 4.4. Tracking transferred sessions.............................6 66 4.5. Session Signal Logging....................................6 67 4.6. Identifier Syntax.........................................6 68 4.7. 3PCC Use Case.............................................6 69 5. Requirements for the End-to-End Session Identifier.............7 70 6. Related Work in other Standards Organizations..................8 71 6.1. Coordination with the ITU-T...............................8 72 6.2. Requirements within 3GPP..................................8 73 7. Security Considerations........................................9 74 8. IANA Considerations............................................9 75 9. Acknowledgments................................................9 76 10. Contributors..................................................9 77 11. References....................................................9 78 11.1. Normative References.....................................9 79 11.2. Informative References..................................10 80 Author's Addresses...............................................11 82 1. Introduction 84 IP-based multimedia communication systems like SIP [1] and H.323 [2] 85 have the concept of a "call identifier" that is globally unique. The 86 identifier is intended to represents an end-to-end communication 87 session from the originating device to the terminating device. Such 88 an identifier is useful for troubleshooting, session tracking, and so 89 forth. 91 Unfortunately, there are a number of factors that contribute to the 92 fact that the current call identifiers defined in SIP and H.323 are 93 not suitable for end-to-end session identification. Perhaps most 94 significant is the fact that the syntax for the call identifier in 95 SIP and H.323 is different between the two protocols. This important 96 fact makes it impossible for call identifiers to be exchanged end-to- 97 end when a network utilizes one or more session protocols. 99 Another reason why the current call identifiers are not suitable to 100 identify the session end-to-end is that in real-world deployments 101 devices like Back-to-Back User Agents often change the values as the 102 session signaling passes through. This is true even when a single 103 session protocol is employed and not a byproduct of protocol 104 interworking. 106 Lastly, identifiers that might have been used to identify a session 107 end-to-end fail to meet that need when sessions are manipulated 108 through supplementary service interactions. For example, when a 109 session is transferred or if a PBX joins or merges two communication 110 sessions together locally, the end-to-end properties of currently- 111 defined identifiers are lost. 113 2. Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [3] when they 118 appear in ALL CAPS. These words may also appear in this document in 119 lower case as plain English words, absent their normative meanings. 121 3. Terminology 123 SIP defines additional terms used in this document that are specific 124 to the SIP domain such as "proxy"; "registrar"; "redirect server"; 125 "user agent server" or "UAS"; "user agent client" or "UAC"; "user 126 agent" (UA); "back-to-back user agent" or "B2BUA"; "dialog"; 127 "transaction"; "server transaction". 129 In this document, the word "session" refers to a "communication 130 session" that may exist between two SIP user agents and that may pass 131 through one or more intermediary devices, including B2BUAs or SIP 132 proxies. A communication session consists of one of more SIP 133 transactions. A very simple communication session may be a single 134 out-of-dialog SIP transaction (e.g., MESSAGE/200). In the case of a 135 SIP dialog, the SIP message exchange includes a dialog creating 136 INVITE transaction, and zero of more subsequent SIP transactions 137 within the same dialog (e.g., ACK, re-INVITE, BYE). Due to the 138 existence of middle boxes, there may be multiple related SIP 139 transactions or dialogs chained together along the path from one end 140 of the communication session to the other. For example: 142 A Middlebox B 143 SIP trans1 -----------------> SIP trans 2 144 SIP dialog 1 <-------------- SIP dialog 2 146 Figure 1 - Communication Session through a Middlebox 148 In such cases, the two SIP transactions or dialogs are part of a 149 single communication session. To be clear, the following are 150 examples of acceptable communication sessions: 152 o A call directly between two user agents 154 o A call between two user agents with one or more SBCs in the 155 signaling path 157 o A call between two user agents that was initiated using third- 158 party call control (3PCC) 160 o A call between two user agents (e.g., Alice and Carol) that 161 results from a different communication session (e.g., Alice and 162 Bob) wherein one of those user agents (Alice) is transferred to 163 another user agent (Carol) using REFER or re-INVITE 165 The following are not considered communication sessions: 167 o A call between any two user agents wherein two or more user 168 agents are engaged in a conference call via a conference focus 170 o Each call between the user agent and the conference focus 171 would be a communication session 173 o Each communication session is a distinct communication 174 session 176 o A call between three user agents (e.g., Alice, Bob, and Carol) 177 wherein the first user agent (Alice) ad hoc conferences the 178 other two user agents (Bob and Carol) 180 o The call between Alice and Bob would be one communication 181 session 183 o The call between Alice and Carol would be a different 184 communication session 186 The term "end-to-end" in this document means the communication 187 session from the point of origin, passing through any number of 188 intermediaries, to the ultimate point of termination. It is 189 recognized that legacy devices may not support the "end-to-end" 190 session identifier, though an identifier might be created by an 191 intermediary when it is absent from the session signaling. 193 4. Session Identifier Use Cases 195 4.1. End-to-end identification of a communication session 197 For SIP messaging that either does not involve SIP servers or only 198 involves SIP proxies, the Call-ID header value sufficiently 199 identifies each SIP message within a transaction or dialog. This is 200 not the case when either B2BUAs or SBCs are in the signaling path 201 between UAs. Therefore, we need the ability to identify each 202 communication session through a single SIP header-value regardless of 203 which type of SIP servers are in the signaling path between UAs. For 204 transactions that create a dialog, each message within the same 205 dialog MUST use the same identifier. 207 Derived Requirements: All Requirements in Section 4 209 4.2. Protocol Interworking 211 A communication session might originate in an H.323 endpoint and pass 212 through a Session Border Controller before ultimately reaching a 213 terminating SIP user agent. Likewise, a call might originate on a SIP 214 user agent and terminate on an H.323 endpoint. It MUST be possible to 215 identify such sessions end-to-end across the plurality of devices, 216 networks, or administrative domains. 218 It is expected that the ITU-T will define protocol elements for H.323 219 to make the end-to-end signaling possible. 221 Derived Requirements: REQ5, REQ7 223 4.3. Traffic Monitoring 225 UA A and UA B communicate using SIP messaging with a SIP B2BUA acting 226 as a middlebox which belongs to a SIP service provider. For privacy 227 reasons, the B2BUA changes the SIP headers that reveal information 228 related to the SIP users, device or domain identity. The service 229 provider uses an external device to monitor and log all SIP traffic 230 coming to and from the B2BUA. In the case of failures reported by 231 the customer or when security issue arise (e.g. theft of service), 232 the service provider has to analyze the logs from the past several 233 days or weeks and correlates those messages which were messages for a 234 single end-to-end SIP session. 236 For this scenario, we must consider three particular use cases: 238 a) The UAs A and B support the end-to-end Session Identifier. 240 Derived Requirements: REQ1, REQ3, REQ4, REQ6. 242 b) Only the UA A supports the end-to-end Session Identifier, the UA 243 B does not. 245 Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6. 247 c) UA A and UA B do not support the end-to-end Session Identifier. 249 Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6 251 4.4. Tracking transferred sessions 253 It is difficult to track which SIP messages where involved in the 254 same call across transactions, especially when invoking supplementary 255 services such as call transfer or call join. There exists a need for 256 the ability to track communication sessions as they are transferred, 257 one side at a time, until completion of the session (i.e., until a 258 BYE is sent). 260 Derived Requirements: REQ1, REQ2, REQ9 262 4.5. Session Signal Logging 264 An after-the-fact search of SIP messages to determine which messages 265 were part of the same transaction or call is difficult when B2BUAs 266 and SBCs are involved in the signaling between UAs. Mapping more 267 than one Call-ID together can be challenging because all of the 268 values in SIP headers on one side of the B2BUA or SBC will likely be 269 different than those on the other side. If multiple B2BUAs and/or 270 SBCs are in the signaling path, more than two sets of header values 271 will exist, creating more of a challenge. Creating a common header 272 value through all SIP entities will greatly reduce any challenge for 273 the purposes of debugging, communication tracking (such as for 274 security purposes in case of theft of service), etc. 276 Derived Requirements: REQ1, REQ3, REQ5, REQ6 278 4.6. Identifier Syntax 280 A syntax that is too restrictive (e.g., one that allows special 281 characters or a very long identifier) would make it difficult to 282 encode the identifier in other protocols. Therefore, the syntax of 283 the identifier should be reasonably restrictive. 285 Derived Requirements: REQ8 287 4.7. 3PCC Use Case 289 Third party call control refers to the ability of an entity to create 290 a call in which communication is actually between two or more 291 parties. For example, a B2BUA acting as a third party controller 292 could establish a call between two SIP UA's using 3PCC procedures as 293 described in section 4.1 of RFC 3725 [7], the flow for which is 294 reproduced below. 296 A Controller B 297 |(1) INVITE no SDP | | 298 |<------------------| | 299 |(2) 200 offer1 | | 300 |------------------>| | 301 | |(3) INVITE offer1 | 302 | |------------------>| 303 | |(4) 200 OK answer1 | 304 | |<------------------| 305 | |(5) ACK | 306 | |------------------>| 307 |(6) ACK answer1 | | 308 |<------------------| | 309 |(7) RTP | | 310 |.......................................| 312 Figure 2 - Session-ID 3PCC Scenario 314 Such a flow must result in a single session identifier being used for 315 the communication session between UA A and UA B. This use case does 316 not extend to three SIP UAs. 318 Derived Requirements: REQ9 320 5. Requirements for the End-to-End Session Identifier 322 The following requirements are derived from the use cases and 323 additional constraints regarding the construction of the identifier. 325 REQ1: It must be possible for an administrator or an external device 326 which monitors the SIP-traffic to use the identifier to identify 327 those dialogs, transactions and messages which were at some point in 328 time components of a single end-to-end SIP session (e.g., parts of 329 the same call). 331 REQ2: It must be possible to correlate two end-to-end sessions when a 332 session is transferred or if two different sessions are joined 333 together via an intermediary (e.g., a PBX). 335 REQ3: The solution must require that the identifier, if present, pass 336 unchanged through SIP B2BUAs or other intermediaries. 338 REQ4: The identifier must not reveal any information related to any 339 SIP user, device or domain identity. This includes any IP Address, 340 port, hostname, domain name, username, Address-of-Record, MAC 341 address, IP address family, transport type, subscriber ID, Call-ID, 342 tags, or other SIP header or body parts. 344 REQ5: It must be possible to identity SIP traffic with an end-to-end 345 session identifier from and to end devices that do not support this 346 new identifier, such as by allowing an intermediary to inject an 347 identifier into the session signaling. 349 REQ6: The identifier should be unique in time and space, similar to 350 the Call-ID. 352 REQ7: The identifier should be constructed in such a way as to make 353 it suitable for transmission in SIP and H.323. 355 REQ8: The identifier should use a restricted syntax and length so as 356 to allow the identifier to be used in other protocols. 358 REQ9: It must be possible to correlate two end-to-end sessions when 359 the sessions are created by a third party controller using 3PCC 360 procedures shown in Figure 1 of RFC 3725 [7]. 362 6. Related Work in other Standards Organizations 364 6.1. Coordination with the ITU-T 366 IP multimedia networks are often comprised of a mix of session 367 protocols like SIP and H.323. A benefit of the Session Identifier is 368 that it uniquely identifies a communication session end-to-end across 369 session protocol boundaries. Therefore, the need for coordinated 370 standardization activities across Standards Development Organizations 371 (SDOs) is imperative. 373 To facilitate this, a parallel effort is underway in the ITU-T to 374 introduce the Session Identifier for the H.323 protocol. The ITU-T 375 SG16 has approved contribution C.552 [5] as a work item with the 376 intent that it be a coordinated and synchronized effort between the 377 ITU-T and the IETF. 379 6.2. Requirements within 3GPP 381 3GPP identified in their Release 9 the need for a Session Identifier 382 for O&M purposes to correlate flows in an end-to-end communication 383 session. TS24.229 (IP multimedia call control protocol based on 384 Session Initiation Protocol (SIP) and Session Description Protocol 385 (SDP)) [6] points to the fact that the Session Identifier can be used 386 to correlate SIP messages belonging to the same session. In the case 387 where signaling passes through SIP entities like B2BUAs, the end-to- 388 end session identifier indicates that these dialogs belong to the 389 same end-to-end SIP communication session. 391 7. Security Considerations 393 An end-to-end identifier, if not properly constructed, could provide 394 information that would allow one to identify the individual, device, 395 or domain initiating or terminating a communication session. In 396 adherence with REQ4, the solution produced in accordance with these 397 requirements MUST NOT provide any information that allow one to 398 identify a person, device, or domain. This means that information 399 elements such as the MAC address or IP address MUST NOT be used when 400 constructing the end-to-end session identifier. 402 8. IANA Considerations 404 There are no IANA considerations associated with this document. 406 9. Acknowledgments 408 The authors would like to acknowledge Paul Kyzivat, Christer 409 Holmberg, Charles Eckel, Andy Hutton, Salvatore Loreto, Keith Drage, 410 Chris Pearce for their contribution and collaboration in developing 411 this document. 413 This document was prepared using 2-Word-v2.0.template.dot. 415 10. Contributors 417 Two other people originally participated as co-authors and provided 418 substantial contributions to this document, namely Roland Jesske, 419 Parthasarathi Ravindran. 421 11. References 423 11.1. Normative References 425 [1] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 426 3261, June 2002. 428 [2] Recommendation ITU-T H.323, "Packet-based multimedia 429 communications systems", December 2009. 431 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 432 Levels", BCP 14, RFC 2119, March 1997. 434 11.2. Informative References 436 [4] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real- 437 Time Applications", RFC 3550, July 2003. 439 [5] International Telecommunications Union, "End-to-End Session 440 Identifier for IP-based Multimedia Communication Systems", 441 March 2011, ITU-T Contribution C.552, http://ftp3.itu.int/av- 442 arch/avc-site/2009-2012/1103_Gen/SessionID.zip. 444 [6] 3GPP, "IP multimedia call control protocol based on Session 445 Initiation Protocol (SIP) and Session Description Protocol 446 (SDP); Stage 3", 3GPP TS 24.229 10.3.0, April 2011. 448 [7] Rosenberg, J., Peterson, J., Schulzrinne, H., Camarillo, G., 449 "Best Current Practices for Third Party Call Control (3pcc) in 450 the Session Initiation Protocol (SIP)", RFC 3725, April 2004. 452 Author's Addresses 454 Paul E. Jones 455 Cisco Systems, Inc. 456 7025 Kit Creek Rd. 457 Research Triangle Park, NC 27709 458 USA 460 Phone: +1 919 476 2048 461 Email: paulej@packetizer.com 462 IM: xmpp:paulej@packetizer.com 464 Hadriel Kaplan 465 Acme Packet 466 71 Third Ave. 467 Burlington, MA 01803, USA 469 Email: hkaplan@acmepacket.com 471 Laura Liess 472 Deutsche Telekom NP 473 64295 Darmstadt 474 Heinrich-Hertz-Str. 3-7 475 Germany 477 Phone: +49 6151 268 2761 478 Email: laura.liess.dt@gmail.com 480 James Polk 481 Cisco Systems, Inc. 482 3913 Treemont Circle 483 Colleyville, Texas, 484 USA 486 Phone: +1 817 271 3552 487 Email: jmpolk@cisco.com 488 IM: xmpp:jmpolk@cisco.com 490 Gonzalo Salgueiro 491 Cisco Systems, Inc. 492 7025 Kit Creek Rd. 493 Research Triangle Park, NC 27709 494 USA 496 Phone: +1 919 392 3266 497 Email: gsalguei@cisco.com 498 IM: xmpp:gsalguei@cisco.com