idnits 2.17.1 draft-ietf-insipid-session-id-reqts-02.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 145: '... the same dialog MUST use the same ide...' RFC 2119 keyword, line 156: '...H.323 endpoint. It MUST be possible to...' RFC 2119 keyword, line 343: '... requirements MUST NOT provide any i...' RFC 2119 keyword, line 345: '...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 (October 9, 2012) is 4215 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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: April 9, 2013 Cisco Systems 6 Laura Liess 7 Deutsche Telekom 8 Hadriel Kaplan 9 Acme Packet 10 October 9, 2012 12 Requirements for an End-to-End Session Identification in 13 IP-Based Multimedia Communication Networks 14 draft-ietf-insipid-session-id-reqts-02.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 April 9, 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. DELETED...................................................4 63 3.3. Protocol Interworking.....................................4 64 3.4. Traffic Monitoring........................................4 65 3.5. DELETED...................................................5 66 3.6. Tracking transferred sessions.............................5 67 3.7. Session Signal Logging....................................5 68 3.8. Identifier Porting to Other Protocols - RTCP..............5 69 3.9. 3PCC Use Case.............................................5 70 4. Requirements for the End-to-End Session Identifier.............6 71 5. Related Work in other Standards Organizations..................7 72 5.1. Coordination with the ITU-T...............................7 73 5.2. Requirements within 3GPP..................................7 74 6. Security Considerations........................................8 75 7. IANA Considerations............................................8 76 8. Acknowledgments................................................8 77 9. References.....................................................8 78 9.1. Normative References......................................8 79 9.2. Informative References....................................8 80 Author's Addresses................................................9 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, billing, session 89 tracking, and so 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. Terminology 115 SIP defines additional terms used in this document that are specific 116 to the SIP domain such as "proxy"; "registrar"; "redirect server"; 117 "user agent server" or "UAS"; "user agent client" or "UAC"; "user 118 agent" (UA); "back-to-back user agent" or "B2BUA"; "dialog"; 119 "transaction"; "server transaction". 121 In this document, the word "session" refers to a 122 "communication session" that may exist between two SIP user agents or 123 that might pass through one or more intermediary devices, including 124 B2BUAs or SIP Proxies. 126 The term "end-to-end" in this document means the communication 127 session from the point of origin, passing through any number of 128 intermediaries, to the ultimate point of termination. It is 129 recognized that legacy devices may not support the "end-to-end" 130 session identifier, though an identifier might be created by an 131 intermediary when it is absent from the session signaling. 133 3. Session Identifier Use Cases 135 3.1. End-to-end identification of a communication session 137 SIP messaging that either does not involve SIP servers or only 138 involves SIP proxies, the Call-ID: header value sufficiently 139 identifies each SIP message within a transaction or dialog. This is 140 not the case when either B2BUAs or SBCs are in the signaling path 141 between UAs. Therefore, we need the ability to identify each 142 communication session per transaction through a single SIP header- 143 value regardless of which type of SIP servers are in the signaling 144 path between UAs. For transactions that create a dialog, have each 145 message within the same dialog MUST use the same identifier. 147 Derived Requirements: All Requirements in Section 4 149 3.2. DELETED 151 3.3. Protocol Interworking 153 A communication session might originate in an H.323 endpoint and pass 154 through a Session Border Controller before ultimately reaching a 155 terminating SIP user agent. Likewise, a call might originate on a SIP 156 user agent and terminate on an H.323 endpoint. It MUST be possible to 157 identify such sessions end-to-end across the plurality of devices, 158 networks, or administrative domains. 160 It is expected that the ITU-T will define protocol elements for H.323 161 to make the end-to-end signaling possible. 163 Derived Requirements: REQ7, REQ9a 165 3.4. Traffic Monitoring 167 UA A and UA B communicate using SIP messaging with a SIP B2BUA acting 168 as a middlebox which belongs to a SIP service provider. For privacy 169 reasons, the B2BUA changes the SIP headers that reveal information 170 related to the SIP users, device or domain identity. The service 171 provider uses an external device to monitor and log all SIP traffic 172 coming to and from the B2BUA. In the case of failures reported by 173 the customer or when security issue arise (e.g. theft of service), 174 the service provider has to analyze the logs from the past several 175 days or weeks and correlates those messages which were messages for a 176 single end-to-end SIP session. 178 For this scenario, we must consider three particular use cases: 180 a) The UAs A and B support the end-to-end Session Identifier. 182 Derived Requirements: REQ1, REQ4, REQ5, REQ8. 184 b) Only the UA A supports the end-to-end Session Identifier, the UA 185 B does not. 187 Derived Requirements: REQ1, REQ4, REQ5, REQ7, REQ8. 189 c) UA A and UA B do not support the end-to-end Session Identifier. 191 Derived Requirements: REQ1, REQ4, REQ5, REQ7, REQ8 193 3.5. DELETED 195 3.6. Tracking transferred sessions 197 It is difficult to track which SIP messages where involved in the 198 same call across transactions, especially when invoking supplementary 199 services such as call transfer or call join. The ability to track 200 communications sessions as they are transferred, one side at a time, 201 through until completion of the session (i.e., until a BYE is sent). 203 Derived Requirements: REQ1, REQ2, REQ10 205 3.7. Session Signal Logging 207 An after the fact search of SIP messages to determine which were part 208 of the same transaction or call is difficult when B2BUAs and SBCs are 209 involved in the signaling between UAs. Mapping more than one Call-ID 210 together can be challenging because all of the values in SIP headers 211 on one side of the B2BUA or SBC will likely be different than those 212 on the other side. If multiple B2BUAs and/or SBCs are in the 213 signaling path, more than two sets of header values will exist, 214 creating more of a challenge. Creating a common header value through 215 all SIP entities will greatly reduce any challenge for the purposes 216 of debugging, communication tracking (such as for security purposes 217 in case of theft of service), etc. 219 Derived Requirements: REQ1, REQ4, REQ7, REQ8 221 3.8. Identifier Porting to Other Protocols - RTCP 223 There may be a desire to associate SIP session signaling with 224 corresponding media flows. To facilitate this association, it should 225 be possible to insert the Session-ID into a media-related message, 226 such as an RTCP sender report message. This association would allow, 227 as an example, for network monitoring equipment to associate troubled 228 network flows with the end-to-end SIP session signaling. 230 Derived Requirements: REQ9c 232 3.9. 3PCC Use Case 234 Third party call control refers to the ability of an entity to create 235 a call in which communication is actually between two or more 236 parties. For example, a B2BUA acting as a third party controller 237 could establish a call between two SIP UA's using 3PCC procedures as 238 described in section 4.1 of RFC 3725 the flow for which is reproduced 239 below. 241 A Controller B 242 |(1) INVITE no SDP | | 243 |<------------------| | 244 |(2) 200 offer1 | | 245 |------------------>| | 246 | |(3) INVITE offer1 | 247 | |------------------>| 248 | |(4) 200 OK answer1 | 249 | |<------------------| 250 | |(5) ACK | 251 | |------------------>| 252 |(6) ACK answer1 | | 253 |<------------------| | 254 |(7) RTP | | 255 |.......................................| 257 Figure 1 - Session-ID 3PCC Scenario 259 Such a flow must result in a single session identifier being used for 260 the communication session between UA A and UA B. This use case does 261 not extend to three SIP UAs. 263 Derived Requirements: REQ10 265 4. Requirements for the End-to-End Session Identifier 267 The following requirements are derived from the use cases and 268 additional constraints regarding the construction of the identifier. 270 REQ1: It must be possible for an administrator or an external device 271 which monitors the SIP-traffic to use the identifier to identify 272 those dialogs, transactions and messages which were at some point in 273 time components of a single end-to-end SIP session (e.g., parts of 274 the same call). 276 REQ2: It must be possible to correlate two end-to-end sessions when a 277 session is transferred or if two different sessions are joined 278 together via an intermediary (e.g., a PBX). This might result in a 279 change in the value of the end-to-end Session-Identifier. 281 REQ4: It must be possible to pass the identifier unchanged through 282 SIP B2BUAs or other intermediaries. 284 REQ5: The identifier must not reveal any information related to any 285 SIP user, device or domain identity. This includes any IP Address, 286 port, hostname, domain name, username, Address-of-Record, MAC 287 address, IP address family, transport type, subscriber ID, Call-ID, 288 tags, or other SIP header or body parts. 290 REQ7: It must be possible to identity SIP traffic with an end-to-end 291 session identifier from and to end devices that do not support this 292 new identifier, such as by allowing an intermediary to inject an 293 identifier into the session signaling. 295 REQ8: The identifier should be unique in time and space, similar to 296 the Call-ID. 298 REQ9a: The identifier should be constructed in such a way as to make 299 it suitable for transmission in SIP and H.323. 301 REQ9c: The identifier should be constructed in such a way as to make 302 it suitable for transmission in SIP and RTCP [3]. 304 REQ10: It must be possible to correlate two end-to-end sessions when 305 the sessions are created by a third party controller using 3PCC 306 procedures shown in Figure 1 of RFC 3725 [6]. 308 5. Related Work in other Standards Organizations 310 5.1. Coordination with the ITU-T 312 IP multimedia networks are often comprised of a mix of session 313 protocols like SIP and H.323. A benefit of the Session Identifier is 314 that it uniquely identifies a communication session end-to-end across 315 session protocol boundaries. Therefore, the need for coordinated 316 standardization activities across Standards Development Organizations 317 (SDOs) is imperative. 319 To facilitate this, a parallel effort is underway in the ITU-T to 320 introduce the Session Identifier for the H.323 protocol. The ITU-T 321 SG16 has approved contribution C.552 [4] as a work item with the 322 intent that it be a coordinated and synchronized effort between the 323 ITU-T and the IETF. 325 5.2. Requirements within 3GPP 327 3GPP identified in their Release 9 the need for a Session Identifier 328 for O&M purposes to correlate flows in an end-to-end communication 329 session. TS24.229 (IP multimedia call control protocol based on 330 Session Initiation Protocol (SIP) and Session Description Protocol 331 (SDP)) [5] points to the fact that the Session Identifier can be used 332 to correlate SIP messages belonging to the same session. In the case 333 where signaling passes through SIP entities like B2BUAs, the end-to- 334 end session identifier indicates that these dialogs belong to the 335 same end-to-end SIP communication session. 337 6. Security Considerations 339 An end-to-end identifier, if not properly constructed, could provide 340 information that would allow one to identify the individual, device, 341 or domain initiating or terminating a communication session. In 342 adherence with REQ5, the solution produced in accordance with these 343 requirements MUST NOT provide any information that allow one to 344 identify a person, device, or domain. This means that information 345 elements such as the MAC address or IP address MUST NOT be used when 346 constructing the end-to-end session identifier. 348 7. IANA Considerations 350 There are no IANA considerations associated with this document. 352 8. Acknowledgments 354 The authors would like to acknowledge Chris Pearce for his 355 contribution and collaboration in developing this document. 357 This document was prepared using 2-Word-v2.0.template.dot. 359 9. References 361 9.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 9.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 Roland Jesske 390 Deutsche Telekom NP 391 64295 Darmstadt 392 Heinrich-Hertz-Str. 3-7 393 Germany 395 Phone: +49 6151 628 2766 396 Email: R.Jesske@telekom.de 398 Paul E. Jones 399 Cisco Systems, Inc. 400 7025 Kit Creek Rd. 401 Research Triangle Park, NC 27709 402 USA 404 Phone: +1 919 476 2048 405 Email: paulej@packetizer.com 406 IM: xmpp:paulej@packetizer.com 408 Hadriel Kaplan 409 Acme Packet 410 71 Third Ave. 411 Burlington, MA 01803, USA 413 Email: hkaplan@acmepacket.com 415 Laura Liess 416 Deutsche Telekom NP 417 64295 Darmstadt 418 Heinrich-Hertz-Str. 3-7 419 Germany 421 Phone: +49 6151 268 2761 422 Email: laura.liess.dt@gmail.com 424 Salvatore Loreto 425 Ericsson 426 Hirsalantie 11 427 Jorvas 02420 428 Finland 430 Email: salvatore.loreto@ericsson.com 431 James Polk 432 Cisco Systems, Inc. 433 3913 Treemont Circle 434 Colleyville, Texas, 435 USA 437 Phone: +1 817 271 3552 438 Email: jmpolk@cisco.com 439 IM: xmpp:jmpolk@cisco.com 441 Parthasarathi Ravindran 442 Sonus Networks, Inc. 443 Prestige Shantiniketan - Business Precinct 444 Whitefield Road 445 Bangalore, Karnataka 560066 446 India 448 Email: pravindran@sonusnet.com 450 Gonzalo Salgueiro 451 Cisco Systems, Inc. 452 7025 Kit Creek Rd. 453 Research Triangle Park, NC 27709 454 USA 456 Phone: +1 919 392 3266 457 Email: gsalguei@cisco.com 458 IM: xmpp:gsalguei@cisco.com