Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7989

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

Pages: 45
Proposed Standard
Obsoletes:  7329
Part 3 of 3 – Pages 37 to 45
First   Prev   None

Top   ToC   RFC7989 - Page 37   prevText

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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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