Dispatch Working Group A. Allen, Ed. Internet-Draft Blackberry Intended status: Informational March 11, 2014 Expires: September 12, 2014 Indicating that out of dialog requests related to an existing dialog must be routed via an intermediar draft-allen-dispatch-routing-out-of-dialog-request-00 Abstract This document discusses the problems for out of dialog requests that are related to another dialog, caused by B2BUA intermediaries that modify SIP parameters or terminate dialogs and proposes some possible solutions. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 12, 2014. Copyright Notice Copyright (c) 2014 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 Simplified BSD License. Allen Expires September 12, 2014 [Page 1] Internet-Draft Out of dialog requests March 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . . 3 3. Potential solutions . . . . . . . . . . . . . . . . . . . . . . 4 3.1. New SIP header field . . . . . . . . . . . . . . . . . . . 4 3.2. New rr-param . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. New URI parameter . . . . . . . . . . . . . . . . . . . . . 4 3.4. New Feature Capability Indicator . . . . . . . . . . . . . 5 3.5. Option Tag . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Allen Expires September 12, 2014 [Page 2] Internet-Draft Out of dialog requests March 2014 1. Introduction In RFC 3265 [1] and RFC 3515 [2] SUBCRIBE requests and REFER requests were allowed to reuse a dialog created by another SIP method (e.g. INVITE). RFC 6665 [3] has deprecated such dialog reuse due to all the problems that dialog reuse caused. However some B2BUA intermediaries change parameters in SIP requests or terminate dialogs and need to receive the SUBSCRIBE and REFER requests that relate to an existing dialog that is record routed via the B2BUA. 2. Problem statement SIP sessions often involve intermediaries acting as B2BUAs that in addition to forwarding SIP requests and responses also act as UAs to perform more complex manipulations of the session. Such manipulations include modifying URIs in the Request-URI, Contact address or other header fields and even terminating the dialog for some mid session requests (for example performing a session transfer when receiving a REFER request rather than forwarding the REFER request to the remote UAS). Typically such functionality has been achieved by sending REFER and SUBSCRIBE requests within the established dialog for the session, with the intermediary then intercepting the REFER or SUBSCRIBE request and then either modifying to conform to the expected view of the remote UAS or processing the REFER or SUBSCRIBE request rather than forwarding it to the remote UAS. However such dialog reuse has been problematic and RFC 6665 [3] has deprecated dialog reuse (except for legacy interoperability). However, if REFER and SUBSCRIBE requests are sent outside the related existing dialog then the requests will not be routed by the manipulating B2BUA and thus will either to fail to arrive at the remote UA due to URI manipulations or fail at the remote UA because parameters in the request (e.g Target-Dialog, Replaces, Refer-To URI, etc) do not match the values at the remote UAS. draft-kaplan-dispatch-gruu-problematic-00 [4] further describes some of the problems if a GRUU is used as the Request-URI of a related out of dialog request. One way B2BUAs have have addressed this problem is by acting as two UAs back-to-back with the Contact URI being overwritten to be the URI of the B2BUA. However this means that GRUU of the UA is overwritten by the B2BUA and the meaning of the Contact header field parameters becomes obscure. Do the Contact header field parameters reflect the capabilities of the Contact address (i.e the B2BUA) or do they reflect the capabilities of the remote UA? If they relect the Allen Expires September 12, 2014 [Page 3] Internet-Draft Out of dialog requests March 2014 capabilities of the B2BUA then the identfication of the capabilities of the remote UAS has been lost. If they reflect the capabilities of the remote UA then they falsely identify that the B2BUA contact address has the capabilities of the remote UA. What is needed is a way for intermediaries that need to receive and manipulate or process mid session requests to indicate that mid session out of dialog requests that relate to the dialog of the session being established, to indicate a URI to be included in the Route header of such out of dialog requests so that the request will route by the intermediary. 3. Potential solutions 3.1. New SIP header field A new SIP header field (e.g. OOD-Record-Route) could be defined which contains the URI of the intermediary for routing out of dialog requests that relate to another dialog. The intermediary would include the new header field containing the URI that the intermediary requires related out of dialog requests to be routed to in the requests and responses at dialog establishment. The UA would then include a Route header field containing the URI received in the new header field in any related out of dialog requests it sends. 3.2. New rr-param A new rr-param(e.g. OOD-RR) could be defined which indicates that this is the URI of the intermediary for routing out of dialog requests that relate to another dialog. The intermediary would include the new rr-param when including its URI in the Record-Route header field. The UA would then include a Route header field containing the URI with the associated new rr-param received in the Record-Route header field in any related out of dialog requests it sends. 3.3. New URI parameter A new URI parameter (e.g. OOD-RR) could be defined which indicates that this is the URI of the intermediary for routing out of dialog requests that relate to another dialog. The intermediary would include the new URI parameter when including its URI in the Record- Route header field. The UA would then include a Route header field containing the URI with the new URI parameter received in the Record- Route header field in any related out of dialog requests it sends. Allen Expires September 12, 2014 [Page 4] Internet-Draft Out of dialog requests March 2014 3.4. New Feature Capability Indicator RFC 6809 [5] defines the Feature-Caps header field for intermediaries to include Feature-Capability indicators indicating the capabilities they support. A new feature-capability indicator (e.g. sip.ood- route) could be defined which contains the URI of the intermediary for routing out of dialog requests that relate to another dialog. The intermediary would include a Feature-Caps header field containing the Feature-Capability indicator with the URI that the intermediary requires related out of dialog requests to be routed to in the requests and responses at dialog establishment. The UA would then include a Route header field containing the URI received in the Feature-Capability indicator in any related out of dialog requests it sends. 3.5. Option Tag A new SIP option tag will be needed for a UA to indicate that it supports the new extension so that the the intermediary can use the new mechanism instead of other approaches that modify the contact address and force dialog reuse. SIP OPTIONS method could be used by the intermediary to determine whether the UAS supports the extension before forwarding the dialog creating request. Alternatively the intermediary might modify the dialog after discovering in a response whether the UAS supports the new extension or not. 4. Security Considerations The capability to include a URI in a request or response which will cause a UA to route other requests via the intermediary provides the possibility to create man-in-the-middle attacks. However this is also true of existing SIP header fields like Record-Route. The same considerations apply as those to the use of Record-Route header fields. 5. IANA Considerations This document does not currently have anything requiring action by IANA. 6. Acknowledgements TBD. Allen Expires September 12, 2014 [Page 5] Internet-Draft Out of dialog requests March 2014 7. Informative References [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [2] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [3] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012. [4] Kaplan, H., "Problems with the SIP Globally Routable User Agent URIs (GRUUs)", Internet Draft draft-kaplan-dispatch-gruu-problematic-00, October 2010. [5] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)", RFC 6809, November 2012. Author's Address Andrew Allen (editor) Blackberry 1200 Sawgrass Corporate Parkway Sunrise, Florida 33323 USA Email: aallen@blackberry.com Allen Expires September 12, 2014 [Page 6]