RFC 6404

Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures

📅 published November 2011, from ietf

RFC 6404 🎀 Security Threats and Suggested Countermeasures for SPEERMINT

RFC 6404 is the spec from the IETF (Internet Engineering Task Force) about Session PEERing for Multimedia INTerconnect (SPEERMINT) security threats and countermeasures. It's giving research paper with real stakes. 💅

  • Authors: J. Seedorf (NEC), S. Niccolini (NEC), E. Chen (NTT), H. Scholz (VOIPFUTURE)
  • Category: Informational 🦋
  • ISSN: 2070-1721
  • Date: November 2011
  • Obsoletes / Updates: nothing is listed in the header, so this one doesn't obsolete or update anything 🌸

Abstract 💜

okay so the SPEERMINT working group (WG) builds a peering framework that reuses existing IETF protocols like SIP and ENUM to connect SIP Service Providers (SSPs) to each other. 🔥 This doc is all about spotting SPEERMINT-specific threat vectors and giving implementers tips on picking good countermeasures 🧚

The security requirements that come out of these threats live in RFC 6271. This doc is the one with the concrete countermeasures for meeting those requirements. ✨ The threats are sorted into buckets for the Lookup Function (LUF), the Location Routing Function (LRF), the Signaling Function (SF), and the Media Function (MF) of one SSP. Then it shows the existing security stuff for SIP and RTP/RTCP (Real-time Transport Control Protocol) that can help with each threat.

Every SSP might be connected to one or more remote SSPs through peering or transit contracts. 🦋 A remote SSP that's been compromised and attacks other SSPs is out of scope here. This doc is focused on attacks on an SSP from outside the trust domain it might share with other SSPs. 🙈

Status of This Memo 🌈

This one is not an Internet Standards Track spec. It's published for informational purposes. ⭐

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details. 💖

You can find the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc6404. 🫶

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 💅

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Read these carefully, because they spell out your rights and restrictions for this doc. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes. 🔥

Table of Contents 🧚

   1. Introduction ....................................................4
   2. Security Threats Relevant to SPEERMINT ..........................5
      2.1. Threats to the Lookup Function (LUF) .......................5
           2.1.1. Threats to LUF Confidentiality ......................5
           2.1.2. Threats to LUF Integrity ............................6
           2.1.3. Threats to LUF Availability .........................6
      2.2. Threats to the Location Routing Function (LRF) .............6
           2.2.1. Threats to LRF Confidentiality ......................6
           2.2.2. Threats to LRF Integrity ............................7
           2.2.3. Threats to LRF Availability .........................7
      2.3. Threats to the Signaling Function (SF) .....................7
           2.3.1. Threats to SF Confidentiality .......................7
           2.3.2. Threats to SF Integrity .............................8
           2.3.3. Threats to SF Availability .........................10
      2.4. Threats to the Media Function (MF) ........................10
           2.4.1. Threats to MF Confidentiality ......................10
           2.4.2. Threats to MF Integrity ............................10
           2.4.3. Threats to MF Availability .........................11
   3. Security Requirements ..........................................11
      3.1. Security Requirements from SPEERMINT Requirements
           Document ..................................................11
      3.2. How to Fulfill the Security Requirements for SPEERMINT ....11
   4. Suggested Countermeasures ......................................12
      4.1. Database Security BCPs ....................................14
      4.2. DNSSEC ....................................................14
      4.3. DNS Replication ...........................................15
      4.4. Cross-Domain Privacy Protection ...........................15
      4.5. Secure Exchange of SIP Messages ...........................15
      4.6. Ingress Filtering / Reverse-Path Filtering ................16
      4.7. Strong Identity Assertion .................................16
      4.8. Reliable Border Element Pooling ...........................17
      4.9. Rate limit ................................................17
      4.10. Topology Hiding ..........................................17
      4.11. Border Element Hardening .................................17
      4.12. Securing Session Establishment Data ......................18
      4.13. Encryption and Integrity Protection of Media Stream ......18
   5. Conclusions ....................................................18
   6. Security Considerations ........................................18
   7. Acknowledgements ...............................................19
   8. Informative References .........................................19

1. Introduction 🌸

okay so VoIP makes security matter even more, because now you have to protect the control plane AND the data plane. 😭 With old-school phones, security was kind of a given. Tapping a call meant getting physical access to the phone lines or breaking into the PSTN nodes or the office Private Branch eXchanges (PBXs). Only super security-sensitive orgs even bothered to encrypt voice over regular phone lines. 🙈

Sending unencrypted data over the Internet is way riskier. Think dual-tone multi-frequency (DTMF) tones that carry a credit card number, for example. 💀

