RFC 7989
End-to-End Session Identification in IP-Based Multimedia Communication Networks
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.
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.
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
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] | +--------------+----------------+-------------------+-----------+
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>.
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>.
[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>.
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.
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