[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-jones-insipid-session-id-reqts) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 7206

Network Working Group                                      Paul E. Jones
Internet Draft                                         Gonzalo Salgueiro
Intended status: Informational                                James Polk
Expires: January 29, 2014                                  Cisco Systems
                                                             Laura Liess
                                                        Deutsche Telekom
                                                          Hadriel Kaplan
                                                                  Oracle
                                                           July 29, 2013


         Requirements for an End-to-End Session Identification in
                IP-Based Multimedia Communication Networks
                draft-ietf-insipid-session-id-reqts-08.txt


Abstract

   This document specifies the requirements for an end-to-end session
   identifier in IP-based multimedia communication networks.  This
   identifier would enable endpoints, intermediate devices, and
   management and monitoring systems to identify a session end-to-end
   across multiple SIP devices, hops, and administrative domains.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 29, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must


Jones, et al.          Expires January 29, 2014                 [Page 1]


Internet-Draft  Requirements for End-To-End Session ID         July 2013


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction...................................................2
   2. Conventions used in this document..............................3
   3. Terminology....................................................3
      3.1. What does the Session-ID Identify?........................3
      3.2. Communication Session.....................................4
      3.3. End-to-End................................................5
   4. Session Identifier Use Cases...................................5
      4.1. End-to-end identification of a communication session......5
      4.2. Protocol Interworking.....................................5
      4.3. Traffic Monitoring........................................6
      4.4. Tracking transferred sessions.............................6
      4.5. Session Signal Logging....................................6
      4.6. Identifier Syntax.........................................7
      4.7. 3PCC Use Case.............................................7
   5. Requirements for the End-to-End Session Identifier.............8
   6. Related Work in other Standards Organizations..................8
      6.1. Coordination with the ITU-T...............................8
      6.2. Requirements within 3GPP..................................9
   7. Security Considerations........................................9
   8. IANA Considerations...........................................10
   9. Acknowledgments...............................................10
   10. Contributors.................................................10
   11. References...................................................10
      11.1. Normative References....................................10
      11.2. Informative References..................................10
   Author's Addresses...............................................11

1. Introduction

   IP-based multimedia communication systems like SIP [1] and H.323 [2]
   have the concept of a "call identifier" that is globally unique.  The
   identifier is intended to represent an end-to-end communication
   session from the originating device to the terminating device.  Such
   an identifier is useful for troubleshooting, session tracking, and so
   forth.

   Unfortunately, there are a number of factors that mean that the
   current call identifiers defined in SIP and H.323 are not suitable
   for end-to-end session identification.  Perhaps most significant is
   the fact that the syntax for the call identifier in SIP and H.323 is
   different between the two protocols.  This important fact makes it
   impossible for call identifiers to be exchanged end-to-end when a
   network uses one or more session protocols.

   Another reason why the current call identifiers are not suitable to
   identify the session end-to-end is that in real-world deployments


Jones, et al.          Expires January 29, 2014                 [Page 2]


Internet-Draft  Requirements for End-To-End Session ID         July 2013


   devices like Back-to-Back User Agents often change the values as the
   session signaling passes through.  This is true even when a single
   session protocol is employed and not a byproduct of protocol
   interworking.

   Lastly, identifiers that might have been used to identify a session
   end-to-end fail to meet that need when sessions are manipulated
   through supplementary service interactions.  For example, when a
   session is transferred or if a PBX joins or merges two communication
   sessions together locally, the end-to-end properties of currently-
   defined identifiers are lost.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3] when they
   appear in ALL CAPS.  These words may also appear in this document in
   lower case as plain English words, absent their normative meanings.

3. Terminology

