From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6404.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc6404.txt (limited to 'doc/rfc/rfc6404.txt') diff --git a/doc/rfc/rfc6404.txt b/doc/rfc/rfc6404.txt new file mode 100644 index 0000000..c24c474 --- /dev/null +++ b/doc/rfc/rfc6404.txt @@ -0,0 +1,1235 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Seedorf +Request for Comments: 6404 S. Niccolini +Category: Informational NEC +ISSN: 2070-1721 E. Chen + NTT + H. Scholz + VOIPFUTURE + November 2011 + + + Session PEERing for Multimedia INTerconnect (SPEERMINT) + Security Threats and Suggested Countermeasures + +Abstract + + The Session PEERing for Multimedia INTerconnect (SPEERMINT) working + group (WG) provides a peering framework that leverages the building + blocks of existing IETF-defined protocols such as SIP and ENUM for + the interconnection between SIP Service Providers (SSPs). The + objective of this document is to identify and enumerate SPEERMINT- + specific threat vectors and to give guidance for implementers on + selecting appropriate countermeasures. Security requirements for + SPEERMINT that have been derived from the threats detailed in this + document can be found in RFC 6271; this document provides concrete + countermeasures to meet those SPEERMINT security requirements. In + this document, the different security threats related to SPEERMINT + are classified into threats to the Lookup Function (LUF), the + Location Routing Function (LRF), the Signaling Function (SF), and the + Media Function (MF) of a specific SIP Service Provider. Various + instances of the threats are briefly introduced inside the + classification. Finally, existing security solutions for SIP and + RTP/RTCP (Real-time Transport Control Protocol) are presented to + describe countermeasures currently available for such threats. Each + SSP may have connections to one or more remote SSPs through peering + or transit contracts. A potentially compromised remote SSP that + attacks other SSPs is out of the scope of this document; this + document focuses on attacks on an SSP from outside the trust domain + such an SSP may have with other SSPs. + + + + + + + + + + + + + +Seedorf, et al. Informational [Page 1] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6404. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + +Seedorf, et al. Informational [Page 2] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + +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 + + + + + + + + + +Seedorf, et al. Informational [Page 3] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + +1. Introduction + + With Voice over IP (VoIP), the need for security is compounded + because there is the need to protect both the control plane and the + data plane. In a legacy telephone system, security is a more valid + assumption. Intercepting conversations requires either physical + access to telephone lines or a compromise to the Public Switched + Telephone Network (PSTN) nodes or the office Private Branch eXchanges + (PBXs). Only particularly security-sensitive organizations bother to + encrypt voice traffic over traditional telephone lines. In contrast, + the risk of sending unencrypted data across the Internet is more + significant (e.g., dual-tone multi-frequency (DTMF) tones + corresponding to the credit card number). An additional security + threat to Internet Telephony comes from the fact that the signaling + devices may be addressed directly by attackers as they use the same + underlying networking technology as the multimedia data; traditional + telephone systems have the signaling network separated from the data + network. This is an increased security threat since a hacker could + attack the signaling network and its servers with increased damage + potential (call hijacking, call drop, Denial-of-Service (DoS) attacks + [RFC4732], etc.). Therefore, there is a need to investigate the + different security threats, to extract security-related requirements, + and to highlight potential solutions on how to protect against such + threats. + + The Session PEERing for Multimedia INTerconnect (SPEERMINT) working + group provides a peering framework that leverages the building blocks + of existing IETF-defined protocols such as SIP and ENUM for the + interconnection between SIP servers [RFC5486]. The objective of this + document is to identify and enumerate SPEERMINT-specific threat + vectors and to give guidance for implementers on selecting + appropriate countermeasures. Security requirements for SPEERMINT can + be found in RFC 6271 "Requirements for SIP-Based Session Peering" + [RFC6271]. These security requirements for SPEERMINT are derived + from the threats that are detailed in this document; they have been + moved from an earlier version of this document to the SPEERMINT + requirements document [RFC6271]. In addition to being the base for + those security requirements, this document provides to implementers + advice and examples for concrete countermeasures on how to meet these + security requirements for SPEERMINT with technical means. The + SPEERMINT terminology outlined in [RFC5486] is used throughout this + document. + + In this document, the different security threats related to SPEERMINT + are classified into threats to the Lookup Function (LUF), the + Location Routing Function (LRF), the Signaling Function (SF), and the + Media Function (MF) of a specific SIP Service Provider (SSP). + Various instances of the threats are briefly introduced inside the + + + +Seedorf, et al. Informational [Page 4] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + + classification. Finally, existing security solutions for SIP and + RTP/RTCP are presented to describe countermeasures currently + available for such threats. Each SSP may have connections to one or + more remote SSPs through peering or transit contracts. A potentially + compromised remote SSP that attacks other SSPs is out of the scope of + this document; this document focuses on attacks on an SSP from + outside the trust domain such an SSP may have with other SSPs. + +2. Security Threats Relevant to SPEERMINT + + This section enumerates potential security threats relevant to + SPEERMINT. A taxonomy of VoIP security threats is defined in + [VOIPSATAXONOMY]. This taxonomy is comprehensive and also takes into + account non-VoIP-specific threats (e.g., loss of power, etc.). + Threats relevant to the boundaries of Layer 5 SIP networks are + extracted from this taxonomy and mapped to the functions of the + SPEERMINT architecture as defined in [RFC6406]. Moreover, additional + threats for the SPEERMINT architecture are listed and detailed under + the same classification of SPEERMINT functions and according to the + CIA (Confidentiality, Integrity, and Availability) triad: + + o Lookup Function (LUF); + + o Location Routing Function (LRF); + + o Signaling Function (SF); + + o Media Function (MF). + +2.1. Threats to the Lookup Function (LUF) + + For a given request, the LUF provides a mechanism to determine the + identity of the requested resource on the terminating domain. The + returned identity can be used to look up Session Establishment Data + (SED) using the Location Routing Function (LRF). In direct peerings, + the LUF is usually hosted locally, whereas in a federation context, + this function may be offered by a third party. + + If the LUF is hosted locally, it is vulnerable to the same threats + that affect database systems in general. If the SSP relies on a + remote third party to provide the LUF functionality, confidentiality, + integrity, and authenticity of the responses are at risk. + +2.1.1. Threats to LUF Confidentiality + + For a given request, the Lookup Function (LUF) determines the target + domain to which the request should be routed. The following attacks + are relevant with respect to eavesdropping on LUF messages: + + + +Seedorf, et al. Informational [Page 5] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + + o SIP URI and peering domain harvesting - an attacker can exploit + this weakness if the underlying database has a weak authentication + system or if SIP messages are sent unencrypted, and then use the + gained knowledge to launch other kinds of attacks. + + o Third-party information - a LUF providing information to multiple + companies / third parties can be attacked to obtain information + about third party peering configurations and possible contracts. + +2.1.2. Threats to LUF Integrity + + The underlying database or LUF messages could be vulnerable to input/ + output message modification attacks: + + o Injection attack - an attacker could manipulate statements + performed on the database LUF messages sent to a third party. A + specific version of this attack is known as "SQL injection". An + SQL injection is a code insertion into the LUF due to incorrect + input validation. + +2.1.3. Threats to LUF Availability + + The underlying database or third party LUF service could be + vulnerable to: + + o Denial-of-Service attacks - For example, an attacker makes + incomplete requests causing the server to create an idle state for + each of them, which causes memory to be 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, the following attacks are related to + eavesdropping on LRF messages: + + o URI harvesting - the attacker harvests URIs and IP addresses of + the existing User Endpoints (UEs) by issuing a multitude of + location requests. Direct intrusion against vulnerable UEs or + telemarketing are possible attack scenarios that would use the + gained knowledge. + + + + + + +Seedorf, et al. Informational [Page 6] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + + o SIP device enumeration - the attacker discovers the IP address of + each intermediate signaling device by looking at the Via and + Record-Route headers of a SIP message. Targeting the discovered + devices with subsequent attacks is a possible attack 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 is not correctly validated or sent + unencrypted. Dynamic call routing discovery and establishment, as in + the scope of SPEERMINT, introduce opportunities for attacks such as + the following: + + o Man-in-the-Middle attacks - the attacker inserts or has already + inserted an unauthorized node in the signaling path modifying the + SED. The result is that the attacker is then able to read, + insert, and modify the multimedia communications. + + o Incorrect destinations - the attacker redirects the calls to an + incorrect destination with the purpose of establishing fraud + communications like voice phishing or DoS attacks. + +2.2.3. Threats to LRF Availability + + The LRF can be the object of DoS attacks. DoS attacks to the LRF can + be carried out by sending a large number of queries to the LRF or + LUF, with the result of preventing an Originating SSP from looking up + call routing data of 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 involves a great number of sensitive + information. Through the Signaling Function, User Agents (UAs) + assert identities and operators authorize billable resources. + Correct and trusted operation of Signaling Function is essential for + service providers. This section discusses potential security threats + to the Signaling Function to detail the possible attack vectors. + +2.3.1. Threats to SF Confidentiality + + SF traffic is vulnerable to eavesdropping, in particular, when the + data is moved across multiple SSPs having different levels of + security policies. Threats for the SF confidentiality are listed + here: + + + + + +Seedorf, et al. Informational [Page 7] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + + o Call pattern analysis - the attacker tracks the call patterns of + the users violating his/her privacy (e.g., revealing the social + network of various users, the daily phone usage, etc.); also, + rival SSPs may infer information about the customer base of other + SSPs in this way; + + o Password cracking - the challenge-response authentication + mechanism of SIP Digest can be attacked with offline dictionary + attacks. With such attacks, an attacker tries to exploit weak + passwords that are used by incautious users. + + o Network discovery - the attacker may learn information 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. + +2.3.2.1. SIP Request Spoofing + + Most SIP request spoofing attacks first require SIP message + eavesdropping. However, some of these attacks can be also performed + by estimating certain fields in SIP headers (e.g., by exploiting the + fact that weak implementations may generate predictable SIP Dialog + parameters) or exploiting broken implementations that do not properly + verify the content of certain headers. Threats in this category are + as follows: + + o session teardown - an attacker can send CANCEL/BYE messages in + order to tear down an existing call at the SIP layer; for such an + attack, the attacker either needs to know (e.g., by eavesdropping + a SIP INVITE message) the SIP Dialog of the call to be hijacked + (To-tag, From-tag, Call-ID) or alternatively may rely on SIP + implementations that do not properly authenticate requests based + on the SIP Dialog; + + o Billing fraud - the attacker can modify and replay an intercepted + INVITE request in order to bill a call to a victim UE and avoid + paying for the phone call; + + o User ID spoofing - SSPs are responsible for asserting the + legitimacy of a user ID; if an SSP fails to achieve the level of + identity assertion that the federation to which it belongs + expects, it may create an entry point for attackers to conduct + user ID spoofing attacks; + + + +Seedorf, et al. Informational [Page 8] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + + o 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 + + Threats in this category are as follows: + + o Forged 199 Response - the attacker sends a forged 199 response to + terminate an early dialog. The forged response will not terminate + the entire session but may alter the direction of the session; + + o Forged 200 Response - having seen the contents of an INVITE + request, an eavesdropper can inject a 200 response, affecting the + processing of the transaction of all proxies between the injection + point and the originating UA and at the originating UA itself. In + the extreme case, this can result in a hijacked call. In many + cases, however, such an attack will leave 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); + + o Forged 302 Response - having seen the contents of an INVITE + request, an eavesdropper could also inject a forged "302 Moved + Temporarily" reply, affecting the processing of the transaction at + intermediate entities and the originating UA. This may allow the + attacker to successfully redirect the call to any destination UE + of his choosing; + + o Forged 404 Response - having seen the contents of an INVITE + request, an eavesdropper could also inject a forged "404 Not + Found" reply, affecting the processing of the transaction at + intermediate entities and the originating UA. Such an attack may + result in disrupting the call establishment. + +2.3.2.3. SIP Message Tampering + + This threat involves the alteration of important field values in a + SIP message or in the Session Description Protocol (SDP) body. + Examples of this threat could be the dropping or modification of + handshake packets in order to avoid the establishment of a secure RTP + session (SRTP). The same approach could be used to degrade the + quality of media session by letting a UE negotiate a poor quality + codec. + + + + +Seedorf, et al. Informational [Page 9] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + +2.3.3. Threats to SF Availability + + o Flooding attack - a Signaling Path Border Element (SBE) is + susceptible to message flooding attacks that may come from + interconnected SSPs; + + o 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; + + o 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 carries sensitive + information. Through the media function, the UE can establish secure + communications and monitor the quality of conversations. Correct and + trusted operations of MF is essential for privacy and service- + assurance issues. This section discusses potential security threats + to the MF to detail the possible attack vectors. + +2.4.1. Threats to MF Confidentiality + + The MF is vulnerable to eavesdropping in which 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 in order 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 violation in many ways: + + o Media injection - if an attacker can somehow detect an ongoing + media session and eavesdrop a few RTP packets, he 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 RTP packets and discard the legitimate ones. + + + + + + + +Seedorf, et al. Informational [Page 10] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + + o Media session teardown - the attacker sends bogus RTCP BYE + messages to a target UE signaling to tear down the media + communication; please note that RTCP messages are normally not + authenticated. + + o Quality-of-Service (QoS) degradation - the attacker sends wrong + RTCP reports advertising more packet loss or more jitter than + actually experimented resulting in the usage of a poor quality + codec degrading the overall quality of the call experience. + +2.4.3. Threats to MF Availability + + o 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; + + o 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 security requirements for SPEERMINT have been moved from an + earlier version of this document to the SPEERMINT requirements + [RFC6271]. The security requirements for SPEERMINT are the + following, from [RFC6271]: + + o Requirement #15: The protocols used to query the Lookup and + Location Routing Functions SHOULD support mutual authentication. + + o Requirement #16: The protocols used to query the Lookup and + Location Routing Functions SHOULD provide support for data + confidentiality and integrity. + + o 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 state that the LUF and LRF should support + mutual authentication, data confidentiality, and integrity. In + principle, these requirements can be fulfilled technically with + Transport Layer Security (TLS) or Datagram TLS (DTLS) [RFC5246] + [RFC4347] or IP layer security (IPsec) [RFC4301]. From a pure + + + + +Seedorf, et al. Informational [Page 11] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + + security perspective both solutions fulfill the security requirements + for SPEERMINT, just on a different layer, and both solutions are + widely deployed. + + However, from a more practical perspective, transport layer security + (i.e., TLS or DTLS) has the advantage that the application using it + is aware of whether or not security (or rather the corresponding + security features) is enabled. For instance, using TLS has the + consequence that the connection fails if the corresponding connection + endpoint cannot authenticate properly. + + While IPsec fulfills the same requirements from a security + perspective, IPsec is somewhat de-coupling security from the + application using it. For instance, IPsec is often provided by + dedicated entities in such a way that from the application layer, it + cannot be recognized whether or not IPsec or certain security + features are turned on ("bump-in-the-wire"). + + In summary, TLS (or DTLS) has some notable advantages over IPsec for + addressing 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, however, 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 described in the previous sections and for addressing the + SPEERMINT security requirements described in [RFC6271]. The + countermeasures listed in this section are not meant to be + exhaustive; rather, the suggested countermeasures are aimed to serve + as starting points and to give guidance for implementers that are + trying to select appropriate countermeasures against certain threats. + + The following table provides a map of the relationships between + threats and countermeasures. The suggested countermeasures are + discussed in detail in the subsequent subsections. + + + + + + + + + + + +Seedorf, et al. Informational [Page 12] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + + +-------+---------------+-------------------------------------------+ + | 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 | | + + + +Seedorf, et al. Informational [Page 13] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + + | | 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 to prevent it + from being a target of attacks often seen on common database systems. + Common security Best Current Practices (BCPs) for database systems + include the use of strong passwords to prevent unauthorized access, + parameterized statements to prevent SQL injections, and server + replication to prevent any database from being 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 + has been designed to protect DNS against well-known attacks such as + DNS cache poisoning or Man-in-the-Middle (MitM) attacks on DNS + queries. Essentially, DNSSEC is 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 + regarding non-existing DNS entries. In the context of SSP peering, + DNSSEC can provide authentication and integrity regarding the + location of a Signaling Function (SF) entity retrieved via DNS. + Using DNSSEC can thus help to 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, at the time of this + writing, DNSSEC is still not yet widely deployed on the Internet, + even limited deployment can add significant integrity protection and + + + +Seedorf, et al. Informational [Page 14] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + + authentication to the LRF for Signaling Function locations received + via DNS entries. Neither end users nor terminals are involved in the + DNS resolution process of the LRF. Hence, 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, the LRF can be secured with + DNSSEC. In the context of SPEERMINT, all three of these requirements + can be fulfilled even in the case of partial DNSSEC deployment. In + particular, even without Internet-wide deployment of DNSSEC, 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 to mitigate DoS + attacks on the LRF. Simultaneously bringing down multiple DNS + servers that support the LRF is much more challenging than attacking + a sole DNS server (single point of failure). + +4.4. Cross-Domain Privacy Protection + + Stripping Via and Record-Route headers, replacing the Contact header, + and even changing Call-IDs are the mechanisms described in [RFC3323] + to protect SIP privacy. This practice allows an SSP to hide its SIP + network topology, prevents intermediate signaling equipment from + becoming the target of DoS attacks, as well as protects the privacy + of UEs according to their preferences. This practice is effective in + preventing SIP equipment enumeration that exploits LRF. + +4.5. Secure Exchange of SIP Messages + + SIP can be used on top of UDP or TCP as transport protocol [RFC3261]. + However, look-up and SED data should be exchanged securely (see + security requirements (Section 3.2)), e.g., to increase the + difficulty of performing session teardown and forging responses (200, + 302, 404, etc). If UDP is used to carry SIP messages, DTLS should be + used to secure SIP message exchange between SSPs. If TCP is used as + a transport protocol, it can be secured with TLS. Therefore, + depending on the underlying transport protocol, SSPs should use + either DTLS or TLS to secure SIP message delivery. + + + + + +Seedorf, et al. Informational [Page 15] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + + In general, encryption and integrity protection of signaling messages + can be achieved on the transport layer (with TLS or DTLS) or on the + network layer (with IPsec). Both solutions are technically sound, + but transport layer security has some advantages. Please refer to + the subsection on fulfilling the SPEERMINT security requirements + (Section 3.2) for a discussion on using TLS/DTLS or IPsec for + protecting the confidentiality and integrity of signaling messages. + Similar to strong identity assertion, a Public Key Infrastructure + (PKI) is assumed to be in place for TLS/DTLS (or IPsec) deployment so + that SSPs can obtain and trust the keys necessary 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). + +4.6. Ingress Filtering / Reverse-Path Filtering + + Ingress filtering, i.e., blocking all traffic coming from a host that + has a source address different than the addresses that have been + assigned to that host (see [RFC2827]), can effectively prevent UEs + from sending packets with a spoofed source IP address. This can be + achieved by reverse-path filtering, i.e., only accepting ingress + traffic if responses would take the same path. This practice is + effective in preventing session teardown and forged SIP replies (200, + 302, 404, etc.), 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" can be achieved thanks to the weak identity + assertion on the From URI of an INVITE request. In a single SSP + domain, strong identity assertion can be easily achieved by + authenticating each INVITE request. However, in the context of + SPEERMINT, only the Originating SSP is able to verify the identity + directly. In order to overcome this problem, 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 of this approach is a + combined mechanism specified in [RFC3324] and [RFC3325]. Using this + approach in a transit peering network scenario, the terminating SSP + must establish a trust relationship with all SSP domains on the path, + which can be seen as an underlying weakness. The use of + cryptographic signatures is an alternative approach. "Session + Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format" + is specified in [RFC3893]. [RFC4474] introduces two new header + fields, IDENTITY and IDENTITY-INFO, that allow a SIP server in the + Originating SSP to digitally sign an INVITE request after + authenticating the sending UE. The terminating SSP can verify if the + + + +Seedorf, et al. Informational [Page 16] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + + INVITE request is signed by a trusted SSP domain. Although this + approach does not require the terminating SSP to establish a trust + relationship with all transit SSPs on the path, a PKI is assumed to + be in place. + +4.8. Reliable Border Element Pooling + + It is advisable to implement reliable pooling on border elements. An + architecture and protocols for the management of server pools + supporting mission-critical applications are addressed in the + RSERPOOL WG. Using such mechanisms and protocols (see [RFC5351] + [RFC5352] [RFC5353] for details), a UE can effectively increase its + capacity in 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. In this way, + legitimate clients can be denied the 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 and may result in false positives (i.e., source IP + addresses blocked) when multiple legitimate clients are located + 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 it (since sessions use more resources on + backend-systems). When calculating rate limits, all entities 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) rather than the ingress limiting + device. + +4.10. Topology Hiding + + Topology hiding applies to both the signaling and media plane and + consists of limiting the amount of topology information exposed to + peering partners. Topology hiding requires back-to-back user agent + (B2BUA) functionality. The most common way is the use of a Session + Border Controller (SBC) as SBE. Topology hiding is explained 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. For + instance, fuzz testing is a common black box testing technique used + + + +Seedorf, et al. Informational [Page 17] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + + in software engineering. Also, security vulnerability tests can be + carried out preventively to assure 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 type of tests needs to + be carried out before product release and in addition throughout the + product life cycle. + +4.12. Securing Session Establishment Data + + Session Establishment Data (SED) contains critical information for + the routing of SIP sessions. In order to prevent attacks such as + service hijacking and denial of service that exploit SED, SSPs should + adopt a secure transport protocol that provides authentication, + confidentiality and integrity to exchange SED among themselves. + Further details can be found in [DRINKS-SPPROV]. + +4.13. Encryption and Integrity Protection of Media Stream + + The Secure Real-time Transport Protocol (SRTP) [RFC3711] prevents + 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 is agreed upon after + negotiation. It also uses HMAC-SHA1 and index keeping to enable + message authentication/integrity and replay protection required to + prevent media injection attacks. Secure RTCP (SRTCP) provides the + same security-related features to RTCP as SRTP does for RTP. SRTCP + is described in [RFC3711] as optional. In order to prevent media + session teardown, it is recommended to turn this feature on. The + choice of the external key management protocol is left to the + deployment, a PKI is necessary to implement the security requirements + of the SPEERMINT requirements document. + +5. Conclusions + + This document presented the different SPEERMINT security threats + classified in groups related to the LUF, LRF, SF, and MF, + respectively. The multiple instances of the threats were presented + with a brief explanation. Finally, suggested countermeasures for + SPEERMINT were outlined together with possible mitigation of the + existing threats by means of them. + +6. Security Considerations + + This document is entirely focused on the security threats for + SPEERMINT. + + + + + +Seedorf, et al. Informational [Page 18] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + +7. Acknowledgements + + This document was originally inspired by the VOIPSA VoIP Security and + Privacy Threat Taxonomy. The authors would like to thank VOIPSA for + having produced a comprehensive taxonomy as the starting point of + this document. Additionally, the authors would like to thank Cullen + Jennings, Jon Peterson, David Schwartz, Hadriel Kaplan, Peter Koch, + Daryl Malas, Jason Livingood, and Robert Sparks for useful comments + to previous editions of this document on the mailing list as well as + 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 + + [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. + + + +Seedorf, et al. Informational [Page 19] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + + [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. + + + +Seedorf, et al. Informational [Page 20] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + + [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. + + + + + + + + + + + + + + + + + + +Seedorf, et al. Informational [Page 21] + +RFC 6404 SPEERMINT Threats and Countermeasures November 2011 + + +Authors' Addresses + + 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 + + + + + + + + +Seedorf, et al. Informational [Page 22] + -- cgit v1.2.3