Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 7989

 
 
 

End-to-End Session Identification in IP-Based Multimedia Communication Networks

Part 3 of 3, p. 37 to 45
Prev Section

 


prevText      Top      ToC       Page 37 
11.  Compatibility with a Previous Implementation

   There is a much earlier document that specifies the use of a Session-
   ID header field (namely, [RFC7329]) that we will herewith attempt to
   achieve backwards compatibility.  Neither Session-ID header field has
   any versioning information, so merely adding that this document
   describes "version 2" is insufficient.  This section contains the set
   of rules for compatibility between the two specifications.  Although
   the previous version was never standardized, it has been heavily
   implemented and adopted by other standards development organizations.
   For the purposes of this discussion, we will label the pre-standard
   specification of the Session-ID as the "old" version and this
   specification as the "new" version of the Session-ID.

   The previous (i.e., "old") version only has a single UUID value as a
   Session-ID header field value, but has a generic-parameter value that
   can be of use.

   In order to have an "old" version talk to an "old" version
   implementation, nothing needs to be done as far as the IETF is
   concerned.

   In order to have a "new" version talk to a "new" version
   implementation, both implementations need to follow this document (to
   the letter) and everything should be just fine.

Top      Up      ToC       Page 38 
   For this "new" implementation to work with the "old" implementation
   and an "old" implementation to work with "new" implementations, there
   needs to be a set of rules that all "new" implementations MUST follow
   if the "new" implementation will be communicating with devices that
   have implemented the "old" implementation.

   o  Since no option tags or feature tags are to be used for
      distinguishing versions, the presence and order of any "remote-
      uuid" value within the Session-ID header field value is to be used
      to distinguish implementation versions.

   o  If a SIP request has a "remote-uuid" value, this comes from a
      standard implementation, and not a pre-standard one.

   o  If a SIP request has no "remote-uuid" value, this comes from a
      pre-standard implementation, and not a standard one.  In this
      case, one UUID is used to identify this dialog, even if the
      responder is a standard implementor of this specification.

   o  If a SIP response has a non-nil "local-uuid" that is 32 octets
      long and differs from the endpoint's own UUID value, this response
      comes from a standard implementation.

   o  If a SIP response arrives that has the same value of Session-ID
      UUIDs in the same order as was sent, this comes from a pre-
      standard implementation and MUST NOT be discarded even though the
      "remote-uuid" may be nil.  In this case, any new transaction
      within this dialog MUST preserve the order of the two UUIDs within
      all Session-ID header fields, including the ACK, until this dialog
      is terminated.

   o  If a SIP response only contains the "local-uuid" that was sent
      originally, this comes from a pre-standard implementation and MUST
      NOT be discarded for removing the nil "remote-uuid".  In this
      case, all future transactions within this dialog MUST contain only
      the UUID received in the first SIP response.  Any new transaction
      starting a new dialog from the standard Session-ID implementation
      MUST include a "local-uuid" and a nil "remote-uuid", even if that
      new dialog is between the same two UAs.

   o  Standard implementations should not expect pre-standard
      implementations to be consistent in their implementation, even
      within the same dialog.  For example, perhaps the first, third,
      and tenth responses contain a "remote-uuid", but all the others do
      not.  This behavior MUST be allowed by implementations of this
      specification.

Top      Up      ToC       Page 39 
   o  The foregoing does not apply to other, presently unknown
      parameters that might be defined in the future.  They are ignored
      for the purposes of interoperability with previous
      implementations.

