RFC 4453

Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)

📅 published April 2006, from ietf

RFC 4453: Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP) 🎀

Okay bestie, the title block is giving main character energy 💅 It's written by J. Rosenberg (Cisco Systems), G. Camarillo, Ed. (Ericsson), and D. Willis (Cisco Systems). It's Informational, so it's info, not a standard 🧚 It's dated April 2006, and the header doesn't list any RFCs that it obsoletes or updates ✨

Status of This Memo 📜

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2006).

Abstract 🫶

Okay so SIP (the Session Initiation Protocol) handles calls across tons of media types, like real-time audio, video, text, instant messaging, and presence. The thing is, right now it lets session invitations, instant messages, and other requests get delivered from one person to another without needing the recipient's explicit consent 😭 Without that consent, SIP can get abused for super shady stuff like spam and denial-of-service attacks 💀 This document lays out a set of requirements for extensions to SIP that add consent-based communications, so nobody gets blasted without saying yes 🌸

Table of Contents 🗂️

1. Introduction ....................................................2
2. Problem Statement ...............................................2
3. Requirements ....................................................4
4. Security Considerations .........................................5
5. References ......................................................6
   5.1. Normative References .......................................6
   5.2. Informational References ...................................6

1. Introduction ✨

SIP [1] handles communication across tons of media types, like real-time audio, video, text, instant messaging, and presence 🦋 A conversation starts when an initiator sends a bunch of SIP requests (like INVITE and MESSAGE [3]) to the person they want to talk to. Sure, the recipient can reject the request and turn down the session, but a SIP network will deliver that request to them without their explicit consent. Not okay 🙈

Getting these requests without explicit consent causes a bunch of problems in SIP networks. These include amplification attacks. Honestly, email has been dealing with these same problems forever 😩 Right now, most SIP services aren't interconnected, so amplification attacks aimed at SIP services are pretty rare compared to the same attacks on email services. The SIPPING working group believes it is necessary to address these attacks proactively so they don't become as burdensome as the attacks on email have become 🔥

This document digs into the problems with the current open model that SIP was designed around. Then it defines a set of requirements for adding a consent framework to SIP 💖

2. Problem Statement 🔍

In SIP networks designed according to the principles of RFC 3261 [1] and RFC 3263 [2], anyone on the Internet can create and send a SIP request to any other SIP user. They just identify that user with a SIP Uniform Resource Identifier (URI) 🫣 The SIP network will usually deliver that request to the user identified by the URI. Network services like call screening can block this messaging, but that's not widespread, and it's definitely not a systematic fix for the problem we're talking about here 🙅‍♀️

Once the SIP request reaches the recipient, the user agent usually takes some kind of automated action to alert the user. For INVITE requests, this usually means an audible alert (e.g., "ringing the phone") or a visual alert (e.g., a screen pop-up window). These indicators often show the subject of the call and the caller's identity. Because the session is real-time, these alerts tend to be pretty disruptive, which is kind of the point, since they're supposed to get the user's attention 📞

For MESSAGE requests, the content of the message is usually rendered to the user 💬

SUBSCRIBE [4] requests don't normally get delivered to the user agents on a user's devices. Instead, they're usually handled by network-based state agents. The watcher information event package lets a user find out that such requests were generated for them, so they get the chance to approve or deny the request. So SUBSCRIBE processing, and especially presence, already has a consent-based operation 🌈 Still, this existing consent mechanism for SIP subscriptions doesn't protect network agents from denial-of-service (DoS) attacks 😬

Here's the big problem: when requests can be delivered straight to user agents without their consent, amplification attacks happen. SIP proxies are a super convenient relay point for targeting a message at a particular user or IP address. They're especially handy for forwarding to a recipient who often can't be reached directly without going through the proxy 🧚 Some SIP proxy servers forward a single request to several instances or contacts for the same user or resource. This is called "forking". Another type of SIP server provides the SIP URI-list service [5], which sends a new copy of the same request to each recipient in the URI-list. Examples of URI-list services are subscriptions to resource lists [6], dial-out conference servers [8], and MESSAGE URI-list services [7]. A SIP URI-list service could be used as an amplifier, letting a single SIP request flood a single target host or network 🌊

For example, a user can create a resource list with 100 entries. Each entry is a URI of the form sip:identifier@target-IP, where target-IP is the IP address the attack is aimed at. Sending a single SIP SUBSCRIBE request to that list will make the resource list server generate 100 SUBSCRIBE requests, each sent to the target's IP address. That target doesn't even need to be a SIP node 😭

Note that the target-IP doesn't need to be the same in all the URIs to attack a single machine. For example, the target-IP addresses may all belong to the same subnetwork, in which case the target of the attack would be the access router of the subnetwork. 🧠

Attackers could also use SIP URI-list servers as amplifiers to deliver spam, on top of launching DoS attacks 🚨 For INVITE requests, this looks like typical "telemarketer" calls. A user might get a stream of never-ending requests for communication, each one disrupting them and demanding their attention. For MESSAGE requests, it's even worse. The user might get a never-ending stream of visual alerts (e.g., screen pop-up windows) delivering unwanted, malicious, or otherwise undesired content 🙃