Internet Telephony has an extra problem too. Signaling devices can be addressed directly by attackers, since they run on the same underlying networking tech as the multimedia data. Traditional phone systems kept signaling on a network separate from the data network. 😤 That makes it way more dangerous, because a hacker could go after the signaling network and its servers and do a lot more damage: call hijacking, call drop, Denial-of-Service (DoS) attacks [RFC4732], and so on. So we need to dig into the different threats, pull out the security requirements, and point to potential solutions for protecting against them. 🔥

The SPEERMINT working group provides a peering framework that reuses existing IETF-defined protocols like SIP and ENUM for interconnection between SIP servers [RFC5486]. This doc's goal is to identify and list SPEERMINT-specific threat vectors and give implementers guidance on picking the right countermeasures. 🦋 The security requirements for SPEERMINT are in RFC 6271 "Requirements for SIP-Based Session Peering" [RFC6271]. Those requirements come from the threats described in this doc. They were moved out of an earlier version of this doc into the SPEERMINT requirements document [RFC6271]. On top of being the base for those requirements, this doc gives implementers advice and examples for concrete countermeasures that meet them with technical means. 💖 The SPEERMINT terminology from [RFC5486] is used throughout. 📚

The threats here are sorted into threats to the Lookup Function (LUF), the Location Routing Function (LRF), the Signaling Function (SF), and the Media Function (MF) of one specific SIP Service Provider (SSP). Each instance of a threat gets a quick intro inside its bucket. Then existing security solutions for SIP and RTP/RTCP are presented as the countermeasures available right now. 🧚 Each SSP may connect to one or more remote SSPs through peering or transit contracts. A potentially compromised remote SSP that attacks other SSPs is out of scope. This doc focuses on attacks on an SSP from outside the trust domain it may share with other SSPs. 🌈

2. Security Threats Relevant to SPEERMINT ✨

This section lists the potential security threats relevant to SPEERMINT. 🎀 A taxonomy of VoIP security threats is defined in [VOIPSATAXONOMY]. It's comprehensive and also covers non-VoIP-specific threats, like loss of power. 💅 The threats that matter at the edges of Layer 5 SIP networks are pulled from that taxonomy and mapped to the SPEERMINT architecture functions defined in [RFC6406]. On top of that, additional threats for the SPEERMINT architecture are listed and detailed under the same function classification and the CIA (Confidentiality, Integrity, and Availability) triad:

  • Lookup Function (LUF) 🔍
  • Location Routing Function (LRF) 🗺️
  • Signaling Function (SF) 📞
  • Media Function (MF) 🎶

2.1. Threats to the Lookup Function (LUF) 🔎

For a given request, the LUF figures out the identity of the requested resource on the terminating domain. 💖 That returned identity can then be used to look up Session Establishment Data (SED) through the Location Routing Function (LRF). In direct peerings the LUF is usually hosted locally. In a federation context, a third party might offer this function instead. 🫶

If the LUF is hosted locally, it's exposed to the same threats that hit database systems in general. 😬 If the SSP depends on a remote third party for LUF functionality, then the confidentiality, integrity, and authenticity of the responses are at risk. 🙈

2.1.1. Threats to LUF Confidentiality ✨

Okay so the LUF is the one that figures out which target domain a request should get routed to 🗺️, and eavesdropping on its messages is where things get messy. Here's what can go wrong:

  • SIP URI and peering domain harvesting - an attacker can pull this off if the underlying database has a weak authentication system or if SIP messages are sent unencrypted 😬. Then they use what they learned to launch other kinds of attacks 💀
  • Third-party information - a LUF that serves info to multiple companies / third parties can get attacked to snag details about third-party peering configurations and possible contracts 🙈

2.1.2. Threats to LUF Integrity 🫣

The underlying database or the LUF messages could be vulnerable to input/output message modification attacks, and that's giving main character chaos:

  • Injection attack - an attacker could manipulate statements run on the database or LUF messages sent to a third party 💅 A specific version of this is called "SQL injection", which is basically code getting inserted into the LUF because the input wasn't validated properly 😭

2.1.3. Threats to LUF Availability 🪫

The underlying database or third-party LUF service could be vulnerable to:

  • Denial-of-Service attacks - for example, an attacker makes incomplete requests, which causes the server to create an idle state for each one, and then memory gets exhausted 💀

2.2. Threats to the Location Routing Function (LRF) 🧭

The LRF determines the location of the Signaling Function (SF) for the target domain of a given request. Optionally, it may return additional SED ✨

2.2.1. Threats to LRF Confidentiality 🔍

Similar to the LUF, these attacks are all about eavesdropping on LRF messages:

  • URI harvesting - the attacker collects URIs and IP addresses of the existing User Endpoints (UEs) by sending a multitude of location requests 📞. Direct intrusion against vulnerable UEs or telemarketing are possible attack scenarios that use that gained knowledge
  • SIP device enumeration - the attacker finds the IP address of each intermediate signaling device by looking at the Via and Record-Route headers of a SIP message 👀. Targeting those discovered devices with follow-up attacks is a possible scenario