12.  Security and Privacy Considerations

   The session identifier MUST be constructed in such a way that does
   not convey any user or device information as outlined in Section 4.1.
   This ensures that the data contained in the session identifier itself
   does not convey user or device information; however, the session
   identifier may reveal relationships between endpoints that might not
   be revealed by messages without a session identifier.

   Section 4.2 requires that a UA always generate a new, previously
   unused UUID when transmitting a request to initiate a new session.
   This ensures that two unrelated sessions originating from the same UA
   will never have the same UUID value, thereby removing the ability for
   an attacker to use the session identifier to identify the two
   unrelated sessions as being associated with the same user.

   Because of the inherent property that session identifiers are
   conveyed end-to-end and remain unchanged by a UA for the duration of
   a session, the session identifier could be misused to discover
   relationships between two or more parties when multiple parties are
   involved in the same session such as the case of a redirect,
   transfer, or conference.  For example, suppose that Alice calls Bob
   and Bob, via his PBX (acting as a B2BUA), forwards or transfers the
   call to Carol.  Without use of the session identifier, an
   unauthorized third party that is observing the communications between
   Alice and Bob might not know that Alice is actually communicating
   with Carol.  If Alice, Bob, and Carol include the session identifier
   as a part of the signaling messages, it is possible for the third
   party to observe that the UA associated with Bob changed to some
   other UA.  If the third party also has access to signaling messages
   between Bob and Carol, the third party can then discover that Alice
   is communicating with Carol.  This would be true even if all other
   information relating to the session is changed by the PBX, including
   both signaling information and media address information.  That said,
   the session identifier would not reveal the identity of Alice, Bob,
   or Carol.  It would only reveal the fact that those endpoints were
   associated with the same session.

   This document allows for additional parameters (generic-param) to be
   included in the Session-ID header.  This is done to allow for future
   extensions while preserving backward compatibility with this
   document.  To protect privacy, the data for any generic-param
   included in the Session-ID header value MUST NOT include any user or

Top      Up      ToC       Page 40 
   device information.  Additionally, any information conveyed through
   an additional parameter MUST NOT persist beyond the current session,
   and therefore MUST NOT be reused between unrelated sessions.
   Additional parameters MAY be used by future extensions of this
   document to correlate related communication sessions that cannot
   already be correlated by the procedures described in this document as
   long as the requirements regarding privacy and persistence defined
   above are followed.

   An intermediary implementing a privacy service that provides user
   privacy as per Section 5.3 of [RFC3323] MAY choose to consider the
   Session-ID header as being a nonessential informational header with
   the understanding that doing so will impair the ability to use the
   session identifier for troubleshooting purposes.

13.  IANA Considerations

13.1.  Registration of the "Session-ID" Header Field

   The following is the registration for the Session-ID header field to
   the "Header Name" registry at

   <http://www.iana.org/assignments/sip-parameters>:

   RFC number: RFC 7989

   Header name: 'Session-ID'

   Compact form: none

   Note: This document replaces the Session-ID header originally
   registered via [RFC7329].

13.2.  Registration of the "remote" Parameter

   The following parameter has been added to the "Header Field
   Parameters and Parameter Values" section of the "Session Initiation
   Protocol (SIP) Parameters" registry:

     +--------------+----------------+-------------------+-----------+
     | Header Field | Parameter Name | Predefined Values | Reference |
     +--------------+----------------+-------------------+-----------+
     |  Session-ID  |     remote     |         No        | [RFC7989] |
     +--------------+----------------+-------------------+-----------+

Top      Up      ToC       Page 41 
14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <http://www.rfc-editor.org/info/rfc3261>.

   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
              Method", RFC 3515, DOI 10.17487/RFC3515, April 2003,
              <http://www.rfc-editor.org/info/rfc3515>.

   [RFC3891]  Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
              Protocol (SIP) "Replaces" Header", RFC 3891,
              DOI 10.17487/RFC3891, September 2004,
              <http://www.rfc-editor.org/info/rfc3891>.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              DOI 10.17487/RFC4122, July 2005,
              <http://www.rfc-editor.org/info/rfc4122>.

   [RFC4579]  Johnston, A. and O. Levin, "Session Initiation Protocol
              (SIP) Call Control - Conferencing for User Agents",
              BCP 119, RFC 4579, DOI 10.17487/RFC4579, August 2006,
              <http://www.rfc-editor.org/info/rfc4579>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [RFC7206]  Jones, P., Salgueiro, G., Polk, J., Liess, L., and H.
              Kaplan, "Requirements for an End-to-End Session
              Identification in IP-Based Multimedia Communication
              Networks", RFC 7206, DOI 10.17487/RFC7206, May 2014,
              <http://www.rfc-editor.org/info/rfc7206>.

