SIP Working Group H. Kaplan Internet Draft Acme Packet Intended status: Standards Track Expires: May 18, 2009 November 18, 2008 A Session Identifier for the Session Initiation Protocol (SIP) draft-kaplan-sip-session-id-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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/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 May 18, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract There are several reasons for having a globally unique session identifier for the same SIP session, which can be maintained across B2BUA's and other SIP middle-boxes. This draft proposes a new SIP header to carry such a value: Session-ID. Kaplan Expires May 18, 2009 [Page 1] SIP Session Identifier November 2008 Table of Contents 1. Introduction................................................2 1.1. Example use-cases for Session-ID.......................3 2. Terminology.................................................4 3. Applicability...............................................4 4. Overview of Operation.......................................4 5. Session-ID Behavior.........................................5 5.1. Generating a Session-ID value..........................5 5.2. UAC Behavior...........................................5 5.3. Proxy Behavior.........................................5 5.4. B2BUA Behavior.........................................6 5.5. UAS Behavior...........................................6 6. New Header..................................................6 6.1. "Session-ID" header....................................6 6.2. Augmented BNF Definitions..............................6 7. Example Exchange............................................7 8. Security Considerations.....................................7 9. IANA Considerations.........................................7 10. Acknowledgments.............................................7 11. References..................................................7 11.1. Normative References...................................7 11.2. Informative References.................................7 Author's Address..................................................8 Intellectual Property Statement...................................9 Full Copyright Statement..........................................9 Acknowledgment....................................................9 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 [Replaces] headers and [dialog-events] package for matching to such, and in [SIP-Identity] and [Connected-identity] as one of the inputs for signing. Unfortunately, the Call-ID is often changed by B2BUA's and other such middle-boxes in the end-to-end message path. A B2BUA logically represents a UAS and UAC, and as such may use a new Call-ID value for the dialog it creates on its UAC half; but there are several use-cases for having a common, consistent end-to-end identifier, as described later in this draft. There are several reasons the Call-ID value is changed by B2BUA's. There are security and privacy reasons, since Call-ID values Kaplan Expires - May 2007 [Page 2] SIP Session Identifier November 2008 typically contain UA IP Addresses; some B2BUA's need to change them to keep track of spiraling dialogs; and some need to change them to keep track of separate forks. In fact, some have argued a B2BUA has no choice but to create a new one, in order to strictly comply with RFC 3261 as a UAC. In general, B2BUA's modify the Call-ID value in both directions, "fixing" it to be what each side of the B2BUA would expect. This works fine if the B2BUA is in the message path, and knows all SIP message or body contents which use or reference the value. However for subsequent out-of-dialog requests, or new SIP uses, a B2BUA often does not or cannot "fix" the value correctly. Therefore, in order to provide an identifier which will not be modified/replaced by B2BUA's, 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 B2BUA's 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 B2BUA's. 1.1. Example use-cases for Session-ID The need for a unique identifier is driven by the following use- cases: 1. Certain SIP applications need to reference dialogs in out-of- dialog requests at a layer above the SIP message dialog matching rules, and wish it to work across B2BUA domains. For example, the SIP Media Control Channel Framework [media-ctrl] needs to reference a dialog identifier used between a UAC and UAS by a third party. The mechanism originally used the Call-ID and remote/local-tags for such matching, but changed due to concerns over B2BUA's changing them, and now uses a new cfw-id SDP attribute. 2. Multiple RFC 3265 Event packages use the Call-ID value in their package bodies to reference established sessions, even though they don't actually need to match a Call-ID per se - and should work across B2BUA domains. These packages could be updated to include a Session-ID XML attribute as an alternative, optional matching criteria. 3. Several proposed and documented identity verification mechanisms need a hard-to-guess dialog identifier for verification. For example, RFC 4474 uses the Call-ID header value in its signature to prevent replay/copy-paste attacks, even though it does not need a Call-ID value per se; it just needs a unique dialog identifier. Likewise, [draft-derive] wishes to perform a reverse dialog-verification to verify a caller identity based on some Kaplan Expires - May 2007 [Page 3] SIP Session Identifier November 2008 unique identifier for the dialog; [draft-pass] creates a header- parameter to perform something similar. 4. Some SIP service providers implement call admission control (CAC) for bandwidth, and only allow SIP INVITE requests if the network has sufficient bandwidth for the given SDP. If a call request is forked by B2BUA's, or crosses them, however, the CAC model treats each fork as a separate call because there is no identifier to tie them together. This leads to rejected forks due to CAC, when they should have been allowed to proceed. A common identifier would provide the information to correlate the requests. Currently proprietary SIP headers are used for this purpose. 5. Troubleshooting SIP sessions is more complicated if multiple legs of the session are on different sides of B2BUA's, due to the lack of a common identifier to tie the legs together. Currently proprietary mechanisms are used to achieve this. 6. When SIP requests cross B2BUA's, the only form of loop detection that will stop a loop is the Max-Forwards hop-count limit being reached (value reaching zero). Via header values are removed by B2BUA's, so both spirals and simple loops cannot be detected by Via branch-parameter matching. A Session-ID value could be used to detect loops by imposing a limit on the number of times the same Session-ID can cross the same B2BUA. This would be a local decision, and an optimization, but it would be useful. 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". 3. Applicability This draft proposes a new SIP header for all requests and responses. 4. 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 the request, or a registration. The value is based on the rules for creating a pseudo-random value (a UUID?), and is inserted in a new Session-ID header defined in this draft. This Session-ID is not used for message dialog-matching rules in RFC 3261, nor does it change the Call-ID usage, nor does it replace the Kaplan Expires - May 2007 [Page 4] SIP Session Identifier November 2008 Call-ID value. Instead this new header value provides an identifier for other uses. 5. Session-ID Behavior 5.1. Generating a Session-ID value This draft proposes the Session-ID header value be generated based on a defined mechanism for creating a 128-bit pseudo-random value, and encode it as its lower-case hex representation. The reason for specifying the mechanism, and its length, is to make it impossible to determine the manufacturer of the device which generated it by looking at its format or value. 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 SBC's to modify that SDP field for "anonymization" purposes) One proposal is to generate it based on the rules for a UUID as defined in RFC 4122. [NOTE: the actual mechanism to use is TBD] 5.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 draft MUST generate a *new* unique Session-ID value whenever it generates an out-of-dialog request, or for a new Registration. The UAC MUST re- use the same Session-ID for any out-of-dialog request it retransmits or re-generates in response to a 3xx, or it re-formulates due to failure responses. 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. The UAC MUST include the Session-ID header and value in any out-of- dialog request, including Registration refreshes, and any retransmitted or regenerate out-of-dialog request. It MAY include them in in-dialog requests or responses, but since they are not used for dialog-matching rules this is not mandatory, and MUST NOT cause dialog or transaction failure if they do not match previous ones. 5.3. Proxy Behavior A Proxy MUST NOT remove or modify the Session-ID header values it receives. If the Proxy forks a request, it MUST copy the same Session-ID value into all the forked request copies. If the Proxy Kaplan Expires - May 2007 [Page 5] SIP Session Identifier November 2008 recurses requests due to 3xx redirection, or regenerates requests due to failures, it MUST use the same Session-ID value, just as the UAC does. 5.4. B2BUA Behavior A B2BUA MUST copy the Session-ID it receives in requests as a UAS, into the related requests it generates as a UAC; and any Session-ID value 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 value 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 value, just as the UAC does. 5.5. UAS Behavior A UAS MAY copy the received Session-ID value into responses and subsequent upstream requests within the dialog. 6. New Header Hdr-field when ACK BYE CAN INV OPT REG PRA INF REF UPD SUB NOT MSG ----------------------------------------------------------------- Session-ID R o o o m m m o o m o m m m Session-ID r o o o o o o o o o o o o o The header is only mandatory for out-of-dialog requests; for others it is optional. [Open Issue: should this be mandatory for all?] 6.1. "Session-ID" header This draft proposes Session-ID to be added to the definition of the element "message-header" in the SIP message grammar. The Session-ID header is a single-instance header. 6.2. Augmented BNF Definitions Session-ID = "Session-ID" HCOLON sess-id *( SEMI generic-param ) sess-id = 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] NOTE: The sess-id value is case-SENSITIVE, just as Call-ID is, however only lower-case characters are defined and allowed. Kaplan Expires - May 2007 [Page 6] SIP Session Identifier November 2008 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: f81d4fae7dec11d0a76500a0c91e6bf6 CSeq: 1 INVITE Contact: 8. Security Considerations There are no specific security issues for this mechanism, beyond those already applicable to SIP-based session signaling. [TBD] 9. IANA Considerations This document makes no request of IANA. 10. Acknowledgments Thanks to Raphael Coeffic and Bob Penfield 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. 11.2. Informative References [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002 [SIP-Identity] Peterson, J., Jennings, C., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. Kaplan Expires - May 2007 [Page 7] SIP Session Identifier November 2008 [Connected-Identity] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007. [Replaces] Elwell, J., "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [dialog-events] Elwell, J., "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [RFC4122] Leach, P., Mealling, M., Salz, R., "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005. [media-ctrl] Boulton, C., Melanchuk, T., McGlashan, S., "Media Control Channel Framework", draft-ietf-mediactrl-sip-control- framework-06, October 2008. [draft-derive] Kuthan, J., Sisalem, D., Coeffic, R., Pascual V., "Dialog Event foR Identity VErification", draft-kuthan-sip- derive-00, October 2008. [draft-pass] Kaplan, H., "Private Extensions to the Session Initiation Protocol (SIP) for Asserter Identification within Trusted Networks", draft-kaplan-sip-asserter-identity-00, July 2008. Author's Address Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: hkaplan@acmepacket.com Kaplan Expires - May 2007 [Page 8] SIP Session Identifier November 2008 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kaplan Expires - May 2007 [Page 9]