SPEERMINT Working Group J. Seedorf
Internet-Draft S. Niccolini
Intended status: Informational NEC
Expires: January 13, 2011 E. Chen
NTT
H. Scholz
VOIPFUTURE
July 12, 2010
SPEERMINT Security Threats and Suggested Countermeasures
draft-ietf-speermint-voipthreats-03
Abstract
This memo presents the different security threats related to
SPEERMINT, classifying them into threats to the Lookup Function
(LUF), to the Location Routing Function (LRF), to the Signaling
Function (SF) and to the Media Function (MF). The different
instances of the threats are briefly introduced inside the
classification. Finally, the existing security solutions for SIP and
RTP/RTCP are presented to describe the countermeasures currently
available for such threats. Security requirements for SPEERMINT can
be found in draft-ietf-speermint-requirements. The objective of this
document is to identify and enumerate SPEERMINT-specific threat
vectors and to give guidance for implementers on selecting
appropriate countermeasures.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Seedorf, et al. Expires January 13, 2011 [Page 1]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
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. Expires January 13, 2011 [Page 2]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Security Threats relevant to SPEERMINT . . . . . . . . . . . . 5
2.1. Threats to the Look-Up 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 . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . 7
2.3.3. Threats to SF Availability . . . . . . . . . . . . . . 9
2.4. Threats to the Media Function (MF) . . . . . . . . . . . . 9
2.4.1. Threats to MF Confidentiality . . . . . . . . . . . . 9
2.4.2. Threats to MF Integrity . . . . . . . . . . . . . . . 9
2.4.3. Threats to MF Availability . . . . . . . . . . . . . . 10
3. Security Requirements . . . . . . . . . . . . . . . . . . . . 11
3.1. Security Requirements from SPEERMINT requirements draft . 11
3.2. How to fulfill the security requirements for SPEERMINT . . 11
4. Suggested Countermeasures . . . . . . . . . . . . . . . . . . 13
4.1. Database Security BCPs . . . . . . . . . . . . . . . . . . 15
4.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. DNS Replication . . . . . . . . . . . . . . . . . . . . . 16
4.4. Cross-Domain Privacy Protection . . . . . . . . . . . . . 16
4.5. Using TCP instead of UDP to deliver SIP messages . . . . . 16
4.6. Ingress Filtering / Reverse-Path Filtering . . . . . . . . 16
4.7. Strong Identity Assertion . . . . . . . . . . . . . . . . 17
4.8. Reliable Border Element Pooling . . . . . . . . . . . . . 17
4.9. Rate limit . . . . . . . . . . . . . . . . . . . . . . . . 17
4.10. Topology Hiding . . . . . . . . . . . . . . . . . . . . . 18
4.11. Border Element Hardening . . . . . . . . . . . . . . . . . 18
4.12. Minimization of Session Establishment Data . . . . . . . . 18
4.13. Encryption and Integrity Protection of Signaling
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.14. Encryption and Integrity Protection of Media Stream . . . 18
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
8. Informative References . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Seedorf, et al. Expires January 13, 2011 [Page 3]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
1. Introduction
With 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 to compromise 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. 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, DoS attacks, etc.). Therefore there is the need of
investigating the different security threats, to extract security-
related requirements, and to highlight potential solutions on how to
protect from such threats.
The objective of this document is to identify and enumerate
SPEERMINT-specific threat vectors and to give guidance for
implementers on selecting appropriate countermeasures. In addition,
this document provides advice to implementers on how to fulfill the
security requirements for SPEERMINT (which are detailed in the
SPEERMINT requirements draft [I-D.ietf-speermint-requirements]) with
technical means. The SPEERMINT terminology outlined in [RFC5486] is
used throughout this document.
Seedorf, et al. Expires January 13, 2011 [Page 4]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
2. Security Threats relevant to SPEERMINT
This section enumerates potential security threats relevant to
SPEERMINT. A taxonomy of VoIP security threats is defined in
[refs.voipsataxonomy]. This taxonomy is comprehensive and takes into
account also 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 [refs.speermintarch]. 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 Look-Up Function (LUF);
o Location Routing Function (LRF);
o Signaling Function (SF);
o Media Function (MF).
2.1. Threats to the Look-Up Function (LUF)
The LUF provides a mechanism to determine for a given request 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 3rd party to provide the LUF functionality both integrity and
authenticity of the responses are at risk.
2.1.1. Threats to LUF Confidentiality
o SIP URIs and peering domains harvesting - an attacker can exploit
this weakness if the underlying database has a weak authentication
system, and then use the gained knowledge to launch other kinds of
attacks.
o 3rd 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.
Seedorf, et al. Expires January 13, 2011 [Page 5]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
2.1.2. Threats to LUF Integrity
The underlying database could be vulnerable to:
o Injection attack - an attacker could manipulate statements
performed on the database by the end user.
2.1.3. Threats to LUF Availability
The underlying database could be vulnerable to:
o Denial of Service attacks - e.g. an attacker makes incomplete
requests causing the server to create an idle state for each of
them causing 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
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.
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 feed bogus information to the LRF if the routing data
is not correctly validated. 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 attack - the attacker has already or inserts an
unauthorized node in the signaling path modifying the SED. The
results is that the attacker is then able to read, insert and
modify the multimedia communications.
o Incorrect destinations - the attacker redirect the calls to a
incorrect destination with the purpose of establishing fraud
Seedorf, et al. Expires January 13, 2011 [Page 6]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
communications like voice phishing or DoS attacks.
2.2.3. Threats to LRF Availability
The LRF can be object of DoS attacks. DoS attacks to the LRF can be
carried out by sending a large number of queries to the LS or Session
Manager, SM, 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)
Signaling function involves a great number of sensitive information.
Through signaling function, user agents (UA) assert identities and
VSP operators authorize billable resources. Correct and trusted
operations 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:
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 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 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.
Seedorf, et al. Expires January 13, 2011 [Page 7]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
2.3.2.1. SIP Request Spoofing
Most SIP request spoofing require first a SIP message eavesdropping
but some of the them could be also performed by guessing or
exploiting broken implementations. Threats in this category are:
o session teardown - the attacker uses CANCEL/BYE messages in order
to tear down an existing call at SIP layer, it is needed that the
attacker replicates the proper SIP header for the hijacking to be
successful (To, From, Call-ID, CSeq);
o Billing fraud - the attacker alters an INVITE request 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 user ID; if an SSP fails to achieve the level of
identity assertion that the federation it belongs expects, it may
create an entry point for attackers to conduct user ID spoofing
attacks.
o Unwanted requests - the attacker sends requests to interfere with
regular operation, i.e. sends a REGISTER request to hijack calls.
The SPEERMINT architecture as defined in [refs.speermintarch] does
not require registrations between the signaling functions (SF) of
the connected SSPs. Superfluous requests like REGISTERs should be
rejected.
2.3.2.2. SIP Reply Spoofing
Threats in this category are:
o Forged 200 Response - the attacker sends a forged CANCEL request
to terminate a call in progress tricking the terminating UE to
believe that the originating UE actually sent it, and successfully
hijacks a call sending a forged 200 OK message to the originating
UE communicating the address of the rogue UE under the attacker's
control;
o Forged 302 Response - the attacker sends a forged "302 Moved
Temporarily" reply instead of a 200 OK, this enables the attack to
hijack the call and to redirect it to any destination UE of his
choosing;
o Forged 404 Response - the attacker sends a forged "404 Not Found"
reply instead of a 200 OK, this enables the attack to disrupt the
call establishment;
Seedorf, et al. Expires January 13, 2011 [Page 8]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
2.3.2.3. SIP Message Tampering
This threat involves the alternation of important field values in a
SIP message or in the 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 UE
negotiate a poor quality codec.
2.3.3. Threats to SF Availability
o Flooding attack - a SBE is susceptible to message flooding attack
that may come from interconnected SSPs;
o Session Black Holing - 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 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 media function, UE can establish secure
communications and monitor 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.
PIN numbers from DTMF tones). SRTP and ZRTP are vulnerable to bid-
down attacks, i.e. by selectively dropping key exchange protocol
packets may result in the establishment of a non-secure
communications.
2.4.2. Threats to MF Integrity
Both RTP and RTCP are vulnerable to integrity violation in many ways:
o Media Hijack - 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.
Seedorf, et al. Expires January 13, 2011 [Page 9]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
As illustrated in Fig. 8, 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.
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 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 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.
Seedorf, et al. Expires January 13, 2011 [Page 10]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
3. Security Requirements
3.1. Security Requirements from SPEERMINT requirements draft
The security requirements for SPEERMINT have been moved from an
earlier version of this draft to the SPEERMINT requirements draft
[I-D.ietf-speermint-requirements]. The security requirements for
SPEERMINT are the following [I-D.ietf-speermint-requirements]:
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 demand 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) [RFC5246] or IP layer security (IPSec)
[RFC4301]. From a pure 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, TLS has the advantage
that the application using it is aware of security (or rather the
corresponding security features) being enabled or not. 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 if IPSec or certain security features are turned
on or not ("bump-in-the-wire").
In summary, TLS has some notable advantages over IPsec for addressing
the SPEERMINT security requirements. In particular, TLS is
preferable over IPSec for SPEERMINT because with TLS security is more
closely coupled to the LUF or LRF. From a mere technical
Seedorf, et al. Expires January 13, 2011 [Page 11]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
perspective, however, both solutions (TLS or IPSec) fulfill the
SPEERMINT security requirements and there may be particular cases
where IPSec is a preferable solution.
Seedorf, et al. Expires January 13, 2011 [Page 12]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
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
[I-D.ietf-speermint-requirements].
The following table provides a map of the relationships between
threats and countermeasures. The suggested countermeasures are
discussed in detail in the subsequent subsections.
+-------+---------------+-------------------------------------------+
| Group | Threat | Suggested Countermeasure |
+-------+---------------+-------------------------------------------+
| LUF | Unauthorized | database security BCPs (Section 4.1) |
| | access | |
| | | |
| | SQL injection | database security BCPs |
| | | |
| | DoS to LUF | database security BCPs |
| | | |
| | | |
| LRF | URI | privacy protection (Section 4.4) |
| | harvesting | |
| | | |
| | SIP equipment | privacy protection (Section 4.4) |
| | enumeration | |
| | | |
| | MitM attack | DNSSEC |
| | | |
| | Incorrect | DNSSEC |
| | destinations | |
| | | |
| | DoS to LRF | DNS replication (Section 4.3) |
| | | |
| | | |
| SF | Call pattern | Encryption and Integrity Protection of |
| | analysis | Signaling Messages (Section 4.13), |
| | | Minimization of Session Establishment |
| | | Data (Section 4.12) |
| | | |
| | Password | Encryption and Integrity Protection of |
| | cracking | Signaling Messages, Minimization of |
| | | Session Establishment Data |
| | | |
| | Network | Minimization of Session Establishment |
| | discovery | Data, Topology Hiding (Section 4.10) |
| | | |
Seedorf, et al. Expires January 13, 2011 [Page 13]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
| | Session | Encryption and Integrity Protection of |
| | teardown | Signaling Messages, TCP (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 | Encryption and Integrity Protection of |
| | Response | Signaling Messages, TCP, ingress |
| | | filtering |
| | | |
| | Forged 302 | Encryption and Integrity Protection of |
| | Response | Signaling Messages, TCP, ingress |
| | | filtering |
| | | |
| | Forged 404 | Encryption and Integrity Protection of |
| | Response | Signaling Messages, TCP, ingress |
| | | filtering |
| | | |
| | Flooding | reliable border element pooling |
| | attack | (Section 4.8), rate limit (Section 4.9) |
| | | |
| | Session black | DNSSEC |
| | holing | |
| | | |
| | SIP fuzzing | border element hardening (Section 4.11) |
| | attack | |
| | | |
| | | |
| MF | Eavesdropping | Encryption and Integrity Protection of |
| | | Media Stream (Section 4.14) |
| | | |
| | Media hijack | Encryption and Integrity Protection of |
| | | Media Stream |
| | | |
| | Media session | Encryption and Integrity Protection of |
| | teardown | Media Stream |
| | | |
| | QoS | Encryption and Integrity Protection of |
| | degradation | Media Stream |
| | | |
| | Malformed | border element hardening |
| | messages | |
| | | |
Seedorf, et al. Expires January 13, 2011 [Page 14]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
| | Message | rate limit |
| | 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. [refs.dbsec] is one of many existing literatures 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][RFC4035]. DNSSEC has
been designed to protect DNS against well-known attacks such as DNS
cache poisoning or man-in-the-middle attacks on DNS queries.
Essentially, DNSSEC is a set of public key cryptography extensions to
DNS which 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 not seen wide deployment on the Internet (due to various
reasons which are out of the scope of this document). However, even
with limited deployment DNSSEC can add integrity protection and
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 which 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 these three 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 trust
Seedorf, et al. Expires January 13, 2011 [Page 15]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
anchor for a certain SSP could be obtained via a DS record of that
specific SSP's top level domain or from the particular SSP directly.
4.3. DNS Replication
DNS replication is a very important countermeasure to mitigate DoS
attacks on LRF. Simultaneously bringing down multiple DNS servers
that support 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. Using TCP instead of UDP to deliver SIP messages
SIP clients need to stay connected with the server on a persistent
basis (differently from HTTP clients). Scalability requirements are
therefore much more stringent for a SIP server than for a web server.
This leads to the choice of UDP as protocol used between SSPs to
carry SIP messages (especially for providers with a large user
community). New improvements in the Linux kernel
[refs.tcp-scalability] show a big increase of the scalability of TCP
in handling large number of persistent (but idle) connections.
Therefore SSP operators still using UDP for their SIP network should
consider switching to TCP. This would significantly increase the
difficulty of performing session teardown and forging responses (200,
302, 404 etc). Since look-up and SED data should be exchanged
securely (see security requirements), it is further recommended to
not only use TCP but TLS for messages exchanged between SSPs.
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.
Seedorf, et al. Expires January 13, 2011 [Page 16]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
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. "SIP Authenticated Identity Body (AIB)"
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
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 infrastructure
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 this mechanism (see [RFC3237] for requirements),
a UE can effectively increase its capacity in handling flooding
attacks.
4.9. Rate limit
Flooding attacks on SF and MF can also be mitigated by limiting the
rate of incoming traffic through policing or queuing. In this way
legitimate clients can be denied of 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 and will all the limitations
related to NAT and mobility issues. It may be preferable to limit
the number of concurrent 'sessions', i.e., ongoing calls instead of
the messaging associated with it (since session 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
Seedorf, et al. Expires January 13, 2011 [Page 17]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
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 B2BUA functionality. The
most common way is the use of a Session Border Controller (SBC) as
SBE. Topology hiding is explained in [refs.sbcfuncs]
4.11. Border Element Hardening
To prevent attacks which 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
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 [refs.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. Minimization of Session Establishment Data
In order to give attackers as few chances as possible for
eavesdropping, session hijacking, and other attacks, SSPs should try
to minimize session establishment data. Unnecessary data exchange
also increases the risk of an implementation vulnerability that could
be exploited by attackers. In addition. unnecessary data exchange
among SSPs can increase the risk of call patterns analysis or
discovery of some SSPs interior topology.
4.13. Encryption and Integrity Protection of Signaling Messages
Encryption of signaling messages can be achieved with TLS or IPSec.
Similar to strong identity assertion, a PKI infrastructure is assumed
to be in place for TLS (or IPSec) deployment so that SSPs can obtain
and trust the keys necessary to decrypt messages and verify
signatures sent by other SSPs.
4.14. Encryption and Integrity Protection of Media Stream
The Secure Real-time Transport Protocol (SRTP) [RFC3711] adds
security features to plain RTP by mainly providing encryption using
AES to prevent eavesdropping. It also uses HMAC-SHA1 and index
Seedorf, et al. Expires January 13, 2011 [Page 18]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
keeping to enable message authentication/integrity and replay
protection required to prevent media hijack 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.
Seedorf, et al. Expires January 13, 2011 [Page 19]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
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.
Seedorf, et al. Expires January 13, 2011 [Page 20]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
6. Security Considerations
This document is entirely focused on the security threats for
SPEERMINT.
Seedorf, et al. Expires January 13, 2011 [Page 21]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
7. Acknowledgements
This document has originally been 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 draft. Additionally, the authors would like
to thank Cullen Jennings, Jon Peterson, David Schwartz, Hadriel
Kaplan, Peter Koch, Daryl Malas, and Jason Livingood for useful
comments to previous editions of this draft on the mailing list as
well as during IETF meetings.
Seedorf, et al. Expires January 13, 2011 [Page 22]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
8. Informative References
[refs.voipsataxonomy]
Zar, J. and et al, "VOIPSA VoIP Security and Privacy
Threat Taxonomy", October 2005.
[refs.speermintarch]
Uzelac, A., "SPEERMINT Peering Architecture",
draft-ietf-speermint-architecture-09.txt (work in
progress), November 2009.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia
Interconnect (SPEERMINT) Terminology", RFC 5486,
March 2009.
[I-D.ietf-speermint-requirements]
Mule, J., "SPEERMINT Requirements for SIP-based Session
Peering", draft-ietf-speermint-requirements-09 (work in
progress), October 2009.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[refs.dbsec]
Gertz, M. and S. Jajodia, "Handbook of Database Security".
[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.
Seedorf, et al. Expires January 13, 2011 [Page 23]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002.
[refs.tcp-scalability]
Shemyak, K., "Scalability of TCP Servers, Handling
Persistent Connections".
[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.
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP)
Authenticated Identity Body (AIB) Format", RFC 3893,
September 2004.
[RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L.,
Loughney, J., and M. Stillman, "Requirements for Reliable
Server Pooling", RFC 3237, January 2002.
[refs.protos]
Wieser, C., "SIP Robustness Testing for Large-Scale Use".
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
and H. Schulzrinne, "Session Initiation Protocol (SIP)
Torture Test Messages", RFC 4475, May 2006.
[refs.sbcfuncs]
Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
A., and M. Bhatia, "Requirements from SIP (Session
Initiation Protocol) Session Border Control Deployments",
draft-ietf-sipping-sbc-funcs-09.txt (work in progress),
February 2010.
Seedorf, et al. Expires January 13, 2011 [Page 24]
Internet-Draft SPEERMINT Threats and Countermeasures July 2010
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@nw.neclab.eu
URI: http://www.nw.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@nw.neclab.eu
URI: http://www.nw.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 379
Hamburg 20537
Germany
Phone: +49 (0) 40 688 900 166
Email: hendrik.scholz@voipfuture.com
URI: http://voipfuture.com
Seedorf, et al. Expires January 13, 2011 [Page 25]
