ISPATCH Working Group H. Kaplan Internet Draft Acme Packet Intended status: Informational Expires: October 17, 2010 April 17, 2010 A Session Identifier for the Session Initiation Protocol (SIP) draft-kaplan-dispatch-session-id-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 17, 2010. Copyright and License Notice Copyright (c) 2010 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 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 BSD License. Kaplan Expires October 17, 2010 [Page 1] Internet-Draft SIP Session Identifier April 2010 Abstract There is a need for having a globally unique session identifier for the same SIP session, which can be consistently maintained across Proxies, B2BUAs and other SIP middle-boxes, for the purpose of Troubleshooting. This draft proposes a new SIP header to carry such a value: Session-ID. Table of Contents 1. Introduction................................................2 1.1. Requirements...........................................3 2. Terminology.................................................4 3. Overview of Operation.......................................4 4. Session-ID Behavior.........................................4 4.1. Generating a Session-ID value..........................4 4.2. UAC Behavior...........................................5 4.3. UAS Behavior...........................................6 4.4. Proxy Behavior.........................................6 4.5. B2BUA Behavior.........................................7 4.5.1 B2BUA Generation of New Session-ID 7 4.5.2 B2BUA Insertion of Saved Session-ID 8 5. Session-ID Migration and Failure Scenarios..................8 6. New 'Session-ID' Header.....................................8 6.1. Augmented BNF Definitions..............................9 7. Example Exchange............................................9 8. Security Considerations.....................................9 8.1. Security considerations for administrators.............9 8.2. Security considerations for Session-ID extensions.....10 9. IANA Considerations........................................10 10. Acknowledgments............................................10 11. References.................................................10 11.1. Normative References..................................10 Author's Address.................................................11 1. Introduction The SIP [RFC3261] Call-ID header value is a globally unique identifier, mandatory in all requests/responses, which identifies SIP messages belonging to the same dialog or registration. It provides a portion of the SIP message dialog-matching criteria, and is used in such things as [Replaces] headers and [dialog-events] package for matching to dialogs, and in [SIP-Identity] and [Connected-identity] as one of the inputs for signing. In practice, the Call-ID is often changed by B2BUAs and other such middle-boxes in the logical end-to-end message path. A B2BUA logically represents a UAS and UAC, and as such generates a new Kaplan Expires - October 2010 [Page 2] Internet-Draft SIP Session Identifier April 2010 Call-ID value for the dialog it creates on its UAC side; in fact for some B2BUA scenarios the Call-ID must be changed for SIP to function properly. At the same time, there is a need for a unique, common, consistent end-to-end identifier to help troubleshoot SIP sessions and message- flows as they cross SIP nodes. Troubleshooting is more complicated if multiple legs of the session are on different sides of B2BUAs, due to the lack of a common identifier such as a Call-ID to tie the legs together. Proprietary mechanisms are currently used to achieve this goal. Therefore, in order to provide an identifier which will not be modified/replaced by B2BUAs, this draft proposes a new SIP Header "Session-ID", and mandatory rules for the value of such a header. The rules are designed to be such that the value in the Session-ID header is not considered unsafe, private, or have any property which would cause B2BUAs to change it. The goal of this draft is to enable use-cases which need a unique identifier for a given session which can successfully cross B2BUAs, such as Application Servers, Softswitches, PBXs, SBCs, Feature Servers, etc. 1.1. Requirements The following requirements drive the need for Session-ID: REQ1: It must be possible for an administrator to use the identifier to identify a set of dialogs which have a direct correlation with each other such that they represent the same SIP session, with as high a probability as possible. REQ2: It must be possible to pass the identifier through SIP B2BUAs, with as high a probability as possible. This requirement drives the following requirements: REQ2a: The identifier must not reveal any information related to any SIP device or domain identity, including IP Address, port, hostname, domain name, username, Address-of-Record, MAC address, IP address family, transport type, etc. REQ2b: The identifier must not reveal to the receiver of it that the Call-ID, tags, or any other SIP header or body portion have been changed by middle-boxes, with as high a probability as possible. REQ2c: The identifier must not be used for anything at a SIP layer to change the behavior of the SIP protocol. Kaplan Expires - October 2010 [Page 3] Internet-Draft SIP Session Identifier April 2010 2. Terminology 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. The terminology in this document conforms to RFC 2828, "Internet Security Glossary". This document uses the terms "header field" and "header field value" following the definition of those terms in [RFC3261], which are not interchangeable. The "header field" is the entire SIP header's contents, including any parameters. The "header field value" is only the field-value portion, which does not include header parameters. 3. Overview of Operation The general concept is that the UAC generating an out-of-dialog request generates a new, pseudo-random, unique value which remains constant for the duration of the transaction, any dialog created from that request, or for a registration. The value is inserted in a new Session-ID header field defined in this draft. The UAC and UAS then reflect this header field value in all messages for the duration of the dialog. In other words, the Session-ID provides a value similar in nature to Call-ID, except one which crosses B2BUAs and which has no sensitive information in it. To aid in migration of deployments, a B2BUA or Proxy MAY also generate and/or insert the value on behalf of a UAC or UAS, if one or the other does not support this document's mechanism. Although the Session-ID concept is similar to the Call-ID, it is not used for message dialog-matching rules in RFC 3261, nor does it change the Call-ID usage, nor does it replace the Call-ID value. Instead this new header field provides an identifier for troubleshooting uses only. The format of the Session-ID value is restricted, both to avoid detection of the system type which generated it, and to keep it a hexadecimal representation such that it can be stored as a 64-bit binary value in log records. 4. Session-ID Behavior 4.1. Generating a Session-ID value This draft mandates the Session-ID header field value be pseudo- random value encoded as a token string of 16 characters in length, comprised of the characters of a-f and 0-9 only. In other words, it Kaplan Expires - October 2010 [Page 4] Internet-Draft SIP Session Identifier April 2010 can be represented as a 64-bit binary value, encoded as lower-case hexadecimal ascii. The algorithm to generate the value is left up to specific implementations, however it MUST have the following properties: - The value MUST be unique for each SIP Dialog or Registration, as described previously. - The value MUST contain 64 bits of randomness, in order to avoid global collisions and detecting the vendor type. - The value MUST NOT contain any fixed character or character sequence which is the same for all Session-ID values generated by the same system. - The value MUST NOT contain any pattern which could reveal the specific vendor or product type, for a single Session-ID value. - The value MUST NOT contain any portion which reveals the IP Address, hostname or domain name in any form. One way to achieve the above properties is to base the Session-ID off of the Call-ID value, by using a one-way digest mechanism with a private key, and encoding the results in hexadecimal ascii. Another way would be to simply create a random 64-bit number and encode it in hexadecimal ascii. Note that if a system needs to pad a value to make the Session-ID value 16 characters, it would fail to meet the requirements above if the pad were of a fixed character sequence, or a fixed string generated from a non-pseudo-random algorithm. The reason for specifying these properties and the length is to make it impossible to determine the manufacturer of the device which generated it by looking at the format or value of a received Session-ID header field. For example, the theoretically random "session id" value in SDP origin line has been found to be fairly vendor-specific in nature, and one can narrow the vendor that generated the SDP simply by the origin session id value. (In fact, this drove some SIP intermediaries to modify that SDP field for "anonymization" purposes) In order to enable trouble-shooting of in-dialog messages, a generator needs to remember or re-create the same Session-ID value for the duration of a given dialog(s). This is described in more detail in following sections of this document. 4.2. UAC Behavior The rules for when a UAC generates a new Session-ID value are similar as those for Call-ID value: a UAC supporting this document's mechanism MUST generate a new unique Session-ID value whenever it generates an out-of-dialog request, or for a new Registration. The Kaplan Expires - October 2010 [Page 5] Internet-Draft SIP Session Identifier April 2010 UAC MUST re-use the same Session-ID value for in-dialog messages, and for any out-of-dialog request it retransmits or re-generates in response to a 3xx, or it re-formulates due to failure responses. This follows the rules in [RFC3261] for Call-ID generation. Session-ID values in Registration "refreshes" - REGISTER requests which are used to update the expiry time but not to register a new contact - MUST use the same Session-ID value as previous REGISTER requests. New Registrations, which add or change the Contact URI for the AoR, but not simply to delete them, MUST use a new Session- ID value. This follows the behavior of Call-ID per RFC 3261; it is re-iterated here because some devices incorrectly change their Call- ID value for every re-Registration, and MUST NOT do the same to the Session-ID. The UAC MUST include the Session-ID header field in every SIP message it transmits. 4.3. UAS Behavior A UAS compliant with this document MUST copy a received Session-ID header field in a request, into responses and subsequent upstream requests sent within the dialog. If an out-of-dialog request is received without a Session-ID header field, the UAS SHOULD generate a new one for subsequent use in the transaction and dialog, as defined for a UAC, and use the same value in all responses and upstream in-dialog requests for the same dialog. 4.4. Proxy Behavior A Proxy MUST NOT remove or modify the Session-ID header field it receives, if one is in the message. By definition, an RFC 3261 compliant Proxy would not modify or remove such a header. If the Proxy forks a request, it MUST copy the same Session-ID header field into all the forked request copies. If the Proxy recurses requests due to 3xx redirection, or regenerates requests due to failures, it MUST use the same Session-ID header field as the original request, just as the UAC does. If the Proxy locally generates any response or request based on a received request, including 100 Trying, it MUST insert any received Session-ID header field from the original request into the response message it locally creates. This is necessary for troubleshooting purposes. Kaplan Expires - October 2010 [Page 6] Internet-Draft SIP Session Identifier April 2010 A Proxy compliant with this draft MAY generate a new Session-ID or insert a previously saved one, if and only if none existed in a received message, following the rules for doing so as a B2BUA defined later. 4.5. B2BUA Behavior A B2BUA compliant with this document MUST copy the Session-ID header field it receives in requests as a UAS into the related requests it generates as a UAC; and any Session-ID field it receives in responses as a UAC into the correlated responses it generates as a UAS. If the B2BUA forks or creates multiple requests as a UAC, from a request it received as a UAS, the B2BUA MUST copy the same Session- ID header field it received into all the forks/requests. If the B2BUA recurses requests due to 3xx redirection, or regenerates requests due to failures, it MUST use the same Session-ID field, just as the UAC does. If the B2BUA locally generates any response or request based on a received request, including 100 Trying, it MUST insert any received Session-ID field from the original request into the response message it locally creates. A B2BUA MAY remember the received Session-ID value for the duration of the transaction and dialog, for the purpose of re-insertion, in case the far-end does not support this draft. In all cases, if the SIP message received by a B2BUA contained a Session-ID header field, a B2BUA compliant with this document MUST NOT remove, modify or replace it as it "forwards" the message on the other logical UA "side" of itself. 4.5.1 B2BUA Generation of New Session-ID If an out-of-dialog request is received by a B2BUA compliant with this document, and the request does *not* contain a Session-ID header field, the B2BUA MAY generate a new one. It MUST then insert it in any requests or responses it generates, as if it had actually received the new Session-ID from the UAC, following the rules previously defined for a B2BUA. This allows for a B2BUA to provide a migration to Session-ID deployment, on behalf of upstream nodes that do not yet support it. As defined previously, if any received message already had a Session-ID, a B2BUA compliant with this document would not replace it. Kaplan Expires - October 2010 [Page 7] Internet-Draft SIP Session Identifier April 2010 4.5.2 B2BUA Insertion of Saved Session-ID If a Session-ID was received in an out-of-dialog request, or the B2BUA locally generated one because none existed, the B2BUA SHOULD insert the same Session-ID field into all responses and upstream in- dialog requests if and only if a Session-ID is not already in them. This allows for a B2BUA to provide a migration to Session-ID deployment, on behalf of downstream nodes that do not yet support it. 5. Session-ID Migration and Failure Scenarios SIP is already widely deployed on the Internet, and it is impractical to expect all UAs to be upgraded to support this document's mechanism in the near future. A solution for gradual migration is necessary, which this document provides by allowing B2BUAs or Proxies to perform the Session-ID generator and inserter role. Even within those device types, it is impractical to expect all B2BUAs to support this mechanism all at once, or any time in the near future. Therefore, it is expected that some B2BUAs and/or UAs will support generating and inserting Session-ID, while others will not support Session-ID at all. Due to the varying types of B2BUAs, such as PBXs, SBCs, Application Servers, Feature Servers, and Softswitches of various flavors, and the numerous SIP deployment models in use, there are going to be cases in which Session-ID will fail to be a consistent value for all related dialogs, or fail to successfully match. The goal of this draft is to improve troubleshooting of current deployments as much as possible - not to cover all possible scenarios - and in this author's opinion that is the best that can be done given the constraints. One example is for forked requests: if a UAC which does not support this mechanism sends a request to a Proxy or B2BUA which also does not support this mechanism, each fork could reach B2BUAs or UASs which *do* support this mechanism. In such a case, each of those forked-to B2BUA/UAS will generate unique Session-IDs and put them in their responses, leading to two different Session-ID values for the same related early dialogs temporarily. Typically, the UAC would eventually only accept one of the dialogs, and only one Session-ID would remain. 6. New 'Session-ID' Header This draft adds the "Session-ID" token to the definition of the element "message-header" in the SIP message grammar. The Session-ID header is a single-instance header. Kaplan Expires - October 2010 [Page 8] Internet-Draft SIP Session Identifier April 2010 6.1. Augmented BNF Definitions Session-ID = "Session-ID" HCOLON sess-id *( SEMI generic-param ) sess-id = 16(DIGIT / %x61-66) ;16 chars of [0-9a-f] NOTE: The sess-id value is technically case-INSENSITIVE, but note that only lower-case characters are allowed. See the Security Considerations section for discussion about using header parameters in Session-ID header fields. 7. Example Exchange In the following example, Alice initiates a call to Bob. Alice generates a Session-ID header in the out-of-dialog INVITE. Alice generates the following: (note: much has been left out for simplicity) INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 From: Alice ;tag=1234567 To: Bob Call-Id: 123456mcmxcix@1.2.3.4 Session-ID: f81d4fae7dec11d0 CSeq: 1 INVITE Contact: 8. Security Considerations There are several security considerations surrounding this document's mechanism. The Session-ID generation algorithm should provide a reasonably random 16-character Session-ID value, to avoid collisions, and would not let one re-create the original Call-ID. There is no known security issue with viewing or modifying the Session-ID, other than to hamper troubleshooting efforts. 8.1. Security considerations for administrators The requirement for the Session-ID is to be an identifier which cannot be used by a recipient to identify if the Call-ID has been changed by middle-boxes. As such, a UAS/UAC cannot detect the original Call-ID, nor whether it has been changed, and thus should not cause administrators concern to be "passed through". Kaplan Expires - October 2010 [Page 9] Internet-Draft SIP Session Identifier April 2010 8.2. Security considerations for Session-ID extensions In general, B2BUA behavior cannot be dictated by standards. They do whatever their owners/operators wish them to do, or whatever is necessary to make their applications work. This document attempts to normatively specify some B2BUA behavior, by creating a SIP header value for which the properties are such that B2BUAs should have no legitimate reason to interfere. This effectively creates a "promise" that future uses of this Session-ID header field, including its value *and* any future defined parameters, maintain this benign property. Any future extensions to the Session-ID mechanism and header field MUST maintain this property, or else B2BUAs will begin to modify it again or remove it, and its value will be lost. Manufacturers of SIP devices should note that there is no guarantee that a B2BUA will not inspect the Session-ID header field, and remove it if it does not comply with this document's value restrictions. Any Session-ID header parameters MUST be registered with IANA and documented in IETF RFCs, pursuant to the requirements of [RFC3968]. 9. IANA Considerations This document asks IANA to register a new SIP header field named 'Session-ID', pursuant to the registration policies for such in [RFC5727]. This is a single-instance header field, and is appropriate for any SIP message, of any Method type, in any request or response. The ABNF rules for this new header allow for header parameters, however they must be registered following the rules of [RFC3968], as required by [RFC5727]. 10. Acknowledgments Thanks to Raphael Coeffic, Bob Penfield, Dale Worley, Paul Kyzivat, Ian Elz, Marco Stura, Martin Dolly, Martin Huelsemann, and Laura Liess for their input. 11. References 11.1. Normative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Kaplan Expires - October 2010 [Page 10] Internet-Draft SIP Session Identifier April 2010 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", RFC 3968, December 2004. [RFC5727] Peterson, J., Jennings, C., Sparks, R., "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", RFC 5727, March 2010. Author's Address Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: hkaplan@acmepacket.com Kaplan Expires - October 2010 [Page 11]