3.1. What does the Session-ID Identify?

   The identifier this document places requirements on, the Session
   Identifier, identifies a set of signaling messages associated with
   exactly two endpoints that, from each endpoint's perspective, are
   related to a single invocation of a communication application.

   How the endpoints determine which signaling messages share a given
   identifier (that is, what constitutes a single invocation of a
   communication application) is intentionally left loosely defined.

   The term "call" is often used as an example of such an invocation for
   voice and video communication, but different protocols and
   deployments define the scope of a "call" in different ways.  For
   instance, some systems would associate all of the activity between
   all three parties involved in a transfer a single "call".

   Similarly, the term "session" is often used as an example of such an
   invocation, but this term is overloaded to describe both signaling
   and media level interaction.  A single invocation of the
   communication application, as described above, may involve multiple
   RTP "sessions" as described by RFC 3550 [4], possibly even multiple
   concurrent sessions.

   In this document, unless otherwise qualified, the term "communication
   session", or simply "session", will refer only to the set of
   signaling messages identified by the common Session-ID identifier.
   That is, a "session" is a set of signaling messages associated with
   exactly two endpoints that, from each endpoint's perspective, are
   related to a single invocation of a communication application.


Jones, et al.          Expires January 29, 2014                 [Page 3]


Internet-Draft  Requirements for End-To-End Session ID         July 2013


   The requirements in this document put some constraint on what an
   endpoint will consider the same, or a different, invocation of a
   communication session.  They also ensure that related sessions (as
   this document is using the term) can be correlated using only the
   session identifiers for each session.  Again, what constitutes a
   "related" session is intentionally left loosely defined.

   The definition speaks of messages associated with exactly two
   endpoints instead of messages sent between two endpoints to allow for
   intermediaries that create messages on an endpoint's behalf.  It is
   possible that an endpoint may not see all of the messages in a
   session (as this document is using the term) associated with it.

   This definition, and the requirements in this document that put some
   constraint on what an endpoint should consider the same, or a
   different, invocation of a communication session facilitates
   specifying an identifier that allows the two endpoints to use two
   entirely different protocols (hence potentially have different ideas
   of what a single invocation means) or use two applications that have
   a different idea of what a single invocation means.

3.2. Communication Session

   A communication session may exist between two SIP user agents and
   that may pass through one or more intermediary devices, including
   B2BUAs or SIP proxies. For example:

          A                  Middlebox(es)                  B
          SIP message(s) ---------------------> SIP message(s)
          SIP message(s)  <-------------------  SIP message(s)

         Figure 1 - Communication Session through Middlebox(es)

   The following are examples of acceptable communication sessions:

     o A call directly between two user agents

     o A call between two user agents with one or more SIP middleboxes
       in the signaling path

     o A call between two user agents that was initiated using third-
       party call control (3PCC) [7]

     o A call between two user agents (e.g., Alice and Carol) that
       results from a different communication session (e.g., Alice and
       Bob) wherein one of those user agents (Alice) is transferred to
       another user agent (Carol) using a REFER request or a re-INVITE
       request

   The following are not considered communication sessions:




Jones, et al.          Expires January 29, 2014                 [Page 4]


Internet-Draft  Requirements for End-To-End Session ID         July 2013


     o A call between any two user agents wherein two or more user
       agents are engaged in a conference call via a conference focus

         o Each call between the user agent and the conference focus
           would be a communication session

         o Each communication session is a distinct communication
           session

     o A call between three user agents (e.g., Alice, Bob, and Carol)
       wherein the first user agent (Alice) ad hoc conferences the
       other two user agents (Bob and Carol)

         o The call between Alice and Bob would be one communication
           session

         o The call between Alice and Carol would be a different
           communication session

3.3. End-to-End

   The term "end-to-end" in this document means the communication
   session from the point of origin, passing through any number of
   intermediaries, to the ultimate point of termination. It is
   recognized that legacy devices may not support the end-to-end session
   identifier, though an identifier might be created by an intermediary
   when it is absent from the session signaling.

4. Session Identifier Use Cases

4.1. End-to-end identification of a communication session

   For SIP messaging that either does not involve SIP servers or only
   involves SIP proxies, the Call-ID header field value sufficiently
   identifies each SIP message within a transaction or dialog. This is
   not the case when either B2BUAs or SBCs are in the signaling path
   between UAs. Therefore, we need the ability to identify each
   communication session through a single SIP header field regardless of
   which type of SIP servers are in the signaling path between UAs. For
   messages that create a dialog, each message within the same dialog
   MUST use the same session identifier.

   Derived Requirements: All Requirements in Section 5