2.2.2. Threats to LRF Integrity 🎣

An attacker may modify messages, e.g., by feeding bogus information to the LRF, if the routing data isn't correctly validated or is sent unencrypted. Dynamic call routing discovery and establishment, as in the scope of SPEERMINT, opens the door to attacks like these:

  • Man-in-the-Middle attacks - the attacker inserts, or has already inserted, an unauthorized node in the signaling path and modifies the SED 😈. The result is that the attacker can then read, insert, and modify the multimedia communications
  • Incorrect destinations - the attacker redirects calls to the wrong destination to set up fraud like voice phishing or DoS attacks 🚨

2.2.3. Threats to LRF Availability 🛑

The LRF can be the object of DoS attacks. DoS attacks against the LRF can be carried out by sending a large number of queries to the LRF or LUF, which stops an Originating SSP from looking up call routing data for any URI outside its administrative domain 🙅‍♀️. As an alternative, the attacker could target the DNS to disable resolution of SIP addresses.

2.3. Threats to the Signaling Function (SF) 🛡️

The Signaling Function holds a whole lot of sensitive info 🗂️. Through it, User Agents (UAs) assert identities, and operators authorize billable resources 💸. Correct and trusted operation of the Signaling Function is essential for service providers, so this section digs into the potential security threats and the attack vectors they open up.

2.3.1. Threats to SF Confidentiality 🕵️‍♀️

SF traffic is vulnerable to eavesdropping, especially when the data moves across multiple SSPs with different levels of security policies. Here are the threats to SF confidentiality:

  • Call pattern analysis - the attacker tracks users' call patterns, violating their privacy (e.g., revealing the social network of various users, the daily phone usage, etc.). Rival SSPs may also infer information about the customer base of other SSPs this way 👥
  • Password cracking - the challenge-response authentication mechanism of SIP Digest can be attacked with offline dictionary attacks 🔐. The attacker tries to exploit weak passwords used by incautious users
  • Network discovery - the attacker may learn about the internal network structure of a peering partner that is directly or indirectly connected, by looking at SIP routing information (i.e, Record-Route, Via or Contact headers) 🧐

2.3.2. Threats to SF Integrity 🧩

The integrity of the SF can be violated using SIP request spoofing, SIP reply spoofing, and SIP message tampering. Yikes 😭

2.3.2.1. SIP Request Spoofing 🎭

Most SIP request spoofing attacks first require SIP message eavesdropping. Some of them can also be performed by estimating certain fields in SIP headers (e.g., by exploiting the fact that weak implementations may generate predictable SIP Dialog parameters), or by exploiting broken implementations that don't properly verify the content of certain headers. The threats in this category are:

  • Session teardown - an attacker can send CANCEL/BYE messages to tear down an existing call at the SIP layer 💥. For this, the attacker either needs to know the SIP Dialog of the call to be hijacked (To-tag, From-tag, Call-ID), which they can learn by eavesdropping a SIP INVITE message, or they may rely on SIP implementations that don't properly authenticate requests based on the SIP Dialog
  • Billing fraud - the attacker can modify and replay an intercepted INVITE request to bill a call to a victim UE and dodge paying for the phone call 💸
  • User ID spoofing - SSPs are responsible for asserting the legitimacy of a user ID. If an SSP fails to reach the level of identity assertion that its federation expects, it may create an entry point for attackers to conduct user ID spoofing attacks 🫥
  • Unwanted requests - the attacker sends requests to interfere with regular operation, e.g., by sending a REGISTER request in order to hijack calls 📵. The SPEERMINT architecture as defined in [RFC6406] does not require registrations between the Signaling Functions (SFs) of the connected SSPs. Hence, superfluous requests like REGISTERs should be rejected 🙅‍♀️

2.3.2.2. SIP Reply Spoofing 🪞

The threats in this category are:

  • Forged 199 Response - the attacker sends a forged 199 response to terminate an early dialog. The forged response won't terminate the entire session, but it may alter the direction of the session 🔀
  • Forged 200 Response - after seeing the contents of an INVITE request, an eavesdropper can inject a 200 response. This affects the processing of the transaction at all proxies between the injection point and the originating UA, and at the originating UA itself. In the extreme case, it can result in a hijacked call 😱. In many cases, though, the attack leaves signaling artifacts that may allow it to be detected (e.g., the element receiving the forged 200 response may also receive other SIP reply messages from the actual terminating UE) 🕵️
  • Forged 302 Response - after seeing the contents of an INVITE request, an eavesdropper could also inject a forged "302 Moved Temporarily" reply. This affects the processing of the transaction at intermediate entities and the originating UA, and may let the attacker redirect the call to any destination UE of their choosing 🏃‍♀️💨
  • Forged 404 Response - after seeing the contents of an INVITE request, an eavesdropper could also inject a forged "404 Not Found" reply. This affects the processing of the transaction at intermediate entities and the originating UA, and may result in disrupting the call establishment 📵

