Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription
Extracted elements (18)
The implicit subscription in REFER was originally required to handle forking: it allows the REFER-Issuer to observe multiple dialogs that may be established from a forked REFER. Where the REFER-Issuer explicitly prevents forking, this requirement is unnecessary.
When the REFER-Issuer already has an explicit subscription to the dialog event package at the REFER-Recipient, the implicit subscription and resulting NOTIFY traffic from REFER creates unnecessary network overhead, motivating this suppression mechanism.
A REFER-Recipient will reject a REFER request containing 'Require: norefersub' with a 420 (Bad Extension) response unless it supports this extension. The 'Require: norefersub' header can be present alongside 'Refer-Sub: false'.
The REFER remains a target refresh request even when the Refer-Sub extension is used to suppress the implicit subscription, consistent with the default REFER behavior.
When a forking proxy forwards a REFER with 'Refer-Sub', only a single 2xx response is returned to the REFER-Issuer, making it unaware of multiple forked dialogs. The REFER-Issuer bears responsibility for ensuring no forking occurs when using this extension.
If a REFER request to a given Request-URI might fork, the REFER-Issuer SHOULD NOT include the 'Refer-Sub' header field. The REFER-Issuer SHOULD use standardized mechanisms to ensure the REFER request does not fork.
If the REFER-Recipient supports the extension and is willing to process the REFER without an implicit subscription, it MUST insert 'Refer-Sub: false' in the 2xx response. If the REFER-Recipient does not include 'Refer-Sub: false' in the response, an implicit subscription is created as in the default case.
In the absence of any other anti-forking mechanism, the Request-URI of the REFER request SHOULD have Globally Routable User Agent URI (GRUU) properties, as those properties ensure the request will not fork.
The 'Refer-Sub: false' header field MAY be used by the REFER-Issuer only when the REFER-Issuer can be certain that the REFER request will not be forked.
The Refer-Sub header field MAY be used with a REFER request and the corresponding 2XX response only. It MAY be encrypted as part of end-to-end encryption.
Using the 'norefersub' tag with the Require header field is NOT RECOMMENDED when the capabilities of the REFER-Recipient are not known, because a fallback to normal REFER would require additional round-trips.
The 'norefersub' option tag, when included in the Supported header field, indicates that a UA is capable of accepting a REFER request without creating an implicit subscription when acting as a REFER-Recipient.
The 'Refer-Sub' header field is defined for use within a REFER transaction only. When set to 'false', it signals that the REFER-Issuer requests that the REFER-Recipient not establish an implicit subscription and the resultant dialog.
This document registers the 'norefersub' option tag in the SIP Option Tags sub-registry of the SIP Parameters Registry. It indicates UA ability to accept a REFER request without establishing an implicit subscription.
This document registers the 'Refer-Sub' SIP header field in the SIP Header field sub-registry of the SIP Parameters Registry. It has no compact form and is only meaningful for the REFER request and corresponding response.
A malicious inclusion of 'Refer-Sub: false' reduces processing and state requirements on the REFER-Recipient (fewer NOTIFYs generated), limiting the usefulness of this header field in denial-of-service attacks.
A man-in-the-middle attacker can insert 'Refer-Sub: false' to suppress NOTIFY messages without the REFER-Issuer noticing, or remove it to cause the REFER-Recipient to generate unwanted notifications. Integrity protection such as S/MIME is recommended to mitigate these attacks.
The Refer-Sub header field syntax is: 'Refer-Sub = "Refer-Sub" HCOLON refer-sub-value *(SEMI exten)' where refer-sub-value is 'true' or 'false', and exten is a generic-param. It is valid only in REFER requests and corresponding 2xx responses.