4.2. Protocol Interworking

   A communication session might originate in an H.323 [2] endpoint and
   pass through a Session Border Controller before ultimately reaching a
   terminating SIP user agent. Likewise, a call might originate on a SIP
   user agent and terminate on an H.323 endpoint. It MUST be possible to
   identify such sessions end-to-end across the plurality of devices,
   networks, or administrative domains.


Jones, et al.          Expires January 29, 2014                 [Page 5]


Internet-Draft  Requirements for End-To-End Session ID         July 2013


   It is expected that the ITU-T will define protocol elements for H.323
   to make the end-to-end signaling possible.

   Derived Requirements: REQ5, REQ7

4.3. Traffic Monitoring

   UA A and UA B communicate using SIP messaging with a SIP B2BUA acting
   as a middlebox which belongs to a SIP service provider. For privacy
   reasons, the B2BUA changes the SIP header fields that reveal
   information related to the SIP users, device or domain identity. The
   service provider uses an external device to monitor and log all SIP
   traffic coming to and from the B2BUA.  In the case of failures
   reported by the customer or when security issue arise (e.g. theft of
   service), the service provider has to analyze the logs from the past
   several days or weeks and correlates those messages which were
   messages for a single end-to-end SIP session.

   For this scenario, we must consider three particular use cases:

     a) The UAs A and B support the end-to-end Session Identifier.

        Derived Requirements: REQ1, REQ3, REQ4, REQ6.

     b) Only the UA A supports the end-to-end Session Identifier, the UA
        B does not.

        Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6.

     c) UA A and UA B do not support the end-to-end Session Identifier.

        Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6

4.4. Tracking transferred sessions

   It is difficult to track which SIP messages where involved in the
   same call across transactions, especially when invoking supplementary
   services such as call transfer or call join. There exists a need for
   the ability to track communication sessions as they are transferred,
   one side at a time, until completion of the session (i.e., until a
   BYE is sent).

   Derived Requirements: REQ1, REQ2, REQ9

4.5. Session Signal Logging

   An after-the-fact search of SIP messages to determine which messages
   were part of the same transaction or call is difficult when B2BUAs
   and SBCs are involved in the signaling between UAs.  Mapping more
   than one Call-ID together can be challenging because all of the
   values in SIP header fields on one side of the B2BUA or SBC will
   likely be different than those on the other side.  If multiple B2BUAs


Jones, et al.          Expires January 29, 2014                 [Page 6]


Internet-Draft  Requirements for End-To-End Session ID         July 2013


   and/or SBCs are in the signaling path, more than two sets of header
   field values will exist, creating more of a challenge.  Creating a
   common header field value through all SIP entities will greatly
   reduce any challenge for the purposes of debugging, communication
   tracking (such as for security purposes in case of theft of service),
   etc.

   Derived Requirements: REQ1, REQ3, REQ5, REQ6

4.6. Identifier Syntax

   A syntax that is too restrictive (e.g., one that allows special
   characters or a very long identifier) would make it difficult to
   encode the identifier in other protocols.  Therefore, the syntax of
   the identifier should be reasonably restrictive.

   Derived Requirements: REQ8

4.7. 3PCC Use Case

   Third party call control refers to the ability of an entity to create
   a call in which communication is actually between two or more
   parties. For example, a B2BUA acting as a third party controller
   could establish a call between two SIP UA's using 3PCC procedures as
   described in section 4.1 of RFC 3725 [7], the flow for which is
   reproduced below.

                 A              Controller               B
                 |(1) INVITE no SDP  |                   |
                 |<------------------|                   |
                 |(2) 200 offer1     |                   |
                 |------------------>|                   |
                 |                   |(3) INVITE offer1  |
                 |                   |------------------>|
                 |                   |(4) 200 OK answer1 |
                 |                   |<------------------|
                 |                   |(5) ACK            |
                 |                   |------------------>|
                 |(6) ACK answer1    |                   |
                 |<------------------|                   |
                 |(7) RTP            |                   |
                 |.......................................|

                     Figure 2 - Session-ID 3PCC Scenario

   Such a flow must result in a single session identifier being used for
   the communication session between UA A and UA B. This use case does
   not extend to three SIP UAs.

   Derived Requirements: REQ9