Top      Up      ToC       Page 42 
14.2.  Informative References

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

   [H.460.27] International Telecommunications Union, "End-to-End
              Session Identifier for H.323 Systems", ITU-T
              Recommendation H.460.27, November 2015.

   [RFC2543]  Handley, M., Schulzrinne, H., Schooler, E., and J.
              Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
              DOI 10.17487/RFC2543, March 1999,
              <http://www.rfc-editor.org/info/rfc2543>.

   [RFC3323]  Peterson, J., "A Privacy Mechanism for the Session
              Initiation Protocol (SIP)", RFC 3323,
              DOI 10.17487/RFC3323, November 2002,
              <http://www.rfc-editor.org/info/rfc3323>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <http://www.rfc-editor.org/info/rfc3550>.

   [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
              Camarillo, "Best Current Practices for Third Party Call
              Control (3pcc) in the Session Initiation Protocol (SIP)",
              BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,
              <http://www.rfc-editor.org/info/rfc3725>.

   [RFC4353]  Rosenberg, J., "A Framework for Conferencing with the
              Session Initiation Protocol (SIP)", RFC 4353,
              DOI 10.17487/RFC4353, February 2006,
              <http://www.rfc-editor.org/info/rfc4353>.

   [RFC5359]  Johnston, A., Ed., Sparks, R., Cunningham, C., Donovan,
              S., and K. Summers, "Session Initiation Protocol Service
              Examples", BCP 144, RFC 5359, DOI 10.17487/RFC5359,
              October 2008, <http://www.rfc-editor.org/info/rfc5359>.

   [RFC5589]  Sparks, R., Johnston, A., Ed., and D. Petrie, "Session
              Initiation Protocol (SIP) Call Control - Transfer",
              BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009,
              <http://www.rfc-editor.org/info/rfc5589>.

Top      Up      ToC       Page 43 
   [RFC6141]  Camarillo, G., Ed., Holmberg, C., and Y. Gao, "Re-INVITE
              and Target-Refresh Request Handling in the Session
              Initiation Protocol (SIP)", RFC 6141,
              DOI 10.17487/RFC6141, March 2011,
              <http://www.rfc-editor.org/info/rfc6141>.

   [RFC6872]  Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur,
              H., and O. Festor, "The Common Log Format (CLF) for the
              Session Initiation Protocol (SIP): Framework and
              Information Model", RFC 6872, DOI 10.17487/RFC6872,
              February 2013, <http://www.rfc-editor.org/info/rfc6872>.

   [RFC7092]  Kaplan, H. and V. Pascual, "A Taxonomy of Session
              Initiation Protocol (SIP) Back-to-Back User Agents",
              RFC 7092, DOI 10.17487/RFC7092, December 2013,
              <http://www.rfc-editor.org/info/rfc7092>.

   [RFC7329]  Kaplan, H., "A Session Identifier for the Session
              Initiation Protocol (SIP)", RFC 7329,
              DOI 10.17487/RFC7329, August 2014,
              <http://www.rfc-editor.org/info/rfc7329>.

Top      Up      ToC       Page 44 
Acknowledgements

   The authors would like to thank Robert Sparks, Hadriel Kaplan,
   Christer Holmberg, Paul Kyzivat, Brett Tate, Keith Drage, Mary
   Barnes, Charles Eckel, Peter Dawes, Andrew Hutton, Arun Arunachalam,
   Adam Gensler, Roland Jesske, and Faisal Siyavudeen for their
   invaluable comments during the development of this document.

Dedication

   This document is dedicated to the memory of James Polk, a long-time
   friend and colleague.  James made important contributions to this
   specification, including being one of its primary editors.  The IETF
   global community mourns his loss, and he will be missed dearly.

Top      Up      ToC       Page 45 
Authors' Addresses

   Paul E. Jones
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC  27709
   United States of America

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


   Gonzalo Salgueiro
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC  27709
   United States of America

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


   Chris Pearce
   Cisco Systems, Inc.
   2300 East President George Bush Highway
   Richardson, TX  75082
   United States of America

   Phone: +1 972 813 5123
   Email: chrep@cisco.com


   Paul Giralt
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC  27709
   United States of America

   Phone: +1 919 991 5644
   Email: pgiralt@cisco.com