2.3.2.3. SIP Message Tampering 🧵

This threat involves altering important field values in a SIP message or in the Session Description Protocol (SDP) body. Examples include dropping or modifying handshake packets to avoid the establishment of a secure RTP session (SRTP) 🔓. The same approach could be used to degrade the quality of a media session by letting a UE negotiate a poor quality codec 📉

2.3.3. Threats to SF Availability 🚧

  • Flooding attack - a Signaling Path Border Element (SBE) is susceptible to message flooding attacks that may come from interconnected SSPs 🌊
  • Session blackholing - the attacker (assumed to be able to make Man-in-the-Middle attacks) intentionally drops essential packets, e.g., INVITEs, to prevent certain calls from being established 🕳️
  • SIP Fuzzing attack - fuzzing tests and software can be used by attackers to discover and exploit vulnerabilities of a SIP entity. This attack may result in crashing a SIP entity 💥

2.4. Threats to the Media Function (MF) 🎙️

The Media Function (MF) is responsible for the actual delivery of multimedia communication between the users, and it carries sensitive information 🔐. Through the media function, the UE can establish secure communications and monitor the quality of conversations 🎧. Correct and trusted operation of the MF is essential for privacy and service-assurance issues, so this section looks at the potential security threats to the MF and the attack vectors they open up ✨

2.4.1. Threats to MF Confidentiality 👂

The MF is vulnerable to eavesdropping, where the attacker may reconstruct the voice conversation or sensitive information (e.g., PINs from DTMF tones) 😳. Some SRTP key exchange mechanisms (e.g., [RFC4568]) are vulnerable to bid-down attacks, where an attacker selectively changes key exchange protocol fields to enforce the establishment of a less secure or even non-secure communication 🙃

2.4.2. Threats to MF Integrity 🧨

Both RTP and RTCP are vulnerable to integrity violations in many ways:

  • Media injection - if an attacker can somehow detect an ongoing media session and eavesdrop a few RTP packets, they can start sending bogus RTP packets to one of the UEs involved, using the same codec 🎶. If the bogus RTP packets have consistently greater timestamps and sequence numbers (but within the acceptable range) than the legitimate RTP packets, the recipient UE may accept the bogus packets and discard the legitimate ones 😵
  • Media session teardown - the attacker sends bogus RTCP BYE messages to a target UE to signal a teardown of the media communication 📴. Please note that RTCP messages are normally not authenticated 🚩
  • Quality-of-Service (QoS) degradation - the attacker sends wrong RTCP reports advertising more packet loss or more jitter than was actually experienced, which results in the use of a poor quality codec and degrades the overall quality of the call experience 📉

2.4.3. Threats to MF Availability 🚨

Okay bestie, last one for the media function: availability. There are two main ways an attacker can mess with it:

  • Malformed messages - the attacker tries to cause a crash or a reboot of the Data Path Border Element (DBE)/UE by sending RTP/RTCP malformed messages 💀
  • Messages flooding - the attacker tries to exhaust the resources of the DBE/UE by sending many RTP/RTCP messages 🌊

3. Security Requirements 🛡️

3.1. Security Requirements from SPEERMINT Requirements Document

The SPEERMINT security requirements used to live in an earlier version of this doc, but they got moved over to the SPEERMINT requirements [RFC6271]. Here they are, straight from [RFC6271] ✨:

  • Requirement #15: The protocols used to query the Lookup and Location Routing Functions SHOULD support mutual authentication.
  • Requirement #16: The protocols used to query the Lookup and Location Routing Functions SHOULD provide support for data confidentiality and integrity.
  • Requirement #17: The protocols used to enable session peering MUST NOT interfere with the exchanges of media security attributes in SDP. Media attribute lines that are not understood by SBEs must be ignored and passed along the signaling path untouched.

3.2. How to Fulfill the Security Requirements for SPEERMINT

Requirements #15 and #16 say the LUF and LRF should support mutual authentication, data confidentiality, and integrity. 🔐 In principle, these can be fulfilled technically with Transport Layer Security (TLS) or Datagram TLS (DTLS) [RFC5246] [RFC4347] or IP layer security (IPsec) [RFC4301]. From a pure security perspective, both solutions meet the SPEERMINT security requirements, just on different layers, and both are widely deployed 🙌

From a more practical angle, though, transport layer security (i.e., TLS or DTLS) has an advantage: the application using it knows whether security (or rather the corresponding security features) is turned on. 👀 For instance, using TLS means the connection fails if the other endpoint can't authenticate properly.

