(IJCNS) International Journal of Computer and Network Security, 41

Vol. 2, No. 5, May 2010

Security Issues for Voice over IP Systems

Ali Tahir1, Asim Shahzad2
1
Faculty of Telecommunication and Information Engineering, UET TAXILA,
Pakistan
ali.tahir.nsn@hotmail.com

2
Faculty of Telecommunication and Information Engineering, UET TAXILA,
Pakistan
asim.shahzad@uettaxila.edu.pk

Abstract: Firewalls, Network Address Translation (NAT), and

encryption produce Quality of Service (QoS) issues which are
the basic building block to the operations of a VOIP system.
There are two major non proprietary standards used for VoIP
communications. They are H.323 and Session Initiation
Protocol (SIP). Firewalls, NAT, and Intrusion Detection
Systems (IDS) are used to filter unwanted packets in VoIP
environment. To provide defense against an internal hacker,
another layer of defense is necessary at the protocol level to
protect the data itself. In VOIP, as in data networks, this can be
accomplished by encrypting the packets at the IP level using
IPSec. As VoIP is an IP based technology that utilizes the
Internet it also inherits all associated IP vulnerabilities. This
research paper focus on different security issues associated with Figure 1. How VOIP works [1]
voice over IP system.
The VoIP networks replace the traditional public-switched
Keywords: Voice-Over Internet Protocol (VoIP), Firewalls. telephone networks (PSTNs), as these can perform the same
functions as the PSTN networks. The functions performed
include signaling, data basing, call connect and disconnect,
1. Overview of VOIP and coding-decoding.

The Voice-Over Internet Protocol (VoIP) technology allows

