RFC 4488

Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription

📅 published May 2006, from ietf

RFC 4488: Suppression of SIP REFER Method Implicit Subscription 💌

okay so RFC 4488 is by O. Levin from Microsoft Corporation 💼, it lives in the Network Working Group 🌸, and it's a Standards Track doc dated May 2006 📅. It doesn't obsolete or update anything, since the header doesn't list any RFCs in either slot 🙅‍♀️. The whole vibe is fixing a SIP REFER quirk, so let's get into it 🦋

Status of This Memo ✨

okay, this part is the legal boilerplate, but it matters 💅 This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (2006). ✨

Abstract 🧚

so the SIP REFER extension from RFC 3515 automatically sets up an event subscription 🔔 It's usually short-lived, and it exists to tell whoever sent the REFER how the receiver is doing with the thing the REFER asked for 📬 But honestly, those notifications aren't needed in every case 🙈 This spec gives you a way to stop that automatic subscription (and the notifications that come with it) with a brand-new SIP extension header field that can go inside a REFER request 💖

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5.  Preventing Forking of REFER Requests  . . . . . . . . . . . . . 4
6.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
    10.1.  Normative References . . . . . . . . . . . . . . . . . . 7
    10.2.  Informative References . . . . . . . . . . . . . . . . . 7

1. Introduction 💫

okay so the REFER spec says every REFER creates an implicit subscription between the REFER-Issuer and the REFER-Recipient 🔁 [3]

this doc adds a new SIP header field called "Refer-Sub" 🎀 It only means something inside a REFER transaction. When it's set to "false", the REFER-Issuer is basically asking the REFER-Recipient not to set up an implicit subscription and the resulting dialog 🙏

it also adds a new option tag called "norefersub" 🏷️ If a UA puts that tag in its Supported header field, it's saying it can accept a REFER without making an implicit subscription when it's the REFER-Recipient ✨

2. Terminology 📖

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1] 💅

to keep things simple when we talk about REFER and its extensions, there are three terms we'll use all the time 🧚‍♀️

  • REFER-Issuer: the UA issuing the REFER request 📤
  • REFER-Recipient: the UA receiving the REFER request 📥
  • REFER-Target: the UA designated in the Refer-To Uniform Resource Identifier (URI) 🎯

3. Motivation 🌷

the REFER spec basically requires that every REFER creates an implicit subscription between the REFER-Issuer and the REFER-Recipient 🔗 That subscription results in at least one NOTIFY going from the REFER-Recipient back to the REFER-Issuer 📨 The REFER-Recipient can choose to cancel the implicit subscription with that NOTIFY 🙅‍♀️ The REFER-Issuer can also cancel it on its own, with an explicit SUBSCRIBE (Expires: 0) after it gets the initial NOTIFY ✋

why require the implicit subscription and that first NOTIFY at all? 🤔 Because a REFER can get forked, and the REFER-Issuer needs a way to see all the multiple dialogs that might come out of one forked REFER 🌿 It's the same approach used to handle forking of SUBSCRIBE [4] requests. But if the REFER-Issuer says outright that forking shouldn't happen, then the implicit subscription requirement isn't needed anymore 🫧

the NOTIFY also tells the REFER-Issuer how the SIP transaction from the REFER is going over at the REFER-Recipient 📊 Now, say the REFER-Issuer already knows how things are going, like when it has an explicit subscription to the dialog event package at the REFER-Recipient 👀 In that case, the implicit subscription and its NOTIFY traffic are just extra network overhead for no reason 😭

4. Definitions 🦋

this doc defines a new SIP header field: "Refer-Sub" 🎀 It's meaningful, and it MAY be used with a REFER request and the corresponding 2XX response, and nothing else 💖 When this header field is set to "false", the REFER-Issuer is asking the REFER-Recipient not to establish an implicit subscription and the resultant dialog 🙏 Note that when you use this extension, the REFER stays a target refresh request (same as the default case, when the extension isn't used) 🔄

this doc adds the following entry to Table 2 of [2] 📋 The table additions are also given for extension methods as of when this doc was published, just as a courtesy to the reader. They're not normative in any way 🫶

Header field        where    proxy ACK  BYE  CAN  INV  OPT  REG  MSG

Refer-Sub           R, 2xx          -    -    -    -    -    -    -

Header field        where    SUB  NOT  REF  INF  UPD  PRA  PUB

Refer-Sub           R, 2xx    -    -    o    -    -    -    -

the Refer-Sub header field MAY be encrypted as part of end-to-end encryption 🔐

the syntax of the header field follows the BNF below 🧩

 Refer-Sub       = "Refer-Sub" HCOLON refer-sub-value *(SEMI exten)
 refer-sub-value = "true" / "false"
 exten           = generic-param

where the syntax of generic-param is defined in [2] 📚