IPsec meets the same requirements security-wise, but it kinda decouples security from the application using it. 🫠 For instance, IPsec is often provided by dedicated entities in such a way that the application layer can't tell whether IPsec or certain security features are on ("bump-in-the-wire").

So in summary, TLS (or DTLS) has some notable advantages over IPsec for the SPEERMINT security requirements. In particular, transport layer security is preferable over IPsec for SPEERMINT because with TLS (or DTLS), security is more closely coupled to the LUF or LRF. 💅 From a mere technical perspective, though, both solutions (transport layer security or IPsec) fulfill the SPEERMINT security requirements, and there may be particular cases where IPsec is a preferable solution 🦋

4. Suggested Countermeasures 🧰

This section describes implementer-specific countermeasures against the threats from the previous sections, and for addressing the SPEERMINT security requirements from [RFC6271]. The countermeasures here are not meant to be exhaustive. They're more like starting points and guidance for implementers picking countermeasures for certain threats 🌸

The table below maps which threats go with which countermeasures. The suggested countermeasures get the full breakdown in the subsections after it 📋

+-------+---------------+-------------------------------------------+
| Group | Threat        | Suggested Countermeasure                  |
+-------+---------------+-------------------------------------------+
|  LUF  | Unauthorized  | database security BCPs (Section 4.1),     |
|       | access        | Secure Exchange of SIP messages           |
|       |               | (Section 4.5)                             |
|       | SQL injection | database security BCPs (Section 4.1),     |
|       |               | Secure Exchange of SIP messages           |
|       |               | (Section 4.5)                             |
|       | DoS to LUF    | database security BCPs (Section 4.1),     |
|       |               | Secure Exchange of SIP messages           |
|       |               | (Section 4.5)                             |
|  LRF  | URI           | privacy protection (Section 4.4), Secure  |
|       | harvesting    | Exchange of SIP messages (Section 4.5)    |
|       | SIP equipment | privacy protection (Section 4.4), Secure  |
|       | enumeration   | Exchange of SIP messages (Section 4.5)    |
|       | MitM attack   | DNSSEC (Section 4.2), Secure Exchange of  |
|       |               | SIP messages (Section 4.5)                |
|       | Incorrect     | DNSSEC (Section 4.2), Secure Exchange of  |
|       | destinations  | SIP messages (Section 4.5)                |
|       | DoS to LRF    | DNS replication (Section 4.3)             |
|   SF  | Call pattern  | Secure Exchange of SIP messages           |
|       | analysis      | (Section 4.5), Securing Session           |
|       |               | Establishment Data (Section 4.12)         |
|       | Password      | Secure Exchange of SIP messages           |
|       | cracking      | (Section 4.5)                             |
|       | Network       | Securing Session Establishment Data       |
|       | discovery     | (Section 4.12), Topology Hiding           |
|       |               | (Section 4.10)                            |
|       | Session       | Secure Exchange of SIP messages           |
|       | teardown      | (Section 4.5), ingress filtering          |
|       |               | (Section 4.6)                             |
|       | Billing fraud | strong identity assertion (Section 4.7)   |
|       | User ID       | strong identity assertion (Section 4.7)   |
|       | spoofing      |                                           |
|       | Forged 200    | Secure Exchange of SIP messages           |
|       | Response      | (Section 4.5), ingress filtering          |
|       |               | (Section 4.6)                             |
|       | Forged 302    | Secure Exchange of SIP messages           |
|       | Response      | (Section 4.5), ingress filtering          |
|       |               | (Section 4.6)                             |
|       | Forged 404    | Secure Exchange of SIP messages           |
|       | Response      | (Section 4.5), ingress filtering          |
|       |               | (Section 4.6)                             |
|       | Flooding      | reliable border element pooling           |
|       | attack        | (Section 4.8), rate limit (Section 4.9)   |
|       | Session       | DNSSEC (Section 4.2)                      |
|       | blackholing   |                                           |
|       | SIP fuzzing   | border element hardening (Section 4.11)   |
|       | attack        |                                           |
|   MF  | Eavesdropping | Encryption and Integrity Protection of    |
|       |               | Media Stream (Section 4.13)               |
|       | Media         | Encryption and Integrity Protection of    |
|       | injection     | Media Stream (Section 4.13)               |
|       | Media session | Encryption and Integrity Protection of    |
|       | teardown      | Media Stream (Section 4.13)               |
|       | QoS           | Encryption and Integrity Protection of    |
|       | degradation   | Media Stream (Section 4.13)               |
|       | Malformed     | border element hardening (Section 4.11)   |
|       | messages      |                                           |
|       | Message       | rate limit (Section 4.9)                  |
|       | flooding      |                                           |
+-------+---------------+-------------------------------------------+

