Security issiues in VOIP Applications

INTRODUCTION

The evolution in the networks & internet has increased different types of applications. One such application is VOIP which has become an alternative to traditional telephone network (public switched telephone network, or PSTN) offering versatile, flexible & economical speech communication. The PSTN of course, is not invulnerable to security breaches. Some of the earliest hackers were "phone phreakers", who specialized in making unauthorized long distance calls.

Today, the threat caused by hackers to IP networks goes far beyond the cost of unauthorized long-distance calls. An attack could take down the network (and thus the company's phone service) for hours or days, and the content of calls intercepted, divulging trade secrets,

confidential client information and more. That makes security a very important issue .Here we are going to discuss the the attacks and the relevant counter measure to provide appropriate lev els of security for VOIP networks.

VOIP (Voice Over Internet Protocol)

The first experiment on telephony networks were conducted by the researchers at MIT in 1970s & the internet protocol specification RFC741 for Network Voice Protocol was published in the year 1977.VOIP uses packet switching which sends digitized data packets over the internet using many possible paths. These packets are reassembled at the destination to generate voice signals.

Before any voice can be sent, a call must be placed. In an ordinary phone system, this process involves dialing the digits of the called number, which are then processed by the telephone companys system to ring the called number. With VOIP, the user must enter the dialed number, which can take the form of a number dialed on a telephone keypad or the selection of a Universal Resource Indicator (URI).The telephone number or URI must be linked with an IP address to reach the called party.

A number of protocols are involved in determining the IP address that corresponds to the called partys telephone number. This process is shown in fig.1. VOIP is increasingly popular because it is cheaper than traditional phone service and in some cases free. Organizations can run their own VOIP service using products from vendors such as Cisco. For consumers, companies including Packet8 and Vonage offer an actual phone that plugs into a broadband connection, while others including Skype offer software that runs on a PC. Most popular instant messaging applications also have VOIP capabilities.

What are the threats?

Some of the security issues that affect VOIP are the same ones that affect any IP network, and some are unique to voice communications. The threats include:

A virus or worm can be introduced to the network and crash the VoIP servers/gateways A denial of service attack can overwhelm the network and bring it down A hacker can access the call server to listen in to, record, or disrupt calls A hacker can give himself/herself or others access to services that are supposed to be restricted Hackers can access the trunk gateway to the PSTN and make unauthorized toll calls A hacker who accesses the call server can register "rogue" IP phones, which can then use the company's VoIP services

A different but related problem with VoIP is the possibility of receiving SPIT (Spam over IP Telephony). Another is the phenomenon is VoIP Phishing.

Security Issues of Voip Applications

With the introduction of VOIP, the need for security is compounded because now we must protect two invaluable assets, our data and our voice. For example, when ordering merchandise over the phone, most people will read their credit card number to the person on the other end. The numbers are transmitted without encryption to the seller. In contrast, the risk of sending unencrypted data across th e Internet is more significant. Packets sent from a users home computer to an online retailer may pass through 15-20 systems that are not under the control of the users ISP or the retailer.

Because digits are transmitted using a standard for transmitting digits out of band as special messages, anyone with access to these systems could install software that scans packets for credit card information. For this reason, online retailers use encryption software to protect a users information and credit card number. Hence, we are to transmit voice over the Internet Protocol, and specifically across the Internet, similar security measures must be applied. The current Internet architecture does not provide the same physical wire security as the phone lines. The key to securing VOIP is to use the security mechanisms like those deployed in data networks (firewalls, encryption, etc.).

The vulnerabilities in VOIP encompass not only the flaws inherent within the VOIP applic ation itself, but also in the underlying operating systems, applications, and protocols that VOIP depends on. The complexity of VOIP creates a high number of vulnerabilities that affect the three classic areas of information security: confidentiality, integrity, and availability.

A virus is a piece of malicious code loaded onto the computer systems without your knowledge and runs against your wishes. As VoIP applications move beyond simply handling voice calls to running different applications, the virus risk is likely to increase because all VoIP applications have their own IP address like the computer systems on IP networks. Thus, a virus attack could bevery effective against the VoIP applications. One of the common examples is that virus injects small replication code through stack overflow to damage the VoIP applications or even bring down the IP networks. To tackle this scenario, VoIP applications should provide a security mechanism to verify re ceived data packet size to avoid exceed bounds of available memory on stack. In summary, virus attacks could generate security threats to integrity and availability.

Denial of Service (DoS) attacks always refer to the prevention of access to a network service by bombarding servers, proxy servers or voice-gateway servers with malicious packets. An incident in which a user is deprived of the services or resource they would normally expect to have. Intruders can launch the full spectrum of DoS attacks (e.g., unauthenticated call control packets) against VoIP applications underlying networks and protocols like traditional PBX. For example, voicemail and short messaging services in IP telephony systems can become the targets of message flooding attacks. The result may prevent legitimate attempts to leave a subscriber a message.

Man in the Middle attacks always refer to an intruder who is able to read, and modify at will, messages between two parties without either party knowing that the link between them has been compromised. The most common man in the middle attack usually involves Address Resolution Protocol (ARP), which can cause an VoIP application to redirect its traffic to the attack computer system. Then the attack computer system can gain complete control over that VoIP applications sessions, which can be altered, dropped, or recorded. For example, an attacker can inject speech, noise or delay (e.g., silent gaps) into a conversation .In general, there are three types of vulnerabilities:(1) Eavesdropping: Unauthorized interception of voice data packets or

Real-Time Transport Protocol (RTP) media stream and decoding of signaling messages; (2) Packet Spoofing: Intercept a call by impersonating voice packets or transmitting information; and (3) Replay: Retransmit genuine sessions so that the VoIP applications will reprocess the information.

To tackle all these types of vulnerabilities, VoIP applications can adopt the Public Key Infrastructure (PKI) a security mechanism to ensure confidentiality of all transmitted data, and to verify and authenticate the validity of each party in the context of public and private key. Without proper encryption, anyone can sniff any voice data packets transmitted over IP networks that make security threats to confidentiality and integrity. In summary, Man in the Middle attacks create security threats to confidentiality and integrity because this type of attack may release the voice data packets to authorized parties or modify the content of conversations.

Security in IPsec

IP network is prone to maximum number of security breaches. Hence a lot of network protocols are developed to protect IP networks. Voice Over IP is vulnerable towards the same attack as the normal data traffic. Here the attacker can directly enter the network to disrupt the s ervice or he could generate excess traffic to disrupt the service.

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). Both schemes provide connectionless integrity, source authentication, and an anti-replay service.

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. Both th e 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. Usually each tunnel is between two network elements such as a router or a gateway..