the voice information to pass over IP data networks. This
technology results in huge savings on the amount of
physical resources required to communicate by voice over
long distance. It does so by exchanging the information in
packets over a data network. The basic functions performed
by a VoIP include - signaling, data basing, call connect and
disconnect, and coding/decoding. The steps involved in
originating and internet telephone call are the conversion of
the analogue voice signal to digital format and compression
/ translation of the signal into internet protocol (IP) packets
for transmission over the internet; the process is reversed at
the receiving end. VoIP software’s like Vocal TEC or Net 2
Phone are available for the user [1]. With the exception of
phone to phone, the user must posses an array of equipment
which should at minimum include VoIP software, an
internet connection, and a multimedia computer with a
sound card, speakers, a microphone and a modem [1].The
VoIP network acts as a gateway to the existing PSTN
network. This gateway forms the interface for transportation
of the voice content over the IP networks. Gateways are
responsible for all call origination, call detection, analogue
to digital conversion of voice, and creation of voice packets.
2. Quality of Service Issues
Quality of Service (QoS) is fundamental to the operation of
a VOIP network. Despite all the money VOIP can save users
and the network elegance it provides, if it cannot deliver at
least the same quality of call setup and voice relay
functionality and voice quality as a traditional telephone
network, then it will provide little added value. There are
various security measures that can degrade QoS. For
example blocking of call setups by firewalls, encryption-
produced latency and delay variation (jitter). QoS issues are
central to VOIP security. If QoS was assured, then most of
the same security measures currently implemented in
today’s data networks could be used in VOIP networks. But
because of the time-critical nature of VOIP, and its low
tolerance for disruption and packet loss, many security
measures implemented in traditional data networks just
aren’t applicable to VOIP in their current form. The main
QoS issues associated with VOIP that security affects are
presented here [4].
2.1 Latency
Latency in VOIP refers to the time it takes for a voice
transmission to go from its source to its destination. We
would like to keep latency as low as possible for ideal
42
systems but there are practical lower bounds on the delay of
VOIP. The ITU-T Recommendation G.114 establishes a
number of time constraints on one-way latency. The upper
bound is 150 ms in [2] for one-way traffic experienced in
domestic calls across PSTN lines in the continental United
States. For international calls, a delay of up to 400 ms was
deemed tolerable, but since most of the added time is spent
routing and moving the data over long distances, we
consider here only the domestic case and assume our
solutions are upwards compatible in the international realm.
VOIP calls must achieve the 150 ms bound to successfully
emulate the QoS that today’s phones provide. It places a
genuine constraint on the amount of security that can be
added to a VOIP network. The encoding of voice data can
take between 1 and 30 ms and voice data traveling across
the North American continent can take upwards of 100 ms
although actual travel time is often much faster . Assuming
the worst case (100 ms transfer time), 20 –50 ms remain for
queuing and security implementations [4].
Figure 2. Sample Latency Budget [4]
Delay is not confined to the endpoints of the system. Each
hop along the network introduces a new queuing delay and
possibly a processing delay if it is
a security checkpoint (i.e. firewall or encryption/decryption
point). Also, larger packets tend to cause bandwidth
congestion and increased latency. In light of these issues,
VOIP tends to work best with small packets on a logically
abstracted network to keep latency at a minimum.
2.2 Jitter
Jitter refers to non-uniform packet delays. It is often caused
by low bandwidth situations in VOIP and can be
exceptionally detrimental to the overall QoS. Variations in
delays can be more detrimental to QoS than the actual
delays themselves. Jitter can cause packets to arrive and be
processed out of sequence. RTP, the protocol used to
transport voice media, is based on UDP so packets out of
order are not reassembled at the protocol level. However,
RTP allows applications to do the reordering using the
sequence number and timestamp fields. The overhead in
(IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 5, May 2010
reassembling these packets is non-trivial, especially when
dealing with the tight time constraints of VOIP.
When jitter is high, packets arrive at their destination in
spurts. The general prescription to control jitter at VOIP
endpoints is the use of a buffer, but such a buffer has to
release its voice packets at least every 150 ms (usually a lot
sooner given the transport delay) so the variations in delay
must be bounded. The buffer implementation issue is
compounded by the uncertainty of whether a missing packet
is simply delayed an anomalously long amount of time, or is
actually lost.
Jitter can also be controlled throughout the VOIP network
by using routers, firewalls, and other network elements that
support QoS. These elements process and pass along time
urgent traffic like VOIP packets sooner than less urgent data
packets. Another method for reducing delay variation is to
pattern network traffic to diminish jitter by making as
efficient use of the bandwidth as possible. This constraint is
at odds with some security measures in VOIP. Chief among
these is IPSec, whose processing requirements may increase
latency, thus limiting effective bandwidth and contributing
to jitter.
The window of delivery for a VOIP packet is very small, so
it follows that the acceptable variation in packet delay is
even smaller. Thus, although we are concerned with
security, the utmost care must be given to assuring that
delays in packet deliveries caused by security devices are
kept uniform throughout the traffic stream [4].
2.3 Packet Loss
VOIP is exceptionally intolerant of packet loss. Packet loss
can result from excess latency, where a group of packets
arrives late and must be discarded in favor of newer ones. It
can also be the result of jitter, that is, when a packet arrives
after its surrounding packets have been flushed from the
buffer, making the received packet useless. Compounding
the packet loss problem is VOIP’s reliance on RTP, which
uses the unreliable UDP for transport, and thus does not
guarantee packet delivery. However, the time constraints do
not allow for a reliable protocol such as TCP to be used to
deliver media. The good news is that VOIP packets are very
small, containing a payload of only 10-50 bytes, which is
approximately 12.5-62.5 ms in [4], with most
implementations tending toward the shorter range. The loss
of such a minuscule amount of speech is not discernable or
at least not worthy of complaint for a human VOIP user.
The bad news is these packets are usually not lost in
isolation. Bandwidth congestion and other such causes of
packet loss tend to affect all the packets being delivered
around the same time. So although the loss of one packet is
fairly inconsequential, probabilistically the loss of one
packet means the loss of several packets, which severely
degrades the quality of service in a VOIP network.
Despite the infeasibility of using a guaranteed delivery
protocol such as TCP, there are some remedies for the
packet loss problem. One cannot guarantee all packets are
delivered, but if bandwidth is available, sending redundant
information can probabilistically annul the chance of loss.
 (IJCNS) International Journal of Computer and Network Security, 43
Such bandwidth is not always accessible and the redundant
information will have to be processed, introducing even
more latency to the system and ironically, possibly
producing even greater packet loss.
2.4 Bandwidth & Effective Bandwidth
As in data networks, bandwidth congestion can cause packet
loss and a host of other QoS problems. Thus, proper
bandwidth reservation and allocation is essential to VOIP
quality. One of the great attractions of VOIP, data and voice
sharing the same wires, is also a potential headache for
implementers who must allocate the necessary bandwidth
for both networks in a system normally designed for one.
Congestion of the network causes packets to be queued,
which in turn contributes to the latency of the VOIP system.
Low bandwidth can also contribute to non-uniform delays
(jitter) [1], since packets will be delivered in spurts when a
window of opportunity opens up in the traffic.
Because of these issues, VOIP network infrastructures must
provide the highest amount of bandwidth possible. On a
LAN, this means having modern switches running at 100M
bit/sec and other architectural upgrades that will alleviate
bottlenecks within the LAN. Percy and Hommer suggest
that if network latencies are kept below 100 milliseconds,
maximum jitter never more than 40 milliseconds, then
packet loss should not occur. With these properties assured,
one can calculate the necessary bandwidth for a VOIP
system on the LAN in a worst case scenario using statistics
associated with the worst-case bandwidth congesting codec.
This is fine when dealing simply with calls across the LAN,
but the use of a WAN complicates matters. Bandwidth usage
varies significantly across a WAN, so a much more complex
methodology is needed to estimate required bandwidth
usage.
Methods for reducing the bandwidth usage of VOIP include
RTP header compression and Voice Activity Detection
(VAD). RTP compression condenses the media stream
traffic so less bandwidth is used. However, an inefficient
compression scheme can cause latency or voice degradation,
causing an overall downturn in QoS. VAD prevents the
transmission of empty voice packets (i.e. when a user is not
speaking, their device does not simply send out white noise).
However, by definition VAD will contribute to jitter in the
system by causing irregular packet generation [4].
2.5 The Need for Speed
The key to conquering QoS issues like latency and
bandwidth congestion is speed. By definition, faster
throughput means reduced latency and probabilistically
reduces the chances of severe bandwidth congestion. Thus
every facet of network traversal must be completed quickly
in VOIP. The latency often associated with tasks in data
networks will not be tolerated. Chief among these latency
producers that must improve performance are firewall/NAT
traversal and traffic encryption/decryption [4]. Traditionally,
these are two of the most effective ways for administrators to
secure their networks. However, they are also two of the
greatest contributors to network congestion and throughput
delay. Inserting traditional firewall and encryption products
Vol. 2, No. 5, May 2010
into a VOIP network is not feasible, particularly when VOIP
is integrated into existing data networks. Instead, these data-
network solutions must be adapted to support security in the
new fast paced world of VOIP.
2.6 Power Failure and Backup Systems
Conventional telephones operate on 48 volts supplied by the
telephone line itself. This is why home telephones continue
to work even during a power failure. Most offices use PBX
systems with their conventional telephones, and PBXs
require backup power systems so that they continue to
operate during a power failure [4]. These backup systems
will continue to be required with VOIP, and in many cases
will need to be expanded. An organization that provides
uninterruptible power systems for its data network and
desktop computers may have much of the power
infrastructure needed to continue communication functions
during power outages, but a careful assessment must be
conducted to ensure that sufficient backup power is available
for the office VOIP switch, as well as each desktop
instrument. Costs may include electrical power to maintain
UPS battery charge, periodic maintenance costs for backup
power generation systems, and cost of UPS battery
replacement. If emergency/backup power is required for
more than a few hours, electrical generators will be
required. Costs for these include fuel, fuel storage facilities,
and cost of fuel disposal at end of storage life.
2.7 QoS Implications for Security
The strict performance requirements of VOIP have
significant implications for security, particularly denial of
service (DoS) issues. VOIP-specific attacks (i.e., floods of
specially crafted SIP messages) may result in DoS for many
VOIP-aware devices. For example, SIP phone endpoints
may freeze and crash when attempting to process a high rate
of packet traffic SIP proxy servers also may experience
failure and intermittent log discrepancies with a VOIP-
specific signaling attack of under 1Mb/sec. In general, the
packet rate of the attack may have more impact than the
bandwidth; i.e., a high packet rate may result in a denial of
service even if the bandwidth consumed is low [4].
3. Standards and Protocols
Over the next few years, the industry will address the
bandwidth limitations by upgrading the Internet backbone to
asynchronous transfer mode (ATM), the switching fabric
designed to handle voice, data, and video traffic. Such
network optimization will go a long way toward eliminating
network congestion and the associated packet loss. The
Internet industry also is tackling the problems of network
reliability and sound quality on the Internet through the
gradual adoption of standards. Standards-setting efforts are
focusing on the three central elements of Internet telephony:
the audio codec format; transport protocols; and directory
services.
In May 1996, the International Telecommunications Union
(ITU) ratified the H.323 specification, which defines how
44
voice, data, and video traffic will be transported over IP–
based local area networks; it also incorporates the T.120
data conferencing standard. The recommendation is based
on the real-time protocol/real-time control protocol
(RTP/RTCP) for managing audio and video signals.
As such, H.323 addresses the core Internet-telephony
applications by defining how delay-sensitive traffic, (i.e.,
voice and video), gets priority transport to ensure real-time
communications service over the Internet [1].
Figure 3: H.323 Architecture [4]
4. Firewalls, NAT AND IDS
Firewalls and NAT present a formidable challenge to VOIP
implementers. However, there are solutions to these
problems, if one is willing to pay the price. It is important to
note that all three major VOIP protocols, SIP, H.323, and
H.248 all have similar problems with firewalls and NATs.
Although the use of NATs may be reduced as IPv6 is
adopted in [4], they will remain a common component in
networks for years to come, and IPv6 will not alleviate the
need for firewalls, so VOIP systems must deal with the
complexities of firewalls and NATs. Some VOIP issues with
firewalls and NATs are unrelated to the call setup protocol
used. Both network devices make it difficult for incoming
calls to be received by a terminal behind the firewall / NAT.
Also, both devices affect QoS and can impose strong inflict
with the RTP stream.
4.1 Firewalls
Firewalls are a staple of security in today’s IP networks.
Whether protecting a LAN, WAN, encapsulating a DMZ, or
just protecting a single computer, a firewall is usually would
be the first line of defense against attackers. Traffic not
meeting the requirements of the firewall is dropped.
Processing of traffic is determined by a set of rules
programmed into the firewall by the network administrator.
These may include such commands as “Block all FTP traffic
(port 21)” or “Allow all HTTP traffic (port 80)”. Much more
complex rule sets are available in almost all firewalls. A
useful property of a firewall, in this context, is that it
provides a central location for deploying security policies. It
is the ultimate bottleneck for network traffic because when
properly designed, no traffic can enter or exit the LAN
(IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 5, May 2010
without passing through the firewall. The introduction of
firewalls to the VOIP network complicates several aspects of
VOIP, most notably dynamic port trafficking and call setup
procedures.
4.2 Stateful Firewalls
Most VOIP traffic travels across UDP ports. Firewalls
typically process such traffic using a technique called packet
filtering. Packet filtering investigates the headers of each
packet attempting to cross the firewall and uses the IP
addresses, port numbers, and protocol type contained therein
to determine the packets’ legitimacy [4]. In VOIP and other
media streaming protocols, this information can also be used
to distinguish between the start of a connection and
established connection.There are two types of packet
filtering firewalls, stateless and stateful. Stateless firewalls
retain no memory of traffic that has occurred earlier in the
session. Stateful firewalls do remember previous traffic and
can also investigate the application data in a packet. Thus,
stateful firewalls can handle application traffic that may not
be destined for a static port.
4.1.1 VOIP specific Firewall Needs
In addition to the standard firewall practices, firewalls are
often deployed in VOIP networks with the added
responsibility of brokering the data flow between the voice
and data segments of the network. This is a crucial
functionality for a network containing PC-Based IP phones
that are on the data network, but need to send voice
messages. All voice traffic emanating from or traveling to
such devices would have to be explicitly allowed in if no
firewall was present because RTP (Real Time Protocol)
makes use of dynamic UDP ports (of which there are
thousands). Leaving this many UDP ports open is an
egregious breach of security. Thus, it is recommended that
all PC-based phones be placed behind a stateful firewall to
broker VOIP media traffic. Without such a mechanism, a
UDP DoS attack could compromise the network by
exploiting the excessive amount of open ports [10].
Firewalls could also be used to broker traffic between
physically segmented traffic (one network for VOIP, one
network for data) but such an implementation is fiscally and
physically unacceptable for most organizations, since one of
the benefits of VOIP is voice and data sharing the same
physical network.
4.2 Network Address Translation (NAT)
NAT is commonly performed by firewalls to conserve IP
addresses and hide internal IP addresses/ports from direct,
external access. This causes issues for VoIP. When VoIP
endpoints negotiate ports for media exchange, they
communicate these ports to one another in packet payloads.
So a conventional NAT remains unaware of ports selected,
cannot translate them meaningfully and blocks them at the
firewall. A Real Time Mixed Media (RTMM) firewall uses
the Back-to-Back User Agent (B2BUA) to work with the
NAT to rewrite the addresses in the signaling stream,
providing NAT pathways for the media streams. To do this,
 (IJCNS) International Journal of Computer and Network Security, 45
the RTMM must be able to perform NAT at media speeds,
to prevent latency/jitter or loss of packets [11].
All of the benefits of NAT come at a price. NATs “violate
the fundamental semantic of the IP address, that it is a
globally reachable point for communications”. This design
has significant implications for VOIP. For one thing, an
attempt to make a call into the network becomes very
complex when a NAT is introduced. The situation is
analogous to a phone network where several phones have
the same phone number, such as in a house with multiple
phones on one line (see Figure 4). There are also several
issues associated with the transmission of the media itself
across the NAT, including an incompatibility with IPSec
[4].
Figure 4. IP Telephones behind NAT and Firewall [4]
Problem:
• Simple NAT devices, which are not VoIP aware, perform
NAT on the IP headers only.
• VoIP packets contain private IP address in the payload.
• Therefore, VoIP sessions cannot be established.
Solution:
• Translates both the IP header and the packet’s payload
with a routable IP address (Far End NAT)
• Media relay until full session establishment.
Session Border Controller (SBC)
• SBC’s started as a solution to connectivity problems
caused by NAT done by non-VoIP aware devices.
• SBC’s are usually used by carriers and located at the
border of their core networks [7].
Figure 5. Far End NAT [7]
4.3 Intrusion Detection System (IDS)
Vol. 2, No. 5, May 2010
Intrusion detection is a second line of defense behind other
security mechanisms (Firewalls, Encryption). Supplying the
detector engine with application specific knowledge makes
it more effective and powerful.
An Intrusion Detection System (IDS) helps administrators to
monitor and defend against security breaches. Intrusion
detection techniques are generally divided into two
paradigms, anomaly detection and misuse detection. In
anomaly detection techniques, the deviation from normal
system behaviors is detected, whereas misuse detection is
based on the matching of attack signatures. Unlike
signature-based intrusion detection, anomaly detection has
the advantage of detecting previously-unknown attacks but
at the cost of relatively high false alarm rate.
Sekar etal introduced a third category of specification-based
intrusion detection. Specification-based approach takes the
manual development of a specification that captures
legitimate system behavior and detects any deviation
thereof. This approach can detect unseen attacks with low
false alarm rate. However, these previous approaches fall
short of defending VoIP applications, because of the cross-
protocol interaction and distributed nature of VoIP.
Figure 6. IDS Engine sits on or close to the end-point [12]
VoIP systems use multiple protocols for call control and
data delivery. For example, in SIP-based IP telephony,
Session Initiation Protocol (SIP) is used to control call setup
and teardown, while Real-time Transport Protocol (RTP) is
for media delivery. A VoIP system is distributed in nature,
consisting of IP phones, SIP proxies, and many other
servers. Defending against malicious attacks on such a
heterogeneous and distributed environment is far from
trivial [2].
4.3.1 Cross-protocol Methodology for Detection
Is the IDS which use cross-protocol detection accesses
packets from multiple protocols in a system to perform its
detection. This methodology is suitable to systems that use
multiple protocols and where attacks spanning these
multiple protocols are possible. There is the important
design consideration that such access to information across
protocols must be made efficiently. A VoIP system
incorporates multiple protocols. A typical example is the use
of SIP to establish a connection, followed by use of RTP to
transfer voice data. Also, RTCP and ICMP are used to
monitor the health of the connection. VoIP systems typically
have application level software for billing purposes and
therefore may have accounting software and a database.
Using the cross-protocol methodology for detection, one can
create a cross-protocol rule to look at the SIP messages, the
46
transaction messages between the accounting software and
the database, and the RTP flows later on. Specifically, each
of the following three conditions must hold [12].
1. The SIP message should follow the correct format.
2. When the accounting software sends out a transaction
to denote a call from user A to user B, check if user A has
sent a SIP Call Initialization message to user B. If user A
has not set up the call with a legitimate SIP Call
Initialization message, then this condition will be violated.
3. Check the source/destination IP addresses of the
subsequent RTP flows. Together with information from
DNS and SIP Location Servers, we can reconfirm that each
RTP flow has a corresponding legitimate call setup.
4.3.2 Stateful Methodology for Detection
A second abstraction useful for VoIP systems in particular is
stateful detection. Stateful detection implies building up
relevant state within a session and across sessions and using
the state in matching for possible attacks. It is important
that the state aggregation be done efficiently so that the
technique is applicable in high throughput systems, such as
VoIP systems.
A VoIP system maintains considerable amount of system
state. The client side maintains state about all the active
connections – when the connection was initiated, when it
can be torn down, and what the properties of the connection
are. The server side also maintains state relevant to billing,
such as the duration of the call.
5. Encryption and IPsec
The only focus on security of the network, protecting
endpoints, other components, from malicious attacks is not
enough for VoIP systems. Firewalls, IDS, NAT, and other
such devices can help keep intruders from compromising a
network, but firewalls are no defense against an internal
hacker in [4]. Another layer of defense is necessary at the
protocol level to protect the data itself. In VOIP, as in data
networks, this can be accomplished by encrypting the
packets at the IP level using IPsec. This way if anyone on
the network, authorized or not, intercepts VOIP traffic not
intended for them, these packets will be impossible to
understand. The IPsec suite of security protocols and
encryption algorithms is the standard method for securing
packets against unauthorized viewers over data networks
and will be supported by the protocol stack in IPv6. Hence,
it is both logical and practical to extend IPsec to VOIP,
encrypting the signal and voice packets on one end and
decrypting them only when needed by their intended
recipient.
Also, several factors, including the expansion of packet size,
ciphering latency, and a lack of QoS urgency in the
cryptographic engine itself can cause an excessive amount of
latency in the VOIP packet delivery. This leads to degraded
voice quality, so once again there is a tradeoff between
security and voice quality, and a need for speed. Fortunately,
the difficulties are not insurmountable. IPsec can be
incorporated into a SIP network with roughly a three-second
additional delay in call setup times, an acceptable delay for
many applications. This section explains the issues involved
(IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 5, May 2010
in successfully incorporating IPsec encryption into VOIP
services.
5.1 IPSec
IPsec is the preferred form of VPN tunneling across the
Internet. There are two basic protocols defined in IPsec:
Encapsulating Security Payload (ESP) and Authentication
Header (AH) (see Figure 7). Both schemes provide
connectionless integrity, source authentication, and an anti-
replay service. The tradeoff between ESP and AH is the
increased latency in the encryption and decryption of data in
ESP and a “narrower” authentication in ESP, which
normally does not protect the IP header “outside” the ESP
header, although Internet Key Exchange (IKE: Responsible
for key agreement using public key cryptography) can be
used to negotiate the security association (SA), which
includes the secret symmetric keys. In this case, the
addresses in the header (transport mode) or new/outer
header (tunnel mode) are indirectly protected, since only the
entity that negotiated the SA can encrypt/decrypt or
authenticate the packets. Both schemes insert an IPsec
header (and optionally other data) into the packet for
purposes, such as authentication [4].
IPsec also supports two modes of delivery: Transport and
Tunnel. Transport mode encrypts the payload (data) and
upper layer headers in the IP packet. The IP header and the
new IPsec header are left in plain sight. So if an attacker
were to intercept an IPsec packet in transport mode, they
could not determine what it contained; but they could tell
where it was headed, allowing rudimentary traffic analysis.
On a network entirely devoted to VOIP, this would equate to
logging which parties were calling each other, when, and
for how long. Tunnel mode encrypts the entire IP datagram
and places it in a new IP Packet [9]. Both the payload and
the IP header are encrypted. The IPsec header and the new
IP Header for this encapsulating packet are the only
information left in the clear.
Figure 7. IPsec Tunnel and Transport Modes [9]
IPSec supports the Triple DES encryption algorithm (168-
bit) in addition to 56-bit encryption. Triple DES (3DES) is a
strong form of encryption that allows sensitive information
to be transmitted over untrusted networks. It enables
 (IJCNS) International Journal of Computer and Network Security, 47
customers, particularly in the finance industry, to utilize
network layer encryption.
Table 1: Encryption Algorithms for VoIP [9]
Encryption Algorithms for IPSec
Type Key Strengt
h computations [4].
DES Symmetric 56-bit Weak
3DES Symmetric 168-bit Mediu
m
AES Symmetric 128, 192, or 256- Strong
bit
RSA Asymmetric 1024-bit minimum Strong
5.2 The Role of IPSec in VOIP
The prevalence and ease of packet sniffing and other
techniques for capturing packets on an IP based network
makes encryption a necessity for VOIP. Security in VOIP is
concerned both with protecting what a person says as well as
to whom the person is speaking. IPSec can be used to
achieve both of these goals as long as it is applied with ESP
using the tunnel method. This secures the identities of both
the endpoints and protects the voice data from prohibited
users once packets leave the corporate intranet. The
incorporation of IPSec into Ipv6 will increase the
availability of encryption, although there are other ways to
secure this data at the application level. VOIPsec (VOIP
using IPSec) helps reduce the threat of man in the middle
attacks, packet sniffers, and many types of voice traffic
analysis. Combined with the firewall implementations, Ipsec
makes VOIP more secure than a standard phone line. It is
important to note, however, that Ipsec is not always a good
fit for some applications, so some protocols will continue to
rely on their own security features.
5.3 Local VPN Tunnels
Virtual Private Networks (VPNs) are “tunnels” between two
endpoints that allow for data to be securely transmitted
between the nodes. The IPSec ESP tunnel is a specific kind
of VPN used to traverse a public domain (the Internet) in a
private manner. The use and benefits of VPNs in IPSec have
been great enough for some to claim “VOIP is the killer app
for VPNs”. VPN tunnels within a corporate LAN or WAN
are much more secure and generally faster than the IPSec
VPNs across the Internet because data never traverses the
public domain, but they are not scaleable [4]. Also, no
matter how the VPN is set up, the same types of attacks and
issues associated with IPSec VPNs are applicable, so we
consider here only the case of IPSec tunneling and assume
the security solutions can be scaled down to an internal
network if needed.
5.4 Memory and CPU Considerations
Packets that are processed by IPSec are slower than packets
that are processed through classic crypto. There are several
reasons for this and they might cause significant
performance problems:
1. IPSec introduces packet expansion, which is more likely
Vol. 2, No. 5, May 2010
to require fragmentation and the corresponding reassembly
of IPSec datagrams.
2. Encrypted packets are probably authenticated, which
means that there are two cryptographic operations that are
performed for every packet.
3. The authentication algorithms are slow, although work
has been done to speed up things as the Diffie−Hellman
5.5 Difficulties Arising from VOIPsec
IPSec has been included in IPv6. It is a reliable, robust, and
widely implemented method of protecting data and
authenticating the sender. However, there are several issues
associated with VOIP that are not applicable to normal data
traffic. Of particular interest are the Quality of Service
(QoS) issues and some others like latency, jitter, and packet
loss. These issues are introduced into the VOIP environment
because it is a real time media transfer, with only 150 ms to
deliver each packet. In standard data transfer over TCP, if a
packet is lost, it can be resent by request. In VOIP, there is
no time to do this. Packets must arrive at their destination
and they must arrive fast. Of course the packets must also be
secure during their travels. However, the price of this
security is a decisive drop in QoS caused by a number of
factors.
A study by researchers focused on the effect of VOIPsec on
various QoS issues and on the use of header compression as
a solution to these problems. They studied several codecs,
encryption algorithms, and traffic patterns to garner a broad
description of these effects. Some empirical results
developed by Cisco are available as well in [4].
Delay
• Processing—PCM to G.729 to packet
• Encryption — ESP encapsulation + 3DES
• Serialization — time it takes to get a packet out of the
router, each “hop” generally has fixed delay.
• IPsec overhead: about 40 bytes (depending configuration)
• IP header: 20 bytes
• UDP + RTP headers: 20 bytes
• RTP header compression: 3 bytes for IP+UDP+RTP
Effects on 8 kbps CODEC (voice data: 20 bytes)
• clear text voice has an overhead of 3 bytes, which
suggests required bandwidth of approximately 9 kbps
• IPsec encrypted voice: overhead 80 bytes and required
bandwidth 40 kbps
5.6 Encryption / Decryption Latency
The cryptographic engine is bottleneck for voice traffic
transmitted over IPsec. The driving factor in the degraded
performance produced by the cryptography was the
scheduling algorithms in the crypto-engine itself However,
there still was significant latency due to the actual
encryption and decryption.
Encryption/decryption latency is a problem for any
cryptographic protocol, because much of it results from the
computation time required by the underlying encryption.
48
With VOIP’s use of small packets at a fast rate and
intolerance for packet loss, maximizing throughput is
critical. However, this comes with a price, because although
DES is the fastest of these encryption algorithms, it is also
the easiest to crack [4]. Thus, designers are once again
forced to toe the line between security and voice quality.
5.7 Expanded Packet Size
IPsec also increases the size of packets in VOIP, which leads
to more QoS issues. The increase is actually just an increase
in the header size due to the encryption and encapsulation of
the old IP header and the introduction of the new IP header
and encryption information. This leads to several
complications when IPsec is applied to VOIP. First, the
effective bandwidth is decreased as much as 63% [4]. Thus
connections to single users in low bandwidth areas (i.e. via
modem) may become infeasible. The size discrepancy can
also cause latency and jitter issues as packets are delayed by
decreased network throughput or bottlenecked at hub nodes
on the network (such as routers or firewalls).
5.8 IPsec and NAT Incompatibility
IPsec and NAT compatibility is far from ideal. NAT
traversal completely invalidates the purpose of AH because
the source address of the machine behind the NAT is
masked from the outside world. Thus, there is no way to
authenticate the true sender of the data. The same reasoning
demonstrates the inoperability of source authentication in
ESP. We have defined this as an essential feature of
VOIPsec, so this is a serious problem. There are several
other issues that arise when ESP traffic attempts to cross a
NAT. If only one of the endpoints is behind a NAT, the
situation is easier. If both are behind NATs, IKE negotiation
can be used for NAT traversal, with UDP encapsulation of
the IPsec packets.
6. Solutions to the VOIPsec Issues
We have raised a number of significant concerns with
IPsec’s role in VOIP. However, many of these technical
problems are solvable. Despite the difficulty associated with
these solutions it is very important for the establishment of a
secure implementation of VOIPsec.
6.1 Encryption at the End Points
One proposed solution to the bottlenecking at the routers
due to the encryption issues is to handle
encryption/decryption solely at the endpoints in the VOIP
network. One consideration with this method is that the
endpoints must be computationally powerful enough to
handle the encryption mechanism. Though ideally
encryption should be maintained at every hop in a VOIP
packet’s lifetime, this may not be feasible with simple IP
phones with little in the way of software or computational
power. In such cases, it may be preferable for the data be
encrypted between the endpoint and the router (or vice
versa) but unencrypted traffic on the LAN is slightly less
damaging than unencrypted traffic across the Internet [4].
(IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 5, May 2010
Fortunately, the increased processing power of newer
phones is making endpoint encryption less of an issue.
6.2 Secure Real Time Protocol (SRTP)
The Secure Real-time Protocol is a profile of the Real-time
Transport Protocol (RTP) offering not only confidentiality,
but also message authentication, and replay protection for
the RTP traffic as well as RTCP (Real-time Transport
Control Protocol).
SRTP provides a framework for encryption and message
authentication of RTP and RTCP streams. SRTP can
achieve high throughput and low packet expansion.
SRTP is independent of a specific RTP stack
implementation and of a specific key management standard,
but Multimedia Internet Keying (MIKEY) has been
designed to work with SRTP.
In comparison to the security options for RTP there are
some advantages to using SRTP. The advantages over the
RTP standard security and also over the H.235 security for
media stream data are listed below [4, 12].
SRTP provides increased security, achieved by
• Confidentiality for RTP as well as for RTCP by
encryption of the respective payloads;
• Integrity for the entire RTP and RTCP packets, together
with replay protection;
• The possibility to refresh the session keys periodically,
which limits the amount of cipher text produced by a fixed
key, available for an adversary to cryptanalyze;
• An extensible framework that permits upgrading with
new cryptographic algorithms;
• A secure session key derivation with a pseudo-random
function at both ends;
• The usage of salting keys to protect against pre-
computation attacks;
• Security for unicast and multicast RTP applications.
SRTP has improved performance attained by
• Low computational cost asserted by pre-defined
algorithms;
• Low bandwidth cost and a high throughput by limited
packet expansion and by a framework preserving RTP
header compression efficiency;
• Small footprint that is a small code size and data memory
for keying information and replay lists.
6.3 Key Management for SRTP – MIKEY
SRTP uses a set of negotiated parameters from which
session keys for encryption, authentication and integrity
protection are derived. MIKEY describes a key management
scheme that addresses real-time multimedia scenarios (e.g.
SIP calls and RTSP sessions, streaming, unicast, groups,
multicast). The focus lies on the setup of a security
association for secure multimedia sessions including key
management and update, security policy data, etc., such that
requirements in a heterogeneous environment are fulfilled.
MIKEY also supports the negotiation of single and multiple
crypto sessions.
 (IJCNS) International Journal of Computer and Network Security, 49
MIKEY has some important properties in [4]:
• MIKEY can be implemented as an independent software
library to be easily integrated in a multimedia
communication protocol. It offers independency of a specific
communication protocol (SIP, H.323, etc.)
• Establishment of key material within a 2-way handshake,
therefore best suited for real-time multimedia scenarios
There are four options for Key Distribution:
• Pre-shared key
• Public-key encryption
• Diffie-Hellman key exchange protected by public-key
encryption
• Diffie-Hellman key exchange protected with pre-shared-
key and keyed hash functions (using an MIKEY extension
(DHHMAC))
6.4 Better Scheduling Schemes
Without a way for the crypto-engine to prioritize packets,
the engine will still be susceptible to DoS attacks and
starvation from data traffic impeding the time-urgent VOIP
traffic. A few large packets can clog the queue long enough
to make the VOIP packets over 150 ms late (sometimes
called head-of-line blocking), effectively destroying the call.
Ideally, the crypto-engine would implement QoS scheduling
to favor the voice packets, but this is not a realistic scenario
due to speed and compactness constraints on the crypto-
engine. One solution implemented in the latest routers is to
schedule the packets with QoS in mind prior to the
encryption phase.
It is not surprising that for voice traffic the crypto-engine
can be a serious bottleneck. Rather than the expected
constraints on the crypto-engine throughput, the critical
factor turned out to be the impossibility to control and
schedule access to the crypto-engine so as to favor real-time
traffic over regular one. This applies regardless of whether
the scheduler is implemented as a software module or a
hardware component. Therefore, if voice traffic is
interleaved with other types of traffic, e.g., ftp or http traffic,
during a secure session, it may happen that the latter
(usually characterized by big packets) is scheduled in the
crypto-engine before voice traffic. In this case voice traffic
might be delayed to the point that packets are discarded
most of the times.
6.5 Compression of Packet Size
Compression of Packet Size turn results in considerably less
jitter, latency, and better crypto-engine performance. There
is, of course, a price for these speedups. The compression
scheme puts more strain on the CPU and memory
capabilities of the endpoints in order to achieve the
compression, and, of course, both ends of a connection must
use the same compression algorithm.
Efficient solution for packet header compression is known
as cIPsec, for VoIPsec traffic. Simulation results from
different sources show that the proposed compression
scheme significantly reduces the overhead of packet headers,
Vol. 2, No. 5, May 2010
thus increasing the effective bandwidth used by the
transmission. In particular, when cIPsec is adopted, the
average packet size is only 2% bigger, rather than 50%
longer plain VoIPsec packets, which makes VoIPsec and
VoIP equivalent from the bandwidth usage point of view.
However, packet loss does have an exacerbated detrimental
effect on packets compressed under the cIPsec scheme.
When packets are lost, they cannot be re-sent and the
endpoints need to resynchronize. However, the time saved in
the crypto-engine and the security provided may be well
worth this price of this approach [5].
6.6 Resolving NAT/IPSec Incompatibilities
The most likely widespread solution to the problem of NAT
traversal is UDP encapsulation of IPSec. This
implementation is supported by the IETF and effectively
allows all ESP traffic to traverse the NAT. In tunnel mode,
this model wraps the encrypted IPSec packet in a UDP
packet with a new IP header and a new UDP header, usually
using port 500. This port was chosen because it is currently
used by IKE peers to communicate so overloading the port
does not require any new holes to be punched in the
firewall. The SPI field within the UDP-encapsulated packet
is set to zero to differentiate it from an actual IKE
communication. This solution allows IPsec packets to
traverse standard NATs in both directions. The adoption of
this standard method should allow VOIPsec traffic to
traverse NATs cleanly, although some extra overhead is
added in the encapsulation/decapsulation process. IKE
negotiation will also be required to allow for NAT traversal.
The problem still remains that IP-based authentication of
the packets cannot be assured across the NAT, (although
fully qualified domain names could be used) but the use of a
shared secret (symmetric key) negotiated through IKE could
provide authentication. It is important to note that IP-based
authentication is weak compared with methods using
cryptographic protocols.
There are several other solutions to the IPsec/NAT
incompatibility problem, including Realm-Specific IP
RSIP), IPv6 Tunnel Broker, IP Next Layer (IPNL), and UDP
encapsulation. RSIP is designed as a replacement for NAT
and provides a clear tunnel between hosts and the RSIP
Gateway. RSIP supports both AH and ESP, but
implementing RSIP would require a significant overhaul of
the current LAN architecture so while it is quite an elegant
solution, it is currently infeasible. Perhaps as a result of
these problems, RSIP is not widely used. The IPv6 tunnel
broker method uses an IPv6 tunnel as an IPSec tunnel, and
encapsulates an IPv6 packet in an IPv4 packet. But this
solution also requires LAN upgrades and doesn’t work in
situations where multiple NATs are used. IPNL introduces a
new layer into the network protocols between IP and
TCP/UDP to solve the problem, but IPNL is in competition
with IPv6 and IPv6 is a much more widely used standard
[4].
50 (IJCNS) International Journal of Computer and Network Security,
7. Security Threats in VoIP
In the early days of VoIP, there was no big concern about
security issues related to its use. People were mostly
concerned with its cost, functionality and reliability. Now
that VoIP is gaining wide acceptance and becoming one of
the mainstream communication technologies, security has
become a major issue.
The security threats cause even more concern when we think
that VoIP is in fact replacing the oldest and most secure
communication system the world ever known – POTS (Plain
Old Telephone System). Let us have a look at the threats
VoIP users face.
7.1 Identity and Service Theft
Service theft can be exemplified by phreaking, which is a
type of hacking that steals service from a service provider,
or use service while passing the cost to another person.
Encryption is not very common in SIP, which controls
authentication over VoIP calls, so user credentials are
vulnerable to theft.
Eavesdropping is how most hackers steal credentials and
other information. Through eavesdropping, a third party can
obtain names, password and phone numbers, allowing them
to gain control over voicemail, calling plan, call forwarding
and billing information. This subsequently leads to service
theft.
Stealing credentials to make calls without paying is not the
only reason behind identity theft. Many people do it to get
important information like business data.
A phreaker can change calling plans and packages and add
more credit or make calls using the victim’s account. He can
of course as well access confidential elements like voice
mail, do personal things like change a call forwarding
number [10].
7.2 Vishing
Vishing is another word for VoIP Phishing, which involves
a party calling you faking a trustworthy organization (e.g.
your bank) and requesting confidential and often critical
information.
7.3 Viruses and Malware
VoIP utilization involving soft-phones and software are
vulnerable to worms, viruses and malware, just like any
Internet application. Since these soft-phone applications run
on user systems like PCs and PDAs, they are exposed and
vulnerable to malicious code attacks in voice applications.
7.4 DoS (Denial of Service)
A DoS attack is an attack on a network or device denying it
of a service or connectivity. It can be done by consuming its
bandwidth or overloading the network or the device’s
internal resources.
In VoIP, DoS attacks can be carried out by flooding a target
with unnecessary SIP call-signaling messages, thereby
Vol. 2, No. 5, May 2010
degrading the service. This causes calls to drop prematurely
and halts call processing.
Why would someone launch a DoS attack? Once the target
is denied of the service and ceases operating, the attacker
can get remote control of the administrative facilities of the
system [10, 12].
7.5 Spamming over Internet Telephony (SPIT)
If you use email regularly, then you must know what
spamming is. Put simply, spamming is actually sending
emails to people against their will. These emails consist
mainly of online sales calls. Spamming in VoIP is not very
common yet, but is starting to be, especially with the
emergence of VoIP as an industrial tool.
Every VoIP account has an associated IP address. It is easy
for spammers to send their messages (voicemails) to
thousands of IP addresses. Voice mailing as a result will
suffer. With spamming, voicemails will be clogged and
more space as well as better voicemail management tools
will be required. Moreover, spam messages can carry viruses
and spyware along with them. [10]
7.6 Call Tampering
Call tampering is an attack which involves tampering a
phone call in progress. For example, the attacker can simply
spoil the quality of the call by injecting noise packets in the
communication stream. He can also withhold the delivery of
packets so that the communication becomes spotty and the
participants encounter long periods of silence during the
call.
7.7 Man-in-the-Middle Attacks
VoIP is particularly vulnerable to man-in-the-middle
attacks, in which the attacker intercepts call-signaling SIP
message traffic and masquerades as the calling party to the
called party, or vice versa. Once the attacker has gained this
position, he can hijack calls via a redirection server [10].
8. Conclusion
This paper provides an overview of the VoIP and of the
issues related to VoIP security. There are numerous
challenges to the secure implementation, deployment and
use of the VoIP on a same network which is used to carry
other network data. These challenges are related to the
service availability, Quality of Service, Firewalls, Intrusion
Detection, IPSec, VoIP threats, and privacy. The next step
for the ongoing research project is to identify specific areas
that will be addressed in the near term research efforts.
References
[1] Rinzam A. VoIP: Voice Over Internet Protocol.
Department of Computer Science and Engineering, M
G College of Engineering.
[2] H. Sengar, D. Wijesekera. Center for Secure Information
Systems, George Mason University, Fairfax, USA. H.
Wang, S. Jajodia. Department of CS, College of
William and Mary, Williamsburg, USA. “IDS: VoIP
 (IJCNS) International Journal of Computer and Network Security, 51
Vol. 2, No. 5, May 2010

Intrusion Detection through Interacting Protocol State Authors Profile

Machines”.
[3] M. Marjalaakso. Security Requirements and Constraints Ali Tahir is an MS Scholar at University of
of VoIP. Helsinki University of Technology, Engineering and Technology, Taxila, Pakistan.
Department of Electrical Engineering and He did his B.Sc Software Engineering from
Telecommunications. UET TAXILA in 2005. He has worked in
[4] D. Richard Kuhn, Thomas J. Walsh, and Steffen Fries, Nokia Siemens Network for two years as an
implementation engineer. Currently he is
“Security Considerations for Voice Over IP Systems:
working in cryptography and network security
Recommendations of the National Institute of Standards center at a Government organization. His areas
and Technology” Special Publication 800-58, Sections 8 of interest are digital image processing, computer vision, network
and 9, January 2005. security and wireless communication.
[5] R. Barbieri, D. Bruschi, E. Rosti. Voice over IPsec:
Analysis and Solutions. Department of Science,
University of Milano, Itlay. Asim Shahzad is pursuing his PhD from
[6] G. Egeland, “Introduction to IPsec in IPv6”. University of Engineering and Technology
http://www.eurescom.de/~publicwebdeliverables/P1100 Taxila, Pakistan. He has also completed his
series/P1113/D1/pdfs/pir1/41_IPsec_intro.pdf MS in Computer Engineering from UET
[7] Check Point Software Technologies Ltd. “Check Point TAXILA. He has done MS in
Solution for Secure VoIP”. 2003 - 2007. Telecommunication Engineering from
[8] NAT: Network Address Translation and Voice Over institute of communication technologies,
Islamabad, Pakistan. He is working as
Internet Protocol. http://www.voip-
Assistant Professor at UET TAXILA in Telecommunication
info.org/wiki/view/NAT+and+VOIP Engineering Department. His areas of interest are optical
[9] Jeremy Stretch. IPSEC: Internet Protocol Security. communication, Data and network Security.
http://www. packetlife.net
[10] M. Hurley. “VoIP VULNERABILITIES”. Centre for
Critical Infrastructure Protection (CCIP). Information
Note, Issue 06, Wellington, New Zealand, January
2007.
[11] Mark D. Collier. Firewall Requirements for Securing
VoIP, SecureLogix Corporation.www.securelogix.com
[12] Yu-Sung Wu, S. Bagchi. School of Electrical &
Computer Eng, Purdue University, S. Garg, N. Singh,
Tim Tsai, Avaya Labs. “A Stateful and Cross Protocol
Intrusion Detection Architecture for VoIP
Environments”.