4.1. Database Security BCPs

Adequate security measures must be applied to the LUF so it doesn't become a target for the attacks you usually see on common database systems 🎯 Common security Best Current Practices (BCPs) for database systems include using strong passwords to prevent unauthorized access, parameterized statements to prevent SQL injections, and server replication so no single database is a single point of failure 🔒 [DBSEC] is one of many existing documents that describe BCPs in this area 📚

4.2. DNSSEC

If DNS is used by the LRF, it is recommended to deploy the recent version of Domain Name System Security Extensions (informally called "DNSSEC-bis") defined by [RFC4033], [RFC4034], and [RFC4035] 🧁 DNSSEC is designed to protect DNS against well-known attacks like DNS cache poisoning or Man-in-the-Middle (MitM) attacks on DNS queries. Basically, it's a set of public key cryptography extensions to DNS that provide authentication of DNS data, integrity protection for DNS entries, and authenticated denial of existence for non-existing DNS entries 🔑 In the context of SSP peering, DNSSEC can provide authentication and integrity for the location of a Signaling Function (SF) entity retrieved via DNS. So it can help defend against MitM attacks on DNS queries invoked by the LRF, session blackholing, and other attacks that lead traffic to incorrect destinations 🚦

DNSSEC has been deployed at the root level and in several top-level domains (e.g., .com and .net). Although DNSSEC still isn't widely deployed on the Internet at the time of this writing, even limited deployment adds real integrity protection and authentication to the LRF for Signaling Function locations received via DNS entries ✨ End users and terminals aren't involved in the DNS resolution process of the LRF. So the LRF can be secured with DNSSEC if: a) the sending SSP uses a DNS resolver that supports DNSSEC extensions, b) the receiving SSP stores the location of its Signaling Function cryptographically signed (using DNSSEC extensions) in the DNS, and c) the sending SSP can obtain an authentication chain (i.e., a series of linked DS and DNSKEY records) to the receiving SSP 🪄 In the context of SPEERMINT, all three of these requirements can be fulfilled even with partial DNSSEC deployment. In particular, even without Internet-wide DNSSEC deployment, it may be possible for a sending SSP to obtain a suitable trust anchor for verifying the receiving SSP's public key. For instance, a suitable trust anchor could be configured for that specific SSP's top-level domain or for the particular SSP's domain directly. If the sending and the receiving SSP use a common ENUM tree, DNSSEC use with the ENUM tree's trust anchor is "straightforward" 🌈

4.3. DNS Replication

DNS replication is a very important countermeasure for mitigating DoS attacks on the LRF 🛡️ Simultaneously bringing down multiple DNS servers that support the LRF is way more challenging than attacking a sole DNS server (which is a single point of failure) 💪

4.4. Cross-Domain Privacy Protection ✨

okay so bestie, the [RFC3323] crew has a few tricks for keeping SIP private 🕵️‍♀️🎀. You can strip the Via and Record-Route headers, swap out the Contact header, and even change Call-IDs. This lets an SSP hide its SIP network topology 🦋, keeps the middle signaling boxes from becoming DoS targets 🎯, and protects the privacy of UEs based on what they prefer 🫶. It's literally so effective at stopping SIP equipment enumeration that exploits LRF 💅. Iconic.

4.5. Secure Exchange of SIP Messages 🔐

SIP can run on top of UDP or TCP as its transport protocol [RFC3261] 🌸. Here's the tea though: look-up and SED data should be exchanged securely (see security requirements (Section 3.2)) 😭. That makes it way harder to pull off session teardown and forged responses (200, 302, 404, etc). If UDP is carrying your SIP messages, DTLS should be used to secure the SIP message exchange between SSPs 💜. If TCP is the transport, it can be secured with TLS 🧚. So depending on the transport, SSPs should use either DTLS or TLS to secure SIP message delivery 👑.

In general, you can get encryption and integrity protection for signaling messages at the transport layer (with TLS or DTLS) or at the network layer (with IPsec) 🌈. Both are technically sound, but transport layer security has some perks ✨. Check out the subsection on fulfilling the SPEERMINT security requirements (Section 3.2) for the full discussion on TLS/DTLS versus IPsec for protecting the confidentiality and integrity of signaling messages 🎀. Just like strong identity assertion, a Public Key Infrastructure (PKI) is assumed to be in place for TLS/DTLS (or IPsec) deployment 🔑, so SSPs can get and trust the keys they need to decrypt messages and verify signatures sent by other SSPs 🫶.

Message-oriented protection such as [RFC3261] authentication does not fulfill the SPEERMINT requirements (e.g., mutual authentication) 🙈. Not it! 💀

4.6. Ingress Filtering / Reverse-Path Filtering 🚧