The IP addresses of these nodes are used as the unencrypted IP address at each hop. Hence, at no point is a plain IP header sent out containing both the source and destination IP. Thus if an attacker were to intercept such packets, they would be unable to discern the packet contents or the origin and destination. Note that some traffic analysis is possible even in tunnel mode, because gateway addresses are readable. If a gateway is used exclusively by a particular organization, an attacker can determine the identity of one or both communicating organizations from the gateway addresses. IPsec allows nodes in the network to negotiate not only a security policy, which defines the security protocol and transport mode as described previ ously, but also a security association defining the encryption algorithm.

Security mechanisms for VOIP

The prominent security mechanisms used along with voice traffic include virtual private networks (VPN), end-to-end encryption and address translation.

Virtual private networks are one of the basic forms of security mechanisms. Here, the communicating parties establish a sort of association with each other using tunnels & the end points are connected through layer 2 techniques like Frame-Relay, ATM or MPLS.

With the end-to-end encryption, communicating entities initially exchange a secret key pair which they will be using to encrypt the data. This key exchange could be carried out in multiple ways including manually sending the key or through a complex key exchange protocol. After the key exchange process, all the data between the communicating nodes will b e encrypted. Even if an attacker gets access to the datagrams, he/she will not be able decode the data immediately. As the encryption algorithm becomes complex, it becomes harder for the attacker to decode the data within the encrypted datagram.

The most likely widespread solution to the network address translation 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.

Problems arising from VOIPsec

There are certain issues associated with VOIP that are not applicable to normal data traffic. Chief among them are latency, jitter, and packet loss. These issues are introduced into the VOIP environment because it is a real time media transfer. In standard data transfer o ver 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.

Solutions to VOIPsec issues

Latency: When an end to end encryption is performed in VOIP it (cryptographic engine) introduces the studies reveals that cryptographic engine as a bottleneck for voice traffic transmitted over IPsec.

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 [33]. One consideration with this method is that the endpoints must be computationally powerful enough to handle the encryption mechanism. But typically endpoints are less powerful than gateways, which can leverage hardware acceleration across multiple clients. Though ideally encryption should be maintained at every hop in a VOIP packets 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. Fortunately, the increased processing power of newer phones is making endpoint encryption less of an issue. In addition, SRTP and MIKEY are future protocols for media encryption and key management enabling secure interworking between H.323 and SIP based clients.

Secure Real Time Protocol (SRTP)

Jitter: refers to non-uniform packet delays. 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 sequ ence number and timestamp fields. The overhead in reassembling these packets is non-trivial, especially when dealing with the tight time constraints of VOIP.

RTP (Real-time Transport Protocol) is commonly used for the transmission of real-time audio/video data in Internet telephony applications. Without protection RTP is considered insecure, as a telephone conversation over IP can easily be eavesdropped. Additionally, manipulation and replay of RTP data could lead to poor voice quality due to jamming of the audio/video stream. Modified RTCP (Real-time Transport Control Protocol) data could even lead to an unauthorized change of negotiated quality of service and disrupt the processing of the RTP stream.

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 was b eing standardized at the IETF in the AVT working group. It was released as RFC 3711 in March 2004.

