Internet DRAFT - draft-allen-dispatch-routing-out-of-dialog-request
draft-allen-dispatch-routing-out-of-dialog-request
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]