the "Refer-Sub" header field set to "false" MAY be used by the REFER-Issuer only when the REFER-Issuer can be certain the REFER request won't be forked 🎯

if the REFER-Recipient supports the extension and is willing to process the REFER transaction without establishing an implicit subscription, it MUST insert the "Refer-Sub" header field set to "false" in the 2xx response to the REFER-Issuer ✨ In that case, no implicit subscription gets created. So no new dialog gets created either, if this REFER was sent outside any existing dialog 🫧

if the REFER-Issuer puts in the "Refer-Sub" header field set to "false" but the REFER-Recipient doesn't go along with it (meaning it either doesn't include the "Refer-Sub" header field, or it includes it set to "true" in the 2xx response), then an implicit subscription gets created like in the default case 🔁

this doc also defines the option tag "norefersub" 🏷️ When it's included in the Supported header field, it specifies that a User Agent (UA) can accept a REFER request without creating an implicit subscription when it's acting as a REFER-Recipient 💖

the REFER-Issuer can learn the REFER-Recipient's capabilities from the option tags in the Supported header field of the dialog-initiating request or response 👀 Another way to learn them is with presence, like the one defined in [6] 📡 But if the REFER-Recipient's capabilities aren't known, using the "norefersub" tag with the Require header field is NOT RECOMMENDED 🙅‍♀️ Why? Because if the REFER-Recipient doesn't support the extension, the REFER-Issuer has to fall back to a normal REFER, which means issuing a brand-new REFER transaction and eating extra round-trips 😩

as described in Section 8.2.2.3 in [2], a REFER-Recipient will reject a REFER request containing a Require: norefersub header field with a 420 (Bad Extension) response unless it supports this extension 🚫 Also, Require: norefersub can show up together with a Refer-Sub: false header field 🤝

5. Preventing Forking of REFER Requests 🌀

the REFER spec allows a REFER request sent outside of an existing dialog to be forked 🍴 A proxy can also fork a method type it doesn't recognize 🤷‍♀️ If forking happens, the sender of a REFER with "Refer-Sub" won't know about it, since the forking proxy only forwards a single 2xx response 😱 So the issuer of a REFER with "Refer-Sub" is the one responsible for making sure no forking happens 🫶

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 make sure the REFER request doesn't fork 🛡️ If there's no other mechanism available, the Request-URI of the REFER request SHOULD have Globally Routable User Agent URI (GRUU) properties according to the definitions in [5], because those properties guarantee the request won't fork 💜

the big takeaway: if forking is possible, don't send Refer-Sub, and make sure your REFER can't fork in the first place 💀

Part 2 is coming next, with the Example, IANA Considerations, Security Considerations, Acknowledgements, and References 🎀

8. Security Considerations 🔒

okay bestie, this is the serious section 🥺 The whole point of this SIP extension is to change what the REFER-Recipient does. The change is that the REFER-Recipient does not establish a dialog and does not send NOTIFY messages back to the REFER-Issuer. So if someone sneaks in a Refer-Sub header field set to false, the recipient gets less processing and less state to manage 💅 That makes it pretty limited as a denial-of-service tool, which is kind of iconic.

BUT 😭 a man-in-the-middle (MitM) can still mess with it. By inserting a Refer-Sub header field set to false, a MitM can suppress the notifications from the REFER-Receiver, and the REFER-Issuer won't even notice. That's honestly easier than doing a full interception. And if a MitM removes a Refer-Sub header field set to false, they can make the REFER-Receiver send notifications over the implicit dialog that the REFER-Issuer had wanted suppressed. Not me being dramatic, it's a real hole 🙈

So to protect against these MitM attacks, integrity protection should be used. For example, the REFER-Issuer could use S/MIME as discussed in RFC 3261 [2] to protect against these kinds of attacks 🛡️✨

9. Acknowledgements 🫶

The SIP community wants to thank Sriram Parameswar, who came up with the ideas first presented in "Suppressing Refer Implicit Subscription" (October 2002). Those ideas became the basis for this specification, so he's a main character here 👑

10. References 📚

10.1. Normative References

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [2] 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.
  • [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
  • [4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.

10.2. Informative References

  • [5] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, October 2005.
  • [6] Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)", Work in Progress, January 2006.
  • [7] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.

Author's Address 🖊️

Orit Levin
Microsoft Corporation
One Microsoft Way
Redmond, WA  98052
USA

Phone: 425-722-2225
EMail: oritl@microsoft.com

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 💜

The IETF doesn't take any position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or how far they reach. It also doesn't say whether any license for those rights is or isn't available. And it hasn't made any independent effort to find out what rights exist. If you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission to use such proprietary rights by implementers or users of this specification can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites anyone interested to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard. Send that information to the IETF at ietf-ipr@ietf.org 📬

Acknowledgement 🌈

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Thank you, IASA 🫶

📦 where this page comes from