idnits 2.17.1 draft-ietf-insipid-session-id-reqts-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 144: '... dialog MUST use the same identifier...' RFC 2119 keyword, line 153: '...H.323 endpoint. It MUST be possible to...' RFC 2119 keyword, line 336: '... requirements MUST NOT provide any i...' RFC 2119 keyword, line 338: '...ss or IP address MUST NOT be used when...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 21, 2012) is 4173 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 371, but no explicit reference was found in the text Summary: 1 error (**), 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: May 21, 2013 Cisco Systems 6 Laura Liess 7 Deutsche Telekom 8 Hadriel Kaplan 9 Acme Packet 10 November 21, 2012 12 Requirements for an End-to-End Session Identification in 13 IP-Based Multimedia Communication Networks 14 draft-ietf-insipid-session-id-reqts-03.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 21, 2013. 41 Copyright Notice 43 Copyright (c) 2012 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. Terminology....................................................3 60 3. Session Identifier Use Cases...................................3 61 3.1. End-to-end identification of a communication session......3 62 3.2. Protocol Interworking.....................................4 63 3.3. Traffic Monitoring........................................4 64 3.4. Tracking transferred sessions.............................4 65 3.5. Session Signal Logging....................................5 66 3.6. Identifier Porting to Other Protocols - RTCP..............5 67 3.7. 3PCC Use Case.............................................5 68 4. Requirements for the End-to-End Session Identifier.............6 69 5. Related Work in other Standards Organizations..................7 70 5.1. Coordination with the ITU-T...............................7 71 5.2. Requirements within 3GPP..................................7 72 6. Security Considerations........................................7 73 7. IANA Considerations............................................8 74 8. Acknowledgments................................................8 75 9. Contributors...................................................8 76 10. References....................................................8 77 10.1. Normative References.....................................8 78 10.2. Informative References...................................8 79 Author's Addresses................................................9 81 1. Introduction 83 IP-based multimedia communication systems like SIP [1] and H.323 [2] 84 have the concept of a "call identifier" that is globally unique. The 85 identifier is intended to represents an end-to-end communication 86 session from the originating device to the terminating device. Such 87 an identifier is useful for troubleshooting, billing, session 88 tracking, and so forth. 90 Unfortunately, there are a number of factors that contribute to the 91 fact that the current call identifiers defined in SIP and H.323 are 92 not suitable for end-to-end session identification. Perhaps most 93 significant is the fact that the syntax for the call identifier in 94 SIP and H.323 is different between the two protocols. This important 95 fact makes it impossible for call identifiers to be exchanged end-to- 96 end when a network utilizes one or more session protocols. 98 Another reason why the current call identifiers are not suitable to 99 identify the session end-to-end is that in real-world deployments 100 devices like Back-to-Back User Agents often change the values as the 101 session signaling passes through. This is true even when a single 102 session protocol is employed and not a byproduct of protocol 103 interworking. 105 Lastly, identifiers that might have been used to identify a session 106 end-to-end fail to meet that need when sessions are manipulated 107 through supplementary service interactions. For example, when a 108 session is transferred or if a PBX joins or merges two communication 109 sessions together locally, the end-to-end properties of currently- 110 defined identifiers are lost. 112 2. Terminology 114 SIP defines additional terms used in this document that are specific 115 to the SIP domain such as "proxy"; "registrar"; "redirect server"; 116 "user agent server" or "UAS"; "user agent client" or "UAC"; "user 117 agent" (UA); "back-to-back user agent" or "B2BUA"; "dialog"; 118 "transaction"; "server transaction". 120 In this document, the word "session" refers to a "communication 121 session" that may exist between two SIP user agents or that might 122 pass through one or more intermediary devices, including B2BUAs or 123 SIP Proxies. 125 The term "end-to-end" in this document means the communication 126 session from the point of origin, passing through any number of 127 intermediaries, to the ultimate point of termination. It is 128 recognized that legacy devices may not support the "end-to-end" 129 session identifier, though an identifier might be created by an 130 intermediary when it is absent from the session signaling. 132 3. Session Identifier Use Cases 134 3.1. End-to-end identification of a communication session 136 For SIP messaging that either does not involve SIP servers or only 137 involves SIP proxies, the Call-ID header value sufficiently 138 identifies each SIP message within a transaction or dialog. This is 139 not the case when either B2BUAs or SBCs are in the signaling path 140 between UAs. Therefore, we need the ability to identify each 141 communication session through a single SIP header-value regardless of 142 which type of SIP servers are in the signaling path between UAs. For 143 transactions that create a dialog, each message within the same 144 dialog MUST use the same identifier. 146 Derived Requirements: All Requirements in Section 4 148 3.2. Protocol Interworking 150 A communication session might originate in an H.323 endpoint and pass 151 through a Session Border Controller before ultimately reaching a 152 terminating SIP user agent. Likewise, a call might originate on a SIP 153 user agent and terminate on an H.323 endpoint. It MUST be possible to 154 identify such sessions end-to-end across the plurality of devices, 155 networks, or administrative domains. 157 It is expected that the ITU-T will define protocol elements for H.323 158 to make the end-to-end signaling possible. 160 Derived Requirements: REQ5, REQ7 162 3.3. Traffic Monitoring 164 UA A and UA B communicate using SIP messaging with a SIP B2BUA acting 165 as a middlebox which belongs to a SIP service provider. For privacy 166 reasons, the B2BUA changes the SIP headers that reveal information 167 related to the SIP users, device or domain identity. The service 168 provider uses an external device to monitor and log all SIP traffic 169 coming to and from the B2BUA. In the case of failures reported by 170 the customer or when security issue arise (e.g. theft of service), 171 the service provider has to analyze the logs from the past several 172 days or weeks and correlates those messages which were messages for a 173 single end-to-end SIP session. 175 For this scenario, we must consider three particular use cases: 177 a) The UAs A and B support the end-to-end Session Identifier. 179 Derived Requirements: REQ1, REQ3, REQ4, REQ6. 181 b) Only the UA A supports the end-to-end Session Identifier, the UA 182 B does not. 184 Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6. 186 c) UA A and UA B do not support the end-to-end Session Identifier. 188 Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6 190 3.4. Tracking transferred sessions 192 It is difficult to track which SIP messages where involved in the 193 same call across transactions, especially when invoking supplementary 194 services such as call transfer or call join. There exists a need for 195 the ability to track communications sessions as they are transferred, 196 one side at a time, through until completion of the session (i.e., 197 until a BYE is sent). 199 Derived Requirements: REQ1, REQ2, REQ9 201 3.5. Session Signal Logging 203 An after the fact search of SIP messages to determine which were part 204 of the same transaction or call is difficult when B2BUAs and SBCs are 205 involved in the signaling between UAs. Mapping more than one Call-ID 206 together can be challenging because all of the values in SIP headers 207 on one side of the B2BUA or SBC will likely be different than those 208 on the other side. If multiple B2BUAs and/or SBCs are in the 209 signaling path, more than two sets of header values will exist, 210 creating more of a challenge. Creating a common header value through 211 all SIP entities will greatly reduce any challenge for the purposes 212 of debugging, communication tracking (such as for security purposes 213 in case of theft of service), etc. 215 Derived Requirements: REQ1, REQ3, REQ5, REQ6 217 3.6. Identifier Syntax 219 A syntax that is too restrictive (e.g., one that allows special 220 characters or a very long identifier) would make it difficult to 221 encode the identifier in other protocols. Therefore, the syntax of 222 the identifier should be reasonably restrictive. 224 Derived Requirements: REQ8 226 3.7. 3PCC Use Case 228 Third party call control refers to the ability of an entity to create 229 a call in which communication is actually between two or more 230 parties. For example, a B2BUA acting as a third party controller 231 could establish a call between two SIP UA's using 3PCC procedures as 232 described in section 4.1 of RFC 3725 the flow for which is reproduced 233 below. 235 A Controller B 236 |(1) INVITE no SDP | | 237 |<------------------| | 238 |(2) 200 offer1 | | 239 |------------------>| | 240 | |(3) INVITE offer1 | 241 | |------------------>| 242 | |(4) 200 OK answer1 | 243 | |<------------------| 244 | |(5) ACK | 245 | |------------------>| 246 |(6) ACK answer1 | | 247 |<------------------| | 248 |(7) RTP | | 249 |.......................................| 251 Figure 1 - Session-ID 3PCC Scenario 253 Such a flow must result in a single session identifier being used for 254 the communication session between UA A and UA B. This use case does 255 not extend to three SIP UAs. 257 Derived Requirements: REQ9 259 4. Requirements for the End-to-End Session Identifier 261 The following requirements are derived from the use cases and 262 additional constraints regarding the construction of the identifier. 264 REQ1: It must be possible for an administrator or an external device 265 which monitors the SIP-traffic to use the identifier to identify 266 those dialogs, transactions and messages which were at some point in 267 time components of a single end-to-end SIP session (e.g., parts of 268 the same call). 270 REQ2: It must be possible to correlate two end-to-end sessions when a 271 session is transferred or if two different sessions are joined 272 together via an intermediary (e.g., a PBX). . 274 REQ3: The solution must require that the identifier pass unchanged 275 through SIP B2BUAs or other intermediaries. 277 REQ4: The identifier must not reveal any information related to any 278 SIP user, device or domain identity. This includes any IP Address, 279 port, hostname, domain name, username, Address-of-Record, MAC 280 address, IP address family, transport type, subscriber ID, Call-ID, 281 tags, or other SIP header or body parts. 283 REQ5: It must be possible to identity SIP traffic with an end-to-end 284 session identifier from and to end devices that do not support this 285 new identifier, such as by allowing an intermediary to inject an 286 identifier into the session signaling. 288 REQ6: The identifier should be unique in time and space, similar to 289 the Call-ID. 291 REQ7: The identifier should be constructed in such a way as to make 292 it suitable for transmission in SIP and H.323. 294 REQ8: The identifier should use a restricted syntax and length so as 295 to allow the identifier to be used in other protocols. 297 REQ9: It must be possible to correlate two end-to-end sessions when 298 the sessions are created by a third party controller using 3PCC 299 procedures shown in Figure 1 of RFC 3725 [6]. 301 5. Related Work in other Standards Organizations 303 5.1. Coordination with the ITU-T 305 IP multimedia networks are often comprised of a mix of session 306 protocols like SIP and H.323. A benefit of the Session Identifier is 307 that it uniquely identifies a communication session end-to-end across 308 session protocol boundaries. Therefore, the need for coordinated 309 standardization activities across Standards Development Organizations 310 (SDOs) is imperative. 312 To facilitate this, a parallel effort is underway in the ITU-T to 313 introduce the Session Identifier for the H.323 protocol. The ITU-T 314 SG16 has approved contribution C.552 [4] as a work item with the 315 intent that it be a coordinated and synchronized effort between the 316 ITU-T and the IETF. 318 5.2. Requirements within 3GPP 320 3GPP identified in their Release 9 the need for a Session Identifier 321 for O&M purposes to correlate flows in an end-to-end communication 322 session. TS24.229 (IP multimedia call control protocol based on 323 Session Initiation Protocol (SIP) and Session Description Protocol 324 (SDP)) [5] points to the fact that the Session Identifier can be used 325 to correlate SIP messages belonging to the same session. In the case 326 where signaling passes through SIP entities like B2BUAs, the end-to- 327 end session identifier indicates that these dialogs belong to the 328 same end-to-end SIP communication session. 330 6. Security Considerations 332 An end-to-end identifier, if not properly constructed, could provide 333 information that would allow one to identify the individual, device, 334 or domain initiating or terminating a communication session. In 335 adherence with REQ4, the solution produced in accordance with these 336 requirements MUST NOT provide any information that allow one to 337 identify a person, device, or domain. This means that information 338 elements such as the MAC address or IP address MUST NOT be used when 339 constructing the end-to-end session identifier. 341 7. IANA Considerations 343 There are no IANA considerations associated with this document. 345 8. Acknowledgments 347 The authors would like to acknowledge Paul Kyzivat, Christer 348 Holmberg, Andy Hutton, Salvatore Loreto, Keith Drage, Chris Pearce 349 for their contribution and collaboration in developing this document. 351 This document was prepared using 2-Word-v2.0.template.dot. 353 9. Contributors 355 Two other people originally participated as co-authors and provided 356 substantial contributions to this document, namely Roland Jesske, 357 Parthasarathi Ravindran. 359 10. References 361 10.1. Normative References 363 [1] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 364 3261, June 2002. 366 [2] Recommendation ITU-T H.323, "Packet-based multimedia 367 communications systems", December 2009. 369 10.2. Informative References 371 [3] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real- 372 Time Applications", RFC 3550, July 2003. 374 [4] International Telecommunications Union, "End-to-End Session 375 Identifier for IP-based Multimedia Communication Systems", 376 March 2011, ITU-T Contribution C.552, http://ftp3.itu.int/av- 377 arch/avc-site/2009-2012/1103_Gen/SessionID.zip. 379 [5] 3GPP, "IP multimedia call control protocol based on Session 380 Initiation Protocol (SIP) and Session Description Protocol 381 (SDP); Stage 3", 3GPP TS 24.229 10.3.0, April 2011. 383 [6] Rosenberg, J., Peterson, J., Schulzrinne, H., Camarillo, G., 384 "Best Current Practices for Third Party Call Control (3pcc) in 385 the Session Initiation Protocol (SIP)", RFC 3725, April 2004. 387 Author's Addresses 389 Paul E. Jones 390 Cisco Systems, Inc. 391 7025 Kit Creek Rd. 392 Research Triangle Park, NC 27709 393 USA 395 Phone: +1 919 476 2048 396 Email: paulej@packetizer.com 397 IM: xmpp:paulej@packetizer.com 399 Hadriel Kaplan 400 Acme Packet 401 71 Third Ave. 402 Burlington, MA 01803, USA 404 Email: hkaplan@acmepacket.com 406 Laura Liess 407 Deutsche Telekom NP 408 64295 Darmstadt 409 Heinrich-Hertz-Str. 3-7 410 Germany 412 Phone: +49 6151 268 2761 413 Email: laura.liess.dt@gmail.com 415 James Polk 416 Cisco Systems, Inc. 417 3913 Treemont Circle 418 Colleyville, Texas, 419 USA 421 Phone: +1 817 271 3552 422 Email: jmpolk@cisco.com 423 IM: xmpp:jmpolk@cisco.com 425 Gonzalo Salgueiro 426 Cisco Systems, Inc. 427 7025 Kit Creek Rd. 428 Research Triangle Park, NC 27709 429 USA 431 Phone: +1 919 392 3266 432 Email: gsalguei@cisco.com 433 IM: xmpp:gsalguei@cisco.com