Jones, et al.          Expires January 29, 2014                 [Page 7]


Internet-Draft  Requirements for End-To-End Session ID         July 2013


5. Requirements for the End-to-End Session Identifier

   The following requirements are derived from the use cases and
   additional constraints regarding the construction of the identifier.

   REQ1: It must be possible for an administrator or an external device
   which monitors the SIP-traffic to use the identifier to identify
   those dialogs, transactions and messages which were at some point in
   time components of a single end-to-end SIP session (e.g., parts of
   the same call).

   REQ2: It must be possible to correlate two end-to-end sessions when a
   session is transferred or if two different sessions are joined
   together via an intermediary (e.g., a PBX).

   REQ3: The solution must require that the identifier, if present, pass
   unchanged through SIP B2BUAs or other intermediaries.

   REQ4: The identifier must not reveal any information related to any
   SIP user, device or domain identity.  This includes any IP Address,
   port, hostname, domain name, username, Address-of-Record, MAC
   address, IP address family, transport type, subscriber ID, Call-ID,
   tags, or other SIP header field or body parts.

   REQ5: It must be possible to identity SIP traffic with an end-to-end
   session identifier from and to end devices that do not support this
   new identifier, such as by allowing an intermediary to inject an
   identifier into the session signaling.

   REQ6: The identifier should be unique in time and space, similar to
   the Call-ID.

   REQ7: The identifier should be constructed in such a way as to make
   it suitable for transmission in SIP [1] and H.323 [2].

   REQ8: The identifier should use a restricted syntax and length so as
   to allow the identifier to be used in other protocols.

   REQ9: It must be possible to correlate two end-to-end sessions when
   the sessions are created by a third party controller using 3PCC
   procedures shown in Figure 1 of RFC 3725 [7].

6. Related Work in other Standards Organizations

6.1. Coordination with the ITU-T

   IP multimedia networks are often comprised of a mix of session
   protocols like SIP [1] and H.323 [2]. A benefit of the Session
   Identifier is that it uniquely identifies a communication session
   end-to-end across session protocol boundaries. Therefore, the need
   for coordinated standardization activities across Standards
   Development Organizations (SDOs) is imperative.


Jones, et al.          Expires January 29, 2014                 [Page 8]


Internet-Draft  Requirements for End-To-End Session ID         July 2013


   To facilitate this, a parallel effort is underway in the ITU-T to
   introduce the Session Identifier for H.323. The ITU-T SG16 has
   approved contribution C.552 [5] as a work item with the intent that
   it be a coordinated and synchronized effort between the ITU-T and the
   IETF.

6.2. Requirements within 3GPP

   3GPP identified in their Release 9 the need for a Session Identifier
   for operation and maintenance purposes to correlate flows in an end-
   to-end communication session.  3GPP TS24.229 [6] points to the fact
   that the Session Identifier can be used to correlate SIP messages
   belonging to the same session.  In the case where signaling passes
   through SIP entities like B2BUAs, the end-to-end session identifier
   indicates that these dialogs belong to the same end-to-end SIP
   communication session.

