idnits 2.17.1 draft-jones-ipmc-session-id-reqts-01.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 237: '... requirements MUST NOT provide any i...' RFC 2119 keyword, line 239: '...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 (January 30, 2012) is 4463 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: July 30, 2012 Parthasarathi Ravindran 6 Cisco Systems 7 Laura Liess 8 Roland Jesske 9 Deutsche Telekom 10 Salvatore Loreto 11 Ericsson 12 Hadriel Kaplan 13 Acme Packet 14 January 30, 2012 16 Requirements for an End-to-End Session Identification in 17 IP-Based Multimedia Communication Networks 18 draft-jones-ipmc-session-id-reqts-01.txt 20 Abstract 22 This document specifies the requirements for an end-to-end session 23 identifier in IP-based multimedia communication networks. This 24 identifier would enable endpoints, intermediate devices, and 25 management and monitoring systems to identify a session end-to-end, 26 associate multiple endpoints with a given multipoint conference, 27 track communication sessions when they are redirected, and associate 28 one or more media flows with a given communication session. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 30, 2012. 47 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction...................................................2 65 2. Terminology....................................................3 66 3. Requirements for the End-to-End Session Identifier.............3 67 4. Session Identifier Use Cases...................................4 68 5. Related Work in other Standards Organizations..................5 69 5.1. Coordination with the ITU-T...............................5 70 5.2. Requirements within 3GPP..................................5 71 6. Security Considerations........................................5 72 7. IANA Considerations............................................6 73 8. Acknowledgments................................................6 74 9. References.....................................................6 75 9.1. Normative References......................................6 76 9.2. Informative References....................................6 77 Author's Addresses................................................7 79 1. Introduction 81 IP-based multimedia communication systems like SIP [1] and H.323 [2] 82 have the concept of a "call identifier" that is globally unique. The 83 identifier is intended to represents an end-to-end communication 84 session from the originating device to the terminating device. Such 85 an identifier is useful for troubleshooting, billing, session 86 tracking, and so forth. 88 Unfortunately, there are a number of factors that contribute to the 89 fact that the current call identifiers defined in SIP and H.323 are 90 not suitable for end-to-end session identification. Perhaps most 91 significant is the fact that the syntax for the call identifier in 92 SIP and H.323 is different between the two protocols. This important 93 fact makes it impossible for call identifiers to be exchanged end-to- 94 end when a network utilizes one or more session protocols. 96 Another reason why the current call identifiers are not suitable to 97 identify the session end-to-end is that in real-world deployments 98 devices like session border controllers often change the values as 99 the session signaling passes through. This is true even when a 100 single session protocol is employed and not a byproduct of protocol 101 interworking. 103 Lastly, identifiers that might have been used to identify a session 104 end-to-end fail to meet that need when sessions are manipulated 105 through supplementary service interactions. For example, when a 106 session is transferred or if a PBX joins two communication sessions 107 together locally, the end-to-end properties of currently-defined 108 identifiers are lost. 110 This draft specifies the requirements for an end-to-end session 111 identifier. With this draft, the authors would like to encourage 112 discussion and progress work in the dispatch working group or working 113 group as designated by the IETF, the outcome of which will be a new 114 RFC that defines a session ID in conformance with these requirements. 116 2. Terminology 118 SIP defines additional terms used in this document that are specific 119 to the SIP domain such as "proxy"; "registrar"; "redirect server"; 120 "user agent server" or "UAS"; "user agent client" or "UAC"; "back-to- 121 back user agent" or "B2BUA"; "dialog"; "transaction"; "server 122 transaction". 124 In this document, the word "session" refers to a 125 "communication session" that may exist between two SIP user agents or 126 that might pass through one or more intermediary devices, including 127 B2BUAs or SIP Proxies. 129 The term "end-to-end" in this document means the communication 130 session from the point of origin, passing through any number of 131 intermediaries, to the ultimate point of termination. It is 132 recognized that legacy devices may not support the "end-to-end" 133 session identifier, though an identifier might be created by an 134 intermediary when it is absent from the session signaling. 136 3. Requirements for the End-to-End Session Identifier 138 REQ1: It must be possible for an administrator or an external device 139 which monitors the SIP-traffic to use the identifier to identify a 140 set of dialogs which have a relationship with each other, such that 141 they represent the same SIP session, with as high a probability as 142 possible. 144 REQ2: It must be possible to identify the end-to-end session when a 145 session is transferred or if two different sessions are joined 146 together via an intermediary (e.g., a PBX). 148 REQ3: It must be possible to identify all sessions participating in a 149 multipoint or multi-party conference by observing the end-to-end 150 session identifiers of each session. 152 REQ4: It must be possible to pass the identifier unchanged through 153 SIP B2BUAs or other intermediaries. 155 REQ5: The identifier must not reveal any information related to any 156 SIP device or domain identity, including IP Address, port, hostname, 157 domain name, username, Address-of-Record, MAC address, IP address 158 family, transport type, etc. 160 REQ6: The identifier must not reveal to the receiver of it that the 161 Call-ID, tags, or any other SIP header or body portion have been 162 changed by middleboxes, with as high a probability as possible. 164 REQ7: It must be possible to identity SIP traffic with an end-to-end 165 session identifier from and to end devices that do not support this 166 new identifier, such as by allowing an intermediary to inject an 167 identifier into the session signaling. 169 REQ8: The identifier should be unique in time and space, similar to 170 the Call-ID. 172 REQ9: The identifier should be constructed in such a way as to make 173 it suitable for transmission in SIP, H.323, RSVP [3], and RTCP [4]. 175 4. Session Identifier Use Cases 177 The Session Identifier is intended to uniquely identify a 178 communication session end-to-end. This document does not specify how 179 the Session Identifier is to be used, but merely defines the 180 identifier in such a way as to enable it to be used for situations 181 encountered in real-world deployments of IP-based multimedia 182 communication systems, including: 184 * End-to-end identification of a communication session 186 * Association of session signaling and media flows, made possible 187 by including the session identifier in media-related messages 188 (e.g., RSVP or RTCP) 190 * Identification of devices taking part in the same multipoint 191 conference 193 * Tracking sessions transferred from one endpoint to another 195 * Facilitate the recording of SIP sessions and correlating those 196 sessions 198 * Logging for the purposes of accounting, billing, debugging, 199 communication tracking (such as for security purposes in case of 200 theft of service), etc. 202 5. Related Work in other Standards Organizations 204 5.1. Coordination with the ITU-T 206 IP multimedia networks are often comprised of a mix of session 207 protocols like SIP and H.323. A benefit of the Session Identifier is 208 that it uniquely identifies a communication session end-to-end across 209 session protocol boundaries. Therefore, the need for coordinated 210 standardization activities across Standards Development Organizations 211 (SDOs) is imperative. 213 To facilitate this, a parallel effort is underway in the ITU-T to 214 introduce the Session Identifier for the H.323 protocol. The ITU-T 215 SG16 has approved contribution C.552 [5] as a work item with the 216 intent that it be a coordinated and synchronized effort between the 217 ITU-T and the IETF. 219 5.2. Requirements within 3GPP 221 3GPP identified in their Release 9 the need for a Session Identifier 222 for O&M purposes to correlate flows in an end-to-end communication 223 session. TS24.229 (IP multimedia call control protocol based on 224 Session Initiation Protocol (SIP) and Session Description Protocol 225 (SDP)) [6] points to the fact that the Session Identifier can be used 226 to correlate SIP messages belonging to the same session. In the case 227 where signaling passes through SIP entities like B2BUAs, the end-to- 228 end session identifier indicates that these dialogs belong to the 229 same end-to-end SIP communication session. 231 6. Security Considerations 233 An end-to-end identifier, if not properly constructed, could provide 234 information that would allow one to identify the individual, device, 235 or domain initiating or terminating a communication session. In 236 adherence with REQ5, the solution produced in accordance with these 237 requirements MUST NOT provide any information that allow one to 238 identify a person, device, or domain. This means that information 239 elements such as the MAC address or IP address MUST NOT be used when 240 constructing the end-to-end session identifier. 242 7. IANA Considerations 244 There are no IANA considerations associated with this document. 246 8. Acknowledgments 248 The authors would like to acknowledge Chris Pearce for his 249 contribution and collaboration in developing this document. 251 This document was prepared using 2-Word-v2.0.template.dot. 253 9. References 255 9.1. Normative References 257 [1] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 258 3261, June 2002. 260 [2] Recommendation ITU-T H.323, "Packet-based multimedia 261 communications systems", December 2009. 263 9.2. Informative References 265 [3] Braden, R., et al., "Resource ReSerVation Protocol (RSVP) -- 266 Version 1 Functional Specification", RFC 2205, September 1997. 268 [4] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real- 269 Time Applications", RFC 3550, July 2003. 271 [5] International Telecommunications Union, "End-to-End Session 272 Identifier for IP-based Multimedia Communication Systems", 273 March 2011, ITU-T Contribution C.552, http://ftp3.itu.int/av- 274 arch/avc-site/2009-2012/1103_Gen/SessionID.zip. 276 [6] 3GPP, "IP multimedia call control protocol based on Session 277 Initiation Protocol (SIP) and Session Description Protocol 278 (SDP); Stage 3", 3GPP TS 24.229 10.3.0, April 2011. 280 Author's Addresses 282 Roland Jesske 283 Deutsche Telekom NP 284 64295 Darmstadt 285 Heinrich-Hertz-Str. 3-7 286 Germany 288 Phone: +49 6151 628 2766 289 Email: R.Jesske@telekom.de 291 Paul E. Jones 292 Cisco Systems, Inc. 293 7025 Kit Creek Rd. 294 Research Triangle Park, NC 27709 295 USA 297 Phone: +1 919 476 2048 298 Email: paulej@packetizer.com 299 IM: xmpp:paulej@packetizer.com 301 Hadriel Kaplan 302 Acme Packet 303 71 Third Ave. 304 Burlington, MA 01803, USA 306 Email: hkaplan@acmepacket.com 308 Laura Liess 309 Deutsche Telekom NP 310 64295 Darmstadt 311 Heinrich-Hertz-Str. 3-7 312 Germany 314 Phone: +49 6151 268 2761 315 Email: laura.liess.dt@gmail.com 317 Salvatore Loreto 318 Ericsson 319 Hirsalantie 11 320 Jorvas 02420 321 Finland 323 Email: salvatore.loreto@ericsson.com 324 James Polk 325 Cisco Systems, Inc. 326 3913 Treemont Circle 327 Colleyville, Texas, 328 USA 330 Phone: +1 817 271 3552 331 Email: jmpolk@cisco.com 332 IM: xmpp:jmpolk@cisco.com 334 Parthasarathi Ravindran 335 Cisco Systems, Inc. 336 Cessna Business Park, 337 Kadabeesanahalli Village, Varthur Hobli, 338 Sarjapur-Marathahalli Outer Ring Road 339 Bangalore, Karnataka 560103 340 India 342 E-Mail: partr@cisco.com 344 Gonzalo Salgueiro 345 Cisco Systems, Inc. 346 7025 Kit Creek Rd. 347 Research Triangle Park, NC 27709 348 USA 350 Phone: +1 919 392 3266 351 Email: gsalguei@cisco.com 352 IM: xmpp:gsalguei@cisco.com