Ingress filtering means blocking all traffic that comes from a host whose source address doesn't match the addresses assigned to that host (see [RFC2827]) 🛑. It's a super effective way to stop UEs from sending packets with a spoofed source IP address 🙅‍♀️. You can do this with reverse-path filtering, which only accepts ingress traffic if the responses would take the same path back 🔄. This practice is effective at preventing session teardown and forged SIP replies (200, 302, 404, etc), but only if the recipient correctly verifies the source IP address for the authenticity of each incoming SIP message 🧐💖.

4.7. Strong Identity Assertion 🪪

"Caller ID spoofing" happens because of the weak identity assertion on the From URI of an INVITE request 📞😤. In a single SSP domain, strong identity assertion is pretty easy to get, since you just authenticate each INVITE request 💅. But in the SPEERMINT context, only the Originating SSP can verify the identity directly 😬. To get around this, there are currently only two major approaches: transitive trust and cryptographic signature ✨.

The transitive trust approach builds a chain of trust among different SSP domains 🔗. One example is the combined mechanism specified in [RFC3324] and [RFC3325] 🌸. In a transit peering network scenario, the terminating SSP must establish a trust relationship with all SSP domains on the path, and honestly that's kind of the underlying weakness 😩.

The other option is cryptographic signatures 🖋️. "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format" is specified in [RFC3893] 📜. [RFC4474] brings in two new header fields, IDENTITY and IDENTITY-INFO, which let a SIP server in the Originating SSP digitally sign an INVITE request after it authenticates the sending UE 💜. The terminating SSP can then check whether the INVITE request is signed by a trusted SSP domain 👑. This approach doesn't make the terminating SSP trust every transit SSP on the path, which is a big glow-up 🦋, although a PKI is still assumed to be in place 🔐.

4.8. Reliable Border Element Pooling 🏊‍♀️

It is advisable to implement reliable pooling on border elements 🌊. The RSERPOOL WG addresses an architecture and protocols for managing server pools that support mission-critical applications 🏥. Using those mechanisms and protocols (see [RFC5351] [RFC5352] [RFC5353] for details), a UE can effectively increase its capacity for handling flooding attacks 💪✨.

4.9. Rate limit 🚦

Flooding attacks on SFs and MFs can also be mitigated by limiting the rate of incoming traffic through policing or queuing 🌧️. The catch is that legitimate clients can end up getting denied service, since their traffic may be discarded 😭. Rate limiting can also be applied on a per-source-IP basis, under the assumption that the source IP of each attack packet is not spoofed dynamically 🕵️. Limitations related to NAT and mobility issues apply here too, and they may result in false positives (i.e., source IP addresses blocked) when multiple legitimate clients sit behind the same NAT IP address 🙈.

It may be preferable to limit the number of concurrent 'sessions', i.e., ongoing calls, instead of the messaging associated with them 📞, since sessions use more resources on backend systems 🧠. When you calculate rate limits, every entity along the session path should be taken into account 🗺️. SIP entities on the receiving end of a call may be the limiting factor (e.g., the number of ISDN channels on PSTN gateways) instead of the ingress limiting device 🧩. Not the bouncer, the club capacity! 🎀

4.10. Topology Hiding 🫥

Topology hiding applies to both the signaling and media planes, and it works by limiting how much topology information gets exposed to peering partners 🌙. It requires back-to-back user agent (B2BUA) functionality 🔁. The most common way to get it is using a Session Border Controller (SBC) as the SBE 🛡️. You can read all about it in [RFC5853] 📖.

4.11. Border Element Hardening 🏋️‍♀️

To prevent attacks that exploit vulnerabilities (such as buffer overflows, format string vulnerabilities, etc.) in SPEERMINT border elements, these implementations should be security hardened 💪. Fuzz testing is a common black box testing technique in software engineering, for example 🐛. Security vulnerability tests can also be run preventively to make sure a UE/SBE/DBE can handle unexpected data correctly without crashing 💻. [RFC4475] and [PROTOS] are examples of torture test cases specific for SIP devices and freely available security testing tools, respectively 🧪. These types of tests need to be carried out before product release, and also throughout the product life cycle 🔁💖.

4.12. Securing Session Establishment Data 🗝️

Session Establishment Data (SED) holds critical information for routing SIP sessions 🗺️. To prevent attacks like service hijacking and denial of service that exploit SED, SSPs should adopt a secure transport protocol that provides authentication, confidentiality and integrity when they exchange SED among themselves 🔐🫶. More details can be found in [DRINKS-SPPROV] 📚.

4.13. Encryption and Integrity Protection of Media Stream 🎶

