Dispatch Working Group A. Allen, Ed. Internet-Draft Blackberry Intended status: Informational February 17, 2015 Expires: August 21, 2015 Indicating that out of dialog requests related to an existing dialog must be routed via an intermediary draft-allen-dispatch-routing-out-of-dialog-request-01 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 August 21, 2015. Copyright Notice Copyright (c) 2015 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 August 21, 2015 [Page 1] Internet-Draft Out of dialog requests February 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . 4 3.5. Embed Route header fields in the contact URI . . . . . . 5 3.6. Option Tag . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Informative References . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction In RFC 3265 [1] and RFC 3515 [4] 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. While draft- ietf-sipcore-refer-explicit-subscription [6] defines a means for the sending of REFER requests to ensure that no subscription is created by the REFER recipient and thus it is safe to send the REFER request on a existing dialog the cases where notifications are needed still require the SUBSCRIBE and REFER request to be sent on a new dialog. 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 Allen Expires August 21, 2015 [Page 2] Internet-Draft Out of dialog requests February 2015 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 [7] 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 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. While some have advocated that a B2BUA should only indicate the capabilities that it understands and supports in the Contact, in the opinion of the author this is not desirable behavior because the feature tags may indicate many kinds of capabilities which do not require the support of the intermediary. For an intermediary only to indicate those capabilities that it understands and supports is a big barrier to UAs mutually exchanging feature capabilities. In the opinion of the author the feature capability indicator mechanism defined in RFC 6809 [2] is the appropriate means for an intermediary to indicate the capabilities that it supports and will allow. It also should be recognised that UAs may store Contact addresses especially if they are GRUUs for use later for originating sessions (e.g. stored in the address book) or for filtering incoming sessions (e.g. incoming sessions addressed to temporary GRUUs). So if the Contact address is overwritten then this information is lost or not valid as a contact outside the lifetime of the current dialog. Additionally the mechanism defined in RFC 6665 [3] depends on the UA receiving a GRUU as the remote target in order to avoid dialog reuse, so overwriting the Contact Address breaks this mechanism. 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 Allen Expires August 21, 2015 [Page 3] Internet-Draft Out of dialog requests February 2015 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. 3.4. New Feature Capability Indicator RFC 6809 [2] 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 Allen Expires August 21, 2015 [Page 4] Internet-Draft Out of dialog requests February 2015 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. Embed Route header fields in the contact URI The Contact URI can contain embedded header fields (see RFC 3261 [5]). The intermediary could embed a Route header field containing its own URI in the Contact URI. One advantage of this approach is that there may be some backward compatibility with this mechanism because RFC 3261 [5] compliant UAs should use the embedded Route header fields when constructing a request addressed to this Contact URI. However it is questionable as to how many implemntations actually will do this in practice. A disadvantage of this approach is if the Contact URI is secured using SMIME or a similar means for detecting man in the middle attaks on the Contact address then tampering with the URI could lead to the UAS believing that the Contact URI has been maliciously tampered with. 3.6. 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. Allen Expires August 21, 2015 [Page 5] Internet-Draft Out of dialog requests February 2015 6. Acknowledgements The author would like to thank Hadrial Kaplan, Paul Kyzivat, Christer Holmberg and Dale Worley for the inital list discussion on the issues raised by this draft and additional suggestions on the solutions. 7. Informative References [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [2] 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. [3] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012. [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [5] 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. [6] Sparks, R., , "Explicit Subscriptions for the REFER Method", Internet Draft draft-ietf-sipcore-refer-explicit- subscription-00, November 2014. [7] Kaplan, H., , "Problems with the SIP Globally Routable User Agent URIs (GRUUs)", Internet Draft draft-kaplan- dispatch-gruu-problematic-00, October 2010. Author's Address Andrew Allen (editor) Blackberry 1200 Sawgrass Corporate Parkway Sunrise, Florida 33323 USA Email: aallen@blackberry.com Allen Expires August 21, 2015 [Page 6]