draft-ietf-sipcore-refer-explicit-subscription-02.txt   draft-ietf-sipcore-refer-explicit-subscription-03.txt 
Network Working Group R. Sparks Network Working Group R. Sparks
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track April 22, 2015 Intended status: Standards Track June 25, 2015
Expires: October 24, 2015 Expires: December 27, 2015
Explicit Subscriptions for the REFER Method Explicit Subscriptions for the REFER Method
draft-ietf-sipcore-refer-explicit-subscription-02 draft-ietf-sipcore-refer-explicit-subscription-03
Abstract Abstract
The Session Initiation Protocol (SIP) REFER request, as defined by The Session Initiation Protocol (SIP) REFER request, as defined by
RFC3515, triggers an implicit SIP-Specific Event Notification RFC3515, triggers an implicit SIP-Specific Event Notification
framework subscription. Conflating the start of the subscription framework subscription. Conflating the start of the subscription
with handling the REFER request makes negotiating SUBSCRIBE with handling the REFER request makes negotiating SUBSCRIBE
extensions impossible, and complicates avoiding SIP dialog sharing. extensions impossible, and complicates avoiding SIP dialog sharing.
This document defines extensions to REFER to remove the implicit This document defines extensions to REFER to remove the implicit
subscription and, if desired, replace it with an explicit one. subscription and, if desired, replace it with an explicit one.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 24, 2015. This Internet-Draft will expire on December 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 22 skipping to change at page 5, line 22
an explicit one, a UA forming a REFER request will include the option an explicit one, a UA forming a REFER request will include the option
tag 'explicitsub' in the "Require" header field of the request. The tag 'explicitsub' in the "Require" header field of the request. The
REFER request is otherwise formed following the requirements of REFER request is otherwise formed following the requirements of
[RFC3515]. Since this REFER has no chance of creating an implicit [RFC3515]. Since this REFER has no chance of creating an implicit
subscription, the UA MAY send the REFER request within an existing subscription, the UA MAY send the REFER request within an existing
dialog or out-of-dialog. dialog or out-of-dialog.
Note that if the REFER forks (see [RFC3261]), only one final response Note that if the REFER forks (see [RFC3261]), only one final response
will be returned to the issuing UA. If it is important that the UA will be returned to the issuing UA. If it is important that the UA
be able to subscribe to any refer state generated by accepting this be able to subscribe to any refer state generated by accepting this
request, the request needs to be formed to limit the number of places request, the UA needs to form the request so that it will only be
that it will be accepted to one. This can be achieved by sending the acepted in one place. This can be achieved by sending the REFER
REFER request within an existing dialog, or by using the Target- request within an existing dialog, or by using the Target-Dialog
Dialog mechanism defined in [RFC4538]. If it is possible for the mechanism defined in [RFC4538]. If it is possible for the request to
request to be accepted in more than one location, and things would go be accepted in more than one location, and things would go wrong if
wrong if the UA did not learn about each location that the request the UA did not learn about each location that the request was
was accepted, using this extension is not appropriate. accepted, using this extension is not appropriate.
4.2. Processing a REFER Response 4.2. Processing a REFER Response
The UA will process responses to the REFER request as specified in The UA will process responses to the REFER request as specified in
[RFC3515] (and, consequently, [RFC3261]). In particular, if the [RFC3515] (and, consequently, [RFC3261]). In particular, if the
REFER was sent to an element that does not support or is unwilling to REFER was sent to an element that does not support or is unwilling to
use this extension, the response will contain a 420 Bad Extension use this extension, the response will contain a 420 Bad Extension
response code (see section 8.1.3.5 of [RFC3261]). As that document response code (see section 8.1.3.5 of [RFC3261]). As that document
states, the UA can retry the request without using this extension. states, the UA can retry the request without using this extension.
skipping to change at page 6, line 9 skipping to change at page 6, line 9
extension will use the same admissions policies that would be used extension will use the same admissions policies that would be used
without the extension, with the addition that it is acceptable to without the extension, with the addition that it is acceptable to
admit an in-dialog REFER request requiring this extension since it admit an in-dialog REFER request requiring this extension since it
can not create another usage inside that dialog. In particular, see can not create another usage inside that dialog. In particular, see
section 5.2 of [RFC3515]. section 5.2 of [RFC3515].
Accepting a REFER request that requires 'explicitsub' does not create Accepting a REFER request that requires 'explicitsub' does not create
a dialog, or a new usage within an existing dialog. The element MUST a dialog, or a new usage within an existing dialog. The element MUST
NOT create an implicit subscription when accepting the REFER request. NOT create an implicit subscription when accepting the REFER request.
If the REFER request was recieved within an existing dialog, the If the REFER request was received within an existing dialog, the
accepting element will not be acting as a SIP-Events notifier in the accepting element will not be acting as a SIP-Events notifier in the
context of that dialog. If it is not otherwise subject to becoming a context of that dialog. If it is not otherwise subject to becoming a
notifier in the context of the dialog, none of the requirements in notifier in the context of the dialog, none of the requirements in
RFC6665, particularly the requirement to provide a GRUU as the local RFC6665, particularly the requirement to provide a GRUU as the local
contact, apply to the message accepting the REFER request. contact, apply to the message accepting the REFER request.
An element that accepts a REFER request with 'explicitsub' in its An element that accepts a REFER request with 'explicitsub' in its
Require header field MUST return a 200 response containing a sip: or Require header field MUST return a 200 response containing a sip: or
sips: URI that can be used to subscribe to the refer event state sips: URI in the Refer-Events-At header field that can be used to
associated with this REFER request. This URI MUST uniquely identify subscribe to the refer event state associated with this REFER
this refer event state. The URI needs to reach the event server when request. This URI MUST uniquely identify this refer event state.
used in a SUBSCRIBE request from the element that sent the REFER. The URI needs to reach the event server when used in a SUBSCRIBE
One good way to ensure the URI provided has that property is to use a request from the element that sent the REFER. One good way to ensure
GRUU [RFC5627] for the event server. As discussed in Section 8, the URI provided has that property is to use a GRUU [RFC5627] for the
possession of this URI is often the only requirement for authorizing event server. As discussed in Section 8, possession of this URI is
a subscription to it. Implementations may wish to provide a URI often the only requirement for authorizing a subscription to it.
constructed in a way that is hard to guess. Again, using a GRUU Implementations SHOULD provide a URI constructed in a way that is
(specifically, a temporary GRUU) is one good way to achieve this hard to guess. Again, using a GRUU (specifically, a temporary GRUU)
property. is one good way to achieve this property.
The accepting element will otherwise proceed with the processing The accepting element will otherwise proceed with the processing
defined in [RFC3515]. defined in [RFC3515].
The event server identified by the Refer-Events-At URI could receive The event server identified by the Refer-Events-At URI could receive
SUBSCRIBE requests at any point after the response containing the SUBSCRIBE requests at any point after the response containing the
Refer-Events-At header is sent. Implementations should take care to Refer-Events-At header is sent. Implementations should take care to
ensure the event server is ready to receive those SUBSCRIBE requests ensure the event server is ready to receive those SUBSCRIBE requests
before sending the REFER response, but as with all non-INVITE before sending the REFER response, but as with all non-INVITE
responses, the response should be sent as soon as possible (see responses, the response should be sent as soon as possible (see
skipping to change at page 10, line 25 skipping to change at page 10, line 25
will return a 421 response indicating which extension is required. will return a 421 response indicating which extension is required.
7. Updates to RFC 3515 7. Updates to RFC 3515
The requirement in section 2.4.4 of [RFC3515] to reject out-of-dialog The requirement in section 2.4.4 of [RFC3515] to reject out-of-dialog
SUBSCRIBE requests to event 'refer' is removed. An element MAY SUBSCRIBE requests to event 'refer' is removed. An element MAY
accept a SUBSCRIBE request to event 'refer', following the accept a SUBSCRIBE request to event 'refer', following the
requirements and guidance in this document. REFER is no longer the requirements and guidance in this document. REFER is no longer the
only mechanism that can create a subscription to event 'refer'. only mechanism that can create a subscription to event 'refer'.
[RFC6665] section 8.3.1 deprecates the 202 Accepted response code.
New implementations of REFER, whether using the 'explicitsub'
extension or not, will never emit a 202 response code. Where RFC
3515 specifies using 202, new implementations MUST use 200 instead.
8. Security Considerations 8. Security Considerations
The considerations of [RFC3515] all still apply to a REFER request The considerations of [RFC3515] all still apply to a REFER request
using this extension. The considerations there for the implicit using this extension. The considerations there for the implicit
subscription apply to any explicit subscription for the 'refer' subscription apply to any explicit subscription for the 'refer'
event. event.
This update to RFC 3515 introduces a new authorization consideration. This update to RFC 3515 introduces a new authorization consideration.
An element receiving an initial SUBSCRIBE request to the 'refer' An element receiving an initial SUBSCRIBE request to the 'refer'
event needs to decide whether the subscriber should be allowed to see event needs to decide whether the subscriber should be allowed to see
the refer event state. In RFC 3515, this decision was conflated with the refer event state. In RFC 3515, this decision was conflated with
accepting the REFER request, and the only possible subscriber was the accepting the REFER request, and the only possible subscriber was the
element that sent the REFER. With this update, there may multiple element that sent the REFER. With this update, there may be multiple
subscribers to any given refer event state. subscribers to any given refer event state.
This document allows an element to accept an initial SUBSCRIBE This document allows an element to accept an initial SUBSCRIBE
request based on having a Request-URI that identifies existing refer request based on having a Request-URI that identifies existing refer
event state. (Such a URI will have previously been sent in the event state. (Such a URI will have previously been sent in the
Refer-Events-At header field in a successful REFER response). The Refer-Events-At header field in a successful REFER response). The
element retrieving that URI from the response, and any elements that element retrieving that URI from the response, and any elements that
element shares the URI with are authorized to SUBSCRIBE to the event element shares the URI with are authorized to SUBSCRIBE to the event
state. Consequently, the URI should be constructed so that it is not state. Consequently, the URI should be constructed so that it is not
easy to guess, and should be protected against eavesdroppers when easy to guess, and should be protected against eavesdroppers when
transmitted. For instance, SIP messages containing this URI SHOULD transmitted. [RFC3261] details mechanisms for providing such
be sent using TLS or DTLS (see the security considerations section of protection, such as sending SIP messages over TLS or DTLS. See the
[RFC3261] for considerations when using other security mechanisms). security considerations section of [RFC3261] for considerations when
An event server receiving a REFER request over an unprotected using other security mechanisms. An event server receiving a REFER
transport can redirect the requester to use a protected transport request over an unprotected transport can redirect the requester to
before accepting the request. A good way to ensure that use a protected transport before accepting the request. A good way
subscriptions use a protected transport is to only construct sips: to ensure that subscriptions use a protected transport is to only
URIs. The event server can also require any of the additional construct sips: URIs. The event server can also require any of the
authorization mechanisms allowed for any SIP request. For example, additional authorization mechanisms allowed for any SIP request. For
the event server could require a valid assertion of the subscriber's example, the event server could require a valid assertion of the
identity using [RFC4474]. subscriber's identity using [RFC4474].
The URI provided in a 'Refer-Events-At' header field will be used as The URI provided in a 'Refer-Events-At' header field will be used as
the Request-URI of SUBSCRIBE requests. A malicious agent could take the Request-URI of SUBSCRIBE requests. A malicious agent could take
advantage of being able to choose this URI in ways similar to the advantage of being able to choose this URI in ways similar to the
ways an agent sending a REFER request can take advantage of the ways an agent sending a REFER request can take advantage of the
Refer-To URI, as described in the security considerations section of Refer-To URI, as described in the security considerations section of
RFC 3515. In particular, the malicious agent could cause a SIP RFC 3515. In particular, the malicious agent could cause a SIP
SUBSCRIBE to be sent as raw traffic towards a victim. If the victim SUBSCRIBE to be sent as raw traffic towards a victim. If the victim
is not SIP aware, and the SUBSCRIBE is sent over UDP, there is (at is not SIP aware, and the SUBSCRIBE is sent over UDP, there is (at
most) a factor of 11 amplification due to retransmissions of the most) a factor of 11 amplification due to retransmissions of the
 End of changes. 9 change blocks. 
40 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/