The Secure Real-time Transport Protocol (SRTP) [RFC3711] stops eavesdropping on plain RTP by encrypting the data flow 🤫. It uses AES as the default cipher and defines two modes of operation (Segmented Integer Counter Mode and f8-mode), which get agreed upon after negotiation 🤝. It also uses HMAC-SHA1 and index keeping to enable message authentication/integrity and replay protection, which are required to prevent media injection attacks 🛡️💅. Secure RTCP (SRTCP) gives RTCP the same security features that SRTP gives RTP 🎧. SRTCP is described in [RFC3711] as optional 🤷‍♀️. To prevent media session teardown, it is recommended to turn this feature on 💜. The choice of external key management protocol is left to the deployment, but a PKI is necessary to implement the security requirements of the SPEERMINT requirements document 🔑✨.

5. Conclusions 🎀

This document presented the different SPEERMINT security threats, grouped by the LUF, LRF, SF, and MF, respectively 🗂️. Each instance of the threats came with a brief explanation 💡. Finally, suggested countermeasures for SPEERMINT were outlined, along with how they could mitigate the existing threats 🧁.

6. Security Considerations 🚨

This document is entirely focused on the security threats for SPEERMINT. Literally the whole vibe is security, bestie, so take it seriously 😤🔐💀.

7. Acknowledgements 🫶

This document was originally inspired by the VOIPSA VoIP Security and Privacy Threat Taxonomy 🌟. The authors would like to thank VOIPSA for producing a comprehensive taxonomy as the starting point of this document 🙏. They also want to thank Cullen Jennings, Jon Peterson, David Schwartz, Hadriel Kaplan, Peter Koch, Daryl Malas, Jason Livingood, and Robert Sparks for their useful comments on previous editions of this document, both on the mailing list and during IETF meetings 💖.

Jan Seedorf and Saverio Niccolini are partially supported by the DEMONS project, a research project supported by the European Commission under its 7th Framework Program (contract no. 257315) 🇪🇺✨. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the DEMONS project or the European Commission 🌸.

8. Informative References ✨

okay bestie, here are all the receipts 📚💅 every one of these is a source the RFC leans on, so I've kept each entry exactly as written 🫶

  • [DBSEC] Gertz, M. and S. Jajodia, "Handbook of Database Security: Applications and Trends", Springer, 2008.
  • [DRINKS-SPPROV] Mule, J., Cartwright, K., Ali, S., and A. Mayrhofer, "Session Peering Provisioning Protocol", Work in Progress, September 2011.
  • [PROTOS] Wieser, C., Laakso, M., and H. Schulzrinne, "SIP Robustness Testing for Large-Scale Use", First International Workshop on Software Quality (SOQUA 2004), September 2004.
  • [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
  • [RFC3261] 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.
  • [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
  • [RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
  • [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
  • [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
  • [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
  • [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
  • [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
  • [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
  • [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
  • [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
  • [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
  • [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
  • [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
  • [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  • [RFC5351] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An Overview of Reliable Server Pooling Protocols", RFC 5351, September 2008.
  • [RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP)", RFC 5352, September 2008.
  • [RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", RFC 5353, September 2008.
  • [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009.
  • [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
  • [RFC6271] Mule, J-F., "Requirements for SIP-Based Session Peering", RFC 6271, June 2011.
  • [RFC6406] Malas, D., Ed. and J. Livingood, Ed., "Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture", RFC 6406, November 2011.
  • [VOIPSATAXONOMY] Zar, J. and et al, "VOIPSA VoIP Security and Privacy Threat Taxonomy, Public Release 1.0", http://www.voipsa.org/Activities/taxonomy.php, October 2005.

Authors' Addresses 🦋

meet the squad who wrote this 🌸💖 here's where to find them, exactly as listed:

Jan Seedorf
NEC Laboratories Europe, NEC Europe,  Ltd.
Kurfuersten-Anlage 36
Heidelberg  69115
Germany

Phone: +49 (0) 6221 4342 221
EMail: jan.seedorf@neclab.eu
URI:   http://www.neclab.eu


Saverio Niccolini
NEC Laboratories Europe, NEC Europe, Ltd.
Kurfuersten-Anlage 36
Heidelberg  69115
Germany

Phone: +49 (0) 6221 4342 118
EMail: saverio.niccolini@.neclab.eu
URI:   http://www.neclab.eu


Eric Chen
Information Sharing Platform Laboratories, NTT
3-9-11 Midori-cho
Musashino, Tokyo  180-8585
Japan

EMail: eric.chen@lab.ntt.co.jp
URI:   http://www.ntt.co.jp/index_e.html


Hendrik Scholz
VOIPFUTURE GmbH
Wendenstrasse 4
Hamburg  20097
Germany

Phone: +49 (0) 40 688 900 163
EMail: hendrik.scholz@voipfuture.com
URI:   http://voipfuture.com
📦 where this page comes from