summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6404.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6404.txt')
-rw-r--r--doc/rfc/rfc6404.txt1235
1 files changed, 1235 insertions, 0 deletions
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]
+