7. Security Considerations

   The security vulnerabilities, attacks, and threat models affecting
   other similar SIP identifiers are well documented in RFC 3261 and are
   equally applicable to the end-to-end session identifier and subject
   to the same mitigating security best practices.

   An end-to-end identifier, if not properly constructed, could provide
   confidential information that would allow one to identify the
   individual, device, or domain initiating or terminating a
   communication session.  In adherence with REQ4, the solution produced
   in accordance with these requirements MUST take appropriate measures
   to properly secure and obfuscate sensitive or private information
   that might allow one to identify a person, device, or domain.  This
   means that information elements such as the MAC address or IP address
   MUST NOT be used when constructing the end-to-end session identifier.
   It is outside the scope of this document to specify the
   implementation details of such security and privacy measures.  Those
   details may vary with the specific construction mechanism selected
   for the end-to-end session identifier and, therefore, will be
   discussed in suitable detail in the solution document specifying the
   actual end-to-end identifier.

   A key security consideration is to ensure that an attacker cannot
   surreptitiously spoof the identifier and effectively render it
   useless to diagnostic equipment that cannot properly correlate
   signaling messages due to the duplicate session identifiers that
   exist in the same space and time.  In accordance with REQ6, this end-
   to-end identifier MUST be sufficiently long and random to prevent it
   from being guessable as well as avoid collision with another
   identifier.  There should also be sufficient verification by any
   application using the end-to-end session identifier to ensure its
   integrity.  The secure transport of the identifier, need for
   authentication, encryption, etc. should be appropriately evaluated



Jones, et al.          Expires January 29, 2014                 [Page 9]


Internet-Draft  Requirements for End-To-End Session ID         July 2013


   based on the network infrastructure, transport domain and usage
   scenarios for the end-to-end session identifier.

8. IANA Considerations

   There are no IANA considerations associated with this document.

9. Acknowledgments

   The authors would like to acknowledge Paul Kyzivat, Christer
   Holmberg, Charles Eckel, Andy Hutton, Salvatore Loreto, Keith Drage,
   Chris Pearce for their contribution and collaboration in developing
   this document.

   This document was prepared using 2-Word-v2.0.template.dot.

10. Contributors

   Two other people originally participated as co-authors and provided
   substantial contributions to this document, namely Roland Jesske,
   Parthasarathi Ravindran.

11. References

11.1. Normative References

   [1]   Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC
         3261, June 2002.

   [2]   Recommendation ITU-T H.323, "Packet-based multimedia
         communications systems", December 2009.

   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

11.2. Informative References

   [4]   Schulzrinne, H., et al., "RTP: A Transport Protocol for Real-
         Time Applications", RFC 3550, July 2003.

   [5]   International Telecommunications Union, "End-to-End Session
         Identifier for IP-based Multimedia Communication Systems",
         March 2011, ITU-T Contribution C.552, http://ftp3.itu.int/av-
         arch/avc-site/2009-2012/1103_Gen/SessionID.zip.

   [6]   3GPP TS 24.229, "IP multimedia call control protocol based on
         Session Initiation Protocol (SIP) and Session Description
         Protocol (SDP); Stage 3".

   [7]   Rosenberg, J., Peterson, J., Schulzrinne, H., Camarillo, G.,
         "Best Current Practices for Third Party Call Control (3pcc) in
         the Session Initiation Protocol (SIP)", RFC 3725, April 2004.


Jones, et al.          Expires January 29, 2014                [Page 10]


Internet-Draft  Requirements for End-To-End Session ID         July 2013


Author's Addresses

   Paul E. Jones
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC 27709
   USA

   Phone: +1 919 476 2048
   Email: paulej@packetizer.com
   IM: xmpp:paulej@packetizer.com


   Hadriel Kaplan
   Oracle
   71 Third Ave.
   Burlington, MA 01803, USA

   Email: hadriel.kaplan@oracle.com


   Laura Liess
   Deutsche Telekom NP
   64295 Darmstadt
   Heinrich-Hertz-Str. 3-7
   Germany

   Phone: +49 6151 268 2761
   Email: laura.liess.dt@gmail.com


   James Polk
   Cisco Systems, Inc.
   3913 Treemont Circle
   Colleyville, Texas,
   USA

   Phone: +1 817 271 3552
   Email: jmpolk@cisco.com
   IM: xmpp:jmpolk@cisco.com


   Gonzalo Salgueiro
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC 27709
   USA

   Phone: +1 919 392 3266
   Email: gsalguei@cisco.com
   IM: xmpp:gsalguei@cisco.com



Jones, et al.          Expires January 29, 2014                [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/