SRTP provides a framework for encryption and message authentication of RTP and RTCP streams. SRTP can achieve high throughput and low packet expansion.

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. 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. Such bandwidth is not alway s 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. Newer codecs such as internet Low Bit-rate Codec (iLBC) are also being developed that offer roughly the voice quality and computational complexity of G.729A, while providing increased tolerance to packet loss.

Better Scheduling Schemes

The incorporation of AES or some other speedy encryption algorithm could help temporarily alleviate the bottleneck, but this is not a scalable solution because it does not address the highest degree cause of the slowdown. 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), effec tively 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. Although this heuristic solves the problem for all packet poised to enter the crypto engine at a given time, it does not address the problem of VOIP packets arriving at a cryptoengine queue that is already saturated with previously scheduled data packets.

QoS prioritizing can also be done after the encryption process provided your encryption procedures preserve the ToS bits from the original IP header in the new IPsec header. This functionality is not guaranteed and is dependent on ones network hardware and software, but if it is implemented it allows for QoS scheduling to be used at every hop the encrypted packets encounter.

There are security concerns any time information on the contents of a packet is left in the clear, including this ToS-forwarding scheme, but with the sending and receiving addresses concealed, this is not as egregious as a cursory glance would make it seem. Still neither the pre-encryption or post-encryption schemes actually implement QoS or any other prioritizing scheme to enhance the crypto-engines FIFO scheduler. Speed and compactness constraints on this device may not allow such algorithms to be applied for some time.

CONCLUSION

This paper has discussed on VOIP architecture, security issues & security mechanisms followed in the VOIP architecture. The generic problems & the solution for the VOIP system are discussed. Future work may include software attacks prevention through solid security policies and their enforcement.

REFERENCES

1.W.C. Hardy, QoS Measurement and Evaluation of Telecommunication s Quality of Service, John Wiley & Sons, 2001.

2.W.C. Hardy, VOIP Service Quality: Measuring and Evaluating Packet-Switched Voice, McGraw-Hill, 2003.

3.International Telecommunications Union. ITU-T Recommendation G.114 (1998): "Delay".

4.P. Mehta and S. Udani, Overview of Voice over IP. Technical Report MS-CIS-01-31, Department of Computer Information Science, University of Pennsylvania, February 2001.

5.B. Goode, Voice Over Internet Protocol (VOIP). Proceedings of thee IEEE, VOL. 90, NO. 9, Sept. 2002.

6.R. Barbieri, D. Bruschi, E Rosti, Voice over IPsec: Analysis and Solutions. Proceedings of the 18th Annual Computer Security Applications Conference,2002.

7.Anonymous, Voice Over IP Via Virtual Private Networks: An Overview. White Paper, AVAYA Communication, Feb. 2001.

8.R. Sinden, Comparison of Voice over IP with circuit switching techniques. Department of electronics and Computer Science, Southampton University, UK, Jan . 2002.

9.K. Percy and M. Hommer, Tips from the trenches on VOIP. Network World Fusion, Jan. 2003

10.Anti-phishing working group. Online: http://www.antiphishing.org/

11.Blau, J., 2005. Cabir worm wriggles into U.S. mobile phones. PC World. Online:

http://www.pcworld.com/news/article/0,aid,119763,00.asp.

12.Chen, X. and Heidemann, J., 2002. Flash crowd mitigation via adaptive admission control based on application-level measurement. Technical Report ISI-TR-557, UniversityofSouthernCalifornia. Online:http://www.isi.edu/~johnh/PAPERS/Chen02a.html.

13.Defense Information Systems Agency (DISA), 2004. Voice Over Internet Protocol (VOIP), SecurityTechnical Implementation Guide, Version 1, Release 1, 13.

14.Demers, S., et al., 1989. Analysis and simulation of a fair queuing algorithm. Proc. Special Interest Group on Data Communication (SIGCOMM), Austin, USA.

15.Gregory, P.H., 2004. Microsoft ignoring the biggest source of secu rity threats? Computerworld, February

16.online: http://www.computerworld.com/securitytopics/security/story/

17.Hensell, L., 2003. The new security risk of VoIP. E-Commerce Times, October 2. Online article: http://www.ecommercetimes.com/story/31731.html.

18.Ioannidis, J. and Bellovin, S.M., 2002. Router-based defense against DDoS attacks. Proc. Network and Distributed System Security Symposium (NDSS), San Diego, USA.

19.Jung, J., et al., 2002. Flash crowds and denial of service attacks: Characterization and implications for CDNs and Web sites. Proc. of the 11th International World Wide Web Conference, Honolulu, USA.

20.Kidman, A., 2004. The next virus threat: IP telephony. June 18. Online:http://www.zdnet.com.au/news/security/0,2000061744,39150881,00.htm