Both the spam-related and the DoS amplification attacks can be eased by adding a consent-based communications framework to SIP. That kind of framework stops servers from relaying messages to users without their consent 🫶

The framework for SIP URI-list services [5] identifies amplification attacks as a problem in the context of URI-list services. That framework requires the use of opt-in lists, which are a form of consent-based communications. The reader can find an analysis of how a consent-based framework helps with spam-related problems in [9]. 📚

3. Requirements 📋

Here are the requirements for a solution that provides consent-based communications in SIP. A relay is any SIP server (a proxy, a Back-to-Back User Agent (B2BUA), or some hybrid of those) that receives a request, turns the request URI into one or more next-hop URIs, and then delivers a request to them 🔁

  • REQ 1: The solution must keep relays from delivering a SIP request to a recipient unless the recipient has explicitly granted permission to the relay using appropriately authenticated messages. 🔐
  • REQ 2: The solution shall prevent relays from generating more than one outbound request in response to an inbound request, unless permission to do so has been granted by the resource to whom the outbound request was to be targeted. This requirement keeps the consent mechanism itself from becoming the focus of DoS attacks 🛡️
  • REQ 3: The permissions shall be capable of specifying that messages from a specific user, identified by a SIP URI that is an Address-of-Record (AOR), are permitted. 💌
  • REQ 4: Each recipient AOR must be able to specify permissions separately for each SIP service that forwards messages to the recipient. For example, Alice may authorize forwarding to her from domain A, but not from domain B. 👑
  • REQ 5: It shall be possible for a user to revoke permissions at any time. 🚫
  • REQ 6: It shall not be required for a user or user agent to store information in order to be able to revoke permissions that were previously granted for a relay resource. 🧺
  • REQ 7: The solution shall work in an inter-domain context, without requiring preestablished relationships between domains. 🌍
  • REQ 8: The solution shall work for all current and future SIP methods. ⭐
  • REQ 9: The solution shall be applicable to forking proxies. 🍴
  • REQ 10: The solution shall be applicable to URI-list services, such as resource list servers [5], MESSAGE URI-list services [7], and conference servers performing dial-out functions [8]. 📞
  • REQ 11: In SIP, URI-lists can be stored on the URI-list server or provided in a SIP request. The consent framework must work in both cases. 🗒️
  • REQ 12: The solution shall allow anonymous communications, as long as the recipient is willing to accept anonymous communications. 🎭
  • REQ 13: If the recipient of a request wishes to be anonymous with respect to the original sender, it must be possible for the recipient to grant permission for the sender without the original sender learning the recipient's identity. 🙈
  • REQ 14: The solution shall prevent attacks that seek to undermine the underlying goal of consent. That is, it should not be possible to "fool" the system into delivering a request for which permission was not, in fact, granted. 🕵️‍♀️
  • REQ 15: The solution shall not require the recipient of the communications to be connected to the network at the time communications are attempted. 📴
  • REQ 16: The solution shall not require the sender of a SIP request to be connected at the time that a recipient provides permission. 🔌
  • REQ 17: The solution should scale to Internet-wide deployment. 🌐

4. Security Considerations 🚨

Security has been discussed throughout this document. It's the thread running through the whole thing, so don't skip past it 🔥

5. References 📚

5.1. Normative References

5.2. Informational References

5.1. Normative References 📚

  • [1] 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.
  • [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
  • [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.

5.2. Informational References 🧠

  • [4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
  • [5] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services", Work in Progress, January 2006.
  • [6] Roach, A.B., Rosenberg, J., and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", Work in Progress, January 2005.
  • [7] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", Work in Progress, February 2006.
  • [8] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", Work in Progress, February 2006.
  • [9] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam", Work in Progress, July 2005.

Authors' Addresses 🎀

Here are the authors, with their contact details exactly as published:

Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ  07054
US

Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI:   http://www.jdrosen.net


Gonzalo Camarillo (Editor)
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: Gonzalo.Camarillo@ericsson.com


Dean Willis
Cisco Systems
2200 E. Pres. George Bush Turnpike
Richardson, TX  75082
USA

EMail: dean.willis@softarmor.com

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

This document is subject to the rights, licenses and restrictions in BCP 78. Apart from what that says, the authors keep all their rights. 💜

The document and everything in it come "AS IS." The contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all disclaim every warranty, express or implied. That includes no warranty that using the information won't infringe any rights, and no implied warranty of merchantability or fitness for a particular purpose. 😭

Intellectual Property 🔐

The IETF doesn't take a 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 a license for those rights is available, and it hasn't independently tried to find any such rights. 🤷‍♀️ If you want to know how rights work for RFC documents, check out BCP 78 and BCP 79. 📖

Copies of IPR disclosures sent to the IETF Secretariat, along with any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission to use these proprietary rights for implementers or users of this spec, can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr. ✨

The IETF also invites anyone to point out any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that to the IETF at ietf-ipr@ietf.org. 💅

Acknowledgement 🫶

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). 👑

📦 where this page comes from