VoIP Security in Public Networks

Master Thesis
VoIP Security in Public Networks

Pawel Lawecki
February 2007
Alcatel-Lucent, Stuttgart
ZA/ON Department
Dr. Stephan Rupp Dr. Wolfgang Holz
Poznan University of Technology

Chair of Telecommunication and Computer Networks
University of Stuttgart
Institute of Communication Networks and Computer Engineering
Prof. Dr. Maciej Stasiak Dr. Mariusz Gbowski
Prof. Dr. Paul. J. Khn Dipl.-Ing. Martin Neubauer Dipl.-Ing. Andreas Gutscher
Abstract
Voice over IP is one of the quickest developing Internet services and slowly replaces traditional telephony. However, while moving telephony to the public IP platform broadens its service capabilities, some security problems may occur. It is because the amount of threats existing in IP networks is much bigger than in case of traditional telephone networks. Therefore security challenges of VoIP public network are considered in this work in detail. Full security analysis is performed that covers many issues like protocol vulnerabilities, architecture of access and service networks, legislative framework or client's and provider's role. Security requirements of both client and provider are analyzed. Considerations regarding how those requirements may be compromised are also carried out, including threat analysis, overview of vulnerabilities and attack techniques against technologies underlying VoIP and specific for VoIP. Finally, some study of existing security mechanisms that could counteract vulnerabilities and prevent attacks is performed. Risk analysis is also carried out in this work. The most serious problems of VoIP public networks are this way identified and security solutions are proposed. Concepts of cooperation between access and service providers are thoroughly discussed. Prevention of identity theft with voice biometric authentication and enforcement of encryption are also investigated.
Pawel Lawecki
Page i
Pawel Lawecki
Page ii
Acknowledgments
This Master Thesis was performed as a final project of my Master studies at Poznan University of Technology. However, it was carried out in Alcatel-Lucent in Stuttgart and supervised by University of Stuttgart, where it was recognized as a Student Project. The Thesis was carried out as a part of VoIP security project in parallel with another work covering security of enterprise networks (Christina Chalastanis [1]). Both works were supervised by Dr. Stephan Rupp in Alcatel-Lucent. I would like to express my gratitude to all the people who helped me in my work, especially to:

Dr. Stephan Rupp for the opportunity of performing my Master Thesis in AlcatelLucent, his support, help and guidance, Prof. Dr. Paul J. Khn for allowing me to do it under the supervision of University of Stuttgart, Dr. Mariusz Gbowski for the help and support by coordinating the Thesis with Poznan University of Technology, Martin Neubauer and Andreas Gutscher for their time and supervision at the University of Stuttgart, Harald Orlamnder for his thorough and valuable comments regarding my Thesis, Dr. Wolfgang Holz, Franz-Josef Banet and Wolfgang Klenner for their time and sharing technical expertise, Christina Chalastanis for the support, discussions and advices, Anna Biliska and Kamila Gajtkowska for all the great effort of correcting the language and structure mistakes.
Pawe awecki
p.lawecki@gmail.com
Pawel Lawecki
Page iii
Pawel Lawecki
Page iv
Table of Contents
1. Introduction............................................................................................... 1
1.1. Motivation....................................................................................................1 1.2. Objectives....................................................................................................1 1.3. Structure..................................................................................................... 2
2. Background................................................................................................ 3
2.1. PSTN & POTS................................................................................................3 2.2. VoIP............................................................................................................3 2.2.1. General Properties......................................................................................... 3 2.2.2. Protocols and Concepts..................................................................................5 2.3. NGN............................................................................................................7 2.4. Technology Summary.................................................................................... 9 2.4.1. PSTN vs. VoIP Comparison.............................................................................9 2.4.2. VoIP Security..............................................................................................12
3. Architecture............................................................................................. 13
3.1. Overall Architecture.....................................................................................13 3.1.1. Public Network............................................................................................13 3.1.2. Access & Service Provider.............................................................................15 3.1.3. Consequences.............................................................................................17 3.2. Access Networks......................................................................................... 18 3.2.1. DSL...........................................................................................................20 3.2.2. Broadband Cable.........................................................................................21 3.2.3. WiMAX.......................................................................................................22 3.3. Provider Architecture................................................................................... 23 3.3.1. Access Provider...........................................................................................24 3.3.2. Service Provider..........................................................................................24 3.3.3. VoIP Server - SIP Architecture......................................................................26
4. Security Analysis Considerations.............................................................. 29

4.1. Available Approaches...................................................................................29 4.1.1. ISO 17799.................................................................................................. 29 4.1.2. X.805........................................................................................................29 4.1.3. NIST Risk Management Guide.......................................................................30 4.2. Chosen Approach........................................................................................ 30
5. Security Requirements Analysis............................................................... 33

5.1. General Requirements..................................................................................33 5.1.1. Confidentiality, Integrity, Availability............................................................. 33 5.1.2. Authentication, Authorization, Accounting.......................................................33 5.1.3. Privacy, Non-repudiation, Traffic Analysis.......................................................34 5.2. Legislative Issues........................................................................................ 35 5.2.1. General Telecommunication Issues................................................................35 5.2.2. Emergency Calls.......................................................................................... 36 5.2.3. Lawful Interception......................................................................................36 5.3. System Requirements Definition....................................................................37 5.3.1. Personal Client............................................................................................37 5.3.2. Business Client............................................................................................ 38 5.3.3. Provider.....................................................................................................39
Pawel Lawecki Page v VoIP Security in Public Networks
5.4. Security Requirements Summary...................................................................40
6. Threat Analysis........................................................................................ 42
6.1. Threats Categorization Overview................................................................... 42 6.2. Threat Taxonomy........................................................................................ 43 6.3. Threat Architecture......................................................................................46 6.3.1. Communication Channel Threats...................................................................47 6.3.2. Interruption of service.................................................................................48 6.3.3. Unwanted Contact.......................................................................................49 6.3.4. Theft of Service and Service Abuse................................................................49 6.4. Client & Provider Threats..............................................................................50 6.4.1. Client......................................................................................................... 50 6.4.2. Provider.....................................................................................................51 6.5. Threat Realizations & Summary.....................................................................52
7. Underlying Layers Analysis...................................................................... 54

7.1. Properties & Vulnerabilities........................................................................... 54 7.1.1. General Overview........................................................................................54 7.1.2. Client & Provider.........................................................................................55 7.1.3. DSL...........................................................................................................57 7.1.4. Broadband Cable.........................................................................................58 7.1.5. WiMAX.......................................................................................................60 7.1.6. Ethernet Scenario........................................................................................61 7.2. VoIP Underlying Attacks............................................................................... 62 7.2.1. Traffic Sniffing............................................................................................63 7.2.2. Man in the Middle Attack..............................................................................63 7.2.3. Malicious Software....................................................................................... 65 7.2.4. Denial of Service.........................................................................................65 7.2.5. Unauthorized Device Control.........................................................................66 7.2.6. Physical Attack............................................................................................ 67 7.3. Underlying Layers Summary......................................................................... 68
8. Application Layer Analysis........................................................................ 69

8.1. Properties & Vulnerabilities........................................................................... 69 8.1.1. General Overview........................................................................................69 8.1.2. SIP Provider...............................................................................................70 8.1.3. Protocols....................................................................................................71 8.1.4. Programming and Configuration....................................................................71 8.1.5. SIP Sequence Flows.....................................................................................73 8.2. VoIP Based Attacks......................................................................................75 8.2.1. Call Pattern Tracking & Eavesdropping...........................................................76 8.2.2. SIP Based MitM...........................................................................................76 8.2.3. Registration Hijacking..................................................................................77 8.2.4. MitM Based Attacks..................................................................................... 78 8.2.5. VoIP Specific DoS........................................................................................79 8.2.6. Impersonation Attacks.................................................................................81 8.2.7. Toll Fraud Attacks........................................................................................ 82 8.2.8. Identity Theft.............................................................................................. 82 8.2.9. SPIT..........................................................................................................83 8.2.10. Social Attacks...........................................................................................83 8.3. Application Layer Summary.......................................................................... 84
9. Solutions Analysis.................................................................................... 85
Pawel Lawecki Page vi VoIP Security in Public Networks
9.1. Existing Problems........................................................................................85 9.2. Available Solutions...................................................................................... 87 9.2.1. Encryption..................................................................................................87 9.2.2. Authentication............................................................................................89 9.2.3. VoIP Security Mechanisms............................................................................90 9.2.4. End-Device Security Mechanisms.................................................................. 92 9.2.5. Policies, Rules, Guidelines............................................................................. 92 9.2.6. SPIT Protection...........................................................................................93 9.2.7. Denial of Service Protection..........................................................................94 9.2.8. Physical Security.........................................................................................95 9.2.9. Education...................................................................................................96 9.2.10. Monitoring & Detection...............................................................................96 9.3. Risk Analysis...............................................................................................97 9.4. Security Summary.......................................................................................99
10. Public Security Platform....................................................................... 101

10.1. Problem Statement.................................................................................. 101 10.2. Authentication.........................................................................................102 10.2.1. General Properties...................................................................................102 10.2.2. Identity..................................................................................................102 10.2.3. Authentication Architecture.......................................................................103 10.3. Possible Solutions.................................................................................... 105 10.3.1. Circle of Trust.......................................................................................... 105 10.3.2. Biometrics..............................................................................................107 10.3.3. Encryption Enforcement............................................................................109 10.4. Security Platform Summary.......................................................................111
11. Summary & Conclusions....................................................................... 113

11.1. Summary & Contribution...........................................................................113 11.2. Conclusions.............................................................................................114 11.3. Outlook.................................................................................................. 115
Abbreviations............................................................................................. 116 References................................................................................................. 118
Pawel Lawecki
Page vii
Figure Index
Figure 1: VoIP/PSTN basic scenarios.................................................................................4 Figure 2: VoIP basic architecture......................................................................................5 Figure 3: VoIP protocol stack [6]......................................................................................6 Figure 4: NGN evolution..................................................................................................7 Figure 5: Pre-NGN networks and NGN converged network (partially [12])............................. 8 Figure 6: VoIP market growth in the USA [14]...................................................................9 Figure 7: Public network abstract architecture..................................................................13 Figure 8: Public IP network general architecture...............................................................14 Figure 9: Access and service providers in OSI layers (partially [18])...................................16 Figure 10: General architecture of public network with technology examples........................17 Figure 11: Telephony open architecture consequences.....................................................18 Figure 12: Combined Architecture and Open Architecture with access networks....................19 Figure 13: DSL access architecture.................................................................................20 Figure 14: Broadband cable access architecture............................................................... 21 Figure 15: WiMAX access architecture.............................................................................23 Figure 16: Access provider architecture...........................................................................24 Figure 17: VoIP service provider architecture...................................................................25 Figure 18: VoIP server in SIP architecture.......................................................................26 Figure 19: ITU-T X.805: Security Architecture for Systems Providing End-to-End Communications [28].................................................................................................... 30 Figure 20: Used security assessment approach................................................................ 31 Figure 21: Lawful Interception principle...........................................................................37 Figure 22: VOIPSA Threat Taxonomy [49].......................................................................44 Figure 23: General threat architecture............................................................................ 46 Figure 24: Information flow in a hypothetical communication system - threats.....................47 Figure 25: Attack technique as a threat realization........................................................... 52 Figure 26: General overview of protocol architecture in public network................................54 Figure 27: DSL access protocol architecture (partially [52])...............................................58 Figure 28: Broadband cable access protocol architecture...................................................59 Figure 29: WiMAX access protocol architecture.................................................................60 Figure 30: Address Resolution Protocol in Ethernet networks............................................. 62 Figure 31: Man in the Middle Attack in Ethernet network...................................................64 Figure 32: SIP based VoIP system - general overview (set from [4] and [75])..................... 69 Figure 33: SIP-PSTN telephony system - general overview................................................ 70 Figure 34: SIP provider general architecture - application layer..........................................70 Figure 35: SIP - user Agent Register operation [4]........................................................... 73 Figure 36: SIP - call initiation (set from [4], [24] and [75])...............................................74 Figure 37: SIP call redirection (set from [4], [24] and [75]).............................................. 75 Figure 38: SIP call forking.............................................................................................75 Figure 39: SIP based Man in the Middle attack - 3xx response code attack [46]................... 76 Figure 40: SIP registration hijacking [78]........................................................................77 Figure 41: SIP MitM based hijacking attacks [79] - registration (top), outgoing call (middle) hijacking and initiating outgoing call (bottom)..................................................................78 Pawel Lawecki Page viii VoIP Security in Public Networks
Figure 42: SIP message flow DoS attack (composed using [82])........................................ 80 Figure 43: Main security problems in VoIP.......................................................................86 Figure 44: Encryption - asymmetric and symmetric key algorithm......................................88 Figure 45: Authentication - digital certificate/signature mechanism.....................................90 Figure 46: DDoS detection and filtering effectiveness [73].................................................95 Figure 47: Risk management - monitoring & detection [106]............................................. 97 Figure 48: Risk analysis - general issues......................................................................... 97 Figure 49: Security solutions summary............................................................................ 99 Figure 50: Authentication architecture - related threats...................................................104 Figure 51: Circle of Trust / Federation - VoIP safe environment........................................105 Figure 52: Biometric voice verification (partially [111])................................................... 107 Figure 53: Tolerance and reliability of a biometric verification system (composed from [112]) ................................................................................................................................108 Figure 54: Encryption background - media & signaling.................................................... 110 Figure 55: Zfone - encryption with simple user GUI........................................................ 111
Table Index
Table Table Table Table Table Table Table Table Table Table 1: PSTN services vs. VoIP comparison summary......................................................10 2: Basic features of the most typical access scenarios.............................................. 18 3: SIP request and respond commands [24]............................................................28 4: Personal client's main security expectations........................................................ 38 5: Business client's main security expectations........................................................39 6: Provider's main security expectations.................................................................40 7: Client's main threats........................................................................................51 8: Provider's main threats.....................................................................................51 9: SIP programming - generality vs. security [6]..................................................... 72 10: Security best practices [51].............................................................................93
Pawel Lawecki
Page ix
Introduction
1. Introduction
1.
1.1.
Introduction
Motivation
Voice over Internet Protocol is a rapidly growing Internet service. It gained popularity as a way to cut costs of international telephone connections by transporting voice over public IP network. Today it is being implemented in many IP applications, where it enables direct, often free communication over the Internet to people from all over the world. As a consequence, VoIP technology slowly replaces traditional telephony. Obviously, telephony is of essential importance to the contemporary economy and functioning of the whole modern society. Providing security to this service is therefore one of the most important tasks of telecommunications. User private information, business negotiation details or even state secrets could be revealed if not well protected. Without correct mechanisms ensuring authentication of callers, confidentiality of the transmission or availability of the service, security of the whole society is at risk. Due to this, one should consider security problems of Voice over IP and try to find out, if moving telephony to a new IP-based platform does not compromise its security. In most cases advances and trends in information technology typically outpace the corresponding realistic security requirements [2]. This is no different in case of VoIP. Most of the efforts were until now invested into providing more advanced services, converged with other IP applications. Security subjects were usually treated as a second-class problems, if not ignored completely. Additional problem is that VoIP telephony is not a completely new idea. It follows the example of traditional telephony and it is seen as a replacement of traditional telephony by its users. Replacement that should provide similar security level. Public network users assume that the security of VoIP telephony should be granted just as in case of the traditional telephony. Due to this, VoIP is different from other IP services, where security is usually treated as one of the service properties configurable by th user. This makes it even more important to investigate security problems of VoIP public network.
1.2.
Objectives
Objective of this thesis is to analyze security problem of VoIP in public networks. In order to do this different steps need to be performed.

VoIP protocols need to be analyzed and investigated. Their security mechanisms and vulnerabilities should be found, architecture of public network should be considered in detail regarding security problems that may occur, some security approach should be found, a method which could be used in order to perform security analysis of public network, different problems, like threats, attacks, security mechanisms should be covered.
Public network is a complicated, diversified and vast entity and, due to this, quite difficult to define. Any attempt to analyze its security problems should take it into account and therefore:

classifications and categorizations should be used in the course of security analysis in order to find some common properties and handle security problem better, VoIP security problems should be generalized and considered in an abstract way in order to simplify and make analysis more readable. Page 1 VoIP Security in Public Networks
Pawel Lawecki
Introduction
1.3. Structure
1.3.
Structure
In the first three chapters of the thesis its subject is analyzed and the scope of interest that will be covered is defined. Three main problems are considered:

Background gives necessary information about VoIP and defines what is understood under this term, Architecture treats about the structure and elements of public network and VoIP protocol architecture, Security Problem Considerations considers security analysis methodology necessary steps and problems that should be investigated to cover all possible problems.
In chapters 5-9 security analysis of VoIP in public network is given, according to the approach described in Security Problem Approach chapter:

Security Requirements Analysis defines what are the security expectations in VoIP public network and describes the role of client and provider, Threat Analysis specifies unwanted occurrences that may affect VoIP public network and tries to categorize them concerning architecture, affected subject, origin, etc. Underlying and Application Layer Analysis gives an overview of attack techniques that may be used and vulnerabilities that may be exploited by attackers, Solutions Analysis describes available security mechanisms and assesses their effectiveness. Public Security Platform describes the biggest problems of VoIP public network and proposes three solutions establishing circles of trust among providers, usage of voice biometric authentication to identify users and enforcement of encryption to ensure confidentiality of transmission.
Finally, the last chapter is a proposal of some additional solutions that could enhance security:
Pawel Lawecki
Page 2
Background
2. Background
2.
Background
Most of people intuitively understand how does traditional telephony work, basing on the years of experience, while dealing with it. However, Voice over Internet Protocol is a rather new technology, and even though an average telecommunication user knows it concerns the Internet and is relatively cheaper, he/she could probably not give any more details. That is why an introduction to VoIP technology is given in this chapter and it bases on a comparison with the previous and known techniques.
2.1.
PSTN & POTS
One could say that traditional telephony evolved in three main steps. [3] Since it has been developed and constructed in 1878, until 1891, it existed in a form of a first generic telephone network. Its biggest disadvantage was that it required human presence in order to switch and set up the telephone calls. Indeed a new technology, which provided automated telephone switching, was introduced in 1891, but the old system existed in parallel much longer. It is because each technology needs time to prove itself useful and after a few decades all of the manual exchanges were replaced. This new system is known as the Plain Old Telephone System (POTS). The third revolution came with the Public Switched Telephone Network (PSTN) that was first introduced in 1970s. In the PSTN, voice did not travel as an analogue signal, but as a digital one1. Thanks to this transformation, new advanced services like for example FAX or other data-based transmissions could be offered. In general the PSTN systems encompass and are compatible with the POTS that uses only 4 kHz of the lowest transmission bandwidth (300 Hz 3,4 kHz). Digital services are transported on higher frequencies. Additionally, from 1990s the higher bandwidth started to be used as a data-network access technology. Many Internet access services, like ISDN and then DSL, ADSL are now offered via the same access lines that were used for PSTN. Cellular networks with their completely different architecture, wireless access and mobility issues are treated here as a similar, but independent technology. Mobile networks have their pros and cons, but on the current stage of the development they are an alternative, complementary technology to the PSTN.
2.2.
VoIP
General Properties
2.2.1.
VoIP is the next and most recent step of the telephony evolution. As the name VoIP stands for, it transports Voice over Internet Protocol packets. This is a huge difference in comparison to the PSTN. [4] The PSTN is circuit switched. It means that, regardless of the amount of information to be sent, a full transmission bandwidth is reserved. Even if the speaker is not saying anything, the same transmission rate is always used and the whole transmission channel is occupied. VoIP, on the other hand, is packet switched. Information that is to be sent is divided into
1 Actually the difference between POTS and PSTN is not that clear. Both names are used alternately by some sources. In most cases however, PSTN specifies a newer and more advanced network, where modern telephony services may be offered, while POTS is a purely voice related system from the past. The biggest difference between the past and contemporary systems is that they used to be analog and are digital now. Because of that, the author decided to specify this fact as a feature distinguishing between PSTN and POTS.
Pawel Lawecki
Page 3
Background
2.2. VoIP
packets and transmitted. Only meaningful information is put into packets the speaker has to say something. Additionally each packet may travel with a different route1 (dynamic routing) in a transport network, as there is no single reserved path (circuit). As a consequence packets arriving at the destination may come in a different sequence, than they were sent. Also, as there is no guaranteed bandwidth, some packets may be lost. These packets are simply transported with the Internet Protocol (IP). Voice transportation with the IP works just the same way, as in any other application like WWW or email. Internet's tariffing system is based on a philosophy different than in the PSTN. Tariffing is independent from geographical distance between the sender and receiver. Therefore, transmitting data between any two points costs the client always the same, which was not a case in the traditional PSTN. That is a primary reason of developing VoIP to be able to call cheaper. First applications of VoIP were to enable voice communication between two users of the Internet. This case is shown in Figure 1 as Scenario 1. Nowadays it has a growing popularity and is used in many Instant Messaging (IM) clients, like Skype, Messenger, Yahoo Messenger, etc. Voice transmission over IP works just as any other Internet service and is fully converged with other IM applications. The next step of VoIP development came with the calls from Internet users to PSTN fixed subscribers (Scenario 2). The main advantage of such a telecommunication solution is that information traveled through the Internet as long as possible and are forwarded to the PSTN at the very end as close to the subscriber as possible. Thanks to this, even international calls are treated as local ones by PSTN provider. Total cost is considerably diminished. The only additional technology that is needed, is translation of VoIP protocols (signaling and data) into the PSTN protocols (SS7 stack). However, it has been achieved with ease, by the introduction
Figure 1: VoIP/PSTN basic scenarios

1 It happens seldom actually. In most of the cases a router simply looks up its routing table and forwards the packet to the right destination. In practice, most of the packets will be routed the same way, even in case of a complicated routing mechanism.
Pawel Lawecki
Page 4
Background of VoIP<->PSTN Gateways.
2.2. VoIP
The last two scenarios (Scenario 3 and 4) might be used by providers when circumstances request it. Certainly many other more complicated scenario cases are possible, but they would merely be a variation of the four presented in Figure 1. The truth is that VoIP and the PSTN coexist in a much more complex way. It is not uncommon that a VoIP user has access to the Internet via DSL so a PSTN related service. In case of such users, even though only VoIP may be used, the PSTN access line has to be maintained, as the technology granting access to the Internet. In all other cases, while using VoIP, one does not even need a telephone device. A computer with a headphone set is enough. No necessity to lay a PSTN cable and pay for a number. Everything can be done in the Internet, in the data network. Obviously, assuming that the used Internet access technology, does not require PSTN presence. Originally VoIP was supposed to provide the traditional PSTN services only like voice calls, faxes, or mailboxes. However, putting a voice transmission in the Internet presented much more possibilities. One could converge the data-based services together with the voice-based ones and get a completely new, advanced functionalities. This phenomena started a few years ago and still take place. Merging VoIP services together with Instant Messaging (IM) or World Wide Web (WWW) is more and more widespread. Of course, while changing platform to a data-based one, VoIP encounters many problems. First and the biggest one is the latency. The acceptable delay in telephony is maximally 200 milliseconds. By higher values, it might be difficult to carry out a conversation. Unfortunately, the available bandwidth in VoIP is not reserved, so there is no guaranteed Quality of Service (QoS), as in the PSTN. Because of too low bandwidth available, voice packets may be forced to wait, what will create a delay. Another problem occurs, if subsequent packets experience delays of different lengths. The receiver needs to collect all the packets in order to reconstruct the full traffic stream and play it to the user. That is why the difference of delays between packets forces the receiver to buffer the traffic and wait for the delayed packets, even if most of the packets is already available. This way even though the mean packet delay over the network may be relatively small, the total delay will be much bigger. It will be considerably increased by single delayed packets. Such a variation of latencies over the network is called jitter. As said jitter may increase the total delay, but also cause break and silence periods. It will happen if some of packets arrive later than the mentioned 200 milliseconds, they will be simply considered lost. Last but not least, packets may be lost because of an insufficient buffer space. All those problems diminish Quality of Service, however new advanced voice (or video) coding schemes can cope with most of those shortcomings.
2.2.2. Protocols Concepts

Figure 2: VoIP basic architecture Pawel Lawecki Page 5
and
While introducing VoIP one has to mention some basic elements and VoIP Security in Public Networks
Background
2.2. VoIP
concepts of a VoIP system. As can be seen in Figure 2 there are four basic elements of a VoIP system [4]:
terminal communication endpoint that terminates the call. It is where the end user resides, but some automatic interaction is also possible (voicemail). Terminal may be software or hardware based. server central point of the system. Terminals register here and their information data (like location, IP, etc.) is stored. Server provides routing mechanisms for the call set up. It also authenticates, authorizes and performs accounting operations. gateway is a border element of VoIP network. It provides interoperability with other types of networks (like VoIP<->PSTN). This means that it usually translates one protocol stack into another1. conference bridge provides functionality for multi point communication. It is separated from server, as there are high resource requirements.
Some PSTN terminals are also shown in Figure 2. Neither PSTN network, nor PSTN terminals are a part of VoIP architecture, but those elements are usually connected to VoIP network in a shown way. Moreover, two basic mentioned scenarios are shown in the figure: IP <-> IP and IP <-> PSTN. When writing about any IT technology one has to introduce the used protocols (Figure 3). Probably two most important ones are the following signaling protocols: Session Initiation Protocol (SIP) [5] [6] and H.323 [7]. They provide similar functionality, but are competing protocols coming from two different organizations: Internet Engineering Task Force (IETF) created SIP, while International Telecommunication Union (ITU) worked out H.323. As signaling protocols, they are responsible for setting up and tearing down the calls, user registration, authentication, etc. There are of course many other additional protocols that are necessary for a correct functioning of a VoIP network and its signaling [8], but they are not so relevant from the point of view of security.
Figure 3: VoIP protocol stack [6] Voice data is transmitted using Real Time Protocol (RTP) [9]. The voice is processed and silence periods are separated from talk spurts. Then it is segmented, synchronized with the receiver and sent. RTP might work together with some QoS protocols like Resource
1 In case of VoIP-PSTN gateway, VoIP signaling protocol, like SIP is translated into SS7 protocol, specific for the PSTN. The PSTN data channel, which is 64 kbps PCM channel with G.711 codec is converted into RTP packets that are distinctive for VoIP. Brief description of the VoIP protocols is given later on in this chapter.
Pawel Lawecki
Page 6
Background
2.2. VoIP
ReSerVation Protocol (RSVP) [10] and RT Control Protocol (RTCP) [9], but it depends on the communication scenario. Additionally Real Time Streaming Protocol (RTSP) [11] is used for voice stream control, when retrieving voice/video data from a server (it provides functionality of VCR-like commands, like stop, pause, rewind, etc.). As shown in Figure 3 there are many underlying protocols that might be used to provide lower OSI1 layer functionalities to VoIP. However, as a consequence of traffic properties, signaling protocols usually use TCP, while data protocols use UDP. It is obvious, when one remembers that by signaling, a reliable transmission of packets is necessary and it is provided by TCP. While transmitting data, on the other hand, we do not care about single packets being lost, but about the delay. UDP, without any mechanisms guaranteeing delivery, ensures much smaller delay than TCP. Different flow control mechanisms, like retransmission and throttling make TCP not feasible for real time transmissions. Internet Protocol packets with data and signaling contents may be transmitted with any available technology. Usually, it is one of the most typical protocols, like ATM, Ethernet, or PPP.
2.3.
NGN
There is one fundamental difference between two mentioned telephony types VoIP and the PSTN. The problem is that, while VoIP is only a telephony service, the PSTN is both service and access to the network. VoIP requires connection to the Internet, in order to function. The PSTN is self-sufficient, it provides a service and access to the network where the service is offered. That is why it is rather difficult to say that VoIP is a complete successor of the PSTN. It merely is a successor of the telephony service. The real replacement of the PSTN system may be achieved, if one offers VoIP service on a Next Generation Network (NGN) platform [12], where NGN
Figure 4: NGN evolution

1
OSI Open Systems Interconnection reference model. Abstract model of networking dividing elementary network functionalities into layers. It is also called a seven layer model. The layer names are: application, presentation, session, transport, network, data link, physical. For more detailed explanation see Figure 9 on page 16.
Pawel Lawecki
Page 7
Background
2.3. NGN
replaces PSTN architecture (access and core network) and VoIP replaces the PSTN services. NGN is a concept of providing a single access network that could replace many others that until now were independent. TV, radio, telephony networks could use a single, highly efficient transport platform. Inside however, it differentiates the services highly demanding, real time services are given priority. Here lays the main difference between VoIP in open architecture (where any access network is allowed) and VoIP in NGN. Thanks to differentiating the services in the NGN one can provide Quality of Service [13]. By this, one keeps all of the packetswitched model advantages, without its biggest disadvantages jitter and delays. In Figure 4 one can see the evolution of the existing technologies into the NGN. The common platform used in the Next Generation Networks may be different for each case. However, there are some properties that should always hold it should be IP based and have a very high bandwidth. Figure 5 shows the described phenomena on the example of radio/TV, telephony and data services. The access networks are merged into one packet switched NGN network. All the services travel in this network and they may be differentiated and distinguished for the sake of service quality. However, the difference between the traffic streams will be merely virtual, as all the services use the same medium. There is one more consequence of introducing NGN that is worth mentioning. Changing the properties of the access and transport network enables new functionalities of the services. Since TV and radio signal is not broadcasted anymore, but it travels to each user separately in IP packets, the user might have an influence on the contents. He/she can decide what to watch. This way one not only provides a network supporting QoS for VoIP, high-bandwidth for data, but also introduces interactivity to the services like television, or radio.
Figure 5: Pre-NGN networks and NGN converged network (partially [12])
Pawel Lawecki
Page 8
Background
2.4. Technology Summary
2.4.
Technology Summary
PSTN vs. VoIP Comparison
2.4.1.
When two technologies start competing for the same users, on the same market, it is obvious that at the end the better one achieves success. The rapid growth of the VoIP services, subscribers and market revenues is a sign that VoIP is better indeed (if one treats the market as an objective point of reference) than the traditional PSTN. Figure 6 shows just how rapid this growth is. What are then the qualities, which decide that development of VoIP is so quick? Is this technology without any faults and is PSTN's marginalization inevitable? Table 1 gives an overview and a summary comparison of VoIP and PSTN telephony services. There are many other relevant issues, but just the most important ones have been presented. Certainly by some of the properties it is really difficult to state which solution is better. Packet switching is good, as it does not transfer any irrelevant information, but on the other hand there is no guaranteed Quality of Service. There has to be enough bandwidth available, or the service will be of a very low quality. If there is enough bandwidth however, the quality of VoIP may be better than in PSTN. In case of PSTN the bandwidth is 64 kbps and cannot be more. In case of services, VoIP's advantage is really clear. Integration of the telephony with data network enables many advanced, interactive and complex services. Introducing most of the VoIP additional services to the Figure 6: VoIP market growth in the USA [14] PSTN would be theoretically possible, but for sure much more complicated, expensive and sometimes even economically unreasonable. Providing mobility in VoIP means that any user may take his terminal (software or hardware) and connect it to any possible place in the given network and everything should work without additional configuration. Once the client is connected in some other place of the network and registered at the server, his home location is updated. That is why this property is sometimes called nomadicity, instead mobility1. The real mobility is offered in cellular networks like GSM. In case of cellular networks, which are also circuit switched, the mobility issue is more advanced and flexible than in VoIP.
This description of mobility is actually a big simplification of the real issue. What is called a terminal, or client in this paragraph is actually called (for SIP networks) User Agent (UA). It is because according to a client-server model, User Agent may be both client and server. If it initiates a call then unquestionably it is a client. However UA additionally wants to receive calls. Because of that the whole registration and authentication mechanism is necessary, if the clients are allowed to be mobile. For the sake of simplicity, in most cases User Agent will be called client, even though it is actually much more complex.
Pawel Lawecki
Page 9
Background
Property
switching
PSTN service
VoIP
circuit switched bandwidth packet switched no bandwidth reservation, resources are used even if reservation; resources are not used, if there is no information to be there is no information to be transmitted transmitted traditional services, like phone calls, faxes, voice mailboxes, caller identification, etc. Quality of Service is guaranteed, bandwidth reservation 64 kbps; but QoS limited to standard value and may not be enhanced originally no mobility option available, but was offered later in mobile networks almost all traditional services and many more video, message, data transmission, etc. no band reservation, quality may be affected if network traffic is too high; but with a sufficient bandwidth available, quality can be better than in PSTN calls may be answered and originated from any place with a sufficiently fast Internet connection; user may generate calls from any place of the network, but also receive them! shared infrastructure with data network relatively low, as existing data networks may be used for transmission no independent power supply, dependent on household electricity; power infrastructure needed for VoIP switches and every single desktop device no widely adopted standard, many RFCs and competitive standards covering some problems simple core network required, features implemented in end points, but the overall architecture complex functionalities of different OSI layers (for example Internet access and VoIP service) may be operated by different companies compression using limitations of eyes and ears to limit bandwidth; audio silence suppression, video motion detection open architecture almost no limitations
services
quality
mobility
infrastructure cost power supply
separate telephone infrastructure necessary relatively high, because of additional infrastructure and management independent power supply (48V supplied by the telephone line), telephones work even during power black out well defined, common standards
standards
architecture
centralized, highly complex central architecture the whole phone system is usually operated by a single company
operators
compression
no compression
access emergency
limited
in case of an emergency call, the caller no built in emergency localization mechanism may be localized, as each client has his/her own subscriber line
uses email-similar address structure, specific to geographical location, number attached to the closest geographically independent, identified by server's domain name or IP exchange and identified by the beginning of the number Table 1: PSTN services vs. VoIP comparison summary
numbering
Pawel Lawecki
Page 10
Background
Deploying telephony on the same infrastructure as data networks lowers not only communication costs, but also management costs of the network. Combining both utilities in one increases profitability for the provider [15]. Also the installation cost is cut, as only one cabling is necessary. Already mentioned cheaper long distance calls, play a great role in VoIP development. There is, however, one trade off in merging data and telephony services in one platform. PSTN telephones are supplied with electricity through the telephone line, which means that even in case of power outage the network could still work. Each PSTN provider has to have an independent power supply, but thanks to it, the whole system was much more resistant. Unfortunately the data access networks do not provide electricity to the end devices. Even if the VoIP provider has an independent power supply, each of the end-clients still needs his/her own power source. If not, then in case of a black out, the provider will indeed still work, but the clients will not be able to use it. Another difference between VoIP and the PSTN is the internal structure. The PSTN architecture is highly centralized, complex and closed. In case of VoIP, one needs only a simple core network, as most of the functionalities are implemented in the end devices. As a consequence the VoIP network is much easier to access. However, the overall structure of the Internet and VoIP networks built on it is also very complex and covered in many RFCs. Another property of the VoIP architecture that it is open, allows the services to be offered by different providers 1. In the PSTN one provider offered all the services, while in VoIP each function may be served by another subject. Different provider for access, voice services, voice mail, faxes, data services, etc. Development of the VoIP technology was also open and non-centralized. There was no single organization that would work on and announce some common standards. Instead of that, there were (and still are) many entities and companies and each of them came up with its own set of standards. It might be considered as a negative approach, as there is of course a lot of organizational mess. On the other hand, non-limited development enables free exchange of ideas, creative thinking and free competition of many solutions. It is just the same advantage that the open source programming has over normal programming approach. There is one disadvantage of a packetized traffic. Each IP packet, apart from voice data, contains a header with all the addressing parameters. IP and other protocols need some additional bandwidth usage. As a consequence the proportion of the signaling to data is much higher than in the PSTN. The packet overhead diminishes the bandwidth utilization2. However, there are many techniques used in VoIP that on the other hand minimize the necessary bandwidth. Different codecs and compression methods use physical limitations of ears. Unnecessary information is filtered out and silence periods are suppressed. So in the essence, the disadvantages of packetizing are, if not totally eliminated, then at least considerably diminished. The last fundamental difference between VoIP and the PSTN systems concerns caller localization. In the PSTN each telephone number is bound to a single subscriber line. A location of each subscriber line is known to the authorities. Because of that, when somebody calls an emergency number (112 in Europe, 911 in the US, etc.), he/she may be easily located. Unfortunately as a consequence of the packet switched platform, mobility and open
1 2 Of course in the theoretically open protocol VoIP world, there are also closed elements and networks. A good example for this is Skype. It is a provider of VoIP telephony in the Internet, but it uses proprietary and secret protocols and unknown encryption. Just to compare this overhead one can compute a typical bandwidth utilization for VoIP. PSTN uses full bandwidth of 64 kbps for voice data with 8 kHz sampling rate and 8 bit resolution. This means a typical voice packet of 10 milliseconds (longer packets are not practical because of the latency) with the same sampling parameters would contain 80 Bytes of data. A typical scenario for VoIP data packet is an RTP packet (Layer 7) enclosed in UDP packet (Layer 4) and put into IP datagram (Layer 3). Header sizes for the mentioned protocols are: RTP 12 Bytes, UDP 8 Bytes and IP 20 Bytes. This sums up to 40 Bytes of signaling data added to each 80 Bytes of voice data, which means the utilization is 66%. If one remembers that usually IP packet is transported to the end-client via Ethernet (or any other Layer 2 technology), the utilization falls down to 58% because of 18 Bytes of Ethernet frame header.
Pawel Lawecki
Page 11
Background
architecture, VoIP does not possess any mechanisms that would enable caller localization. The bottom line of the comparison between VoIP and the PSTN is that in the long term VoIP's success cannot be stopped. It offers much more services that PSTN and does it with smaller costs and better access. With enough bandwidth (or with guaranteed QoS) VoIP offers the same, or even better quality with many advanced, interactive functionalities. The open architecture ensures competition between providers and freedom of choice for the user. All the economical factors are on the side of Voice over IP technology. Is then VoIP's dominance so inevitable?
2.4.2.
VoIP Security
The only significant problem that may considerably limit march of VoIP on the telephony market is the security issue. Many clients (especially business clients) before considering complete resignation from the PSTN will probably ask, just how safe it is. And the answer they can get is not always satisfactory. It is not true that there were no security problems in the PSTN. There were many, however, mostly closed, proprietary architecture made those problems marginal. Access to the network was very complicated and before performing any attack one had to have a physical access to the provider's infrastructure. It was of course not impossible to simply break into a telephone box standing in the middle of the street, but was already discouraging. With the process of opening and decentralizing telephony architecture, VoIP made the technology much more available, flexible and user-driven. On the other hand, it made telephony vulnerable to many dangers that may be caused by malicious, or disruptive actions of the system users. In the Internet, it is much easier to stay anonymous. One does not have to break into any physical infrastructure attack is geographically independent and if performed with enough skills, almost untraceable. Additionally, if there are many providers involved into providing a service, then the responsibility for providing some security mechanisms may be blurred. Second, and even more serious issue, was putting VoIP on the data platform. It is not a secret that the Internet is a network full of many dangers. Dangers that until now were unknown to the telephony world: viruses, worms, Denial of Service (DoS) attacks, spam, etc. Amount of various threats and variations of malicious software grows together with the complexity of the Internet and sometimes even quicker, so it would be very naive to believe that VoIP services could stay unaffected. Additional issues, like emergency calls and power supply add even more complications to the whole problem. While there are some prospects of solving the emergency call problem in the near future, power supply issue may be impassable for now. Installing independent power supply to all end users is simply economically unfeasible. One should probably emphasize that even if the client decides to stick to the PSTN because of security problems, he/she may find more difficulties than it used to be in the past. The PSTN's evolution is heading towards Advanced Intelligent Networks (AIN) that are much more integrated with the Internet [16]. Which means that soon the PSTN will also be subject to the same problems, as VoIP. Estimating the seriousness of all those dangers is difficult without analyzing how the users access the networks, what technologies do they use, or what is the structure of provider's network. Also protocols and underlying technologies, or used overlying applications play a very big role and need to be defined. But most of all one needs to identify a most feasible way of solving security problem in order to comprehend the whole case.
Pawel Lawecki
Page 12
Architecture
3. Architecture
3.
Architecture
Trying to consider any security issues without defining what public network really is, would be rather difficult. In order to understand better the nature of public network, some closer investigation is performed in this chapter. Apart from the public network definition, one should also try to specify the structure and architecture of such a system. Of course it is not easy, as public network may consist of many elements providing a variety of services. What makes it even more complicated, there are many technologies from different generations, providing the same services, so there is always more than one way to provide a single function. Additionally some of the past services converge together in order to create some more complex and comprehensive functionalities. Those advanced services are also often put on a new, common communication platform, like in Next Generation Networks (NGN). There is also some attempt to define private network and its influence on public infrastructure. In order to research all those issues, one should search for some simplifications in this complicated structure. Finding basic relations between the network elements and repeating phenomena might be essential by answering security questions.
3.1.
Overall Architecture
Public Network
3.1.1.
Public network is a complex organism consisting of many entities and elements. However, its primary sense of being is a platform providing some sort of services. Because of that, almost every subject that is a part of public network may be classified either as a client or provider. Client uses the services, while provider delivers them. Of course both entities have to be connected together through some kind of network. As a result one could say that public network is a set of interconnected clients and providers. The example of such an architecture is shown in Figure 7. Such a client-provider model resembles well known client-server model, but only to some extent. While client-server concept emphasizes information exchange mechanisms and
Figure 7: Public network abstract architecture Pawel Lawecki Page 13 VoIP Security in Public Networks
Architecture
3.1. Overall Architecture
communication between two end-points, client-provider is much more general and abstract. As shown in Figure 7, it considers economical and logical aspect of the relationship between client and provider. Basic objective of the client is to use services, whereas provider is a company, so its primary motivation is to earn money. One should also remark that the client-provider model may be used only to describe a relationship between two subjects. However, any subject may have relationships with many others. That is why a client may at the same time also be a provider. The image on Figure 7 and especially the cloud with the Internet, is very simplified, but helps understanding basic relationships occurring in the public network. There is also some specification of what is a private network in the figure. It is a part of the client's (but can also be a part of provider's) network that is managed by the client and is not freely available from the public network. Most of the time it is not even fully visible from the outside. There are many types of public networks. In the next sub chapter a few examples will be given, but of course the most important type of the network in this thesis has to be a public IP network. As the name states VoIP is transported and offered in IP networks. In Figure 8 a general structure of a public IP based network is shown. As in case of an abstract example from Figure 7 public network consists of Internet Service Providers (ISPs) that offer services to users, users and some interconnecting network. Many different services may be offered in public IP network WWW, Instant Messaging, email, VoIP, etc.
Figure 8: Public IP network general architecture In this case an interconnecting network is the Internet. Actually the Internet is very often identified with a public IP network itself. We say that services are offered in the Internet, not through it. It is true from the client's perspective. Additionally, the Internet is often described as a network of networks, what in practice means that each ISP's network or client, when connected to the Internet is also a part of it. Pawel Lawecki Page 14 VoIP Security in Public Networks
Architecture
In the thesis an assumption will be made that public network indeed is equivalent to the Internet, as this is the biggest and most spread IP public network. However, it does not always have to be true. There are also public IP-based networks that are connected to the Internet, in order to provide services like VoIP or IPTV (television over IP). But at the same time they are protected from the Internet with security technologies, so it is not the same scenario as by direct connection. One could even say that it has some properties of a private network connected to the Internet. Moreover, not every public network has to be connected to the Internet 1. That is why one should not exclude the possibility of other public IP networks that are competitive to the Internet emerging in future. However any security analysis that worked out for the Internet will also hold for any other global IP based network. Just as in the abstract model, private (enterprise) network is defined as a network which is not visible in the public network. This is usually an internal network of a client or private company2. It also might be some part of the provider's network that is not visible from the outside. From the logical point of view, the difference between home, university or company network is just quantitative. There is simply a scale difference. And that is why there are services that are offered typically for home-users and other for big company-networks. There is, however, no logical obstacle against offering the same service for both, company and home users. The only mechanism working against it is the economical supply and demand law - single clients pay less, so they get worse and less complex services. Because of that, in this thesis the clients will not be differentiated as for size and it will be considered as an internal property of a private network. There will be, however, some distinction between different types of clients introduced later, but only regarding security requirement issue. Moreover, due to the essential role of providers in public network, structure and architecture of their internal network will be considered, even though it probably should be classified as private.
3.1.2.
Access & Service Provider
As already mentioned, VoIP has a much more open and distributed architecture than the traditional telephony. Different providers may offer different elements of the telephony functionalities. In order to get the full service bundle, it might be necessary to use services of many different providers. There are many possibilities, some providers may be responsible for the access infrastructure, others for voice connections, voicemail, message delivery, etc. Thanks to the open, functionally distributed architecture, a user might choose the best service from the best provider. Solving security problems in such a complex system might be very complicated, if one does not find any general provider classification. Probably the best mean to compare providers is the OSI Model that distributes different network functionalities on different Model Layers. One could define the service suppliers, regarding the OSI Layers, on which their service is running. In this work two3 categories of providers are distinguished:
1 In case of VoIP, considering IP-based networks that are not connected to the Internet does not make any sense. Elements of public network need to be interconnected via some globally widespread network (Internet is the only one so far), if one wants to provide services similar to the PSTN. Otherwise one could call only clients from the same network. A single private network can actually span more than one location. In such a case it uses some specific service from a public operator, like leased lines, or a technology like Virtual Private Network (VPN). There is also a concept of putting the whole private network into the public network, which is called CENTREX. Such issues of complicated relationships between public and private network will not be considered here. One could mention one more type of provider Content Provider that offers content based services on top of communication services like VoIP and PSTN. Telephony content provider category includes /continued on page 16
Pawel Lawecki
Page 15
Architecture

providers offering access to public network (the Internet) are called Access Providers, providers offering services in public network are called Service Providers,
Certainly such naming is not fully accurate, since network access is also a service provided to the user. Nonetheless it is offered in the physical world, while the services offered by the Service Provider are purely virtual and need some network platform to occur. Access is then treated not as a physical service, but as a necessary condition, for virtual service to occur. Figure 9 shows how the functionalities of both providers are distributed in OSI Model. Such a classification is not only valid for VoIP, but for any other Internet service. Access provider is responsible for the delivery of IP packets to the destination so it resides in the three bottom layers. Usually some telecommunication provider is responsible for this role. It might offer for example DSL, or broadband cable connection. Access provider owns many devices like switches (OSI L2) and routers (L3) and some medium interconnecting them (L1). The cabling (or for example some wireless technology) and necessary infrastructure are brought to the end user. On the other side of the network Access provider has a connection to the Internet, where it handles forwarding user data to public network.
Service provider resides on the higher OSI layers. It is responsible for exchanging data necessary for the service to occur. A typical VoIP provider is usually connected to the Internet and its services are offered to any user, independently of his/her geographical location. Its infrastructure consists of VoIP servers necessary for connection set up, and devices like authentication and billing servers, client databases, etc. In order to establish end-to-end relation between client and server, service provider certainly needs the complete protocol stack. However, lower layers are served by another entity and service provider may focus on the application layers, where the service is controlled. Of course service and access are just two basic provider types. Theoretically functionality of each layer (or even more distributed) might be handled by another provider. It is highly
services like for example information numbers with forecasts, timetables, stock market data, horoscope, etc.; human services like counseling or (usually very profitable to providers) adult content lines; or interactive services like gaming. Division of the system into Subscriber, Carrier (Access) Provider, Service Provider and Content Provider is described by some sources as a business chain [17]. Content providers will actually be mentioned at the end of the thesis, in chapter 10.Public Security Platform.
Figure 9: Access and service providers in OSI layers (partially [18])
Pawel Lawecki
Page 16
Architecture
impractical and probably never applied, but shows the opportunities of the open architecture and vertical function partition. On the other hand, both service and access might be offered by a single provider. It is exactly how the traditional PSTN telephony works. A single provider is the owner of the cabling, communication devices in between and telephone exchange. Figure 10 shows a general architecture of a public communication network with some technology examples. As already described, the end user connects to service provider and other networks via access provider's infrastructure. Service provider itself also has to use some access connection infrastructure in order to exist in the Internet. As one can see from the technology examples, this categorization and architecture is valid not only for telephony, but also television, radio and others. Actually public network may consist of many independent and not interconnected networks, where each of them provides some service. Some of them are broadcast networks (TV, or radio), some are used for communication (GSM, PSTN) while others are interactive (Internet). As described in the previous chapter however, NGN networks try to combine all of those services in a single network and put it on a single communication platform.
Figure 10: General architecture of public network with technology examples One should also emphasize the importance of access providers. They interconnect each subject existing in a public network. Thanks to them, there is a link between service providers and users. From the security point of view, most of the dangers come from anonymous users, so the role of access providers might be crucial by identifying and eliminating them from the network.
3.1.3.
Consequences
The PSTN supported only a closed architecture, where both access and service were provided by a single entity. In VoIP, as it has already been mentioned, two approaches are possible. In Figure 11 both architectures are shown. A VoIP provider may be at the same time also a provider granting access network1, just as in the PSTN. Such an approach is called in this work a Combined Architecture (1). Another possibility is a strictly Open Architecture (2), where
1 It might be the same provider but also two providers who very closely cooperate. Both are usually encountered in NGN platforms.
Pawel Lawecki
Page 17
Architecture
VoIP service provider is connected to the Internet and does not own its an access infrastructure. There are many consequences of the open telephony architecture (it is shown with more details in Figure 12). First of all, any service provider is visible in the whole public network. It means that services are geographically independent. Once the access has been provided the user may use the most attractive offer, which of course boosts the competition and lowers prices. However, while such a network has an outstanding connectivity, it is also vulnerable to the attacks from all possible locations of the Internet. Another, serious consequence to VoIP is that access provider usually is not aware, what kind of traffic is transported through its network. It means no QoS may be provided, as the packets requiring low delay are not differentiated from others. What is even more critical is the lack of communication between the providers. In traditional PSTN and by combined approach it is much easier to control security inside the network. If any service abuse should happen, the provider has the user access information, so it is easier to identify, or at least locate the hacker. But since access and service providers do not cooperate with one another, the problem gets complicated. Unfortunately the security of the network suffers because of the open architecture, as the VoIP Service Provider usually does not know, where its users or attackers come from. Last, but not least there are many access scenarios and many technologies providing Internet connectivity are available. Each of them has different properties, vulnerabilities and threats. Depending on the access technology that is used, security issues are different. That is why in the next paragraph there is a closer investigation in the architecture of different access scenarios.
Figure 11: Telephony consequences
open
architecture
3.2.
Access Networks
DSL WiMAX yes yes Cable modem no partially yes
Mobility Shared medium
no no
Other ISDN, WiFi, Examples GPRS UMTS Table 2: Basic features of the most typical access scenarios
1
There are tens, if not hundreds, access technologies available. Each of them is in some way different than the others and unique. It is, however, useless to consider all of them. Most technologies have similar properties and differ only in technical details. There are only a few technical qualities that might be considered important from the security point of view and they have been presented in Table 21. Together with the properties, three different examples of access networks are also presented there.
Mobility in WiMAX is only possible with Standard IEEE 802.16e, the basic standard offers only nomadicity.
Pawel Lawecki
Page 18
Architecture
3.2. Access Networks
First of all there is a shared medium issue. There are many tools enabling traffic eavesdropping and interception in local area networks, where many nodes use the same access medium like a cable in fixed networks, or radio frequency in wireless ones. If a given access technology operates via such a local access network, with shared medium, then it is vulnerable to all kinds of malicious attacks. Second important issue is mobility. Providing mobility means that the user, equipped with some terminal, may connect to the network in any place it is available and there will be no additional configuration necessary. Additionally, in case of a wireless network, communication should not be broken, even if the terminal is moving (signal handover between base stations). In such an environment it is extremely difficult to provide some security requirements. No user is fixed to a single geographical position, so it is not easy to locate or identify him/her.
Figure 12: Combined Architecture and Open Architecture with access networks One could also distinguish another property, which is amount of time available for an attacker. Networks with constant connection, like for example university networks, are connected to the Internet all the time. This gives a hacker an unlimited amount of time to perform an attack. However, from the point of view of security, it really does not matter, if the user is connected to the Internet for one hour, or is connected 24 hours a day. According to different sources [19]: Twenty minutes is how long it takes for an unprotected PC to be compromised when connected to the Internet.... Because of that, time and constant connection issue was not shown in the table and is not be considered in the following chapters. In the following paragraphs three most typical access technologies are described. As it is shown in Figure 121 these are: DSL, Broadband Cable and WiMAX. Each of them represents different combination of two properties mobility and shared medium, as shown in the table. Additionally all the mentioned differences between VoIP combined architecture (1) and open architecture (2) are shown in detail.
In the figure central elements of access and service provider are specified Authentication server for access and VoIP server for service. It is shown this way, as those elements are most important regarding VoIP security. However, both service and access provider possess an authentication server. More detailed structures are given in Figures 16 and 17, in this chapter.
Pawel Lawecki
Page 19
Architecture
3.2.1.
DSL
Digital Subscriber Line (DSL) is one of the quickest developing Internet access technologies. To be precise, it is a family of technologies that includes for example Asymmetric DSL (ADSL), Symmetric DSL (SDSL), High Data Rate DSL (HDSL), Very-high-bit-rate Digital Subscriber Line (VDSL)1, etc. Differences between those technologies will not be considered here. Instead, some basic and common architecture elements have been found and presented in Figure 13. [20] [21] [22] As one can see the DSL does not disable the traditional PSTN telephony. Both technologies coexist thanks to the frequency splitting technique. The simple device, called splitter, filters away the lowest 4kHz of the bandwidth, where the PSTN services reside, for the IP network output and higher frequencies for the traditional telephony output (otherwise DSL channel would interfere with the PSTN channels). Thanks to it, both signals IP and PSTN, travel on the same cabling. The process is repeated at the access provider's side - the low PSTN frequencies are connected to the PSTN traditional telephone exchange, while the DSL data is processed in the IP infrastructure.
Figure 13: DSL access architecture There is another device besides the splitter that needs to be installed by the end user. Apart from filtering the lower frequencies one needs to translate the DSL signaling to some Local Area Network (LAN) protocol, usually Ethernet. This function is performed by a DSL modem that is located behind the splitter's high frequency port. The DSL modem very often contains also some router capabilities, what enables the user connection of more than one end devices. In case of users demanding only IP or only PSTN service, frequency splitter is not necessary, but modem for IP is still required. On the access provider's side the role of the modem is played by the DSL Access Multiplexer (DSLAM). This device translates the DSL signaling protocols into some IP Metropolitan Area Network (MAN), or Wide Area Network (WAN) protocols. DSLAM is usually located quite close to the end user (a few kilometers).
1 VDSL is currently deployed as an access technology for IPTV.
Pawel Lawecki
Page 20
Architecture
In form of an IP traffic the signal travels through the access provider's transport network. It goes through higher and higher levels of traffic aggregation, to finally reach the Broadband Remote Access Server (BRAS). BRAS is a central device of the Access Provider's infrastructure. It performs many critical functions, like authentication, billing and decides if the traffic should be forwarded to the Internet. A firewall that is between the BRAS and public network, provides some basic protection. DSL access network does not provide mobility and has no medium shared by many users. Each end user (subscriber line) is connected separately to the DSLAM. It is a solution inherited from the PSTN, where each user is separately connected to the PSTN concentrator. This allows us to conclude that DSL technology should not be vulnerable to the attacks in the local network.
3.2.2.
Broadband Cable
Another very popular access scenario is provided via cable TV infrastructure broadband cable access. In some features it is quite similar to the DSL. It also uses an already existing platform, that was meant for another service, to deliver Internet access. However, the used signal splitting technique and internal architecture differ. [20] [21] [22] Standard television signal does not need to be separated from the IP-based data, if one simply wants to plug the cable in the TV. For the distribution of the IP traffic usually two ordinary television channels are reserved. One for upstream (5 to 42 MHz range) and one for downstream (50 to 750 MHz) bandwidth. Unlike in DSL, IP signal does not have to be split from TV signal. Some of the channels reserved for IP are simply not usable for TV and will be not recognized, but they do not interfere with other channels.
Figure 14: Broadband cable access architecture Just as shown in Figure 14, while connecting a home Ethernet network to the cable network one needs to deploy a cable modem. The cable modem isolates the two mentioned television channels and translates the cable TV signaling into Ethernet protocols. As in DSL, the modem might contain some router functionalities. Pawel Lawecki Page 21 VoIP Security in Public Networks
Architecture
A single downstream 6 MHz television channel can carry up to 27 Mbps of downstream data. Upstream channels can deliver 500 Kbps to 10 Mbps from home and business end-users. This upstream and downstream bandwidth is shared by other data subscribers connected to the same cable network segment, which according to the sources [20] used to be 500 to 2000 homes on a single network. However, as the users demand for bandwidth grows, fiber goes closer to the end user and less users are nowadays sharing the same local network (probably less than 100). Still the shared medium exists, but it could have not been different, as the cable access platform was meant for a broadcasted service. Originally all the users were supposed to receive the same television signal. Because of that, there are no separate connections between end-users and the access network. The IP signal is multiplexed and merged on a single television channel that causes necessity to share the bandwidth. Architecture derived from such a broadcasted network has another consequence on the local access network. The local access network is actually semi-common only the downstream traffic is visible at all end stations of a given segment. Upstream traffic, going from the end user to the Internet, is multiplexed and forwarded to subsequent traffic aggregation layers and is not visible to the other users. Traffic from the whole network segment is connected to the access provider via an optic fibre. Many segments are multiplexed and aggregated and connected to a central element of a broadband cable access architecture Cable Modem Termination System (CMTS). Of course in between IP signal needs to be demultiplexed (or multiplexed in the downstream direction) from the overall cable TV channel. Just as BRAS in DSL this element is responsible for the authentication, billing system and traffic allowance. CMTS is also connected to the Internet, with a firewall in between. The original television infrastructure is not very complex. There has to be some broadcasting unit that transmits the signals of different TV channels. This infrastructure should probably be connected in a similar place, like BRAS. The bottom line of Broadband Cable access is, that the security is probably worse than in DSL, since the users may see the downstream. Even though it is encrypted, it creates some potential vulnerabilities.
3.2.3.
WiMAX
The last of the mentioned access scenarios is wireless. Worldwide Interoperability for Microwave Access (WiMAX) is one of many wireless network standards created in recent years. WiMAX together with other technologies, like for example Wi-Fi, or UMTS, complements the traditional offer of the fixed access providers. [21] [23] WiMAX (IEEE 802.16) has been chosen here as an exemplary wireless technology, as the solutions used in it are applied in many new technologies. For example it might be slower than Wi-Fi1 (IEEE 802.11), but it is much more stable. It is so, because Wi-Fi expects the network units to compete for the transfer medium (in this case, a radio frequency). It might lead to a situation, where different units, with different distance to the Access Point (AP) may start transmitting in parallel and block the network. WiMAX requires the subscriber to compete only for allowance into the network. Once let into the system, the subscriber receives a time slot and can use it for transmission with a certainty that no other station will interrupt. Of course there is a trade off. WiMAX is indeed more stable, but in some cases - with a small number of users might be actually slower. Additionally, WiMAX provides better mobility mechanisms than Wi-Fi, but worse than Universal Mobile Telecommunications System (UMTS) created in mobile networks.
1 It is actually not slower, but is expected that more users are connected to a single base station. Because of that, bandwidth reserved for one user is usually lower than in Wi-Fi.
Pawel Lawecki
Page 22
Architecture
The nature of the medium based on the radio frequency is that it may be accessed and is visible by everybody. It means that all stations hear, what the others transmit. Even though there is a time-slot based mechanism, the local access network is definitely common. The local access network is built from Base Stations (BS) that are responsible for communication between the Access Provider's core network and the end-users. There are many different devices that may connect to the network via BS - apart from traditional PCs, or access switches (that can connect whole networks) one can also use notebooks, mobile phones, PDAs, or any other equipment with a suitable network card. The example of such a network is shown in Figure 15. The signal from many Base Stations is aggregated on some switch (or switches) and forwarded to the central element of the WiMAX network - Access Control (WiMAX AC). AC, just as BRAS, or DSLAM is responsible for authentication and traffic allowance. Is connected to the Internet and hidden behind a firewall, as in previous examples.
Figure 15: WiMAX access architecture Unlike in DSL or Broadband cable the common local access network in WiMAX is not a remnant after generic technologies. The Internet access is not provided on an already existing infrastructure. Here, it is a consequence of ensuring mobility mechanism. One assumes that the end-devices will be moving and changing their geographical positions (Base Stations), so there is no way to supply a physically separate connection to them, as it was done in the PSTN.
3.3.
Provider Architecture
From the point of view of security there are two essential issues left that need to be considered. These are: architecture of the core network of access provider and service provider. In both cases there are many different elements possible, however, only the most relevant are presented.
Pawel Lawecki
Page 23
Architecture
3.3. Provider Architecture
3.3.1.
Access Provider
End users are connected to the access provider via its transport network, as it is shown in Figure 16. The transport network may be built on one of the different technologies mentioned and described in the last paragraph.
Figure 16: Access provider architecture The central part of the access provider's internal network and the element through which the whole traffic has to pass, is Authentication Server. It is just a common name for devices like DSLAM, CMTS and WiMAX AC. Authentication Server actually consists of additional devices like authenticator and AAA Server, as shown in the figure. Authenticator performs basic traffic allowance functions. Even though authenticator controls most of the administrative functions, some of them are performed on a logically separate device called Authentication, Authorization, Accounting (AAA) server. Authenticator is an executive part of all access processes, but information necessary to perform it are stored in AAA server1. Just as the name stands for, the AAA server stores the user's credential in order to authenticate, information about granted authorization rights and finally details about the number of credits, or time units the clients used. The last information is usually used at the end of the month in order to prepare billing information, by yet another application server. Another device, apart from the AAA server, that is connected to the Authenticator is a router. Router controls the traffic of packets. Depending on the Internet address it forwards the packet to the right destination. The router distributes the packets going outside and coming inside. Additionally, if there is a mobility to be provided, the router should be equipped in some Home Allocation (HA) mechanism that stores where the given end user (in which BS) is available. As in any other example, the infrastructure of the provider is separated from the Internet by a firewall that filters some of the unwanted traffic and provides a basic protection. Additionally on the figure there is some distinction of two mentioned VoIP service connections open architecture (2) and NGN-like approach (1). Depending on the type of a connection the VoIP service infrastructure will be either directly connected to the access provider, or will be located somewhere in the Internet.
3.3.2.
Service Provider
Figure 17 represents the core network of the Service Provider. The same two cases of direct
1 This architectural property is similar to IEEE 802.1x standard describing user allowance mechanisms to a wireless network.
Pawel Lawecki
Page 24
Architecture
(1), or indirect (2) connection of the end users to the service provider, are shown on the illustration. Between the network of a service provider and external networks there has to be a firewall. This firewall should only let through the VoIP traffic. However, sometimes it is really difficult to identify what is the VoIP traffic and what is not. While signaling protocols have some well defined ports on which they work, the data protocol RTP uses dynamic port allocation (generally ports 16384-32767). It is extremely complicated to keep control of all those ports and each time analyze, if an incoming transmission is voice related. Analysis is very time consuming and resource demanding, that is why firewall either blocks a port, or leaves it open.
Figure 17: VoIP service provider architecture There are fortunately two solutions for this problem. Either one uses a VoIP aware firewall that can read the control protocol packets and check - on which ports exactly will the RTP transmission take place, or one uses Session Border Controller (SBC). SBC is a device that solves the problem of VoIP firewall traversal without modifying or changing the firewall itself. Whole traffic pretending to be VoIP is being forwarded to SBC and analyzed there. SBC is also used as a solution to Network Address Translation (NAT) traversal problem. VoIP server is a device that plays the role of a telephone exchange in IP world. As its predecessor, it is responsible for setting up and receiving the calls and if necessary forwarding them in the right direction. As VoIP provides mobility, the VoIP server also has to store the location of each end user, which is done using registration mechanism (in order to know, where to forward a received call). Each VoIP client registers that he/she is available and has to notify the server under which IP it is available. Additionally VoIP server uses AAA server and billing system, as the access provider. The function of both units is exactly the same authenticating users, determining price plan and available services, finally storing the information about the used services and create the bill. The role of authenticator from the access scenario can be taken over by the VoIP server itself, AAA server, or be performed by yet another device. Everything depends on the chosen implementation. Apart from being connected to the Internet, where IP<->IP calls are created, the VoIP server has to be connected also to the PSTN networks. Of course in between, the existence of a gateway that translates VoIP signaling into PSTN signaling is necessary. There are two more specific functions that should be considered here. Firstly, it was already mentioned that VoIP requires some independent localization module for emergency calls. It may cooperate with GPS system, or any other that can locate the caller with a acceptable accuracy. Secondly, there is an issue of Lawful Interception (LI). In many countries all over the world, different government security agencies require some details about performed calls. It Pawel Lawecki Page 25 VoIP Security in Public Networks
Architecture
usually does not regard the content of the call, but some general information about the call: like calling and called party, duration, etc. This all has to be done by some independent LI system that usually mirrors the traffic that occurs between VoIP server and PSTN, or Internet and analyzes it on its own.
3.3.3.
VoIP Server - SIP Architecture
There are two VoIP signaling protocols that were already mentioned: SIP 1 and H.323. Both were created by international organizations as standards ready for application. H.323 was introduced earlier and thanks to it has probably more applications 2 than SIP. However, for the last few years Session Initiation Protocol has been gaining more and more interest from VoIP companies as a much more open, flexible and extensible protocol. Additionally, it is applied in many other fields, like Instant Messaging or even 3G mobile telephony (3rd Generation Partnership Project 3GPP). SIP and H.323 are not the only VoIP signaling protocols. There are many other standards created by single organizations and just for their use. Just to mention for example the well known Skype3, or Cisco's Skinny. Even though it is clear that each of the protocols has its pros and cons, their thorough investigation is not in the scope of this thesis. As mentioned on the beginning SIP is currently probably the most dynamic and advanced signaling protocol, therefore it has been chosen for this thesis to present security issues regarding VoIP. However, straight majority of the issues described in this thesis is independent from signaling protocol. SIP is a text-based and highly extensible protocol. It is also quite similar to other Internet protocols, like HTTP and SMTP. It is relatively simple, as it has only a few methods. SIP provides presence and mobility mechanisms. Almost every PSTN service may be offered on top of it, but also other Internet services. It is used in VoIP to initiate, modify or terminate user sessions. Depending on the considered signaling protocol, VoIP server from Figure 17 will be deployed differently. Figure 18 shows how it is structured in case of SIP. There are five elements of SIP architecture shown in the image [24] [6] [4]:
User Agent (UA) is the endpoint entity. It initiates and terminates sessions by exchanging requests and responses. User Agent is actually a UA Client, as it originates calls and UA Server, as it also listens for incoming calls. It may be both hardware and software based. Proxy Server is
Figure 18: VoIP server in SIP architecture

1
2 3
SIP is not only a VoIP signaling protocol. It is generally a protocol used for creating, modifying and terminating sessions with one or more participants. The application that is concerned in the session may be different than VoIP. This could be for example distribution of multimedia, multimedia conferences, distributed computer games, etc. Moreover in order to make VoIP communication possible other protocols are needed. RTP was already mentioned and is used for real-time transportation of data. Session Description Protocol (SDP) is another one, that is used together with SIP. It is used to describe encode capabilities of session participants. [4] It is difficult to state it precisely, since no market analysis concerning signaling protocol share is widely available. Skype is actually a name of the product - Skype client, and a name of the client's signaling protocol at the same time.
Pawel Lawecki
Page 26
Architecture
intermediary entity that acts as both server and client. It actually makes requests on behalf of other clients. A Proxy interprets messages and if necessary, rewrites them before forwarding. It keeps no session state.
Redirect Server is used by the client to find out new address of the called party. Server accepts a SIP request and maps the SIP address into new addresses and returns them to the client. Redirect Server simply redirects callers to other servers. Registrar a server that collect users' locations. It accepts SIP registration requests and updates its location database with the location of the user. A registered user may receive calls. Back-to-Back User Agent (B2BUA) it is a similar device to a Proxy Server, but has a tighter control of the call, it can for example disconnect a call or alter messages. Additionally it maintains a session state. It receives a request, processes it as a User Agent Server and (instead of simple forwarding as a Proxy Server) it generates requests as a User Agent Client.
The first of the mentioned elements User Agent is a part where the user resides, all other elements are functional elements of a VoIP server. Depending on the network implementation, not all of them have to be used. One could say that the Session Border Controller is a realization of B2BUA and is used by solving firewall or NAT traversal problem. Three other functional elements Proxy, Registrar and Redirect Server are usually standard logical entities of a SIP Server. Device that realizes most of the functionalities of a VoIP server, so indirectly also a telephone exchange. It has however one advantage over a telephone exchange - thanks to registering and redirection mechanisms it provides mobility. In order to communicate, elements of the Session Initiation Protocol architecture use request and respond commands. Some examples of those commands are shown in Table 3. More exact application of the commands and communication examples are given in chapter 8.Application Layer Analysis in context of vulnerability discussion.
Pawel Lawecki
Page 27
Architecture
Requests INVITE ACK BYE CANCEL OPTIONS REGISTER INFO Responses 100 180 200 300 301 302 400 401 403 408 480 481 482 500 600 603 604 606 Response types:
Description Initiates a call, changes call parameters (re-INVITE). Confirms a final response for INVITE. Terminates a call. Cancels searches and ringing. Queries the capabilities of the other side. Registers with the Location Service. Sends mid-session information that does not modify the session state. Description Trying Ringing OK Multiple choices Moved permanently Moved temporarily Bad request Unauthorized Forbidden Request time-out Temporarily unavailable Call/Transaction does not exist Loop detected Server error Busy everywhere Decline Does not exist anywhere Not acceptable Provisional (1xx) progress info, no transaction termination Final (2xx 6xx) final response, transaction termination
Response classes: 1xx Provisional, request received 2xx Success, request received, understood and accepted 3xx Redirection, further action needed to complete the request 4xx Client Error, bad syntax or cannot be fulfilled at this server 5xx Server Error, failed to fulfill a valid request Table 3: SIP request and respond commands [24]
Pawel Lawecki
Page 28
Security Analysis Considerations
4. Security Analysis Considerations
4.
Any security problem in a computer or telecommunication system is usually extremely complicated and requires special means. While combining functionalities, elements and structure of both worlds data and voice, VoIP unfortunately also inherits both problem spaces. That arises a question what methodology to use while trying to investigate the security problem of VoIP public networks.
4.1.
Available Approaches
There is no single worldwide set of rules or legislative mandate for information security. While law in many countries requires protection of stored data, it very seldom indicates how to protect information transmitted in IT system [25]. However, there are many standards, criteria and methodologies [26] used for security assessment in IT systems that are already worked out and proposed by different international bodies and organizations. As the presentation of all available security problem solution approaches is not in the scope of this work, only a few most distinctive examples are given below.
4.1.1.
ISO 17799
ISO 17799 [25] is a standard created by International Standard Organization (ISO) that is intended to be a single reference point for identifying and classification of security mechanisms. It is a global set of security standards that was inspired by independent standards from different countries and now starts to replace them. Among its predecessors are many well established and acknowledged references, like for example the British ITSEC, or American US TCSEC (also known as Orange Book). The newest version of the ISO 17799 standard was issued in 2005. The recommendations and controls described in the standard may be used to secure any network. Introducing all the ISO rules requires some enforcement body that could control if the standards are carried out. Network administrators may try to implement ISO 17799 on their own, while securing the part of network under their supervision. Unfortunately ISO 17799 is not a freely available standard and it has to be purchased. While it is not a problem for owners of big networks or providers, most of the small, low-budget networks will not buy any security standard.
4.1.2.
X.805
X.805 [27] [28] methodology is used for IT network risk assessment. It is also a standard established by an international organization, International Telecommunication Union (ITU). X.805 is a security tool that divides network analysis into layers, planes and dimensions. Such an approach ensures investigating every single security issue. In Figure 19 one can see how that method works. Network components are divided into three layers: applications, services and infrastructure. Each layer is further composed of three security planes: end user, control/signaling and management. And finally, to such a set of nine security perspectives, different security requirements may be applied. In the figure there are eight main requirements shown and they are called security dimensions. So in total there are 72 security perspectives that should give a complete overview of all relevant risks in any network. X.805 risk assessment tool is a very detailed and complicated mechanism. It might be a very powerful solution for network administrators.
Pawel Lawecki
Page 29
4.1. Available Approaches
Figure 19: ITU-T X.805: Communications [28]
Security
Architecture
for
Systems
Providing
End-to-End
4.1.3.
NIST Risk Management Guide
The last presented methodology differentiates between three scenarios risk management, risk assessment and risk mitigation and it presents more general approach to the security problem. Risk Management Guide was created by the National Institute of Standards and Technology (NIST) in the U.S. Department of Commerce. [29] Risk management approach is usually used in institutions with a centralized structure. Members of the personnel take on different roles in order to participate in the security management process. Public networks consist of many institutions and independent users from different countries. It is a very complicated issue to provide risk management to such a platform. Risk assessment is the part, where the authors of the NIST Risk Management Guide put the biggest emphasis. It allows determining the extent of potential threats. This methodology is divided into nine main steps: system characterization, threat identification, vulnerability identification, control analysis, likelihood determination, impact analysis, risk determination, control recommendations and results documentation. It may be used as an initial phase of solving a security problem. One has to assess the risk first and come up with security solutions and then try to manage the already secure system and make sure all the security policies are enforced. Risk mitigation approach may be used in enterprises or in provider networks. This approach involves prioritizing, evaluating and implementing security solutions recommended in risk assessment, in order to minimize the risks. In simple words, risk mitigation is a process of deciding which security solutions should be introduced first depending on the cost, complexity, priority, risk of attack, severity of attack, etc.
4.2.
Chosen Approach
The three presented security approaches are used mostly for centralized organizations. Problem of any public network with open architecture is that it consists of many independent elements. While one can assess risks and threats for each element of such a network, no widespread security management policy is possible. There is no single administering and Pawel Lawecki Page 30 VoIP Security in Public Networks
4.2. Chosen Approach
enforcement body. The only thing international society can do is to create security recommendations and hope that they will be implemented. At the end, however, each administrator cares about security on its own. This was definitely not a problem in a much more closed architectures, as in the PSTN. Additionally, the detailed structure of public network is not specified and implementations are different for every service provider. One can only cover architecture specific topics and try to distinguish some general differences like between open and combined architecture (Architecture chapter), but certainly not the issues specific to implementation. General architecture from Figure 17 together with some examples of access scenarios may only be considered. Specifying VoIP architecture in a more detailed way would mean going into the implementation world and would be not feasible in the thesis. Therefore no detailed and precise method (like ISO 17799 or X.805) may be used. One needs some abstract rules of conduct that may be applied to different types of architectural solutions. Even though risk assessment proposed by NIST seems to be the best option for VoIP public network security problem, it is still too complicated and was thought for organizations (or in the best case - centralized architectures) in the first place. The approach chosen for public network VoIP security assessment in this Thesis, uses some of the methods mentioned in the previous paragraphs. At the same time, however, tries to stay as simple and intuitive as possible. In Figure 20 a model of security guideline assumed in this Thesis is shown. It uses some steps from NIST Risk Assessment [29] and some from Edward Amoroso's basic computer security issues [30]. While the first source proposed nine mentioned steps, Amoroso believes any security problem can be divided into three issues: - threat that may be present in computer (or telecommunication) system, - vulnerability some unfortunate characteristic of a system that makes it possible for a threat to potentially occur, - attack action taken by some malicious intruder that involves exploitation of certain vulnerabilities in order to cause an existing threat to occur.
Security assessment approach chosen for the public network VoIP problem is somewhere between those two mentioned models. First step of the assessment is security requirements declaration. It defines the expectations that are required from the system and by this also gives some system characterization. In the process of security requirements different criteria may be used. One may apply the security dimensions from the X.805 methodology, or build analysis on the famous security triad Confidentiality, Integrity, Availability (CIA). Moreover, the requirements may be prioritized, in order to specify which are most relevant. Threat identification should determine how the defined security requirements may be compromised. There are also many realizations of this step, but probably the best approach should regard the threat consequences. This way threat identification is a logical outcome of security requirements definition. One declares first, what should be provided in the system and then, what could go wrong. First, what one expects from the system, then what he/she does not want to occur. The equence of the threats may be prioritized and by this it is equivalent to impact analysis (first threat is most unwanted; second is very unwanted, but not as much as the first one; etc.). In both mentioned security guidelines (NIST & Amaroso), vulnerabilities and attacks are Pawel Lawecki Page 31 VoIP Security in Public Networks
Figure 20: Used assessment approach
security
4.2. Chosen Approach
considered separately. First some system weakness is described and then an action that could exploit it, is pondered. For the sake of simplicity, however, one could consider both issues together. A threat may be realized by an attack technique applied to a system vulnerability. A weakness that cannot be exploited by some technique is not a weakness. At the same time we do not care if somebody already performed the attack (Amaroso's action). If a vulnerability may be used with some technique, then we assume somebody will exploit it rather sooner than later. In public network, with its open and distributed architecture, the probability of any event related to vulnerability exploiting is always big. Additional issue considers origin of a vulnerability. There are two options possible. Either it is a VoIP fault application programming, protocol failing, configuration error, etc.; or the vulnerability is related with some underlying technology. Because of different structures and architectures both origins should be considered separately. Finally, as requirements are specified, threats that may compromise them are determined, and vulnerabilities on which some attack technique may be used are identified one can propose some security solutions. Most important issues may be declared and recommendations given.
Pawel Lawecki
Page 32
Security Requirements Analysis
5. Security Requirements Analysis
5.
As described in one of the previous chapters risk assessment of Voice over IP in public networks should start with analysis [31] [32] [33] of security expectations. One should state what requirements are imposed on the system. Of course before such an analysis may be performed, definitions of the basic and most widespread security requirements should be given. Some special issues concerning VoIP also need to be mentioned. Additionally, analysis of the subjects and roles appearing in the system has to be considered.
5.1.
General Requirements
Confidentiality, Integrity, Availability
5.1.1.
There are many different ways to classify the security requirements. One of them is the CIA1 triad, which concerns three most basic security problems Confidentiality, Integrity and Availability. These three issues describe properties of the communication process that happens between two parties. They are usually also considered superior requirements and all the others, mentioned in the following sub chapters are just requirements that help to meet those three major ones, by covering more specific problems. CIA are basic system security requirements, but it does not mean they are simple. There are many issues comprised in each of those properties. There is no common, agreed definition of each of those three and different sources may give different descriptions. Below, definitions of CIA requirements that are used in this work, are given. Confidentiality is usually understood as: restrictions on the accessibility and dissemination of information [32]. Which in case of VoIP (or generally telephony) means limited access to the information exchanged between two or more communication end-points. It is usually accomplished by encryption of the transmitted information. Confidentiality may regard both signaling and content. Integrity usually regards insertion, deletion or modification of information. In VoIP telephony two integrity issues appear data and signaling. Data integrity regards the exchanged content and signaling integrity considers all the protocol information necessary for transmission handling. Compromising signaling integrity may result in compromising almost every other security requirement. That is why the correctness, completeness, wholeness, soundness and compliance with the intention of the creators of the data [32] has to be ensured. Availability is one of the most important security requirements that needs to be ensured. If the service is not available most of the time, the technology will not be considered feasible, reliable and trustworthy by the users. The availability of a system is usually measured in a time unit - system's uptime. In traditional telephony this uptime is at least 99,999%. That means that the network is unavailable for service approximately 5 minutes per year [34]. Providing such a low downtime on an IP based platform is an extremely challenging problem. If availability is not ensured after all, then the system suffers degradation or interruption in its service to the customer as a consequence of failures of one or more of its parts [32]. Since VoIP requires a real-time transmission, already lowered quality may make the conversation impossible to be carried out.
5.1.2.
Authentication, Authorization, Accounting
While CIA requirements describe the properties of a communication process, the AAA regards
1 CIA mentioned in this thesis never regards Central Intelligence Agency, so the US secret service, but as explained it is a shortcut for a three security requirements: Confidentiality, Integrity and Availability.
Pawel Lawecki
Page 33
5.1. General Requirements
mostly user-system interaction. It stands for Authentication, Authorization and Accounting. All the three operations where already mentioned by provider's infrastructure description in the Architecture chapter. The AAA requirements are also complicated, but not so ambiguous as CIA. Authentication regards checking identity. There are many possible system subjects that may be authenticated. It may be the provider, end-user, or any other intermediate device. Because of that there are two basic types of authentication in VoIP:
end-to-end, where only the communication end points authenticate to one another, devices in between, or provider do not take part in the process and they are not aware of end-users identity, as most of the communication details are hidden, hop-to-hop, which is safer and easier to implement, as devices in between also authenticate the users and one another and have access to all the communication details. However, there is an issue of trusting those devices, as we share our authentication information with them.
Authentication is necessary to correctly set up the communication between end-points. It usually includes identification of the users (and/or providers and/or intermediate devices) and verifying the integrity of messages containing authentication information. This security requirement is very complex and it is currently one of the most important issues of VoIP security because of that it will be considered in detail in the final chapter. Once the end-user has been identified, another action is necessary to be done. His/her rights in the system have to be determined. Authorization process is necessary to check if a user (or some administrator) is allowed to perform a requested operation or access requested data. For example, it is used by providers in VoIP authorization, to find out what tariff plan should be used for a given user, what data may be accessed by him/her, etc. It is also a crucial process by accessing VoIP server (IP-PBX). Unauthorized access and modification of configuration data may result in compromising many other security requirements. Accounting regards the activity, practice, or profession of maintaining the business records of a person or organization and preparing forms and reports for tax or other financial purposes [33]. It is a process necessary for creating billing invoices for clients1. Because of that it is a very important issue for the provider as it wants to be paid for the service; and for the client, as he/she does not want to pay more than necessary. All three security requirements are necessary for the provider and they are usually provided in a AAA server. However authentication is a much more complex issue and appears in many other relations, not only client-provider.
5.1.3.
Privacy, Non-repudiation, Traffic Analysis
As already said, there are many other ways to consider security expectations. CIA & AAA is one of the possible approaches. Another one, could be for example Parkerian Hexad [36], which adds three additional issues to the CIA security triad: Authenticity, Utility and Possession. While the first one is synonymous with authentication, two others add some new properties. Utility regards usefulness of the information if the authorized receiver of the message is able to use it (for example decryption key might have been lost and even though information is safe, it cannot be used). Possession issue considers ownership and control of the information (if for example some attacker stole a password and is not able to use it, he/she still compromised the ownership of the password).
1 Actually what is called accounting here is a rather complicated process [35] including many steps: collection of parameters (collection of data necessary for charging), tariffing (rules on how to map money to the different parameters), charging (binding between collected data and tariffs), billing (creating a bill for the customer) and accounting (settlement between the involved operators). All five mentioned mechanisms for the sake of simplicity of the thesis will be called accounting.
Pawel Lawecki
Page 34
5.1. General Requirements
Yet different issues are considered in the RAS properties Reliability, Availability and Serviceability. The RAS properties were actually created as design attributes to ensure feasibility of the system, but they could still be considered as security requirements. While considering utility and possession issues in VoIP telephony does not make much sense, as this is a real-time transmission and a lost or stolen key will simply start key exchange from the beginning, there are some other issues worth investigating. Some of them could be supplementary to the mentioned CIA and AAA requirements and cover more possible problems. First of those additional expectations is privacy. Users always assume that the personal information they are sharing with a VoIP provider (or simply set it in their VoIP client software or hardware) will not be shared with unauthorized subjects. It includes information about personal details, but also about our number, geographical location, conversation details, availability status, etc. Non-repudiation as a general security requirement means the inability to deny the integrity and authenticity of a document [32]. In VoIP telephony it would mean that none of the participants of a transmission is able to deny the fact of taking part in it. It may be used for example by complaints to some institution about its services (via VoIP telephony), if it tried to deny that we used it. Or the other way around, if the client does not want to pay and the provider can prove that the service was used. Non-repudiation means that there is always a proof of involvement. Last of the additional issues - traffic analysis is very much connected to the privacy problem. One could even say that traffic analysis issue depends on the privacy definition. Some information may be deduced from the analysis of traffic, if we have access to it. As most of the IP networks (access and transport) contain a shared medium, other users can see our traffic and analyze it. Only from the amount of sent packets one can deduce if some transmission occurs. Normally information that the transmission occurred is not considered private, it is merely some general detail that may be concluded. However, sometimes some really private details may be revealed just from the traffic analysis (for example geographical location). Additional property of security requirements is that the relations between them are very complex. Compromising some of them may result in breaching many others. It means that some security requirements are necessary to provide some others. One needs to authenticate before providing authorization first find out who you are talking to, then determine his/her rights in the system.
5.2.
Legislative Issues
General Telecommunication Issues
5.2.1.
There are two general telecommunication issues. First of all, any communication system is expected to meet the criteria of multi-party freedom model [37], where user can move fluently from role-to-role, including: initiating contact, joining communication in progress, accepting contact, terminating communication in progress and refusing contact. Multi-party freedom is a practical and implicit operating requirement for VoIP telephony. Secondly there is a basic social responsibility model [37] that is also expected to work in any VoIP system. The model determines what should be denied, tolerated or permitted by looking to intention and impact of a person's conduct. It may mean, for example that an intentional and harmful action, like interrupting a communication system is justified. It is usually a case, if it serves some other, more important social requirement, like for example aiding in a rescue, or preventing a disaster. The background of this model is based on concepts of mens rea and actus reus - used in criminal law.
Pawel Lawecki
Page 35
5.2. Legislative Issues
Last but not least, most developed countries legally require data privacy and protection. In the United States this is provided by Electronic Communication Privacy Act of 1984, where ... the provisions for access, use, disclosure, interception and privacy protections of electronic communications [38] is set out. ECPA prohibits unlawful access and certain disclosures of communication contents. Additionally, the law prevents government entities from requiring disclosure of electronic communications from a provider without proper procedure [38]. Other communication privacy acts include for example [39] EU Telecommunications Privacy Directive (2002) or Commonwealth Model Privacy Act (2002). All examples obligates providers to ensure user data privacy and prevent its disclosure.
5.2.2.
Emergency Calls
Emergency call requirement is a special security issue imposed on VoIP providers by the law (in most countries, where VoIP achieved considerable market position). It demands from VoIP providers that emergency task forces (usually Public Safety Answering Points PSAP) are provided with the call back number and geographical location information of the caller [40]. This enables them to react to an emergency call and find the user that is in need of help. It is, however, just the most typical emergency call, but there are other types. In total there are three classifications of emergency calls [41]:

Citizen to Authority for example, the mentioned issue: VoIP emergency call, Authority to Authority for example: communication between emergency personnel, Authority to Citizen for example: broadcast to users for natural disaster warning, based on their geographical location.
Each of those call types should be served in a VoIP network, with a higher priority than this of the regular call, according to the social responsibility issue. Unfortunately, the problem gets really complicated in the open VoIP architecture. First of all, the access provider is not VoIP aware. It does not distinguish between voice and data, much less it can provide priority to an emergency call. Secondly not all access technologies are location aware and VoIP mobility makes the clients constantly able to move. While it could be theoretically possible to determine location of a user connected via broadband cable or DSL, WiMAX causes much more problems. Last, but not least, even if the access provider knew the client's location, there is no communication between him and the service provider anyway. Additionally, quite often the users are connected to a private network that is hidden behind a proxy. This makes it impossible to find out which user performed an emergency call, since nothing behind the proxy is visible from the public network and the proxy itself seems to be the communication end-point. Because of those issues solving emergency calls problem with pure VoIP, or VoIP related applications is extremely difficult. Additional technologies have to be used in order to do it. This could include for example some satellite positioning system like American GPS, or European Galileo (the latter should be functional in a few years). All this makes emergency call issue extremely complicated and requires a complex law framework.
5.2.3.
Lawful Interception
Another lawfully enforced security requirement is the Lawful Interception (LI). Increasing amount of threats from organized criminal groups, or terrorist organizations convinced many countries to introduce lawful interception (mentioned in Figure 17, on page 25). It is a tool used to closely monitor the communication traffic of users. It obligates providers to make details about its users' communication available to a Law Enforcement Agency (LEA) [42].
Pawel Lawecki
Page 36
5.2. Legislative Issues
Details that should be shared with the LEA by the provider may differ from one jurisdiction to another, but the general properties stay the same. The LI should be totally transparent to the users and undetectable. There should be a management handover interface available for the LEA workers [43] and the service provided to other users should not be affected. In Figure 21 some general LI architecture is shown. Traffic is intercepted via mirroring port on a device between the VoIP provider and the outside world (Internet). The whole traffic should go through this device. Necessary information about transmission is stored in some data server and provided to the LEA, at its wish.
Figure 21: Lawful Interception principle
5.3.
System Requirements Definition
Declaring security requirements of a system is complicated, even if this is a very abstract one, like VoIP in public network. The problem is that the requirements are never as simple as the described general security requirements classes. They have to be stated and defined separately and then translated into general requirements. The best way to define system requirements is to find out what are its elements and declare security requirements for each of them separately. In case of VoIP public network these would simply be client and provider. One can consider security requirements in relation to those subjects, with awareness of their demands and this way define their expectations. Additionally one should remember that each subject cares most of all (or only) about its own security. Other subjects may even be assumed a source of a potential threat. Below, risk assessment for three different subjects provider and two different client types are presented. Security expectations for each subject are gathered in a few simple points. General security requirements that need to be considered by each of those points are also detailed. However, one should remember that some quite complicated relations between general security requirements already exist. Sometimes declaration of one security requirement implies another one. If an attacker performs a meaningful modification of packets (integrity violation) it usually means that confidentiality was compromised earlier. Compromised confidentiality usually results in violating privacy, since the attacker knows all the details of the conversation. Another example other way around, mentioning authorization may imply correct authentication was already performed. And many other examples could be given, what makes security requirement problem subjective to some extent, as it depends on the assumed, non-spoken context and intuitive understanding of some issues.
5.3.1.
Personal Client
There are two types of clients that are considered in the analysis. First of them is the personal client. One could say it is a regular VoIP user who wants to call his/her relatives or friends and pay as little as possible. In Table 4 most important security expectations of the personal client are defined. The Pawel Lawecki Page 37 VoIP Security in Public Networks
5.3. System Requirements Definition
sequence of the expectations reflects their priority. Obviously any priority may reflect only the feeling and understanding of the problem by the author and is subjective to some extent. However, even if the reader does not agree with the priority sequence, the defined expectations hold anyway.
Personal client wants: 1. to pay only for services he/she used and not more than he/she should (accounting, authorization, authentication, integrity of signaling) 2. to have a proof that he/she really used a service (non-repudiation) 3. to have a service on an acceptable level of usability (availability, integrity) 4. that the connection is really set up with a telephone number (or other identifier) that is shown in the device, not a different one regards being called and calling (authentication, integrity of signaling) 5. what he/she really says to be transmitted unmodified (integrity of data) 6. the conversation to be confidential and not eavesdropped (confidentiality of data) 7. his/her private information to be kept secret (privacy, authorization, authentication) 8. no unwanted calls (authentication, availability) 9. details about the conversation to be secret (traffic analysis, confidentiality of signaling)
Table 4: Personal client's main security expectations As already described the primary reason of shifting from the PSTN to VoIP is the cost of the service. Because of that this should probably also be the key security requirement that the accounting and other related mechanisms, like authorization, authentication, etc. work correctly (1). It means that client is not charged for a service he/she did not use. Once the client has been charged, the provider should also be able to prove that the service was really used, so it should have a safe and functional non-repudiation mechanisms (2). Once the economical requirements are met, one should ensure that the service exists, is usable and feasible (3). Once all the basic VoIP requirements are met, client looks at the reliability details. Because of that, connection should be set up with the chosen number, when the client is calling (4) and the device should always show the true number of the calling party (still 4). Content of the conversation should be transmitted unmodified (5). Even though personal client does not carry out any confidential conversations, where some significant information is exchanged, he/she still would not like the content of the conversation to be know to unauthorized persons (5). Of course also client's private information should not be freely available and should be restricted only to authorized personnel (6). No client enjoys unwanted SPam over Internet Telephony (SPIT) calls, especially automated ones, so some mechanism protecting against them should be available (7). Finally, some users might want to be able to hide details about their conversations and be certain that nobody knows with whom they talked (8).
5.3.2.
Business Client
Another example of client could be business user, who performs some official conversations, where confidential, or crucial data is exchanged. For such a user it is better if the service is not available at all than to have an unsafe service. Instead of VoIP he/she might look for some other service. Detailed security expectations of a business client are shown in Table 5. Certainly the first condition of providing confidentiality is knowing who are we talking to, or at least being sure it is really the number we called, or were called by (1). Next step is ensuring secrecy of the communication channel, so that nobody else may eavesdrop our conversation (2). Modifying content of the conversation is just as dangerous as eavesdropping, especially if Pawel Lawecki Page 38 VoIP Security in Public Networks
some trade negotiations are carried out, so one should provide appropriate mechanisms against it (3). Sometimes even the fact that a conversation took place may compromise a sensitive business transaction, so protection of the transmission details is necessary (4). Last but not least, business client wants his/her private information to be kept secret and not revealed as this is also a necessary requirement of a safe and reliable service (5). Once basic confidentiality mechanisms are provided, the business user might consider using the service (6). Of course then the cost and charging system also becomes an issue that is expected to work properly (7). Sometimes in business conversations proving that a call really took place, is needed and a proof of involvement should be possible to use (8). Finally, the business users also do not wish any unwanted SPIT calls, as it consumes time and blocks the number (9).
Business client wants: 1. that the connection is really set up with a telephone number (or other identifier) that is shown in the device, not a different one regards being called and calling (authentication, integrity of signaling) 2. the conversation to be confidential and not eavesdropped (confidentiality of data) 3. what he/she really says to be transmitted unmodified (integrity of data) 4. details about the conversation to be secret (traffic analysis, confidentiality of signaling) 5. his/her private information to be kept secret (privacy, authorization, authentication) 6. to have a service on an acceptable level of usability (availability, integrity) 7. to pay only for services he/she used and not more than he/she should (accounting, authorization, authentication, integrity of signaling) 8. to be able to prove that a conversation really took place (non-repudiation) 9. no unwanted calls (authentication, availability) Table 5: Business client's main security expectations
One should probably mention that the extent to which security requirements have to be met for both client classes is different. Availability expectations of personal client are much lower than these of business client, even though they have relatively smaller priority. Moreover negative effect of poor availability may be reduced by a very attractive service price. This means that the mentioned acceptable level of usability means something different for personal and business clients. Business expectations are much higher in every field. Generally it can be said that business client expects security on the level already known from the PSTN, while personal client can accept smaller security as a trade off for a smaller service price.
5.3.3.
Provider
Another key subject of the VoIP system is service provider. Its sense of being, as it is a company, is to earn money. In order to do it, provider offers services that are needed by clients and that they are wishing to pay for. Additionally provider has to meet some legislative requirements imposed on it by a government. All these issues are presented in Table 6. First and primary need of a provider is to have a service. One could say it is not true, since most of all provider should want to be paid, but most tariffing plans assume that the provider is payed after delivering a service (unless it is a flat rate). Because of that provider should most of all care about keeping service availability (1). Once the service is available provider should ensure charging system which is working correctly (2). If it will not be paid for the services, there is no sense to provide them. It also
Pawel Lawecki
Page 39
has to implement some authorization mechanisms, to know what price plan should be applied to which client, in order to be paid appropriate amount of money (in any case not less) (3). In order to correctly charge the clients, provider needs to authenticate users (4). Then the provider needs to be protected against clients' complaints and be always able to prove that a given service was really used (5).
Provider wants to: 1. have a service on an acceptable level of usability (availability, integrity) 2. be paid for the services it provided (accounting) 3. charge the right amount of credits for the service the client used, not some cheaper one (authorization, integrity of signaling) 4. know who is using the service in order to charge the right client (authentication) 5. be able to prove that the service was really used (non-repudiation) 6. be able to provide requirements) Provider has to: 7. be able to locate the caller and provide the call-back number, if an emergency number was dialed (emergency call) 8. provide mechanisms for supervision and inspection of the traffic to an appropriate federal agency (lawful interception) 9. protect client data and prevent its disclosure (privacy) special service properties, required by the client (client
Table 6: Provider's main security expectations Once all own expectations are met, provider should probably take care for the client's requirements and offer a service that will be satisfactory for the market (6), else the client will not want to use it and in consequence there will be no payment. However these requirements are not of essential meaning to the provider. Especially in cases where the client cannot easily detect that one of his/her requirements has been compromised. This regards issues like: endto-end authentication (authentication between users), privacy, secrecy, confidentiality. Provider tries to minimize its operational cost, so it will not provide service properties that are not absolutely necessary. Therefore there are some additional security expectations that are lawfully demanded from the provider. As said, provider has to ensure emergency call mechanisms (6), support lawful interception (7) and protect client's privacy (8).
5.4.
Security Requirements Summary
There are many security requirements, but from among them only a few most important ones have been chosen to describe VoIP in public networks: CIA requirements Confidentiality, Integrity, Availability; AAA Authentication, Authorization, Accounting; additional IP telephony requirements Privacy, Non-repudiation, Traffic analysis; legislative requirements emergency call localization and lawful interception. There are two most important subjects that have to be considered in a VoIP public network. These are clients and providers. Additionally, there are two classes of clients that were detailed earlier personal and business clients. Both personal and business user models are merely abstract. Moreover they represent two extreme and opposite approaches. Personal user is very service oriented, while business one cares mostly about confidentiality. While these models may be represented in reality, most of the real users will be probably placed somewhere between those two approaches. It was already said that business client's requirements are in every case higher than those of Pawel Lawecki Page 40 VoIP Security in Public Networks
5.4. Security Requirements Summary
the personal one. Moreover one could say that VoIP technology started with meeting the security expectations of a personal client. Performing this task on an acceptable level caused remarkable growth of number of users and market services. With time however, market will mature and its expectations will shift closer to business client model. Because of that an assumption is made in this thesis that personal requirements are already more or less met, since the VoIP market grows so quickly and only business client model will be investigated in the thesis and treated as a default client model.
Pawel Lawecki
Page 41
Threat Analysis
6. Threat Analysis
6.
Threat Analysis
The primary and basic meaning of threat is usually associated with an indication of impeding danger or harm [32]. If one remembers that the threat in this case regards a computer system, Edward Amoroso's definition from Fundamentals of Computer Security Technology [30] is probably the most accurate. It defines threat as: any potential occurrence, malicious or otherwise, that can have an undesirable effect on the assets and resources associated with a computer system. The most important issue by the threat analysis is: what kind of an undesirable effect, danger or harm may occur. One should also try to classify threats according to their similarities. Thanks to that, common solutions that solve a whole group of problems may be found later. Once threats are classified, they may be associated to client's and provider's security requirements. This is necessary before any priority may be given to the threats. After defining threats that may occur in the system, different attacks and vulnerabilities are described in the next chapters.
6.1.
Threats Categorization Overview
Threat analysis is a very complicated problem, as there are many ways to solve it. Because of that, the first thing one should try to perform is threat categorization. But even this is already a complex problem. There are many different factors according to which one can categorize threats. Additionally, many factors may be used at the same time and with different priorities. The Internet community does not agree on the common way to categorize threats, not mentioning the way to apply such a categorization to an existing network model. One could say that threat problem is similar to security approach problem shown in the chapter 4.Security Analysis Considerations. There are also many sources and it is difficult to choose the best approach. Some of them are definitely worth mentioning:
NIST: Security Considerations for Voice Over IP Systems [44]. One of the most renowned sources concerning VoIP security. The document gives mostly technological background and some descriptions of VoIP security solutions. In attachment a threat analysis is presented, which proposes a following classification: 1.Confidentiality and Privacy, 2.Integrity Issues, 3.Availability and Denial of Service. BSI: VoIPSEC, Studie zur Sicherheit von Voice over Internet Protocol [45]. A very detailed VoIP security analysis from German Federal Office for Information Security. It focuses mostly on small networks (usually private) and protocol related problems. The text describes many threats according to a classification over: 1.Integrity and Authenticity, 2.Confidentiality, 3.Availability. Additionally attacks are classified regarding: 1.Attacker properties, 2.Attack point, 3.Layer. XMCO: Voice over IP Security, A layered approach [46]. It describes some protocol based attacks. The author uses following threat classification: 1.Signaling Protocols Layer, 2.Transport Protocols Layer, 3.Application Layer. Group work from University of Colorado: An Analysis of Security Threats and Tools in SIP-Based VoIP Systems [47]. Threats and attacks are classified into three most important groups: 1.Confidentiality, 2.Integrity and 3.Availability threats. Additionally, within those groups threats are analyzed on different layers: 1.Network Interface, 2.Network, 3.Transport and 4.Application. Chris Roberts: Voice over IP Security [48]. Listing of most popular threats, attacks and solutions. Threats are categorized into: 1.Service disruption, 2.Service Interception and Eavesdropping, 3. Service Fraud and Abuse. Page 42 VoIP Security in Public Networks
Pawel Lawecki
Threat Analysis
6.1. Threats Categorization Overview
VoIPSA: VoIP Security and Privacy Threat Taxonomy [37]. A most general and basic taxonomy of threats. It includes following categories: 1.Social Threats (Misrepresentation, Theft of Service, Unwanted Contact), 2.Eavesdropping, 3.Interception and Modification, 4.Service Abuse, 5.Intentional Interruption of Service and 6.Other Interruptions of Service.
Each of mentioned sources uses different threat classification. Moreover, there are much more other possible categorizations. Any of them may be used, depending on the issue one wants to emphasize. Just to show how complicated the threat problem really is, some examples are given below. One could approach security problem according to a factor like:

affected subject (user, provider, state, etc.), affected system element (server, intermediate device, software/hardware client, etc.), type of system threat (physical, network, copyright, etc.), origin (human, technology, natural catastrophe, etc.), intention (on purpose, unaware, accidental, etc.), layered approach (OSI model layers, TCP/IP model layers, etc.), service approach (disruption, interception, fraud-abuse, etc.), protocol type (signaling, data, etc.), protocol specific (SIP, H.323, MGCP, RTP, etc.), regarding the compromised security requirement (integrity, privacy, availability, etc.), consequence (misrepresentation, interruption of service, eavesdropping, etc.).
Advantages and disadvantages of each of the classifications will not be given here. As already said, the choice depends on the issue one wants to emphasize. Since the security requirements analysis was performed emphasizing client's and provider's expectations, the same problem will stay most important in the threat analysis. In this case it means that the most important issue of any occurrence is its final impact on the client's and provider's security expectations. Origin, intention or protocol is not so important for them 1. They have their requirements and expect them to be met. That is why the VOIPSA Taxonomy [37], which is eventconsequence oriented, was chosen here. It classifies the threats, regarding the consequences they cause to the system. There is only a limited amount of possible consequences, but many ways of achieving them, so the Taxonomy may be used to classify attacks and may help in assessing their impact. Additionally, other classifications put their emphasis on either private network or protocol. VOIPSA Taxonomy is the most general one and thanks to it is also the most flexible one. It can be easier adapted to the problem of public network. It does not of course mean that other mentioned sources are not helpful at all. They are used in the following chapters as overview of possible attack techniques and vulnerabilities that may be exploited. Their threat categorization, however, is not applied in the thesis. Since the consequence approach is chosen a more detailed distinction between a threat and attack may be given. The most basic difference between those two problems is that: threat is an unwanted occurrence, while attack is a way to achieve it. Attack is a malicious, harmful technique used against a communication system and threat is a consequence and result of using this technique. In order for an attack to occur, a system vulnerability has to exist.
6.2.
Threat Taxonomy
VoIP Security Alliance is an open, vendor-neutral, non-profit organization, made up of VoIP and information security companies, organizations, and individuals. It allows its members to participate in VoIP security related projects [2]. Creating the Threat Taxonomy [37] was a task
1 It might be important later, on the stage of looking for a security solution. Depending on the origin of a threat different security solutions may be applied.
Pawel Lawecki
Page 43
Threat Analysis of one of its working groups.
6.2. Threat Taxonomy
In Figure 22 [49] the basic structure of the taxonomy is shown. Threat classes mentioned in the previous chapter are listed. This includes: Eavesdropping, Interception and Modification, Social Threats, Service Abuse, Intentional and Unintentional Service Interruption. Such approach seems to suit best for VoIP in public networks, unfortunately it is not ideal.
Figure 22: VOIPSA Threat Taxonomy [49] First of all, it is not precise. For example a physical intrusion shown on the figure as one of realizations of Intentional Interruption, may also lead to eavesdropping (physical access to the shared medium), interception & modification (inputing some intermediate device between victim's computer and his/her connection to the Internet) or even cause identity theft and misrepresentation (direct access to a registered end device). However, such an approach to the problem would complicate the taxonomy very much. It seems that each taxonomy is a trade off between precision and complexity. Its usefulness depends on the degree to which one wants to investigate threat problems. Secondly, no taxonomy may be perfect for each problem. For example since this thesis treats about public networks (every member of the society, who pays might use it), it is probably a good idea to consider social threats separate categories and bring them to the first plan. On the other hand, interruption of service is mostly a provider's problem and it would be probably easier to treat intentional and unintentional interruption as a single category. Any differentiation between interruption types would be probably easier to consider by searching solutions for provider's vulnerabilities, not on the level of threat categorization. Additionally, some other details of the existing categories may need to be also adjusted in order to easier solve the VoIP security in public networks problem1. Below a detailed version of VOIPSA taxonomy [37] is given (with mentioned adjustments to social threats and service interruption):
misrepresentation false or misleading communication, delivering information which is false, does not include concealment of information. Misrepresentation may concern: identity (false caller ID or number; false voice, name, or organization in a voice/video mail; false email; false presence information), authority (false password, key, certificate of another; circumvention of conditional access; false claim of government authority),
This regards identity theft. According to VOIPSA identity theft is a realization of the Service Abuse category and leads to an unauthorized usage of services by the attacker, while using somebody else's account. However, this is performed indirectly and is mostly a misrepresentation problem. Attacker misrepresents identity through valid credentials and among many other things may illegally use credits of some other person. But there may perform also many other serious threats. For example many banks regard calling number identification as a serious part of client's authentication process.
Pawel Lawecki
Page 44
Threat Analysis
rights (presentation of a password, key, certificate with the intent to gain rights not granted; circumvention of conditional access to gain rights not granted; modification of access control lists), content (false impersonation of the voice of the caller; false impersonation of the words of a caller; misleading printed words, images, video; modification of spoken, written or visual content), identity theft1 (misrepresentation of physical identity through a legitimate virtual identity obviously, only if it is done without the consent of the identity owner).
theft of service any unlawful taking of an economic benefit of a service provider by means intended to deprive the provider of lawful revenue or property (deletion or altering of billing records; bypass of lawful billing systems; unauthorized billing; taking of service provider property). unwanted contact any contact that either requires prior affirmative consent (incoming call) or bypasses a refusal of consent (outgoing call). Unwanted contact types: harassment (embarrassing, intimidating, vexing, annoying or threatening the receiver), extortion (affecting: freedom, rights, benefit, property; under a threat of loss or harm to the: health, reputation, property, safety, welfare of the person or anyone he/she knows), unwanted lawful content (such as lawful pornography, solicitations of lawful products or services; once the receiver refuses consent to ongoing or future contacts). eavesdropping method by which an attacker is able to monitor the entire signaling and/or data stream between two or more VoIP endpoints, without altering it. Eavesdropping may be realized by: call pattern tracking (unauthorized analysis of any traffic on the network), traffic capture (unauthorized recording of traffic), number harvesting (unauthorized collection of IDs: numbers, strings, URLs, email addresses, or any other identifiers), conversation reconstruction (any unauthorized monitoring, recording, storage, reconstruction, recognition, interpretation, translation and/or feature extraction of any audio or voice portion of any communication including identity, presence or status), voicemail reconstruction (as above, but regards any voice mail message), fax reconstruction (as above, but regards any document image), text reconstruction (as above, but regards any text). interception and modification method by which an attacker can see the entire signaling and data stream between two endpoints, and can also modify the traffic as a intermediary in the conversation. There are different types of this method: call black holing (any unauthorized method of dropping, absorbing or refusing to pass any essential element of VoIP protocol which effects in preventing or terminating communication), call rerouting (call sinkholing, unauthorized redirecting of an IP or any other essential element of VoIP protocol with the effect of diverting communication), conversation alteration (unauthorized modification of any information in the audio, video, and/or text portion), conversation degrading (unauthorized and intentional reduction of QoS), conversation impersonation and hijacking (injection, deletion, addition, removal, substitution, replacement or other modification of any communication, which alters its content, identity, presence or status), false caller identification (signaling of an untrue identity or presence).
Moved from service abuse.
Pawel Lawecki
Page 45
Threat Analysis
service abuse improper use of service. It is a large category which includes: call conference abuse (hide identity for the purpose of committing fraud), Premium Rate Service (PRS) fraud (artificially increasing traffic to maximize billing), improper bypass or adjustment to billing (avoiding authorized service charges or concealing fraud by altering billing records), other improper access to services (call bypass connection to add unauthorized parties; internal fraud exploiting internal access into authentication system; registration attacks; misconfiguration of end-points; concealing fraud by spreading access across multiple accounts). interruption of service which may be realized by: specific Denial of Service attack (specific to various VoIP application protocols), general Denial of Service attack (indirect affecting VoIP, through protocols not specific to VoIP), physical intrusion (also indirect affecting of VoIP, through damaging physical infrastructure), resource exhaustion (interruptions of services arising from any other reason than power outage), loss of external power, performance latency.
6.3.
Threat Architecture
All the threats mentioned in the VOIPSA Taxonomy could be divided into four main categories, taking their architectural aspect into account. They are presented in this sub chapter and described regarding to their role in the threat architecture where and what they affect.
Figure 23: General threat architecture In Figure 23 it is shown what elements of a client-server (user-provider) model are affected by a given class of threats. Threats may affect client, server, or communication channel. Arrows mean that a threat is usually used against a given element, however, almost in every case a threat may also affect another element (with a much smaller probability). Beneath the image, involved OSI layers are shown. Normally only user and server should have access to higher, application layers. But in case of an attack on the communication channel, some attackers may get access to the application peer between user and server.
Pawel Lawecki
Page 46
Threat Analysis
6.3. Threat Architecture
6.3.1.
Communication Channel Threats
The first and probably the most serious threat type is a one that affects communication channel. These threats, indeed, allow VoIP communication, but they additionally carry other unpleasant consequences. These are: eavesdropping, interception & modification, misrepresentation. While the other threat classes could be called preceding communication or communication related the mentioned three ones affect the very act of communication and violate most of its basic security requirements. Confidentiality, integrity, authentication, privacy, or even availability may be compromised by these threats. In Figure 24 information flow in a general communication model have been shown. In a correct case, the information flows from point A to point B without any interferences or problems. Unfortunately transport technologies and telephony protocols in an IP world are imperfect and they allow different attacks to occur. Others may see, modify, hijack or redirect what we are sending. First of the threats shown on the image is eavesdropping. Since most of the IP transport technologies contain a shared medium, other users may see our transmitted information. It may be achieved by many different techniques. An attacker may track the traffic pattern, capture it, harvest some specific information from the traffic or even try to reconstruct it. As one can see on the image, the information flow between points A and B is not affected. It simply flows to the attacker additionally. Because of that confidentiality and privacy is compromised. Next of the threats presented in Figure 24 is interception & modification. One could say that this threat comprises Figure 24: Information flow in a hypothetical eavesdropping and adds new dangers. communication system - threats Whole information between point A and B goes through attacker's device and none of the users is aware of this fact. By this, the whole traffic is eavesdropped and additionally may be tampered with. Attacker in this case possesses a lot of power over the traffic. He/she may break communication between two points by black holing or signal degradation. Rerouting call and giving false caller ID is also possible. Finally all kinds of conversation alteration and modifications may happen. Attacker may perform hijacking, substitution, deletion, addition, etc. In this case, apart from confidentiality, integrity and availability may be also compromised. Communication in eavesdropping is not affected and in interception & modification is usually allowed, but might be modified (however complete blocking is also possible). In misrepresentation in turn, communication between A and B is prevented and the traffic is redirected. The information flows between one of the valid communication points, here point A, and the attacker. The problem is that the user A may believe he/she is talking to B. One could actually say that misrepresentation may be achieved by interception, where the traffic is not forwarded and additionally authentication requirement is compromised (client A is talking to X, but thinks he is talking to B). In misrepresentation various techniques may be used. Attacker delivers some misleading, false information, usually concerning his/her identity. It may be achieved by pure social engineering and convincing the user that some untrue information is true. Attacker may bypass some Pawel Lawecki Page 47 VoIP Security in Public Networks
Threat Analysis
security mechanisms, or provide a valid, but stolen password or certificate. False caller ID, caller voice, name, or organization may also be presented. In most critical case, the whole identity may be stolen1. Misrepresentation compromises most of all authentication security requirement. All three mentioned threats affect communication channel, by using some medium, or protocol vulnerabilities. As a matter of fact, clients and servers should also be considered parts of communication channel (end-points) and may be attacked. This is however less probable.
6.3.2.
Interruption of service
Interruption of service is a problem that affects both client and provider in the same way. It is at the same time a fundamental threat. If the service is not available at all, no other threat may appear. Therefore the service availability was mentioned as one of the most basic requirements earlier2. Client wants to use service and if it is not available, his/her need cannot be satisfied. Provider, on the other hand, tries to satisfy the need in order to make business and earn money. What is important, in most tariffing plans provider is paid for an already provided service. That is why interruption of service is a problem of both network subjects. It means no service for client and no payment for provider. Most frequently interruption of service threat is caused by Denial of Service (DoS) attack (or flood attack). It is based on sending exceptionally lot of packets to the server to consume its computing abilities and lower its performance. The whole problem is that these are usually absolutely valid packets that in a normal communication would be processed and answered by the server. That is why the DoS attacks are so dangerous. It is extremely difficult to filter them out from the normal, regular traffic. DoS attacks may occur not only on VoIP layer, and while using VoIP related protocols, but also on underlying Internet protocols. Other types of service interruption may be related to any attack disabling the system or lowering its processing capabilities. In most cases these are indirect attacks that cripple the whole IP communication, not only VoIP. Any type of physical attack, virus, or even a natural catastrophe may lead to such consequences. In this type of threat, communication is affected by preventing it from occurring or interrupting an already ongoing transmission. Interruption of service usually means violating availability requirement, or in more optimistic case, only lowering service quality. Because of its nature interruption of service may never be totally eliminated even in a perfect system somebody's mistake may lead to a failure. The real question in this context is, if one can provide an availability of a similar value, as in traditional telephony, so the famous 99.999%. Most of the interruption of service threats are aimed against VoIP server. The obvious reason is that the striking power of such an attack is much bigger. While disabling a server, one affects the whole network and no user may use the service. Another type of attack would be targeted against communication channel which is any intermediate device. Disabling any intermediate device would mean the Internet traffic of clients connected to this device is blocked, which of course would also eliminate Voice over IP. So indirectly it is also a threat to VoIP. Theoretically some protocol based attacks could be also aimed against single clients. Their ability to initiate or receive calls could be crippled or completely blocked. However, indirect attacks that completely disable end device (especially software based clients running on fully
1 2 It was already mentioned that identity theft is, according to VOIPSA, counted as one of the service abuse threats. Here however, it is assumed that the service abuse is achieved indirectly via misrepresentation and identity theft is one of the misrepresentation threats. It is a requirement that has to be met in order for a VoIP to exist at all, so it is a basic requirement. But it is not a requirement of a highest priority for the personal client it was service cost and for the business client it was confidentiality.
Pawel Lawecki
Page 48
Threat Analysis
functional PCs) are much more probable. Viruses, worms or any other type of malicious software can render useless a whole Operation System (OS) and by this, prevent VoIP from working.
6.3.3.
Unwanted Contact
A threat that is targeted mostly against the client is unwanted contact. Unwanted contact is a problem that occurs before VoIP communication is established. It is related to a problem of communication freedom and privacy protection. On one hand anybody has a right to call anybody else, on the other, every client should also have a right to protection from unwanted communication. This threat type is usually related to violation of privacy requirements and additionally availability, as unwanted contact is blocking communication link. Authentication is also involved, as unwanted callers should be identified. Most of the unwanted contact problems are1 caused by SPam over Internet Telephony (SPIT) calls. Just as traditional email spam, such calls are automated and usually carry some publicity content. Of course in case of SPIT the effect on user is far more distracting, annoying and time-consuming. User is momentarily interrupted and has to answer the phone. Additionally, as VoIP is real-content, it is much more complicated to determine that a given call is VoIP spam. Unwanted calls may also regard a human calling, instead of just a machine. Attacker in person may try to manipulate its victim and use means of social engineering. Regarding content of the conversation, not only advertising calls are possible, but all kinds of harassment and extortion calls may happen. The receiver may be annoyed, vexed, intimidated or even threatened. While advertising calls (telemarketing) are allowed in most countries 2, other described types of unwanted calls are definitely unlawful. Because of that, some protection has to be provided to the user. There are actually two issues related to this problem. First of all one should protect client's personal data and information that may lead to an unwanted contact. Secondly one should protect users from the callers that were already refused communication and in some way marked as unwanted contact. In all of the described cases user is the target of the attack. However, most of the unwanted contact control mechanisms will be put on a server, so it may be also become a target of the attack. Information necessary for any SPIT call may be collected from a compromised server, or by eavesdropping (see next sub chapter). The latter technique is called number harvesting.
6.3.4.
Theft of Service and Service Abuse
Last but not least, there is a group of threats that mostly affect Internet Service Provider (ISP), which in case of VoIP means VoIP provider. These are theft of service and service abuse categories. They influence the provider's business activity by stealing its services without paying, or by lowering due payment. In both of the problems accounting and authorization may be compromised. In service abuse also authentication may be violated. Theft of service means stealing credits directly from provider and using its services without paying. Service abuse usually concerns paying less for services or using somebody else's account in order to use services. In both cases provider is still paid, but less, or charges a wrong client. Actually, sometimes the provider may actually be paid more because of service abuse. For example, some malicious software may artificially increase traffic, in order to inflate somebody's bill. In such a case provider actually gains financial benefits, but loses trust and in
1 2 Most of the sources are still only predicting this type of threat and it is much less widespread than email spam. Telephone marketing is allowed in the US and most countries of the EU [50]. There are some limitations in Denmark and Greece. In Germany telemarketing is forbidden. In most of the new EU member countries there is no special legislation concerning telephone marketing.
Pawel Lawecki
Page 49
Threat Analysis consequence may lose a client also.
Theft of service almost always regards attacking a server or gateway. It might be performed while using some VoIP protocol weakness, or simply by breaking onto the mentioned devices. Server or gateway may be compromised in many ways. One could perform an attack from the inside of the provider's internal network (either by its own worker, or by physical intrusion). Its defenses may also be cracked from a distance and configuration may be changed. One could also use some vulnerability of authentication mechanism. Any scenario of using server vulnerability is possible and would have to be considered on a specific example (provider's network). The mentioned attack possibilities regard also service abuse. There is, however, one additional problem. System may not only be compromised by server's or VoIP protocol's weaknesses, but also by using correct VoIP mechanisms, where the attacker uses some existing valid identity to use services. In this case, client's end-device had to be compromised earlier and the attacker uses his/her authentication data (credentials). Most systems are defenseless to such type of an attack.
6.4.
Client & Provider Threats
Listed threat categories can be used for client and provider threat analysis. Similar interrelations to these in security requirements, exist for threat classes. Different threat classes depend on or influence one another. For instance, successful interception and meaningful modification requires eavesdropping and understanding the content first. Or in a different example, service abuse includes identity theft for access without permission, where authentication process is correctly carried out, but does not result in correct identity recognition, etc. Another problem is mapping security requirements into threat classes. It is definitely not a simple one-to-one relation. For example breaching authentication may be achieved by different threats, like misrepresentation, interception & modification or performing unwanted contact. Accounting is compromised by theft of service or service abuse. There are usually more threats that may violate a single security requirement and more requirements that are violated by a single threat. That is why simple mapping cannot be carried out and one has to consider the threats in context of well defined security expectations. Last but not least, there is a problem of stating what threat categories are to be considered in each of the client's or provider's expectation. As already shown in the security chapter (5.3. System Requirements Definition) their expectations are usually more complex than the general security requirements. The same refers to the threat classes.
6.4.1.
Client
Violation of client's security expectations means that they are simply not met. Because of that declaration of most unwanted client's threats may be achieved by a plain negation of the expectations, as in Table 7. As said in the previous chapter, only business client model with higher expectations will be considered and treated as a default client. Threat analysis achieved from expectations negation is very similar to the security requirements analysis. Client most of all does not want to be eavesdropped and that the content of the conversation is revealed (2), but before secrecy of data can be provided one should be sure if he/she is talking to the right person (1). This regards calling and being called, as well. Client is also afraid of data modification (3) and details about the conversation being disclosed (4). Final confidentiality threat regards revealing private information of a business client, as it also may be dangerous for him/her (5). Another type of threat is the interruption of service (6). It has a lower priority than Pawel Lawecki Page 50 VoIP Security in Public Networks
Threat Analysis
6.4. Client & Provider Threats
confidentiality threats, as we assume that for a demanding client (business client model) it is better not to have service at all, than to have an unsafe service. Obvious threat to any client is inflating the service price (7). Removing proof of involvement is an also dangerous threat (8). Unwanted calls are in the least case tiresome (9), but of course may lead to more hazardous consequence. Client does not want: the connection to be set up with a different person/organization than it should, or 1. than the client believes it to be (misrepresentation, interception & modification of signaling) 2. the content of the conversation to be known to anybody else, who did not take part in it (data eavesdropping) 3. the content of the conversation to be modified in any way (interception & modification of data) 4. any details about the conversation to be revealed (signaling eavesdropping) 5. any private information about him/her to be accessible to unauthorized subjects (eavesdropping, interception & modification, misrepresentation) 6. any service failures that prevent or unable communication (interruption of service) 7. to pay for the service he/she did not use, or pay more than he/she should (theft of service, service abuse) 8. the proof of involvement to be removed (interception & modification, service abuse) 9. any unwanted calls (unwanted contact) Table 7: Client's main threats
6.4.2.
Provider
Just as in the security requirement analysis, a provider most of all is afraid of inability to provide services. Without the service, provider has no product to sell (1). Once an available service is offered, the provider must protect itself against stolen credits (2), or abused services, where clients pay less than they should (3). If the provider is not protected from those threats, then its whole economical sense of being is undermined. Of course charging wrong clients (4) or losing their proofs of involvement (5) causes malfunction of the whole Provider does not want: 1. any service failures that prevent or unable communication (interruption of service) 2. his/her services to be stolen (theft of service) 3. to charge smaller amount of credits than it should (service abuse) 4. to charge a wrong client (misrepresentation, service abuse) 5. that the proof of involvement is removed (interception & modification, service abuse) 6. the client's requirements to be compromised (client's threats) Provider cannot let: 7. emergency call mechanisms to be mislead, interrupted, interfered, or disabled (emergency call) 8. lawful interception mechanisms to be mislead, interrupted, interfered, or disabled (lawful interception) 9. client's privacy to be compromised or disclosed to unauthorized persons (privacy) Table 8: Provider's main threats Pawel Lawecki Page 51 VoIP Security in Public Networks
Threat Analysis charging system and therefore should be avoided as well.
6.4. Client & Provider Threats
After threats critical to the provider's expectations, there are also client's threats (6). Provider needs to protect the system from them, otherwise the clients might stop using the service. Finally, there are threats against state expectations emergency call mechanisms (7), lawful interception (8) and privacy requirements (9). All the threats are summarized in the Table 8.
6.5.
Threat Realizations & Summary
Attack techniques, fatal events, or negligence may all lead to a threat realization. They all should be analyzed, as the final aim of a security analysis is to find out some security solution and protect the system. In order to do it, one needs to investigate attack techniques closer and find out how exactly could they affect VoIP system. In case of threats, the most important issue is consequence to the system - what element of the system is affected and how. Attack techniques, on the other hand, need to be investigated taking into account their origin. One has to find out where does a given attack come from, how it was performed, what part of the system was vulnerable and exploited. Attack technique uses a weakness of some functional layer, in Figure 25: Attack technique as a threat realization order to realize one of the threats and affect one of the system subjects. The problem described is shown in Figure 25. In order to determine what threats are realized by what techniques one should try to map attack techniques into threats. However, just as two previous mappings performed in this thesis, this one is not simple either. Firstly, some techniques realize many different threats. Everything depends on the attacker's will. Secondly, a single threat may be realized by many different attack techniques. Attack to threat mapping is therefore definitely not a simple one-to-one relation. Both problems are especially complicated on underlying layers since the attack techniques developed there, affect VoIP only indirectly and were not created to achieve some VoIP specific threat. Moreover, since the underlying layers are similar to most computer systems, also the amount of developed attack techniques is enormous. Because of that, the best way to solve the problem is to consider existing attack techniques and generalize them. Instead of considering every single attack technique, it is better to find a general type of attack. It is a big simplification, since some attack techniques exist in many variations. They work with
Pawel Lawecki
Page 52
Threat Analysis
6.5. Threat Realizations & Summary
the same principle, but are targeted against different layers or protocols. A given type of attack could be defined taking under consideration its origin, exploited vulnerability, affected subject and realized threat. This would help to reflect attack types into threat taxonomy as much as possible. Such an approach has additional advantage. Creating classes of general attack types that work similarly may be enough to find a common solution for them. Instead of searching for solutions against all attack techniques, one needs to find a solution for the whole group of attacks with similar properties. Threat realizations are described in the next two chapters. As described in chapter 4.Security Analysis Considerations, analysis of vulnerabilities & attack techniques, is best to divide into two parts. The first treats about layers underlying VoIP and is presented in the chapter 7. Underlying Layers Analysis. The latter is VoIP specific and is shown in chapter 8.Application Layer Analysis. In both chapters a description of their layer functionalities is given, with an attempt to state its vulnerabilities. Then general attack types are presented with examples of the most common techniques.
Pawel Lawecki
Page 53
Underlying Layers Analysis
7. Underlying Layers Analysis
7.
In order to work properly Voice over IP requires many underlying technologies and it is not just Internet Protocol. The Internet, the biggest known public network, is a very complex and diverse communication platform. Because of that any service working on top of it encounters, apart from incredible flexibility and extensibility, also great number of problems. These problems are described in this chapter. First, there is some general system description, combined with vulnerabilities overview. This includes general system architecture on lower layers and most popular access scenarios, mentioned already earlier. Then, most common attack techniques are introduced and discussed. Their influence on VoIP is also investigated.
7.1.
Properties & Vulnerabilities

General Overview
7.1.1.
As already described in chapter 3.1.Overall Architecture the general structure of a public network may be divided into a few basic elements. As shown in Figure 26 there have to be users acting as clients, VoIP provider working as service deliverer, and some transport network. It is between VoIP user and VoIP provider, where the whole application layer based communication takes place. But in order for those application layers to work, functionality of lower layers has to be provided and ensure correct working of communication channel.
Figure 26: General overview of protocol architecture in public network First of all one has to consider security and vulnerabilities of end-devices, where the VoIP functionalities reside. Certainly user's device, or VoIP server may be compromised by many malicious techniques on underlying layers. These, most of all, include attacks against Operation System (OS), but also any other application that is necessary to sustain a running and fully operable computer system. Of course no underlying layer application is explicit for VoIP, so any threat to those layers should be treated as a general threat to a computer system Pawel Lawecki Page 54 VoIP Security in Public Networks
Underlying Layers Analysis that affects VoIP only indirectly.
7.1. Properties & Vulnerabilities
Attacks against server or any end-device are not so easy to perform, if basic precautions are taken. However, if the attacker succeeds with an attack against any crucial application, he/she may gain a total control of the computer and through this, compromise VoIP. In order for the communication between VoIP client and server to take place, there has to be some network transporting the information. It is shown in Figure 26 and is divided in two main parts - access network and core network. Core network of the Internet consists, most of all, of routers. The routers provide functionality of Layer 3, what is realized obviously with the Internet Protocol. Routers in the Internet core network are the most important nodes through which the gathered traffic of all IP applications is transported. Their impact on VoIP, however, is limited. First of all, since these are devices common for the whole Internet traffic, they are well protected and usually managed by administrators with thorough technical expertise. Secondly routers provide functionality up to the third OSI Layer. This in practice means that there are not many vulnerabilities, as the lowest layers are usually less complicated. Their only function is to route and forward packets. They do not have to process or reply anything, because of that even DoS attacks have small impact on them. Moreover, it would be highly inefficient to attack a node of the Internet core network in order to affect VoIP. Last, but not least, lower layers in the core network could have the influence on VoIP users only if the potential attackers had direct access to the network. However, the physical access to the core network and its devices is usually very limited. Therefore the security of the core network will not be considered in this thesis. The access networks are not common for the whole Internet traffic. They might be limited geographically and provide Internet access to a limited group of users or be country-wide. As said in case of the core network, lower layers are not so complex and do not provide any advanced functionalities, so they should be considerably safe. The truth is that access networks do not provide much more functionalities than core networks. However, the biggest difference between two mentioned network types is that the latter is directly accessible to the users. Already described (3.2.Access Networks) issues, like shared medium, or mobility may expose clients to many threats from other users, as any user is of course also a potential attacker. Since the attacker has a direct access to the shared medium and it is often vulnerable (either of negligence, or built-in potential vulnerabilities), he/she might attack it. Because of that VoIP telephony services that are accessed through such networks may be affected and their security may compromised. Deeper analysis of access network security will be therefore presented in the next sub chapters.
7.1.2.
Client & Provider
Client's IP device and provider's server are critical to consider from the point of view of VoIP security. They host and provide basic functionalities to overlying VoIP layers. Because of that, their vulnerabilities and attacks, that may be possibly used against them, should be considered. The basic issue in case of any device is always its Operating System (OS). In order to describe what the operating system really is one could use a quite detailed definition from Farlex'es Free Computing Dictionary [32] that says its the master control program that runs the computer. The first program loaded when the computer is turned on, its main part, the "kernel," resides in memory at all times. The operating system sets the standards for all application programs that run in the computer. Applications "talk to" the operating system for all user interface and file management operations. Pawel Lawecki Page 55 VoIP Security in Public Networks
VoIP as any other application has to run on some operation system, therefore its vulnerabilities might be critical. Of course there are many different operation systems, just to mention Windows XP, Windows 2000, or Linux Red Hat. Servers may use yet more different types of software. Because of that, it is impossible to state what are vulnerabilities of a system underlying VoIP and what is their influence on the telephony. Moreover, vulnerabilities change constantly as new versions of operation systems are issued. Therefore, the only thing one can actually do, is to describe some important properties, or parameters that specify vulnerabilities. According to Symantec [51], there are three basic parameters describing security of operating system:
exploit code development time it is a time between an initial publication revealing a vulnerability and appearance of an exploit-code, a malicious software exploiting this vulnerability, patch development time - it is a time between disclosure date of a vulnerability and the release date of a patch that repairs it, window of exposure it is the time difference between exploit code development and patch development time. It specifies how long the operation system was vulnerable and exposed to attacks with exploit code.
Different systems have different values of window of exposure, and before installing a VoIP client on a computer, one should probably check out the safety of the system. Of course, even a negative value of window of exposure (patch released before exploit code appeared) will not help if the client does not carry out regular system updates and install those patches. Obviously, not only the operation system is vulnerable and may allow device take over. Actually most of the vulnerabilities regard web-applications [51], but one should probably be suspicious regarding all other applications. As each additional functionality of a device creates a bigger space for potential vulnerabilities. Therefore, usage of softphones, software based VoIP clients, on a complicated operation system, together with many other applications is rather reckless. One could say that VoIP has enough own problems it has to deal with and does not need adding new ones (8.Application Layer Analysis). It is much better to use a hardware based VoIP phone (similar to telephones known from the PSTN), since it is limited to providing only VoIP functionalities. It also has some Operation System running underneath and the window of exposure problem also concerns it, but at least the OS is simple and should have less vulnerabilities. In reality however, most of the home users will probably decide for a softphone, since it does not require any additional costs and may be installed while staying in front of the computer. Therefore, security of a VoIP application running on a home PC, or notebook has to be considered. Fortunately there are some solutions to window of exposure problem that do not require a hardware phone. This could be simply the usage of firewall and antivirus. Firewall blocks access of unauthorized application to the computer, by blocking application ports. Antivirus detects exploit code that already got to our computer and neutralizes it. Exploit code and malicious software may have different forms and be distributed in many ways. Some of the most popular examples include: viruses, worms or Trojan horses. All these techniques may lead to an unauthorized control over a device. It usually regards home users' computers, but might as well be targeted against a VoIP server. Unauthorized control over a device may also be achieved by other techniques. Just to mention a trivial physical attack and physical access to a device that has a registered VoIP client running on it. It could lead to identity theft and compromising almost every single security requirement. An unauthorized control over a server could have dreadful consequences to the VoIP provider and the whole network. Anything could be modified, rerouted, accessed,
Pawel Lawecki
Page 56
Underlying Layers Analysis etc.
Certainly, sometimes unauthorized control may also be gained as a result of user's or administrator's negligence. If a simple password is chosen for device remote access it may be cracked, even though security mechanisms are in place and working well. Most of the mentioned attacks regard both client and provider. However, single users (especially home users) are less likely to have a well established security measures and are much more vulnerable to all those problems. Attackers know it very well and target most of the attacks against them. According to Symantec, attacks against home users account for even 86% of the total number of attacks [51]. However, some attacks affect ISPs and even those with the best security mechanisms. A VoIP server that is protected with firewalls, antiviruses, has all necessary updates installed and is perfectly managed is still vulnerable to Denial of Service attacks. As already described earlier, DoS attacks do not require any vulnerability to exist. Their basis for action is to send valid packets in large quantities. The problem is that those packets do not lead to communication or any other meaningful action. Still, they have to be processed by the server in order to find out what do they concern and be replied. This consumes server's computing power and may cause lack of resources necessary for establishment of other, meaningful transmissions. Denial of Service may be performed on VoIP underlying layers 1. If such an attack is used against VoIP server, even though most of its functionalities lay on higher layers, the resources will be exhausted and server will not be able to perform its work properly.
7.1.3.
DSL
DSL is one of the most popular Internet access networks. As described in chapter 3. Architecture it derives from traditional PSTN networks. The same physical cable as in PSTN is used in DSL for Internet dial-up access and IP packets transmission. It was also already said that DSL has some definite security advantages that originate from data transmission over physically independent links subscriber lines. Each subscriber line is aggregated in the access provider's network by DSLAM, where each connection is assigned a VLAN identifier. This way even, once the traffic is aggregated in the network, it is still virtually separated and logically no common link is present. No shared medium or Local Access Network means obviously much less vulnerabilities and dangers to VoIP. However, some dangers still exist and some security mechanisms should exist. Obviously, DSL architects are aware of this and some security measures are always deployed. Protocol architecture showing authentication in DSL is shown in Figure 27 [52]. As one can see, between user's end device and BRAS there is authentication mechanism. Additionally, between DSLAM and BRAS a virtual VLAN channel is created for data from each subscriber line. In case of solutions with higher security, it might be required for BRAS to perform other operations as for example [53] data encryption. This, however, includes security of traffic forwarded to the Internet. Concerning communication between DSL modem and BRAS, physical channel separation from end user to DSLAM and then a logical division of communication channels is already considered highly secure. The only part of the DSL transmission that Authentication is usually performed by RADIUS Protocol (PPP) or PPP over Ethernet (PPPoE) method are usually some login and password
1
is encrypted, is authentication mechanism. Protocol used in conjunction with Point to Point [54]. Credentials that are checked in such a given by user. However, most of the time, in
VoIP specific DoS is also possible for example with valid SIP packets that do not lead to any meaningful action, but this will be described in chapter 8.Application Layer Analysis.
Pawel Lawecki
Page 57
order to identify users, it is enough to check up VLAN tag of a given packet this identifies subscriber line and by this also user.
Figure 27: DSL access protocol architecture (partially [52]) Authentication mechanism has also some additional functions and is usually used to authorize users and check their access rights to a given service. The NE provides the possibility to authenticate the users to make sure that only those users who have access rights can make use of the services offered by the service providers [54]. Other security properties of DSL architecture may include tracking users to a port to prevent a fraudulent activity [55] and protection against many of the attacks described later in this chapter: [55] DoS prevention, IP and MAC-antispoofing, broadcast control, [56] intrusion prevention and virus scanning. This all makes DSL a really safe environment. Most of the vulnerabilities are excluded by simple division of shared medium no common LAN problem exists here. Thanks to that, high security of communication channel is provided. Of course, there is no control of traffic content and any attack can be targeted directly against end user, but no problem should result from medium vulnerabilities. Additionally, some DSL deployments provide VoIP specific support. Triple-play [57] concept that is a marketing term for providing high-speed data, television and telephony access as a single product is often used in context of DSL. This is usually solved by bringing more intelligence into aggregation and access network and providing service differentiation with Quality of Service. VoIP specific solutions include even some special delay/jitter/loss characteristics.
7.1.4.
Broadband Cable
Broadband cable access was also presented in architecture chapter. It was described that the local access network is semi-common, since the downstream traffic travels to all users on a single segment. Obviously, in order to make cable Internet access network safe and prevent other users from Pawel Lawecki Page 58 VoIP Security in Public Networks
eavesdropping and unauthorized traffic access, some solutions had to be developed to eliminate those vulnerabilities. Data over Cable Service Interface Specification (DOCSIS) [58] and PacketCable [59] are standards and specifications that are to provide a common framework for Cable TV industry and enable a wide range of multimedia services. They also include many security specifications. Like for example authentication, packet filtering, secure distribution of keys from CMTS to Cable Modem (CM) mechanisms. All those specifications allowed development of Internet access through cable TV networks and are widely adopted today [60].
Figure 28: Broadband cable access protocol architecture Two special standards are worth mentioning in this context - Baseline Privacy Key Management (BPKM) and Baseline Privacy Plus (BPI+) [61]. They introduce very strong authentication and encryption mechanisms. X.509 digital certificates, RSA (a public-key encryption algorithm) and two-key triple Data Encryption Standard are very powerful methods that secure key exchanges between Cable Modem and CMTS. Additionally, BPI+ establishes a shared secret between CM and CMTS that secures exchanges of traffic encryption keys. This ensures a two-tiered mechanism for key distribution. The basic principle of this mechanism is shown in Figure 28. One can see that there is authentication and then encryption between Cable Modem and CMTS. Each CM carries a unique X.509 certificate that was issued by the CM's manufacturer [61]. The CMTS associates a cable modem's identity to a subscriber in order to check his/her access rights in the network. Once the user is authenticated, authorized and traffic keys are exchanged, data traveling from CM to CMTS is safely encrypted. This way only own downstream traffic is visible to the users. Therefore one could say that BPI+ provides a level of data privacy across the shared medium cable network equal to or better than that provided by dedicated line network access services (analog modems or digital subscriber lines) [61]. Confidentiality, authentication, data and signaling integrity are all ensured. Moreover, there are some efforts to make cable access environment's availability close to this known from the PSTN [62]. This all makes cable access networks a technology that is really safe and lacks any major vulnerabilities.
Pawel Lawecki
Page 59
Not only availability issue is a very big advantage in context of VoIP, but there are also other VoIP specific solutions. Some PacketCable based implementations provide also service differentiation and Dynamic Quality of Service (DQoS) [63].
7.1.5.
WiMAX
Last of the mentioned earlier access network technologies is WiMAX. Unlike two previous examples, it does not use any past technology to introduce IP network access. Moreover, it does not even provide any fixed connection, since the signal is distributed over microwave radio frequencies. This, as it was already described, causes a lot of potential vulnerabilities concerning shared medium and mobility mechanisms. However, WiMAX provides many security measures to counteract its vulnerabilities.
Figure 29: WiMAX access protocol architecture WiMAX architecture is based on IEEE 802.161 security architecture but some implementations include additional features that actually increase security level [64]. In those solutions both user and device are authenticated. Terminal's credentials X.509 certificate stored in the device at the connection building stage are checked by the network. Thanks to device authentication black listed and stolen terminals may be rejected, since credentials are bound to the terminal [65]. User's credentials are bound to his/her subscription and chargeable account. Differentiating both authentications allows [65] preventing valid subscribers from using stolen terminals or rogue users from stealing services using valid terminal. Each valid subscriber is simply bound to his/her device. The only problem in this context may be storing user's credentials in computer's memory. Both authentications are carried out through PKMv2-EAP protocols. Extensible Authentication Protocol (EAP) is a framework and transport protocol for other authentication protocols. For
1 Additionally, 802.16e provides the supplement for mobility (roaming and handover).
Pawel Lawecki
Page 60
example for device authentication EAP/TLS method is used, where client and server authenticate each other using digital certificates. Client generates a pre-master secret key by encrypting a random number with the server's public key and sends it to the server. For user authentication other EAP methods, like for example EAP-TTLS/CHAP or EAP-SIM may be used. Basic principle of this mechanism is shown in protocol architecture in Figure 29. Double authentication takes place between user's device (user credentials and Network Interface Card (NIC) certificate) and WiMAX Access Control. The whole described encryption and authentication scheme makes WiMAX really safe. EAP/TLS and EAP-TTLS/CHAP are considered one of the most secure authentication methods [66]. Thanks to authenticating both client to provider and provider to client communication ends are always correctly identified and encrypted traffic is really safe. Therefore one can say that security protocols successfully countermeasure any WiMAX vulnerabilities and make it a safe network access technology, which is a proof that wireless networks may be also safe1. WiMAX can also possibly offer VoIP specific solutions on top of its architecture [67]. Concepts, like QoS over the air are available. It is possible to make Radio Access Network VoIP (SIP) aware.
7.1.6.
Ethernet Scenario
It has been shown that all three described access scenarios are really safe, if correctly deployed. Each of them has built-in mechanisms for prevention of traffic eavesdropping, interception or modification. There is, however, one problem. Sometimes between access technology and the end-users additional technology is used, in order to create a Local Area Network (LAN). This might happen for example in case of an Internet caf, library, university, or any other open access network that provides connectivity to the Internet. If some obvious vulnerabilities exist in such a network, the security is ostensible, since the VoIP user may be attacked in his/her closest vicinity. All safe mechanisms of the Internet access network is meaningless. Because of that, it is worth to casually investigate LAN, even though it is mostly a private, not public, network issue. The most widely used LAN technology is Ethernet [32]. On images concerning access technologies Ethernet was sometimes shown as a network technology interconnecting enddevice with a modem (but the modem may be also directly connected to the end-device for example through USB port). In case of a network with more devices connected to an access link, modem is often replaced with a router that contains all the modem functionalities. Thanks to this all end-devices may share the same access network channel. Ethernet uses a copper cable as a physical medium for signal distribution. Copper cables from many end-devices may be aggregated with a node device like hub or switch. Hub works on a most bottom OSI layer and simply forwards a physical signal to all ports. Of course since the signal from one computer is forwarded to all of them, there is a shared medium and no security can exist without encryption. Most of today's networks, however, use switch instead of hub. Switches forward Ethernet frames (they encapsulate IP packets on Layer 2) only to appropriate ports 2, where the addressee of the frame resides. Since each device is connected to a switch on a separate cable, only one cable is connected to each port and switch forwards frames only to the
1 2 In case of another popular wireless access scenario Wi-Fi, it is often emphasized [66] that one should use Wi-Fi Protected Access (WPA) security standards and not Wired Equivalent Privacy (WEP), which may be easily cracked. Actually the mechanism is a bit more complicated on the network startup, as the switch has to find out first, what devices are connected to what ports. Because of that, first frames are forwarded to all ports, until the appropriate device replies. Once the device replied, the switch learns where it is located and from this moment on, all the frames destined to this device are forwarded only to its port. This has, however, only a minimal influence on the security.
Pawel Lawecki
Page 61
appropriate ports. Negative effects of shared medium are neutralized1. Therefore an Ethernet LAN based on switches is considered relatively safe. However, there is a dangerous vulnerability concerning Address Resolution Protocol (ARP) [68]. ARP is used by the devices connected to an Ethernet LAN in order to translate IP (Layer 3) address into MAC (Layer 2) address, where MAC stands for Media Access Control. Modus operandi of ARP is shown in Figure 30. If a device wants to send a packet to another device, then it has to use ARP protocol. As shown on the example in figure, Default Gateway wants to send a packet to the PC with IP=x, but it does not have its MAC address (1). Therefore it broadcasts an ARP request to find out which computer has the mentioned IP (2). Since the frame is broadcasted, switch forwards it to all connected ports. Once the PC with IP=x receives a request, it replies to the Default Gateway and gives its MAC address (3). Switch forwards the frame to the Default Gateway and it is stored in its ARP cache. If no activity is occurring for some time and the record becomes older than some assumed value, it is removed from the cache (4). The whole mechanism repeats by the next packet. The mechanism is valid for any device that has at least Layer 3 functionality.
Figure 30: Address Resolution Protocol in Ethernet networks The described mechanisms shows how the correct translation of IP addresses into MAC addresses looks like. However, as said - ARP protocol contains a serious vulnerability. A technique called ARP spoofing may be used in order to perform a Man in the Middle attack. This mechanism is shown in the next sub chapter. Additionally, Ethernet technology is sometimes used as an aggregation technology for the user traffic in access network, as was shown in previous paragraphs. Even though it is highly improbable that such an Ethernet-based transport network could get compromised, one should always take such a possibility under consideration.
7.2.
VoIP Underlying Attacks
In context of general attacks and techniques against a computer system Symantec Internet Security Threat Report [51] seems to be one of the best sources. Issued every quarter, it
1 It is still a shared medium, but clients do not see one another's packets thanks to Layer 2 mechanisms.
Pawel Lawecki
Page 62
7.2. VoIP Underlying Attacks
specifies most wide spread and popular Internet attack techniques and common vulnerabilities regarding computer systems in general, so also VoIP underlying layers. Another paper with a very thorough analysis of attacks against VoIP on lower layers is a security analysis on VoIP (VoIPSec [45]) from German Federal Office for Information Security. Obviously these are just two main sources, but are accompanied by many others.
7.2.1.
Traffic Sniffing
Traffic sniffing is a technique of analyzing packets in the network. It may be usually performed with some programs analyzing network, as it is a technique also used by network administrators for network management and failure detection (just to mention Wireshark, formerly known as Ethereal [69]). The freely available software is also often used by attackers. Traffic sniffing is possible wherever there is a shared medium and all devices can see each other's traffic, or the traffic has been forked, rerouted, etc. and is available to the attacker. Of course if encryption is used, as in WiMAX or Broadband Cable, then the ability of an attacker to sniff the traffic is very limited. Apart from sniffing a network analysis is possible to perform with some software. It works in a more active way than sniffing. Instead of just hearing to what happens on the network, an attacker may send some standard requests with different protocols in order to detect other clients and determine network structure. Such a technique is usually used as a preliminary action of MitM attack (may be performed for example with Cain & Able [70]).
7.2.2.
Man in the Middle Attack
Man in the Middle attack is a technique, with which an attacker manages to place himself/herself between two valid communication end-points. [3] The attacker may use some traffic interception mechanism. Thanks to it, he/she is able to read, insert and modify messages exchanged between two parties, while the victims are not aware that their security has been compromised. MitM attack may be carried out on any functional layer (including application SIP based MitM), if appropriate security measures are not established. Of course in case of lower layers it requires a shared medium. In common local access network the attacker may use vulnerability of network protocols and reroute the traffic. As already described in chapter 6.3.Threat Architecture, MitM attack may compromise confidentiality, data and signaling integrity, availability and to some extent, even authentication security requirements of VoIP. Threats, like interruption of service, interception & modification and eavesdropping may be realized. A call may be black holed, hijacked or modified. Identity theft and acquiring credentials by the attacker is also possible. An example of MitM attack is shown on Ethernet scenario. It is achieved with a technique called ARP spoofing [71]. But any other technology similar to Ethernet, or with weak authentication mechanisms and shared medium may be attacked in a similar way. As described in one of the previous sections, records in ARP cache (mapping of IP to MAC address) are normally removed after some time and a new ARP request is broadcasted. However, gratuitous ARP reply without any request is also possible. If it is sent more often than the cache clearing interval, the validity of the record is sustained. The switch (or any other receiving device) will not even send any ARP requests, as a valid record will exist all the time. This is a serious vulnerability and may be used by an attacker. He/she could send gratuitous ARP replies with a spoofed MAC address. In simpler words, he/she can lie and say that somebody's IP address is available under his/her MAC address. If the attacker spoofs both the user and gateway user is lied about gateway's address and Pawel Lawecki Page 63 VoIP Security in Public Networks
gateway about user's address and the lie is successful, then the whole traffic between the gateway and the user is traveling through the attacker's computer. Once this happens a Man in the Middle attack is achieved. In reality the true MAC address of the attacker is not used. Instead the hacker creates an additional and virtual MAC address on his/her computer and the packets destined to the victim, are actually forwarded to the port, where the hacker is connected. This way hacker may receive those packets without disguising his/her identity. The ARP spoofing based MitM attack can be performed for example with Cain & Abel program [71], which also contains functionality of detecting VoIP (media RTP stream) in the attacked traffic and storing it. The described technique is summarized in Figure 31.
Figure 31: Man in the Middle Attack in Ethernet network The described example of MitM attack will look similarly in other networks with a common local access network, where there are some protocol vulnerabilities and authentication of devices fails. Other techniques from different layers could be used in order to achieve MitM attack. These are for example [45]: STP rerouting, VLAN rouge Trunk, ICMP Redirect, IRDP Spoofing, Route Injection, HSRP-Attack, VRRP-Attack, DHCP rouge Server. Instead of MitM attack, a traffic reroute could also be performed, where attacker intercepts the victim's traffic, but does not forward it further. Techniques as MAC spoofing, VLAN Hopping, or DNS spoofing could be used. Some of them regard small networks, like this shown in Ethernet scenario, and they should be considered private. The example was shown only to show that a public user accessing VoIP services in an unknown public network, should not assume it secure. It should be especially taken into consideration when using open, unprotected networks, like in Internet caf, library, etc. But there are also some, like for example DNS spoofing, that may be used in the whole Internet.
7.2.3.
Malicious Software
In order to perform an attack against a computer system an attacker very often uses some kind of a malicious software. Three basic and most widespread malicious software types are viruses, worms and Trojan horses. Each of those three software types propagates differently Pawel Lawecki Page 64 VoIP Security in Public Networks
through public network and has a different purpose when attacking a device. Computer virus is a software used to infect a computer existing program (or just macro) and this program has activate. Once, activated it multiplies itself and attaches These programs infect yet other programs and this way the [32]. It is usually buried within an to be executed, for the virus to to other programs in the system. whole system is infected.
Viruses may perform all kinds of damage. The result of their activity, as of any program, depends on the way they were programmed. They may [3] damage or delete files, or even format the whole hard disk of a device. VoIP client running on the compromised machine could be also attacked. A Trojan horse is a program that appears legitimate, but performs some illicit activity when it is run [32]. Trojan horse, similarly to virus, needs some other host-program and needs to be executed in order to start working. However, it does not replicate it stays in one program on one computer (unless program is copied). It may be used to locate password, destroy programs, or make system more vulnerable. However, the most characteristic property of Trojan horse is that it can allow some attacker to take control of the device from a remote site. By controlling the OS of the device it is running on, Trojans may affect VoIP in many ways. A worm is a destructive program that replicates itself throughout disk and memory [32]. It spreads on its own through the network and infects vulnerable devices and does not need to be attached to any other program. This means that unlike virus or Trojan horse, worm may infect a computer even if the user did not execute any suspicious software. The computer simply has to have some system or application vulnerability that allows the worm to infect the device. Because of that, worms are much more dangerous than all other kinds of malicious software. A worm may attack VoIP in many different ways. First of all, only by unlimited propagation through the network, worms consume the bandwidth, so they lower the quality. Secondly, they may take device's resources and eventually take the whole system down and disable either a VoIP client or even server. Last but not least, a worm can launch a DoS attack from the infected devices and disable the VoIP server. All of the mentioned types of the malicious software may also propagate in email attachments. Due to this, it is extremely dangerous to open executable files attached to messages of unknown origin. There is one more important issue one should probably mention, while writing about malicious software. Group of compromised computers on which attackers have installed software that listens for and responds to commands [51] creates a distributed, infected network, called bot network. Bot networks can potentially be used to launch massive denial of service floods, but also steal or corrupt great quantities of sensitive information, and confuse and disrupt use of the network [72] and by this also Voice over IP. Such a network may be used to perform Distributed DoS (DDoS) attacks, generate SPIT calls, or perform theft or abuse of service on a large scale.
7.2.4.
Denial of Service
The basic mechanism of a Denial of Service attack is to send a tremendous amount of packets to a server in order to consume its computing power. The packets look like normal, valid packets that are sent from client to server during a transmission. Usually they are some kind of requests and therefore, need to be processed by the server and replied. If a big enough quantity of such packets is sent to a VoIP server, it will not have enough resources to process and forward regular call requests. Its computing abilities and performance are lowered and the clients are denied the service. Pawel Lawecki Page 65 VoIP Security in Public Networks
Requests may be targeted against any node of the VoIP network. VoIP server is the most obvious choice, but any intermediate device may also be attacked. Requests may be sent with any protocol the device supports. In case of a router it will be protocols up to Layer 3, but VoIP server is vulnerable to any protocol from the stack. Attacks like protocol based DoS can also be targeted against single VoIP clients. Different attacks could include techniques like [45]: MAC flooding, STP BPDU-Attack, IP spoofing, DHCP Starvation regarding attacks in the shared local access network, and Ping Flood, Land Flood or SYN Flood from any place of the network. Other attacks include [74]: malformed packets, packets causing buffer overflow, packet flooding, call tear down using ICMP error message, DHCP server impersonation, TFTP server impersonation. Probably many others exist and will appear in future, but the mechanism is always similar1. There are also VoIP related DoS attacks (described in the next chapter 8.Application Layer Analysis). However, regardless of the amount of packets, a single attacker is not able to cause a Denial of Service on a server that is able to process requests from thousands of clients. Due to that, attackers usually use malicious software to take over many devices and create a bot network. Such a controlled, distributed network of zombie-like devices may be used to perform a Distributed Denial of Service (DDoS) attack. It is the DDoS that is the real danger for the VoIP server. Since it uses many infected computers in various geographical locations, it is not easy to detect and difficult to protect from. At the same time the attacker stays anonymous, as he/she uses other clients as his/her tools. Additionally, DDoS may be used in two modes [73]:
direct attacks attacker uses daemons (zombies, infected devices) to send out packets directly toward the target. Common Internet protocols (like TCP, or UDP) are used with spoofed IP addresses. Only a few compromised hosts are sufficient. reflector attack attacker forces daemons to initiate attack that is reflected to some other device, like router or web server. Zombies send packets with a spoofed IP address which is this of the victim. In response to requests by attackers, reflectors flood victims with reply packets.
Moreover, instead of flooding a VoIP server with packets, the traffic could be redirected to a senseless location (that does not exist), using some underlying protocol's vulnerability. Because of the nature of DoS attacks, interruption of service threats may never be totally eliminated. One can filter out most of the DoS packets, but because of their surface validity some packets will still have to be processed. Full detection is impossible. But some solutions have to be found, as according to Symantec [51], there are currently above six thousands DoS attacks per day and Internet Service Providers account for 38% of this (and additionally 8% in Telecommunication sector).
7.2.5.
Unauthorized Device Control
If an attacker acquires control of one of the elements of the system, he/she may realize most of the existing threat types, and this without even being detected. While getting control over user's VoIP device or any other intermediate device of the communication channel has serious, but limited consequences, taking over a VoIP server could be fatal to the whole system. Obviously once a device is controlled any operation is possible. The attacker may eavesdrop the traffic, perform an undetectable (since it is a valid communication node) MitM attack, disable the device causing DoS. If it is user's device or a VoIP server then additionally configuration may be changed. Changing configuration of VoIP server could lead to an absolute
1 According to one of the sources, shares of protocols in direct DoS attacks are [73]: TCP (94 %), UDP (2%), ICMP (2%).
Pawel Lawecki
Page 66
control over the system by the attacker. In case of an access to VoIP client identity could be stolen leading to service abuse and misrepresentation, or even microphone of a device could be turned on without user's knowledge and sounds from the vicinity of the computer could be eavesdropped. In this context there is a question of storing VoIP client's or server's credentials. Taking over the device on lower layers does not necessarily have to lead to taking over control over higher, application layer. If for example credentials are required from the user at each login, then it may be difficult for an attacker to compromise VoIP functionalities. However, much more often user credentials are simply stored in the device's memory. Unauthorized access may be gained by many techniques. Attacker may use some malicious software, try to crack the password, or acquire valid access credentials in any other way, including physical. Malicious software may sniff the keyboard (detect what is being written) and send this information to the attacker. This may regard client's device or server directly typing in authentication credentials, or in case of a remote login any other computer. If the password is too simple, or not protected well enough it may be cracked. There are many cracking programs available that use different approaches just to mention vocabulary attacks (program tries to use different words as a password) or brute force attack (all possible symbol combinations checked one after another). The latter one may even use a combined processing power of a bot network. Very often users set some default credentials for example the same password and login name or use names of family members as passwords. In such a case password may be simply guessed. Last but not least, a hacker may use sophisticated methods of social engineering and simply try to convince the user, or administrator to give him/her the password.
7.2.6.
Physical Attack
Physical attack is usually the least probable technique an attacker could use, as it requires his/her personal presence and may lead to revealing his/her real identity. However, if successfully carried out, it may have severe consequences to the system. Physical attack may be realized in many ways. Intrusion, tampering with network devices, or simple vandalism could be called physical attack on purpose. Fire, flooding the building, turning off the electricity, or breaking network connection could be called by unaware human mistakes and lead to VoIP interruption of service. Different kinds of natural disasters, wars and terrorist attacks may also disrupt functioning of VoIP as general physical attacks damaging the infrastructure. Of course, unaware and general physical attacks are not sophisticated and may in most cases lead only to service interruption, by damaging some part of the network infrastructure. Purposeful attack, however, may lead to compromising probably every single security requirement. An attacker may get unauthorized access to the devices, manipulate, reconfigure, install malicious software or additional spying devices, or simply disable them. Attacking a single user is easiest, but does not lead bring any large scale profits. And since physical attack carries much risk, the attacker will expect to gain a lot. Of course attacking VoIP provider directly seems to bring most benefits in a VoIP public network. Once the VoIP server is compromised, service may be stolen and private data of thousands of users may be acquired. However, VoIP provider is also aware of that and will introduce complicated security measures regarding physical access. Therefore, an attack concerning access network is relatively of highest probability. The access to its physical infrastructure is much simpler and compromising it might already affect many users. The closer to the core network the attacker decides to attack, the more users are affected, but also the bigger is the risk of detection. Pawel Lawecki Page 67 VoIP Security in Public Networks
Attack against VoIP may also be performed indirectly. Not only the network infrastructure may be targeted, but also the power supply infrastructure. As already mentioned, VoIP requires independent electricity supply. Power is not distributed on the access cable as in PSTN (anyway not all VoIP access technologies use cables). It means that a power blackout may interrupt VoIP services.
7.3.
Underlying Layers Summary
It is clear that protocols underlying VoIP and necessary for its correct functioning have many major vulnerabilities. Exploiting them may lead to realization of many serious threats like for example eavesdropping, interception, modification or interruption of service. Therefore, the communication channel cannot be usually considered safe. Moreover, systems where end-clients and servers are installed are also often full of weaknesses and faults. Different kinds of attacks may even lead to complete take over of the device and compromise VoIP phone. Even though this threat is of smaller probability in case of hardware phones, it still exists. It was shown that the most popular access scenarios are usually safe. They implement different security measures in order to protect the clients (usage of such secure access networks will be discussed later in chapter 10.Public Security Platform). But even in case of the safest access network, its advantages may be eradicated with deployment of other network technologies between the end-user and access network, as it was shown on the example of Ethernet LAN. Anyway, the influence of underlying layers on VoIP is not very sophisticated. It could not be different as most of the attacks affect VoIP only indirectly and there are no complex functionalities in those layers. They can usually cause interruption of service or completely bring down VoIP system by attacking lower layer functionalities. The chapter has also proven that mapping of attack into threats is not simple. It is difficult to state what threat is realized by a given attack, since the attack may actually lead to multiple threats. Everything depends on the will of the attacker. Just to mention the example of Man in the Middle attack, where a hacker may decide to eavesdrop, modify, black hole traffic, cause interruption of service or even try to misrepresent other party of a VoIP call. Most of the time, attacks described in this chapter are treated by hackers as preliminary attacks against VoIP. They allow attackers to perform many unauthorized actions, like spying the network, rerouting packets, disabling service, stealing control of a device, etc. Therefore layers underlying VoIP have to be considered vulnerable and some security measures should be found to counteract their weaknesses.
Pawel Lawecki
Page 68
Application Layer Analysis
8. Application Layer Analysis
8.
As already said earlier, SIP has been chosen as the the VoIP signaling protocol for this thesis. Together with RTP that transports real-time media, both protocols provide most of functionalities necessary for VoIP on application layer. Therefore these are the two most important protocols mentioned in this chapter. Just as the previous chapter, Application Layer Analysis consists of two main logical parts. First, some overview of application layer architecture with description of vulnerabilities is given. Then most widely known VoIP specific attack techniques are introduced.
8.1.
Properties & Vulnerabilities

General Overview
8.1.1.
Application layer or so to say VoIP layer (VoIP specific protocols on application layer) has a different logical architecture from this shown on underlying layers. For VoIP, an available communication channel is assumed existing and just as shown by introduction of OSI layers in chapter 3.Architecture, VoIP service protocols may concentrate on setting up end-to-end connection.
Figure 32: SIP based VoIP system - general overview (set from [4] and [75]) Architecture of SIP signaling protocol was also introduced in the third chapter. Its most important elements are User Agents and SIP Servers 1. The latter, logically consists of Proxy Server, Registrar Server and Redirect Server. For protocols on the application layer only a few communication nodes exist and sometimes only end-nodes (one on each end of communication channel). Just as shown in Figure 32 signaling traffic travels between User Agents and SIP Servers. In the bottom part of the figure the mentioned architecture of SIP Server is shown. Another application protocol mentioned already earlier that has essential meaning for VoIP is RTP, also shown on the image. RTP transports voice (or other real-time content, like video)
1 Last of the mentioned elements Back to back User Agent is usually implemented as Session Border Controller and is a device used in private networks as a solution to NAT/firewall traversal problem. Admittedly, SBC is also discussed in public networks as a kind of delimiting device between providers, but it will not be considered here.
Pawel Lawecki
Page 69
data between communicating end users. It is worth mentioning that RTP packets travel directly between end users, not like SIP signaling through SIP servers. Of course communication may also occur between SIP servers and gateways, if transition to other than IP public networks is necessary. This may include for example PSTN - calls between SIP User Agent and PSTN Phone. In this case, as shown in Figure 33, both voice and signaling data have to travel to a gateway and there be translated to other protocols. In most cases VoIP vulnerabilities and attacks are considered here on examples of communication scenarios not including gateways and regarding UA to UA communication. However, a gateway is also a sort of a User Agent, as it actually terminates SIP/RTP call and initiates a new for example PSTN one. Therefore, almost all of the described issues consider SIP-PSTN scenario in the same way1.
Figure 33: SIP-PSTN telephony system - general overview
8.1.2.
SIP Provider
As already mentioned in chapter three, VoIP provider's internal architecture is quite complex and contains many functionalities. Obviously, many functionalities also mean a big vulnerability space and sensitive network elements. In Figure 34 a general architecture of SIP provider is shown. It contains only elements that provide application layer services. Additionally, entities related to private network problems are not shown in the figure. As said, compromising different elements may realize various threats. Of course, central element of this infrastructure is SIP Server. In case it is not Figure 34: SIP provider general architecture - application layer protected well enough, many vulnerabilities occur and all kinds of threats may be realized. Improper and insecure deployment of AAA server and billing system may occur in toll fraud and service abuse, what will bring financial damage to a provider. Compromising a gateway, grants the attacker access to free calls to
1 However, in case of Default Gateway the risk of an attack is much smaller, since it resides in a controlled environment provider's internal network.
Pawel Lawecki
Page 70
Application Layer Analysis the PSTN network.
Last two elements shown in the figure are of great importance for the whole society. Disruption or disturbing emergency positioning mechanisms may in effect lead to suffering or even death of people calling for help. Lawful interception in turn, provides a tool for fighting against organized crime and terrorist organizations. The functioning of both mentioned mechanisms is crucial for society and may lead to fatal events. Therefore it is required from providers by law and malfunction of those mechanisms may lead to public prosecution of a provider by state. Similar requirements regard ensuring users' privacy so protection of servers with users' personal data. Authentication between provider's servers and encryption of internal traffic is actually a necessity. If it is not ensured, different vulnerabilities occur and potential attacker, once he/she gets into provider's network may perform many malicious actions.
8.1.3.
Protocols
Not only underlying layers and computer system architecture have their vulnerabilities. The same regards application layer and its VoIP protocols, for example SIP and RTP. In case of RTP, most of its vulnerabilities effect from its simplicity. It is a real-time transport protocol carried by UDP. Its basic aim is to transport voice (or any other content) as quickly as possible. In order to do it, it has to give up all other complicated functionalities and be as simple. Only this way it can be processed quickly enough and not increase an already considerable overhead (see one of the footnotes in section PSTN vs. VoIP Comparison for detailed computation). Because of that, no complicated end-to-end relation is maintained and different kinds of insertion attacks may be performed. This results usually in interruption of service or in the best case higher computer resources consumption and lower quality of service. Other RTP vulnerability is related to encryption. Since encrypting the voice packets increases overhead and may lower the quality of conversation, users may often avoid using it. Not encrypted traffic may be simply eavesdropped or even modified, while using one of many attack techniques described in this and previous chapter. Since RTP is simple and does not provide many different functionalities, its vulnerability space is also quite small in comparison with SIP. Most of SIP problems, in opposite to RTP, effects from its complexity. Since IP core network is simple, it is SIP and applications in end-devices that have to provide most of the system functionalities. In case of SIP architecture (or VoIP in general) a simple rule applies either you have a clever network and dumb terminals or dumb network and clever terminals [76]. IP core network is as simple as possible, so SIP as a signaling protocol serving the terminals has to be clever. Not only most of system functionalities are available at end-devices and may be controlled by end-users, but also SIP headers are text based and open to modification. Because of that various kinds of session and registration hijacking attacks are possible, where some parameters of SIP header are modified by an attacker and control over the connection is intercepted. As SIP is a protocol just as any other, Denial of Service and Man in the Middle attack can also be performed using its vulnerabilities. It is difficult to say that Spam over Internet Telephony is caused by a system vulnerability. It is not related to any protocol and appears in a perfectly working system. It is caused rather by a misuse of service and is content related. However, it realizes one of the threats unwanted contact, and therefore it should also be mentioned in application layer analysis.
8.1.4.
Programming and Configuration
All the vulnerabilities that were mentioned so far, were enabled by design flaws within IP Pawel Lawecki Page 71 VoIP Security in Public Networks
telephony protocols or system architecture. However, as described in previous section, SIP is a complex and clever protocol that allows user to control behavior of VoIP to a great extent - it is possible to program SIP (this regards also other VoIP signaling protocols like H.323). Therefore, apart from protocol built-in vulnerabilities, there are some that may be caused by improper usage, programming mistakes and misconfiguration. SIP programming [6] allows user to control call processing logic. Depending on the aim of a signaling service, it may be programmed in different places of the network. For example call distribution or services for users that are not always on-line have to be implemented in the network. Others, like forward on busy operation may be programmed in both network and end-device. Finally, services like distinctive ringing live best in end-devices and it would be impractical to implement it in the network. There are three ways to program SIP that are suggested by IETF [6]: CGI, Call Processing Language (CPL) and Servlets. SIP-CGI Common Gateway Interface, follows Web-CGI a protocol for interfacing external application software with an information server. It is language independent any programming language may be used. Due to this, CGI programs are almost unlimited in their power. On the other hand programming errors may easily affect server. CPL is actually a special purpose call processing language it was created exactly to do this. It may be used by both SIP and H.323 servers, so is actually protocol independent. As a call processing language it has a limited scope and is less powerful than CGI, but provides higher server security. Java servlets are somehow a compromise between CGI's power and CPL's security. Java is admittedly a powerful programming language and may perform most of operations. However, its power is limited only to some virtual space, where it may be executed Java sand-box. Thanks to this it is clear for the executing server, what are the limits a Java programmed service can do. This way security is provided. In Table 9 a summary of RT code admin. the described language verification policy properties is shown. As can Highest, any binaries may no no yes CGI be seen, be executed principal Medium, all commands differences no yes yes Servlets known to Java Virtual may be Machine may be executed presented as Lowest, only CPL commands may be a trade off yes yes yes CPL executed between generality and Table 9: SIP programming - generality vs. security [6] security [6]. The more, the given call processing language can do, the more vulnerabilities it has and is potentially more dangerous to SIP server, or end-device. The choice of programming method may look difficult, but usually one would choose the highest security language that can perform a requested call processing operation. In simple words security, but not for the price of functionality.
Generality
Security by
While it is possible to describe general properties of each of those programming methods it is impossible to state exact vulnerabilities and attack techniques, as these absolutely depend on the implementation. Due to this, possible attacks will be different for each network and sometimes even for each end-user. It is quite difficult to state, what is actually the seriousness of VoIP vulnerabilities resulting from wrong programming. According to NIST Computer Security Division's ICAT project, in Pawel Lawecki Page 72 VoIP Security in Public Networks
Application Layer Analysis case of computer systems [77]:

only 5-8% of vulnerabilities are configuration issues, only 16-31% of problems are due to bad design practices, about 60-80% of the flaws are implementation mistakes made by programmers.
Obviously, in VoIP system programing is much less complex and sophisticated process than in most of other IT applications. Therefore, it is relatively small problem in case of SIP programing and most vulnerabilities lay in protocol field anyway. However, as VoIP systems will be developed and become more complex in the future, it shows some trend. Probably with time, significance of programing flaws will grow. As to other applications that are VoIP related, for example softphones, this may be a problem already, but is also different for each implementation.
8.1.5.
SIP Sequence Flows
There are some basic SIP operations that take place in any implementation, that are worth mentioning and investigating a bit closer. It is because they show some general SIP properties and potential vulnerabilities. The most fundamental mechanism in SIP architecture is registration [4]. Each client, in order to be able to receive and generate calls, needs to register his/her presence on Registrar Server. At the same time a client provides information about, where he/she is available location IP address. So apart from notifying server about presence status, registration also provides mobility. Registration is performed as showed in Figure 35. User Agent sends to Registrar Server a Register request containing his/her location IP address (1). Server stores this information in some Location Database (2) and acknowledges it to the user (3). If no proper authentication of Register request is performed, a potential attacker may register in place of a valid user. This may cause that he/she will be able to misrepresent the victim, abuse services (charging) by generating outgoing calls or replying incoming ones. In Figure 36 another sequence diagram is shown. It presents a standard call initiation [4] [24] [75] in SIP, where a user Alice is calling user Bob. In order to initiate a call Alice sends an Invite request to her Proxy Server with a sip address of a called party (1). Proxy Server (if the called party is not on the same server) checks up IP address of Bob's Proxy Server (2,3) and forwards Invite packet (4). Upon receiving it, Bob's Proxy Server retrieves IP contact address that Bob submitted with his Register request (5,6) and forwards invitation directly there. Once Bob answers the phone, session is established, RTP packets are started to be sent and conversation may take place. When Alice or Bob decide to hang up the phone a Bye request is sent and the call is finished. A vulnerability space in case of a call initiation is also considerably big. Attacker may try to eavesdrop, disrupt or take over the call. He/she might also try to redirect the call and misrepresent the called party. Namely, many different threats could be realized here, if no proper security steps are undertaken. Pawel Lawecki Page 73 VoIP Security in Public Networks Figure 35: SIP - user Agent Register operation [4]
Figure 36: SIP - call initiation (set from [4], [24] and [75]) Figure 37 shows a SIP solution in case a user is going to be connected to some other Proxy Server temporarily, or for good. This method is call redirection and it may for example regard redirecting calls to the Proxy Server of a company, where Bob works. The scenario shown in the figure omits some of the steps shown already in previous image. After receiving Invite packet from Alice's Proxy Server (1) Bob's usual Proxy Server finds out that Bob is available under different location (2,3). Therefore it sends a Moved temporarily reply and provides address of the Proxy Server, where Bob is currently connected (4). Due to this Alice's proxy transmits another Invite request to another location Bob's company (5). Proxy Server of the company checks up the internal network IP address of Bob in its Location Database and forwards call invitation to this location (6). SIP call redirection mechanism is also a sensitive element of the system. Attacker may use it to perform unauthorized call redirections and misrepresent the caller or called party. It is also possible to use this mechanism in order to perform MitM attacks and redirect victim's traffic through hacker's computer. This way misrepresentation requirements could be compromised and confidentiality, privacy as well. Last example of a standard SIP sequence flow is presented in Figure 38 and regards adding more than a single location, where a user is available. SIP call forking enables storing two or more IP location addresses to a Location Database. This way, upon receiving Invite request from other party (1) and finding out that Bob registered more than one location (2,3) Bob's server will forward invitation to two stored addresses (4). This way for example both Bob's User Agents may be called at the same time home and mobile. He is able to answer the one that is more convenient for him. Pawel Lawecki Page 74 VoIP Security in Public Networks
Call forking might be used for incoming call hijacking and misrepresentation if an unauthorized location is added to Location Database. However, more probably, the mechanism can be used for creating fork loop and by amplifying amount of meaningless locations Denial of Service attack may be achieved.
Figure 37: SIP call redirection (set from [4], [24] and [75])
Figure 38: SIP call forking Most of the time, the attacks mentioned above may be detected afterwards. Usually network administrators monitor the traffic and use log or trace files to store information about the traffic. This way, some faulty configuration or misuse may be eliminated.
8.2.
VoIP Based Attacks
By investigating attacks against VoIP on application layer, many sources are helpful. Problems with VoIP are not so well defined, as new emerge every month and it is really hard to find a source that would cover all attack types. Pawel Lawecki Page 75 VoIP Security in Public Networks
8.2. VoIP Based Attacks
One should also state that distinction of attack techniques between underlying and application attacks is sometimes unambiguous. Many attack techniques on higher layers require performing some lower layer attack first. This complicates classifying some problems and blurs the mentioned division.
8.2.1.
Call Pattern Tracking & Eavesdropping
Call pattern tracking is in other words VoIP signaling (SIP) traffic analysis. A hacker may obtain some details about calls of other users, if he/she is able to analyze some traffic streams that are not protected enough. This is possible even in case of an encrypted traffic some elements usually stay visible in clear. In such case attacker can compromise traffic analysis requirement and find out some details of the transmission. Additionally techniques like number harvesting (storing all the called and calling numbers) may lead to SPIT, so unwanted contact. Of course call pattern tracking is always possible when an attacker has full access to victim's traffic. This regards for example non-encrypted traffic in shared medium or any other attack that lets attacker see packets of other users in clear. Not only call pattern tracking is then possible, but also eavesdropping of the whole transmission, if RTP packets are available to attacker and not encrypted. Either non protected traffic, or traffic interception may lead to compromising one of the most critical requirements confidentiality.
8.2.2.
SIP Based MitM
Session Initiation Protocol just like any other protocol has its vulnerabilities. Due to this, it is possible to perform a Man in the Middle attack also on VoIP layer. Two types of MitM attack were described in the previous chapter. In order to put himself/herself between the communication endpoints an attacker could either compromise one of the valid communication nodes, or add himself/herself as a new node while using some protocol's weakness. Since compromising and taking control of a valid VoIP node requires attack on underlying layers, only the latter MitM type may be considered in case of SIP. A simple example of a SIP based MitM attack is shown in Figure 39. It is based on a 3XX response code attack [46], a family of responses that are responsible for call redirection. Upon detecting that the victim has issued an INVITE request (1), the attacker responses with a 301 Moved Permanently (or 302 Moved Temporarily, in case of a single attack) code (2) and pretends to be a location, where the called party is now available. Therefore the victim issues a new INVITE request to the attacker (3). Hacker forwards the call (4) and communication through his/her device is established. Figure 39: SIP based Man in the Middle attack - 3xx response code attack [46] An attack similar to this may include spoofing proxy and usage of 305 Use Proxy code. This way communication between proxy and User Agent could be redirected. However, such an attack is more complicated.
As said at the beginning, the attack shown in Figure 39 requires that the attacker detects the original INVITE request first. This, as described in the previous chapter, may be achieved if the traffic is traveling through a shared medium, or some underlying layer attack was performed. Additionally, the described attack is possible, if messages are sent in the clear, what allows an Pawel Lawecki Page 76 VoIP Security in Public Networks
attacker to see the content of the initial INVITE message and no strong authentication method is used, what allows the attacker to send Moved Permanently reply. In order to perform most of SIP MitM or misrepresentation attacks redirection of traffic on lower layers is usually required. This is usually MitM attack on some of the underlying layers. It is because the attacker needs some insight in the victim's signaling traffic to collect it and be able to modify and resend. Actually in order to perform MitM and misrepresentation VoIP layer similar techniques are used. Both require traffic redirection, but only MitM includes forwarding the traffic. The difference depends only on the attacker's decision in case of MitM he/she will redirect the traffic from one of the parties and forward it to the final destination, in case of misrepresentation he/she will pretend to be the final destination. SIP based MitM has similar consequences to any other protocol based MitM attack. It allows the attacker to eavesdrop, modify, block the traffic, or even misrepresent the end user.
8.2.3.
Registration Hijacking
Registration Hijacking [78] technique uses some of the SIP vulnerabilities, in order to completely steal identity of a victim, by hijacking its connection to SIP Server. An attacker uses weaknesses in registration mechanism, providing mobility in VoIP. The basic principle of the attack is shown in Figure 40. As can be seen, in normal case Alice regularly sends registration packets (1) in order to update her location and keep User Agent on-line. Ted performs a Denial of Service attack against Alice's device (2) in order to out date her registration record in the Location Database. Communication between Alice and server is broken and her location information, not updated regularly is removed from Location Database. Any other deregistering attack is also possible here. Once Alice is not registered anymore, Ted sends his own registration packet (3). It is in most cases an intercepted packet that Alice sent earlier, but with an overwritten IP address, where Alice is available. Moreover, Ted needs to generate a registration racecondition, i.e. send repeatedly REGISTER requests in a timeframe shorter than Alice. This way her legitimate registration is overridden, even after the DoS attack is stopped. Thanks to regular requests Ted's registration packet with a modified IP address is stored in Location Database Figure 40: SIP registration hijacking [78] (4) and acknowledged by Registrar Server (5). Once the attack is successful, any incoming call is forwarded to Ted. A caller might think he/she reached Alice's device and is speaking to somebody trustworthy. Just as in the previous attack, some conditions have to be met, in order for this attack to occur. The signaling messages have to be also transmitted in clear, so that the attacker could intercept, read and modify them. Additionally, system cannot have any message integrity or replay attack detection mechanisms. In some cases the described registration hijacking will work, even in case a remote SIP Proxy (callers Proxy) requires authentication of user registration. If Alice's SIP messages were Pawel Lawecki Page 77 VoIP Security in Public Networks
transmitted in clear and Ted could capture them. Once modified, those almost valid packets may be replayed and this way allow authentication to remote Proxy. Successful attack of this type may compromise confidentiality and privacy, by misrepresenting a victim.
8.2.4.
MitM Based Attacks
Two attacks mentioned above did not require any sophisticated preliminary actions. They required interception of only single packets (like INVITE or REGISTER) and general knowledge about the victim, but performing a constant MitM attack was not necessary. However, performing a MitM attack (does not matter on what layer) may increase control of an attacker over the traffic and endanger VoIP system, even if default authentication methods are used [79]. Being in the middle, between two valid communication nodes, allows an attacker to see every single SIP packet. Of course they have to be transmitted in clear for the hacker to be able to understand them, but once intercepted and analyzed, every single packet can be modified. Many implementations use authentication methods by each action performed by a user. While it helps to eliminate some dangers, the mechanisms have their vulnerabilities as well. Most often used authentication method, which is HTTP Digest [80] is sending most part of the packet header in clear and only some SIP parameters are encrypted for the sake of authentication. This method does not provide full message integrity protection, even if it detects replay attacks. Because of that, a MitM attacker can modify some packet parameters before forwarding it to valid recipient. In top part of Figure 41 an example of such attack is shown. As a preliminary action, Ted performs a Man in the Middle attack, to redirect Alice's traffic and put himself between her and SIP server. Thanks to this, he is able to control SIP registration of Alice's User Agent. Alice sends Register request (1) that may be forwarded by Ted without any modifications (2), as authentication is necessary and a simple Register packet would not be accepted by SIP Server anyway. Instead, server replies with a Nonce (3) that is supposed to check user's identity. Nonce is also called a challenge, as it challenges user's knowledge and Figure 41: SIP MitM based hijacking attacks [79] - registration (top), checks if he/she is outgoing call (middle) hijacking and initiating outgoing call (bottom) able to provide authentication credentials. In order to reply a nonce user needs to know a password, therefore Ted forwards it to Alice (4) and lets her answer it. Alice sends her Response packet (5), where her password is encrypted with an MD5 algorithm and hashed. Some SIP parameters are also included in the hashed (encrypted) part for example a part allowing the server reply attack detection. However, most part of the packet header is send in clear and location IP may be overwritten. Ted uses this possibility and sends a Response with his own IP address, instead of Pawel Lawecki Page 78 VoIP Security in Public Networks
Application Layer Analysis Alice's.
The described scenario is shown on the top part of the figure. It results with registration hijacking. Incoming calls are directed to Ted, instead of Alice just as in the previous presented attack method. Here, however, it is successful even though a default authentication method1 is used. The middle part of Figure 41 presents another possible usage of MitM attack in SIP session hijacking. In this case an outgoing call may be taken over or redirected. The attack shown in figure assumes that Ted did not modify a Response packet (5) and simply forwarded it to SIP Server (6). The real attack starts, when Ted receives an Invite request for call set up (7). Invite packet is also required to authenticate in most cases, but just as in registering reply only some part of the SIP header is hashed. Due to this, Ted may modify for example the called number and redirect call (8,9,10). It is very dangerous, since she would think she called somewhere else. If, instead of forwarding an unmodified Response request, Ted does modify location IP (6) he may hijack the session and call the number chosen by Alice (8) or modify the number and completely take over the connection (6,8). This way many different attacks are possible to occur. Ted may completely take over and steal incoming and outgoing calls, but also redirect an outgoing call Alice is trying to do. There is one disadvantage for Ted, while performing this type of attack he might act, only when Alice (or some other valid user in case of incoming calls) is doing something. He cannot simply initiate an outgoing call on his own. It is because different challenges are generated every single time and the system is usually able to detect reply attacks. The bottom part of Figure 41 shows an attack, where Ted modifies IP address (6) and then is able to generate outgoing calls (7) on its own. Such a scenario, however, is possible only if no proper authentication mechanisms exist at call initiation. MitM based SIP session hijacking attacks are dangerous, as they may be carried out even in case of default authentication methods are working correctly. As a consequence of such an attack, a hacker may compromise almost every single security requirement and realize most of threats. All MitM issues mentioned above regard SIP signaling traffic. However, RTP media stream is also intercepted, what endangers also the content of the call. Even if an attacker decides not to modify signaling traffic in any way, he/she might still modify voice content. It is difficult to say to what extent such an attack is dangerous, since voice processing software is not so developed up to date. Due to this no sophisticated attacks against media are possible yet, but this problem may occur in the future. Last but not least, an attacker could use regular update mechanisms to install some malicious software on devices where User Agents are normally running. Upon detection of update request a Man in the Middle attacker could transmit his/her own software to the device. This regards both software and hardware VoIP phones.
8.2.5.
VoIP Specific DoS
In the previous chapter many different types of Denial of Service attacks were described. As in case of any protocol, DoS may also be performed, basing on SIP packets. Moreover, since SIP has more functionalities and is more complex than underlying protocols, the actual impact on VoIP availability may be much bigger for SIP flooding. Obviously all basic DoS principles described in the previous chapter also hold here. Denial of Service attack may be direct or reflected. It may be caused by single compromised devices or
1 It is for example a default authentication method in Asterisk server [81] one of the most popular implementations of IP PBX available on the market. Its popularity is additionally enhanced, as it is open-source and freeware.
Pawel Lawecki
Page 79
Application Layer Analysis by a distributed network of virus infected machines.
From the attack type point of view, SIP based DoS could be divided into three basic categories [82]: flooding attacks and message flows attacks. Each of them influences VoIP network in a different way, but all result in a potential DoS. Flooding attacks [83] is a huge Server (or other VoIP nodes) by processed by those devices. This functions described in the previous

family of different techniques allowing to compromise SIP flooding it with seemingly valid packets that need to be family also includes attacks on underlying communication chapter. Generally flooding attacks could include:
replaying any valid intercepted SIP packets each of them is analyzed and sometimes replied by the targeted device, DoS attacks against authentication mechanisms - a lot of computation power necessary to check users identity hash encryption functions, etc.), memory exhaustion attack targeted against state maintenance in SIP servers, CPU attacks message parsing [82], security checks, application execution, etc., amplification attacks [76] based on malicious usage of loops and forking.
Obviously these are only some of possible examples. Attacks could be also more complicated and include interaction of SIP server with other devices like DNS server, application servers, gateway, etc. Any way of artificial increasing of traffic or taking memory and/or CPU on a server may be used by an attacker. Another type of DoS attack is called message flow attack. In opposite to flooding attack it does not try to increase the usage of any network resources. Instead of that, it uses methods to end or terminate a session, cancel an invitation, redirect a call and update session parameters [82] to disrupt on-going or set-up communication. SIP requests, like: Cancel, re-Invite, Bye or Update may be used to achieve this aim. In Figure 42 general principle of such attacks is shown. At some step of transmission between two users in this case Alice and Bob, an unauthorized SIP request is send by an attacker Ted. The aim of the message is either to tear down the connection (Cancel/Bye) or modify session parameters without knowledge of valid users and unable session establishment (Invite/Update). In sequence diagram underneath the figure Ted sends unauthorized messages to SIP Server claiming to be Bob. However, any other participant of the transmission
Figure 42: SIP message flow DoS attack (composed using [82]) could be cheated in the same way.
Additionally, there are two other requests that may be used in a similar way by an attacker to perform DoS attack Refer and Info [82]. Unlike flood attacks, message flow DoS is possible only if no proper authentication Pawel Lawecki Page 80 VoIP Security in Public Networks
Application Layer Analysis mechanisms are implemented.
Other SIP DoS attacks could include call redirection (using for example 3xx code responses) to not existing locations. In case of SIP MitM call could be also black holed and all communication between valid end-nodes blocked. Worms and viruses may be created in order to affect VoIP functionalities in a direct way. VoIP software and hardware phones could be completely disabled. Bot networks could generate SIP based Distributed DoS and flood any VoIP network. However, signaling protocol based Denial of Service is not the only problem that may cause service interruption. There are other attack techniques that may be used using different protocols. This could be for example insertion attacks [46]. Instead of tampering with signaling, an attacker inserts rouge RTP packets in a RTP stream. This, obviously, confuses both enddevices, may cause transmission errors and the session might be interrupted. It has been mentioned earlier that encryption of media traffic stream increases overhead. Some way of authenticating every packet would be even more resource consuming. Due to this, performing media insertion attack may be sometimes very simple and availability could be easily compromised. Different techniques of insertion attacks include: SSRC Colllision attack, SSRC manipulation, codec manipulation or RTCP insertion attacks.
8.2.6.
Impersonation Attacks
Impersonation attacks are all techniques, where an attacker pretends to be someone else than he/she really is. This may regard client impersonation as in registration and session hijacking, or server impersonation by Man in the Middle attack. There are other impersonation methods that may be used differently. One of them is manipulation of Caller ID or Calling Line Identification (CLID). It is one of the most trivial application layer attacks against VoIP [48]. An attacker substitutes someone else's telephone number in place of his/her own. This way an invalid number is displayed to a victim by an incoming call. In order to spoof Caller ID, an attacker may use services of one of many spoofing providers. For a small fee it is possible to call any number with your own substituted. Moreover, some IP PBX software, like for example Asterisk allows CLID spoofing. As a result of this, an attacker may even install his/her own PBX and use it to call other users, while spoofing Caller ID. Caller ID masquerading may seem harmless and good for making jokes. However, it may compromise caller number based authentication schemes. Since it is very often used for example in banking services access, its impact on security may be significant. Impersonation attacks may also be much more sophisticated and regard combining a few different methods. For example, apart from spoofing Caller ID, an attacker could also use some social engineering techniques to additionally increase credibility. Voice processing methods are probably not so advanced yet, to allow substitution of attacker's voice and try to imitate victim. It will, however, probably change in the future and any misrepresentation of content will be possible (then will appear the question just how genuine this artificial voice really is). As described in threat taxonomy, an attacker may also try to misrepresent rights and authority. Another type of attack may include server impersonation while contacting a gateway. This way a user could get a free access to VoIP->PSTN call services, which causes theft of service and financial losses to a provider.
Pawel Lawecki
Page 81
8.2.7.
Toll Fraud Attacks
Toll fraud attacks are meant to simply steal telephony services [48]. The elements that collect and store details about conversations that took place, take care of billing and prepare invoices are located in VoIP provider's network. To be exact SIP Server, AAA Server and Billing Server. Due to this all toll fraud attacks are targeted against those elements. Obviously, attack techniques that may be used against servers depend on implementation and established security measures. However, there are some known attack techniques that may be used against poorly protected system. They are described in Chris Robert's Voice over IP Security [48]:

compromising VoIP network and place calls as if they originated from inside of the network if this is a criteria granting service, compromising voicemail system and programming mailboxes to accept third party billed calls, charging international calls to a telephone number by employing a third number billing scam, exploiting default settings in automated attendant functions to locate long distance trunks, impersonating an IP Telephony signaling to place free phone calls, compromise gateway and fake call termination messages to stop billing but leave the media path open.
8.2.8.
Identity Theft
Identity theft is a technique that works by stealing valid user identification credentials. An attacker owning login and password of a victim may use his/her identity and cause all kinds of threats to VoIP systems. Moreover, from the point of view of security mechanisms, everything works well. All security requirements may hold, but the system will still be compromised. An attacker will be able to misrepresent identity and abuse services, as his/her calls will be charged on victim's account. Usually it is the legitimate user that detects that his/her identity was stolen and undertakes appropriate actions. A victim notices that his/her billing is wrong and he/she has been charged for not used services. Because of that it is very important for such a system to ensure that in case of identity theft, a legitimate user may retrieve his/her credentials (get new one). User identity may be stolen in many ways. Most obvious methods include compromising communication channel by traffic sniffing, or MitM attacks. In case of non-encrypted, or trivially encoded (Base64) authentication packets, an attacker may come into possession of user credentials. Of course if he/she manages to eavesdrop communication channel first. Other way is to compromise user's device. Basic computer weaknesses and attack techniques against them were described in the previous chapter. Viruses, worms, Trojan horses may gain unauthorized control1 or install keyboard sniffers in order to eavesdrop an entered password. Last element of the communication system that may be compromised in order to get user credentials is SIP server (and to be more exact, its part storing authentication data). As SIP server runs on a complicated computer system, just like user's device, most attacks that may be used against client are also dangerous here. However, as already described in the previous chapter, servers are usually much better protected. Additionally, there are some direct attack methods that try to convince a user to share his/her
1 If the attacker has access to the user device he/she may usually also retrieve the credentials stored there. It may be extracted in case of passwords stored for example in the registry [79], but also in case of more advanced methods, like for example Windows Credentials Manager (Skype uses it CryptProtectData [84]) - which can be also hacked [85].
Pawel Lawecki
Page 82
credentials. A hacker may simply call a user and use social engineering means to present himself/herself credible. Another possibility might regard VoIP phishing. Just as in email phishing a seemingly legitimate message is sent to a user that requests immediate contact with some institution and gives a call back number. Just by sheer coincidence (many messages of this kind sent so it results from probability) the user might be using services of this institution. Call back number is almost the same as original one, so the user might not notice it and simply use the number given in request. Once the number is dialed, an automatic voice system requests user's password and login. The user types it in with phone keyboard just as in the original institution's system and his/her identity is stolen this way. VoIP phishing may regard SIP credentials, or any other service running on top of VoIP. Obviously user credentials that are too simple, may simply be guessed or cracked. In such a case none of the described above, sophisticated attack methods is necessary.
8.2.9.
SPIT
SPam over Internet Telephony (SPIT) [74] [86] is another complex threat that actually does not need any system vulnerability. It is because this threat is content based and results from malicious usage of VoIP services. Internet Telephony spam calls are generated automatically and bomb users with hundreds of publicity messages. Unlike in email spam, however, SPIT content is real-time based. Therefore it cannot be filtered out and prevented before the telephone rings. Moreover, voice spammers usually use Call ID masquerading and forge SIP identities. Because of that, a user usually cannot simply reject the call, as he/she does not know who is calling and in the worst case can receive the same SPIT call all over again. Moreover, impact of unwanted contact on user is much bigger in VoIP than in case of email. A telephone call interrupts user immediately. He/she gets distracted in an unexpected moment, not by mailbox checkup as in email. Additionally, during a SPIT call the telephone line is occupied, so one could say that it compromises availability requirements to some extent. In case of a voicemail bombing [48] (Vbombing) attack service may be totally interrupted and lead to Denial of Service or at the very least cause service disruption. An attacker delivers multiple voice mail messages to a user and simply floods his/her voicemail. An attacker could also compromise voicemail server directly and store SPIT messages there. Additional issue that makes SPIT a very powerful tool is the cost. In most cases calls inside a VoIP networks are free of charge, so SPIT calls may be generated without any factor that limits them. But even in case of paid networks open architecture of IP based systems makes it possible for hackers to generate unauthorized calls. This in effect could even affect the traditional PSTN networks, if gateway is somehow compromised. Attackers may use different methods in order to collect a user number for SPIT calling. VoIP network may be sniffed in order to perform number harvesting, what was already mentioned. Other examples include random generation of numbers or SIP directory harvest attack [87]. In case of the latter, careless configuration may cause that upon receiving a request from the attacker all contacts stored on server are returned to him/her. Finally, a most trivial solution may to use electronic telephone book, if such is available.
8.2.10.
Social Attacks
Just as in case of underlying layer analysis physical attacks against the infrastructure could lead almost to every single threat, the same may regard content based attacks on application layer. It is not hard to imagine that an extraordinarily convincing attacker may acquire a lot of information through simple conversation.
Pawel Lawecki
Page 83
In such attacks a hacker could for example call unaware users and introduce himself/herself as a member of provider's staff and request some credentials. End-users usually lack technical expertise and it may be simple to convince them to do that. Provider's workers are much more qualified and are aware of most dangers, but still by a careful manipulation a hacker could get some sensitive information. In order to achieve it, hackers use social engineering [88]. Social engineers aim against the weakest element of any security chain human. They usually try to manipulate someone into sharing sensitive information. The person is not aware at all of what is happening. According to Kevin Mitnick, an infamous American hacker: the human factor is truly security's weakest link [88]. Social engineering methods comprises many sophisticated techniques and play with people's emotions and trust. Very often a combination of both social and technological attacks may be performed to increase the credibility of an attacker. In social engineering, a hacker usually misrepresents authority, rights or identity. Therefore, authentication and authorization security requirements are compromised.
8.3.
Application Layer Summary
Application layer mechanisms are much more complicated than underlying generic Internet protocols. Just as lower layer protocols they have many vulnerabilities and weaknesses. Therefore, numerous attack techniques that allow to exploit them has been created by hackers. The consequences of attacks targeted directly against VoIP layer are often critical. All the threats mentioned in the previous chapter may also be realized here. Additionally, clients may also be misrepresented, their calls rerouted and identity stolen. VoIP services may be actually used against them, as in case of SPIT, or be misused and their account may be charged with calls that were carried out by the attacker. Some of the attacks are also performed together with lower layer techniques, for example Man in the Middle attack. They could also include sophisticated manipulations of users with social engineering techniques. The bottom line of application layer analysis is that VoIP layer is also very vulnerable and has many potential problems. They could lead to very serious consequences and therefore should be counteracted. Some security measures should be found to protect VoIP protocols.
Pawel Lawecki
Page 84
Solutions Analysis
9. Solutions Analysis
9.
Solutions Analysis
Two previous chapters have shown a large amount of vulnerabilities and attack techniques that may be used against VoIP. Different types of attacks may be used against various elements of the communication system. Therefore some flexible and comprehensive security framework is required. Only this way VoIP's security requirements may be ensured. Obviously, there are many solutions for IP based networks' problems that are already available. As VoIP is just another service offered on top of an IP network, it may try to reuse them. As there are many available security technologies, they need to be analyzed, compared and their usefulness to VoIP needs to be determined. Some other, VoIP specific problems, need to be taken care of separately and specific solutions need to be found. As said, the available solutions have to be analyzed. Many factors need to be taken under consideration and it is not just their level of security. Ease of use is definitely important for any average user. Cost and complexity, in turn, play a big role for provider. Probability of occurrence of a given attack is important for the whole system. Such properties need to be considered in order to ensure that implementing a security solution will not cause more problems than the potential attack. This chapter contains investigation of all the described issues. First, some final overview of existing problems is given. Then, comparison and description of available security solutions is presented. Next, in the chapter with risk analysis, all important factors of security measures are analyzed and their usefulness to VoIP's problems is assessed. Finally, the solution issues are summarized and some conclusions are drown.
9.1.
Existing Problems
The main problem with the Internet and its leading transport protocols is that they were originally created for a (relatively) small network interconnecting American universities in the last century. Development of the network to the size that we know today was obviously not assumed back then. Serious security problems of todays IP world could not have been foreseen either. Therefore underlying protocols contain many serious vulnerabilities. The most obvious solution to change the protocols of traditional TCP/IP stack in order to eliminate those weaknesses would be certainly the purest one. Unfortunately, since functionalities of the Internet protocols are implemented in billions of devices all around the world, this is simply logistically unfeasible. There are of course safe access scenarios, like those shown in chapter 7.Underlying Layers Analysis. By adding additional security functionalities to underlying layers, most of weaknesses resulting from vulnerable IP related protocols and their architecture are eliminated. However, those access technologies are safe only if the access provider deploys them correctly and ensures correct functioning of all available security measures. The average user has no means and necessary technical expertise to check, if his/her access technology is implemented according to all security standards and implementations. Moreover, most of the users do not even know what their access technology really is. VoIP provider has no means to determine security of an access scenario either. As said, there is usually no cooperation between access and service providers in public IP network with completely open architecture1. Due to this, there can be no absolute certainty that access network of a given VoIP user is safe. All these properties make clear that any security solution should be independent from the lower layers. Security measures, should simply assume that the communication channel is
1 Some possibilities of such application are described in chapter 10.Public Security Platform.
Pawel Lawecki
Page 85
Solutions Analysis not safe.
9.1. Existing Problems
Obviously, underlying protocols are not the only ones that are vulnerable. VoIP protocols also have their weaknesses and faults that may be exploited by a potential attacker. Some attack techniques that may be used against VoIP, have been present in the IP world for a long time and are also used against common Internet underlying protocols. Others are VoIP specific and use its specific vulnerabilities. Some of them use simple protocol weaknesses of basic VoIP mechanisms, while others may even use sophisticated human manipulation. Different elements of the system may be targeted in order to achieve different aims. Therefore any security solution has to also counteract VoIP vulnerabilities and solve its weaknesses. The summary of the described attack techniques exploiting numerous vulnerabilities is shown in Figure 43. Solutions have to handle all of them. Moreover, solutions should be as simple as possible and at the same time neutralize as many attacks as possible. This makes it cheaper and easier to use. It also limits any vulnerability space of
Figure 43: Main security problems in VoIP security measures as they obviously also have it.
From the point of view of finding a security solution, the best way to categorize the mentioned attacks is the way they affect VoIP system. One could specify three main types of attacks:
attacks against communication channel are attacks that try to influence voice packets traveling over shared medium. These are for example: traffic sniffing, MitM attack, call pattern tracking, call eavesdropping, registration hijacking, MitM based attacks, impersonation attacks, attacks against end-devices try to influence VoIP system by direct attack against end-devices hosting voice services. These are for example: malicious software, unauthorized device control, toll fraud attacks. One should also remember that enddevices are a part of communication channel as well and by direct attack against enddevice all channel threats may be realized, content based attacks affect services provided by VoIP. These are for example: DoS attacks, identity theft and SPIT. Some property of the service or content is mishandled, although no system vulnerability actually exists, direct human attacks are realized when attacker overcomes some system Page 86 VoIP Security in Public Networks
Pawel Lawecki
Solutions Analysis
9.1. Existing Problems
protection mechanism by direct interference either by physical action or interaction with other users. Hacker can either attack VoIP network on physical layer, by tampering with the infrastructure - physical attacks, or tries to affect the system through its users - social engineering. Certainly, such categorization allows easier finding of solutions. Communication channel attacks should be neutralized by finding some reliable mechanisms for protecting data between two end-devices. This could include strong end-to-end authentication of both parties, with elimination of MitM attack and encryption of the traffic between them. End-devices need to be particularly protected against all unauthorized intrusions and misuses, as they host most critical VoIP functions. Protection could for example mean installing some firewalls or antiviruses. Specific solutions should be found against problems that use VoIP service properties. Even though they seem legitimate, they carry some dangerous content. These are automated publicity message in case of SPIT and senseless content in Denial of Service. Identity theft is also an example of such an attack although the packets seem to come from a legitimate user and all valid credentials are provided, it is still not the user. Such attacks are most difficult to handle and they require special approaches for each of them. Last but not least, there are all kinds of attacks that do not directly influence computer system. They may regard attacking physical infrastructure of the system, or manipulating persons that use it.
9.2.
Available Solutions
Encryption
9.2.1.
Encryption [89] [75] [90] is a basic way to protect traffic stream in an unsafe communication channel. Its purpose is to allow protect VoIP stream from unauthorized reading. Only legitimate end-users and necessary communication nodes, like proxies are allowed to see it. In order to encrypt, one needs three basic elements: encryption algorithm (usually some complicated mathematical operation), encryption key (some large binary number, usually different each time), the message itself. One can categorize encryption algorithms in different ways, but probably the one that is used most often differentiates between key distribution approaches. There are two encryption algorithm categories regarding this issue: symmetric and asymmetric key algorithms. Symmetric key algorithm bases on a shared secret. Both (or more in case of a conference) parties that take part in the communication have to know some secret key. A party that wants to send a message uses the secret key to encrypt it and the party that receives uses the same secret key to decrypt the message. Obviously, in such an approach the biggest challenge is the distribution of those secret keys. One has to ensure that only the authorized parties receive it. Asymmetric key algorithm bases on pairs of two types of keys private and public. Public key of each user is made available to the others, while his/her private key has to be safely stored and stay secret. The encryption algorithm itself works in such a way that a message encrypted with a public key can only be decrypted with a private key. It is achieved by some sort of a one way mathematical operation. This way, when Alice wants to send some content to Bob, she uses his public key to encrypt the message and Bob decrypts it with his private key. Both types of key algorithms are presented in Figure 44, together with message sending exemplary scenario. Appropriate keys are used for both methods.
Pawel Lawecki
Page 87
Solutions Analysis
9.2. Available Solutions Certainly, also in case of asymmetric scheme distribution of keys might be a problem. How may Alice be sure that it is really Bob's public key? If a MitM attack is performed, a hacker might succeed in delivering his own public key to Alice. This way, even though Alice encrypts the message and makes it safe on the communication channel, the security is compromised because of a poor authentication. However, the advantage of asymmetric key algorithm over the symmetric one is obvious. The latter, needs confidential distribution of key, what actually means that other secure connection has to be used to do it. Moreover, transmission between each two users would need another key other key for communication Alice-Bob and a different one for Alice and for example John. Otherwise, John could
Figure 44: Encryption - asymmetric and symmetric key algorithm decrypt messages from Alice to Bob.
In case of asymmetric algorithm one needs key distribution to be only authenticated it has to be sure, where does the key come from. No confidentiality is necessary here. Once safely delivered, it may be used in communication with all other users. Distribution of public keys is an authentication issue and is therefore described in the next section. The only big advantage of asymmetric key algorithms is that they require very large computational power and consume a lot of resources. In case of a real time service, like VoIP this plays a huge role. Therefore, in most applications asymmetric encryption algorithm is used in order to distribute keys for a symmetric encryption. That is, a symmetric session key is sent in a message encrypted with an asymmetric algorithm. In order to provide better mobility to the user to make him/her able to log on to his VoIP service from different devices, in place of complicated private keys a simple password and login may be used. Otherwise, a complicated and impossible to remember combination of symbols has to be carried on some mobile device. Which is of course highly inconvenient for the user. There is one last property that has to be mentioned - sniffing (or performing call pattern tracking of) encrypted VoIP traffic. Even in case of an encrypted traffic, there is always a question of what amount of information is still visible. It is mostly dependent on the layer, where encryption has been used and the way the data is encrypted. One cannot forget that not all data may be encrypted and hidden. Some layers and some information have to be visible, in order to allow communication nodes in between to route the packets. Depending on the extent of trust and architecture two approaches may be used: end-to-end or Pawel Lawecki Page 88 VoIP Security in Public Networks
Solutions Analysis
9.2. Available Solutions
hop-by-hop encryption. Although end-to-end encryption is better to provide absolute confidentiality (no interconnecting devices are allowed to see the traffic), it is not always possible. For example, proxy has to know all the SIP routing information in order to forward the call correctly. The basic disadvantage of encryption is that it obviously increases latency. Cryptographic computations are usually very complex and therefore time-consuming. While in case of signaling traffic, this problem may be neglected, media consists of small packets transmitted at a fast rate in real time. Therefore providing confidentiality to the media stream always comes at a price of latency and higher computational requirements. There is a trade off between security (confidentiality) and quality of transmission.
9.2.2.
Authentication
Authentication [32] [75] [89] in a computer network is nothing else than verifying digital identity. It has to be checked if the other party is really, who he/she says. There are two basic authentication scenarios: user-user and user-provider. In each case it is possible to authenticate only one side or both sides to one another. Users authenticate one another in order to be sure who are they talking to, while providers want to know who is trying to access services and therefore should be charged. Authentication in VoIP is usually performed by taking into account either of two things:

what you know for example some password, phrase, PIN, etc., what you have might be certificate, smart card, security token, etc.
The biggest security problem in this mechanism is distribution of information (key) that the users will know, or proofs that they will have in order to authenticate. Both information and proof may be distributed by IP communication channel, the same where the VoIP call is taking place or by other distribution channels. The latter may mean for example post, generic phone call, visit in person in some key distribution office. Although such a distribution makes it much safer, it is very complicated and requires involving assets other than IP network. It is worth using it only in case of a critical communication, like for example banking or financial services on top of VoIP. Other cases use asymmetric key algorithms and use only IP network as a medium for distributing public keys between the parties. Of course, one could simply exchange keys between both end-nodes. The method doing so is called Pre-Shared Keys (PSK). Obviously, such an approach is unsafe as it is vulnerable to Man in the Middle attack1. Therefore some of implementations use additional security measures. One could for example exchange public keys only during the first contact and store them in end devices to reuse them in following contacts. This way an attacker has only one chance to compromise communication channel between two parties during the first key exchange. In case of user to user authentication another solution could be used. Public keys could be simply exchanged on session start up and then some check word (hash commitment [91]) computed from those public keys could be displayed at both end-devices. Users can simply read it and check if it is the same. This way a two-factor authentication is performed preshared key and content based check up. If word is not the same at both ends, it means there is a Man in the Middle attack being carried out against the transmission stream2. Different than PSK key distribution method bases on Public Key Infrastructure (PKI). It uses another property of asymmetric key algorithms that a message encrypted with somebody's private key, may only be decrypted with his/her public key so other way around than in
1 2 If the MitM attack is being performed at the very moment of key exchange. Later on it has no influence on VoIP security. See the next session. This is done in case of ZRTP - extension to RTP for Diffie-Hellman key agreement for SRTP [91].
Pawel Lawecki
Page 89
Solutions Analysis
encryption. This way, a digital signature or digital certificate may be created. If a message may be decrypted with somebody's public key it had to be encrypted with this person's private key. Message is authenticated this way, as one can be sure that it really comes from this person. Public Key Infrastructure is created by deploying servers with keys (key servers), also called Certificate Authorities (CA) in the network. In some moment of time a public key of such a trusted server is transmitted to the user. From this moment on this user may retrieve any key stored in CA. Information retrieved from CA is actually not a key, but a certificate as it contains the key and its owner's identity information and is encrypted with CA's private key. This way any user retrieving a certificate may be sure it is valid, if it is Figure 45: Authentication - digital certificate/signature possible to decrypt it with a mechanism public key of a CA. The whole mechanism is shown in Figure 45. The figure presents digital certificate or signature algorithm on the example on CA (top part of the figure), but obviously the mechanism works on any pair of public and private keys. Thanks to the deployment of CA one only needs to transmit a single public key this of the CA. In the same transmission a user may register himself/herself in the CA. This way in the following transmissions, he/she may be always correctly authenticated and may authenticate others that are registered in the CA. This limits the probability of compromising the system to one single chance (unless one uses other secure channel and then even this chance is eliminated this is the case of smart cards and security tokens). Although it is really secure, PKI is difficult and costly in implementation. It is due to the fact that it requires supporting a network of key servers in the public network.
9.2.3.
VoIP Security Mechanisms
Obviously, encryption and authentication general principles that were described in two previous sections are already implemented in different solutions and available for use in VoIP [45] [44] [75]. Security solutions for VoIP could be divided in two basic groups signaling (mostly SIP) and media (mostly RTP) related and regard a few basic issues encryption, authentication and key distribution. Below some of the VoIP security mechanisms are given:
media encryption - SRTP [92] - Secure Real-time Transport Protocol - a cryptographically secured transport protocol for RTP and RTCP packets, which by default uses AES encryption algorithm with 128-bit key. SRTP provides [44] confidentiality, packet integrity, protection against replay attacks, refreshes session key1, allows upgrading with new
If an attacker collects enough cipher text encoded with the same key then he/she may
/continued on page 91
Pawel Lawecki
Page 90
Solutions Analysis
cryptographic algorithms. At the same time it demands low computational cost (asserted by pre-defined algorithms) and low bandwidth cost (limited packet overhead).
media key negotiation [93] - MIKEY [94] Multimedia Internet KEYing, supports different types of key distribution (PSK, PKI, Diffie-Hellman), supports refreshing keys, well suited for real-time multimedia scenarios (two-way handshake). However, by some sources [95] considered as too complicated to implement or test and causes large delay by answering calls. - ZRTP [91] allows exchange of session keys (Diffie-Hellman) and other parameters necessary for SRTP session. It is completely self-contained in RTP and does not require any PKI. ZRTP provides confidentiality, MitM detection. If a secret is know from the signaling protocol it can also perform authentication. - SDES [96] - SDP Security Descriptions for Media Streams. Keys are transported in attachments of SIP messages. Most of the implementations today use this method [95]. It is extremely simple to implement. However, it requires either trust to intermediate devices or some way of signaling encryption.
signaling authentication - HTTP Digest [80] - bases on a challenge-response mechanism. Client's password together with a response are encrypted and sent in the SIP header. Although it provides some authentication security, it is vulnerable to modification attacks, as it does not provide message integrity. As already mentioned, HTTP Digest is a default authentication method set in Asterisk PBX software.
signaling security (authentication, encryption, media key distribution) - TLS [97] - hop-by-hop encryption protocol that works between UAs and Proxies. It provides confidentiality, integrity and protection from replay attacks. Its disadvantage is that it requires a reliable TCP protocol stack SIP/TCP. TLS replaces SSL and is as secure as HTTPS. - IPsec & IKE (multiple RFCs for IPsec, see IETF home page, IKE - [98]) IPsec is a network layer encryption protocol. It works in both hop-by-hop and end-to-end scenarios. It is usually used in a SIP VPN (Virtual Private Network) scenario or between administrative SIP domains. It does not provide key exchange mechanisms, so Internet Key Exchange (IKE) protocol needs to be used additionally. - S/MIME [99] SIP messages carry MIME bodies, but at the same time another SIP message may be completely encrypted inside MIME body. This provides encryption of signaling with ensured confidentiality and integrity. It is based on end-user certificates and therefore requires PKI.
Probably the most common scenario for encryption data, signaling and exchanging session keys [95] is: TLS + SRTP + SDES. SRTP is a most effective real-time voice encryption protocol. SDES is very simple and requires adding a single field in the SIP header. Last but not least, TLS is a protocol allowing encryption of SIP packets send between users and SIP Proxies. Using the described mechanisms it is possible to make the connection between two enddevices very safe. Majority of communication channel attacks can be prevented. Some of the lower layer attacks may still be performed, but since the content is encrypted, it can hardly be affected. For example underlying layer MitM attack may still redirect the traffic stream. But since the content is incomprehensible for the attacker he/she cannot eavesdrop or modify it or misrepresent the callee. It can, however, still cause a DoS attack by black holing.
cryptanalyze it and crack the encryption. Because of that, instead of using a single and fixed key for the whole session, session keys are refreshed. This way every session key is used only for a short, limited duration of time which eliminates the threat of cryptographic analysis. By fixed session keys the probability of cracking the encryption grows together with the duration of session.
Pawel Lawecki
Page 91
Solutions Analysis
9.2.4.
End-Device Security Mechanisms
End-device was mentioned to be another weak point of the VoIP public network. Underlying system of a device where VoIP functionalities reside, may be affected and compromised in many ways. Due to this different protection techniques have been designed to protect it. Presentation of all possible security measures to protect computer systems is of course not in the scope of this thesis, but some basic overview is given below. The most basic protection of end device regards regular installation of security patches. In chapter 7.Underlying Layers Analysis window of exposure was mentioned to be a critical security issue of any application or OS. One can do nothing to limit the official exposure time, but any available security patches should be installed as soon as possible. This problem regards both hardware and software phones. Of course, in case of hardware phones security patches are only necessary for simple VoIP software and underlying system. Software phones, in turn, work on a complicated Operation Systems among many other applications. Vulnerability of any application may be used to compromise security of the system, so security patches should be installed in all applications regularly, not just in the Operation System. Correct configuration and security patches eliminate most of the threats in case of a simple hardware VoIP phone. Of course malicious software like worms may still affect it during the window of exposure time, but this risk may never be totally eliminated. Most of other problems and therefore also solutions regard software phones only. In order to protect the computer system with VoIP softclient various standard security tools may be used. The most typical ones are:
antivirus searches and scans for known viruses in order to disable them. Each antivirus has a set of known virus definitions, which obviously needs to be regularly updated. Most of todays antiviruses detect and disable also other kinds of malicious software, like worms and Trojan horses. spyware remover usually contained in an antivirus. It detects and removes spying software malicious software that monitors activities performed on the computer and transfers this information to some unauthorized user. firewall controls incoming and outgoing traffic on end-device. It blocks application ports that are unnecessary for the end-device. It also checks and authorizes applications communicating with the network. Firewall monitors the traffic in order to detect and block unauthorized access or transmission.
These tools help to eliminate many vulnerabilities of computer systems and diminishes the risk of using software VoIP clients, therefore they should be always used.
9.2.5.
Policies, Rules, Guidelines
Certainly, even the best security technologies will not help, if they are not used or their working is compromised with some reckless activity. Therefore security frameworks usually contain also some policies and guidelines. These are rules for the end-user that should be obeyed in order to minimize threats to the computer system. They include activities that should be performed and those that should be avoided. Example of such rules is shown in Table 10. The rules are taken from Symantec's threat report [51]. They cover just the most basic guidelines for end-device users. There are other much more thorough recommendations, guides, audit check lists that may be used to establish a secure VoIP system. They are especially useful for providers' internal networks or for enterprises. However, those guidelines are mostly an issue of private networks and are therefore not investigated here. Some references that cover this problem are given below:
NIST: Security Considerations for Voice Over IP Systems [44] gives recommendations Page 92 VoIP Security in Public Networks
Pawel Lawecki
Solutions Analysis to deployment of a VoIP system,

David M. Davis: Checklist: IT Security Policy [100] general IT security policies, Val Thiagarajan: Audit Check List [101] detailed audit checklist for IT systems, Miercom: 2004: A VoIP Security Assessment [102] detailed coverage of security problems in VoIP. Contains also security comparisons of some VoIP market devices, SNAC: Security Guidance for Deploying IP Telephony Systems [103] IP telephony guideline for mitigation of VoIP vulnerabilities,
install security solutions, like antivirus, firewall, etc. ensure that security patches are up-to-date ensure that passwords are a mix of letters and numbers, do not use dictionary words, change passwords often never view, open, execute any email attachments unless they are expected (especially files with extension .vbs, .bat, .exe, .pif or .scr) keep virus definitions updated regularly be selective about freeware, shareware, free downloads or file-sharing applications, as they often contain spyware be careful by agreeing to End-User Licensing Agreements (EULAs). Some spyware may be installed after accepting the EULA turn off services that are not needed test security to ensure correct protection Table 10: Security best practices [51]
DISA: Internet Protocol Telephony & Voice Over Internet Protocol, Security Technical Implementation Guide [104] VoIP network detailed security implementation guide.
Unfortunately, those complex and sophisticated guidelines are unfeasible for public networks. As said already in chapter 4.Security Analysis Considerations, there is simply no organization that could enforce implementing and obeying the rules described in the documents. It can only be voluntarily used by VoIP providers, whereas users take care of the computer system security on their own. Even the very simple security guidelines described in Table 10 are seldom fully obeyed by the users.
9.2.6.
SPIT Protection
Basic problem with spam is that there is no legal framework to fight with it. Spam is legal and in most countries1 the same regards SPIT. Since it is legal, providers cannot just block it and prevent SPIT call from vexing the user. However, they can provide users with some SPIT protection mechanism and give them control over it. Legally, a user has the right to refuse communication and block the call. Of course, first such a call has to be detected, which in case of VoIP spam is another, even more complicated problem. Email spam, even though very irritating, is relatively simple to detect. It is text-based and the content is there - can be analyzed, before the user reads it. There are some quite successful email spam filters available that work on basis of email text analysis. However, in case of SPIT, this problem is much more complex. First of all, VoIP spam is carried by voice and voice recognition algorithms are still imperfect. Secondly, the content is real time based and is not known before the call is started (unless stored on a voicemail). In any case SPIT calls should be somehow handled before the user is bothered to answer it. There are already some technologies available [86]:
identity based requires strong authentication
As already mentioned only Germany forbids telemarketing and there are some other limitations in Greece and Denmark. The rest of the EU countries and the US allow it. [50]
Pawel Lawecki
Page 93
Solutions Analysis
- white lists identities allowed to call. They may be configured by the user, but initial contact is a problem, since explicit permission for every identity is required. In order to spoof a call, spammer would have to know the identity from a white list. - black lists identities that should be rejected. However, it can be easily circumvented by spammers if there is an infinite supply of VoIP identities.
circle of trust inter-domain authenticated connections. Each domain controls its own users and prevents SPIT calls. This method is not scalable well, as each new domain has to set up authenticated connections to all other domains. pattern/anomaly detection detecting suspicious patterns in VoIP traffic to identify SPIT calls. For example some protocol based fingerprinting may be used [105]. Statistical and pattern based filtering has the drawback that legitimate calls may sometimes also be blocked. caller interaction might be irritating for a caller - computational puzzle something that has to be solved, before the call is authorized. Reduces potential of SPIT generators. - Turing test conversational method to distinguish computers from humans computer is the judge. - consent-based communication a caller is authorized upon the first contact callee is the judge. It is actually a mechanism for white list/black list methods.
feedback from callee each user who receives a SPIT call reports it to the SPIT identification system. It is a reputation based system (ebay-like). Suffers for the same problem as black list.
Some sources [86] predict that SPIT will become a severe issue in the next two-three years. There will be probably no single protection technology, since SPIT is quite a complicated issue. Rather a flexible approach will be required. So far, the most promising approach is the white list and identity based technology. It works similarly to contact lists in Instant Messaging. It may also include reputation and friend of friend services to ease establishing the first contact. A serious inhibitor for SPIT may be cost of a telephone call. Email spam is for free, SPIT might be free of charge or not depending on the VoIP network.
9.2.7.

Denial of Service Protection
In two previous chapters a few different types of Denial of Service attacks were described: message flow attack VoIP specific, flooding attack VoIP protocols or underlying protocols, - direct, - reflected, other black holing, virus, device disabling, etc.
Attacks like message flow DoS may be easily eliminated if each message is authenticated and the system is immune to replay attacks. Black holing is a problem of authenticating nodes on lower layers, in order to prevent MitM attack. Most of device disabling threats, like viruses may be eliminated with correct protection of end and intermediate devices. However, all kinds of flooding attacks both direct and reflected, on underlying and VoIP protocols are extremely difficult to handle. As already described earlier, in these attacks hacker generates many seemingly legitimate packets and floods with them some element of the system. While, single computers performing DoS attack, would not be critical to the system, the whole network of compromised computers may already do it. Distributed Denial of Service caused by bot networks is one of the most complicated threats against computer networks. There are two basic problems in case of flooding DDoS attacks [73] - tracking the source of the packet and detecting that a packet is actually a part DoS attack. Either or both may help Pawel Lawecki Page 94 VoIP Security in Public Networks
Solutions Analysis stopping such an attack.
In order to block an attack one has to know DDoS packet's origin. Unfortunately, due to the techniques like IP spoofing (attacker sends packets with an untrue source address), it is sometimes very difficult to determine where does a given packet come from. Additionally, DoS attack may also be indirect, as in case of reflector attacks. Another problem is detection of DDoS. If each attack source (infected device) sends packets only occasionally (long intervals between the following packets) it is very difficult to detect such an attack at the source. And obviously source would be the most effective place to filter such malicious packets. From the point of view of access network of the attack source, there are just a few incomprehensible packets and it is not obvious at all if this is a DoS attack. On the victim's side, however, packets from many attack sources are accumulated and DDoS packets simply flood him/her. It is simple to determine that the victim is under DDoS attack from large amount of packets, but filtering them out is highly ineffective, as it requires very large computational resources The principle described above is shown in Figure 46. As shown, the closer to the victim, the bigger is the probability of attack detection and lower is the effectiveness of attack filtering. Therefore the suitable place to deploy DDoS solutions is the core network, where detection of attacks is already possible and filtering may be still effective. There are different approaches of doing it, like for example [73]: Route Based Packet Filtering (RPF) and Distributed Attack Detection (DAD) and they have proved themselves useful in limiting the impact of DDoS on the IP networks.
Figure 46: DDoS detection and filtering effectiveness [73]
Of course, there are also other solutions installed directly at the access network that prevent source address spoofing and try to detect DoS attacks already at the source. This was mentioned by description of access scenarios in chapter 7.Underlying Layers Analysis. However, it is still unclear how such solutions could help protecting VoIP applications, as DDoS against VoIP installations is still not a big problem and is expected to arise in the future. Anyway, one can only try to minimize the impact of the Distributed DoS attacks, but it is probably impossible to eliminate this threat totally, in the current Internet architecture.
9.2.8.
Physical Security
By describing security measures of an IP network, one cannot forget about its physical security. Every single element of the infrastructure should be protected from unauthorized physical access, but this problem is especially important in case of provider's installations. VoIP provider's network and, inside it, devices like SIP Server, AAA Server, Billing Server, Clients Database, etc. need to be protected. No unauthorized persons should be allowed in the vicinity, as this could lead to compromising the whole network. Of course, other elements of the IP network infrastructure are also important. Switches, concentrators, cabling should be all somehow secured.
Pawel Lawecki
Page 95
Solutions Analysis
Physical security of clients' end-devices is also important, as once stolen, they may reveal client's privacy secrets and/or lead to identity theft. Therefore, issues like storing passwords in the devices and blocking stolen devices should be thoroughly considered. In case of all elements of the VoIP infrastructure, it is also important to remember about power supply issue. VoIP provider, core network devices, access network nodes all need some independent power source, if they should remain on-line in case of a power black out. Regarding end-users, independent power supply may be necessary to sustain VoIP in enterprises and private networks of very high security requirements 1. However, most of the time, power supply problem of end-devices is overestimated. Modern PSTN handsets also need electricity and mobile phones manage to withstand lack of power only for a limited period of time. This is, therefore, not a major disadvantage of VoIP in comparison with other technologies.
9.2.9.
Education
Security of VoIP, just as of any other IP application, depends also on the expertise and skills of its users. A user has to be familiar with dangers, threats and possible attacks. He/she should also know what actions should be avoided and what security measures should be undertaken. This all makes educating end-user one of the most important security challenges of VoIP and any other computer application. The more thorough is the knowledge of a user, the more secure is the network. Correct training of users should also make them more alert and resistant to social engineering attacks that actually exploit the lack of expertise and awareness. This issue is especially important in case of VoIP providers and access networks administrators.
9.2.10.
Monitoring & Detection
When implementing security measures, there is always a question to what extent do they eliminate the threats. How successful are the security mechanisms and what is the risk of attack succeeding anyway. There is a rule concerning security of IT systems and it says that 99.99% reliable = 100% vulnerable [77]. In order to protect the network and provide a secure VoIP communication system, one needs to find and fix all problems. At the same time, attacker needs to find only one vulnerability. Therefore leaving even one vulnerability unprotected leaves the system open to a potential attack. However, there are three basic problems preventing any security framework from covering all possible issues.
Detecting literally ALL vulnerabilities is close to impossible the Internet with all its applications is an extremely complicated system. Due to this, there are always some vulnerabilities that are not noticed. And a vulnerability that is not detected cannot be protected. Applications change all the time and new functionalities are deployed in IP networks all the time. System changes and so should the security measures. However, the problem is that security measures always follow system changes and there is usually a period of time when system is unprotected. Each security solution is actually an application, therefore it also has its vulnerabilities. Due to this, the two problems mentioned above apply also to security measures.
supply has to be ensured to the network infrastructure devices, but also to every single phones require electricity to work). For this one could use for example a UPS device Supply is a device, which maintains continuous power supply. It works as a battery and for some time after power black out.
In such a case power desktop device (VoIP Uninterruptible Power allows devices to work
Pawel Lawecki
Page 96
Solutions Analysis
In such a case, the only thing one can do is to simply assume that all the security measures only minimize the risk of an attack (some do it very well), but very seldom manage to eliminate it completely. Obviously, this problem has been present in the computer networks from the very beginning, therefore there are already some solutions that help to handle it. In Figure 47 a way to minimize the impact of unforeseen attacks is shown. It is often referred to as risk management [106] and it is actually an approach used by many providers, administrators, etc. Even though all the protection measures are in place and policies & rules are applied, there are additional activities performed. The VoIP system is constantly under observation and the whole traffic is monitored. This way one can detect any unusual behavior that might mean some attack is being performed. If this is confirmed policies & rules and protection measures have to be modified in order to cover the new problem. Moreover, instead of just waiting for an attack to occur, the network may be actually actively tested for vulnerabilities. This way one can try to detect any other non protected system weaknesses, before the attacker does it. This is referred to by some sources [107] as a proactive approach.
Figure 47: Risk management monitoring & detection [106]
9.3.
Risk Analysis
In order to determine general security of VoIP public network, one has to analyze security of its elements. This way, one can decide how to deploy all the security measures and where are the remaining problems. There are three basic elements of VoIP in public networks: end-device (user), VoIP server (provider) and communication channel (access and core network). A summary of a simple risk analysis of each of those elements is shown in Figure 48.
Figure 48: Risk analysis - general issues
Pawel Lawecki
Page 97
Solutions Analysis
9.3. Risk Analysis
Two basic communication channel security measures were presented earlier encryption and authentication. There are many available implementations providing secure communication with MitM attack detection. If correctly applied, they ensure confidentiality and integrity of the VoIP traffic. While authentication is obviously necessary to provide correct functioning of the system and is therefore always applied (although sometimes very weak [79]), encryption is often not used at all. There are of course some trade-offs while using encryption, as it may increase latency and quality of the conversation. However, there are some applications that implement encryption by each call and are really successful (Skype). One should therefor try to find solutions in open architecture VoIP telephony that also use encryption by each call. Otherwise security of the traffic stream may be easily compromised in the communication channel. VoIP Server is the key element of each Voice over IP system. Due to this, it should be very well protected, with all available security solutions. These could be regular security patches, firewalls, antiviruses, security policies & rules, educating administrators and constant monitoring of the network. People managing the VoIP server should have thorough expertise and be aware of most existing vulnerabilities, attacks and security measures. With all security solutions in place VoIP server is quite secure. Of course, it is clear that some administrators ignore security problem and do not deploy full security frameworks. Nonetheless, security of VoIP server has primary meaning for provider's business activity and, as the amount of successful attacks against VoIP will grow, the problem will also be noticed and correctly handled. The only attack that cannot be easily handled is Denial of Service attack. In this case one can only mitigate its impact. Last but not least, security of end-device hosting VoIP functionalities has to be investigated. Theoretically, users have the same security measures available, as the providers. However, they usually lack the expertise and knowledge. Most of the time, users are not even aware of possible dangers in the Internet, they do not obey security rules and do not install security software. Therefore the only relatively safe solutions for VoIP are hardware phones. Users have only limited control over the device and additionally VoIP phones have very limited functionalities1. Security of software phones is usually only ostensible. Besides VoIP there are many other applications running on home users' computers. Each application and Operation System has its weaknesses, what makes the combined vulnerability space of each machine, really big. Additionally, due to their negligence and ignorance2 users usually fail to install available security measures. Therefore computers are vulnerable to all serious attacks, like worms, spyware or Trojan horses and very often their underlying system becomes a part of bot network. Some specialists, like for example Vincent Cerf (one of the fathers of the Internet), claim that [108] of the 600 million computers currently on the Internet, between 100 and 150 million are already part of botnets. Other experts claim that about 50% of all pirated Windows programs came with Trojans pre-installed on them [109], which actually can cause unauthorized control of the device, even if the security measures are installed. These two opinions show, how serious the threat to the computers connected to the Internet might really be. Other attacks that are architecturally difficult to place may also cause huge problems. This concerns especially attacks on large scale like DoS or SPIT. Controlled automatically they may affect the whole VoIP network. Their detection at the same time is very difficult, as they are content based. Fortunately, DoS attacks are usually only temporarily, as they disrupt availability only for a limited period of time and SPIT is usually only a vexing problem that is not followed by any serious consequences.
1 2 Soon, this might not be true anymore, as the market trend is that phones take over more and more functionalities that were until now typical for computers (see any 3G mobile phone). Therefore hardware phones will probably evolve into communication devices that are more similar to computers, than to the traditional telephones. It is not an attempt to judge any user, it is merely a simple statement of facts.
Pawel Lawecki
Page 98
Solutions Analysis
9.3. Risk Analysis
Identity theft, on the other hand, compromises some major security requirements of a VoIP network. It allows attacker to misrepresent the victim, access victim's private data, alter configuration and abuse services. Hacker could also modify access credentials and prevent legitimate user from using his/her identity (what could be permanent, if there is no mechanism for retrieving a stolen virtual identity). It is obvious then that consequences of identity theft attack are much more serious than for DoS and SPIT. The attacks where the hacker affects the network in a direct way, physically or by social engineering techniques, can also lead to very serious consequences and compromising security requirements. However, probability of such attacks is much lower than in case of other problems. To sum up, the biggest problems of VoIP public network is the vulnerability of end-devices. It is because security framework of VoIP public network expects users to secure them. This is, however highly impractical. Users have no background concerning complex Internet technologies and they should not be expected to take care of system (at least their part of it) security.
9.4.
Security Summary
The bottom line of the security solutions analysis is that, although there are some attacks that are extremely difficult to handle, most may be eliminated with use of existing security measures. Correct deployment of available security solutions can make VoIP a service with security level very close to this known from the PSTN, while keeping all its advantages, like advanced services, user control, flexibility and lower costs. However, the biggest problem of VoIP public networks is that those security solutions are actually seldom deployed. This problem regards, most of all, end users. The truth is that most of the users do not have any idea about security threats and countermeasures in IP networks and, to make it even worse, they do not want to have it. Most serious threats to VoIP in public network may be realized due to weak end-devices protection or lack of encryption. Both are caused by users' lack of expertise and knowledge. It is, however, difficult to expect user to be a specialist in VoIP technology just to make a phone call. Any service or application that is being offered in public network has to be simple and take care of security. Therefore one should try to determine, if there are any approaches that allow ensuring system security independently of the end-user. In Figure 49 overview of
Figure 49: Security solutions summary
Pawel Lawecki
Page 99
Solutions Analysis
9.4. Security Summary
possible attacks against VoIP and existing security measures is shown. The attacks & vulnerabilities that can be eliminated or are considered of low risk are written in black. Attacks that in the best case may be minimized, but are impossible to be totally eliminated with the described security countermeasures, are written in red. Most of the red attacks are connected exactly to the problem of weak security of IP end-devices. Malicious software infects machines connected to the network and can compromise user security by stealing identity credentials or compromise network security by causing Distributed Denial of Service attack. SPIT may be caused by infected computers or by other machines. Last but not least, not using encryption makes user traffic vulnerable to all attacks that may occur in the communication channel.
Pawel Lawecki
Page 100
Public Security Platform
10. Public Security Platform
10.
The purpose of this chapter is to present security platform issues in public networks. Present some additional solutions and ideas that could enhance security of VoIP in public networks and solve some of the problems mentioned in the security analysis. Some basic properties of a security platform are given and the role of authentication in VoIP security is investigated in order to prove its importance. General properties of authentication process and related issues are also described. Then some possible solutions to the problem of public network security are considered. Increased cooperation between providers, biometrics and enforcement of some security mechanisms are considered in detail.
10.1.
Problem Statement
Security platform is in other words a framework covering the network security problems. Obviously, every single VoIP system has some security platform. The question is, how secure it is and if it is able to protect the system from the described attacks and countermeasure its vulnerabilities. In most security platforms encountered in VoIP public networks security is left up to the users. Users are allowed to install security measures, according to their will. Security is simply treated as one of many other service properties. Unfortunately, as already described in the previous chapter, this approach is not really successful. Main reason for this is that an average user does not install security solutions, because they:

require thorough expertise and understanding many specialist concepts, may require considerable financial outlays, complicate using the service may require some additional actions upon each call, registration, etc, may lower quality of the service or even exclude some risky functionalities from the service.
One cannot force the users to install any security measures. IT specialists may only try to educate the users and make them aware to the security issues, but probability of succeeding in this crusade is very improbable. Therefore one should attempt to propose other implementations of security platforms that somehow take over security mechanisms and ensure safety of users and providers. It should be done, while keeping most of the service control up to the user, but take care of the system security instead of the user. User wants a simple, cheap, effective service and assumes security to be one of the granted system properties. Only such a user-friendly solution may be successful in a public network. This is true in case of any IP application, but especially regarding VoIP, which is supposed to be analogous to the PSTN - no user had to consider any security issues in case of traditional telephony networks. A security platform for VoIP in public networks has a great many problems to overcome. It should not only provide security for VoIP users, but also mitigate threats coming from other IP network users, who intentionally or unwittingly (bot nets) become attackers. Most important security issues are:

mitigation of content based attacks, like DoS and SPIT, reliable authentication that, if possible, is immune to identity theft attacks, enforcement of using encryption, which is necessary to provide confidentiality in communication channel.
DoS and SPIT are two most typical and wide scale attacks that may affect any VoIP network. Authentication immune to identity theft attacks would make VoIP system much more protected Pawel Lawecki Page 101 VoIP Security in Public Networks
10.1. Problem Statement
from the problem of weak end-device security. Using encryption together with the reliable authentication for each transmission would make VoIP resistant to communication channel threats.
10.2.
Authentication
General Properties
10.2.1.
Authentication is probably the most important issue in VoIP public network. It is not only important as a way to identify users, but may also help fighting against different threats, by identifying attackers. It is also necessary as a preliminary condition for reliable encryption1. In chapter 5.3.System Requirements Definition authentication was stated as the most important security requirements for the (business) user. There is no sense in providing confidentiality by encrypting the traffic, if one is not absolutely sure, who is on the other end of the line. If VoIP is to be a complete replacement for the PSTN, it has to have a very well working authentication system. It is especially important, if one remembers that many institutions and content providers use authentication provided by the telephony provider in their own authentication schemes. Moreover, VoIP could be used as a communication platform for e-administration initiatives, if it is reliable enough. Therefore, one should make VoIP authentication platform immune to misrepresentation attacks and make it immune to attacks shown earlier in this thesis, like for example caller ID spoofing, registration and call hijacking, etc. Identity theft issue should be also carefully investigated in this context, as it results in compromising authentication scheme, even though all methods may work perfectly well. One should try to find authentication mechanisms that could provide immunity to identity theft attacks. Authentication is also important for the provider. It has to know whom to charge and if the user who is trying to access the service is authorized to do it. It is also crucial by access to user private data stored by the provider and access (especially remote login in this context) to all key elements of VoIP provider's infrastructure. This is most of all VoIP server, but also gateway, AAA and Billing servers, etc. Finally, authentication may be a very important security mechanism to fight against various threats. VoIP spamers could be more easily prevented from vexing the user, if they are identified. Authentication of packets (what user are they coming from) could help fighting with Denial of Service attacks. Correct authentication of both communication nodes may eliminate Man in the Middle attack, eavesdropping, traffic rerouting and many other threats that are otherwise difficult to handle. It is probably the only single security mechanisms that covers so many threats and attacks. Authentication is therefore critical from the point of view of reliable functioning of VoIP and providing a VoIP security platform. At the same time it is a basic preventing/counteracting security measure that may help to handle many security threats.
10.2.2.
Identity
There are a few basic questions concerning each authentication process: who authenticates whom, what for, what is authenticated (what kind of identity) and what is the proof of identity provided by the user. Those questions actually represent the most general authentication properties. Two basic issues concerning authentication identity are what proof of identity does the user
1 It is true, even if call participants know one another, as it is used to detect MitM attack.
Pawel Lawecki
Page 102
10.2. Authentication
provide and what type of identity is being authenticated. The first issue is important by defining security level of the security mechanism. It specifies what is the strength of the proof. The latter concerns mostly anonymity issue. It decides to what extent is the user's identity being checked by the system. Proof of identity may be provided on four1 different levels [32]. A person may prove his/her identity in four following ways, starting from the least secure, to the most secure: 1. What You Know usually some user password. However, only the knowledge of it is verified here and password may be obviously intercepted or sniffed in some way. 2. What You Have a physical or virtual object, might be a digital certificate, smart card, NIC number etc. More secure than simple password, especially a physical object, where possession actually a possession of something is verified. Yet any physical object may be stolen. 3. What You Are biometrics as for example fingerprints and iris recognition. More difficult to forge. However, everything depends on the precision of the verifying system and the forge if forge is more precise than what verification acknowledges, the system may be fooled. 4. What You Do dynamic biometrics such as hand writing and voice recognition. They are most secure ways of authenticating a user. System has to be protected against replay attacks, otherwise simple repeating legitimate biometric data may fool it. Depending on the chosen proof of identity different properties of the user (identities) may be verified. There are three basic identities that may be authenticated in a VoIP system:
device identity usually some keys imprinted in the device by a manufacturer. The mechanism should be strong cryptographically. In the past MAC address was used to identify a device, but it is definitely not sufficient anymore (chapter 7.2.2.Man in the Middle Attack). virtual identity identity created for the user in the Internet for example nick name. It usually cannot be paired with any physical identity (real name). Therefore if stolen, it might be irretrievable. Virtual identity may be protected with knowledge (password) or some digital object (certificate). physical identity name, document ID number, social security number, etc. Regards authenticating a real person. Might be done by pairing virtual identity with physical one on some server of a provider. Then, even though only virtual identity is checked, it can be also mapped to a physical person. Physical identity is resistant to identity theft attacks (even in case of stolen password, user may change it personally by the provider). Additionally physical identity may regard: - person usually a private user. It is a single identity one physical identity is one real person. - institution usually some company or office. It is a multiple identity a single institution has many representatives.
Possibility to determine physical identity standing behind the virtual or device identity is very helpful in securing the system and deploying very reliable authentication platforms. However, it may on the other hand limit user anonymity. This issue is considered very important by some users especially in context of excessive control of the user by the state.
10.2.3.
Authentication Architecture
Many VoIP entities may try to authenticate one another for different purposes. Obviously, the purpose of authentication, as a security measure, is to mitigate or eliminate some threats. Therefore one should investigate VoIP authentication architecture, in order to specify what
1 Two of them were already mentioned in chapter 9.2.2.Authentication.
Pawel Lawecki
Page 103
Public Security Platform threats may be eliminated by authenticating VoIP system elements.
In Figure 50 a simple scenario of call initiation is shown. Alice tries to call Bob. In order for that to happen, two (or more) VoIP providers are involved in connection set up. First, Alice's home provider accepts her call request and tries to establish connection with Bob through his remote provider. While this is happening, different authentication operations may be carried out, with following issues being considered (arrow shows who is authenticated to whom):
caller -> local provider - theft of service is this user authorized to use the service? - service abuse is this really the user? should his/her account be charged? - interruption of service is this a DoS attack attempt and if yes, who is causing it? local provider -> caller - eavesdropping is this provider on the other end of the channel and if not MitM? - interception & modification is MitM being carried out and is packet integrity violated? caller -> remote provider - unwanted contact is the call a SPIT attempt against the callee? caller -> callee - misrepresentation (incoming) is the calling ID correct? is this really this person calling or some attacker is impersonating him/her? callee -> caller - misrepresentation (outgoing) is the reached number really the same with the dialed one?
Figure 50: Authentication architecture - related threats The description and figure given above, show what possible threats may be eliminated by effective use of authentication. There is, however, one additional problem regarding VoIP architecture. It is the transitivity of the authentication information. Is the authentication information being shared between the devices or is each device performing authentication with all others independently. There are two solutions possible in this context and choosing one depends on the trust to the following communication nodes and network architecture. One can carry out each of the described authentications independently and perform end-toend authentication for each two devices that communicate. This multiplies the amount of necessary operations, but makes security of each authentication independent from the others. One can also provide a platform that authenticates in a hop-by-hop manner. Each communication node authenticates only previous and following communication node and
Pawel Lawecki
Page 104
assumes that other devices also do it reliably. This requires trust to other intermediate devices1. There are less authentications carried out, but the effectiveness of some operations depends on others. For example (Figure 50) Alice-Bob's Provider authentication depends on authentication of Alice<->Alice's Provider and Alice's Provider<->Bob's Provider. Most of the threats mentioned in Figure 50 can be solved with correct deployment of authentication mechanisms like asymmetric key algorithms with encryption and data integrity mechanisms. However, as said earlier there are three problems that need additional attention:

interruption of service and unwanted contact threats, identity theft attack, lack of encryption usage in VoIP transmissions.
Those three problems are addressed in the next chapter.
10.3.
Possible Solutions
Circle of Trust
10.3.1.
Circle of trust is in simple words a group of providers that cooperate with and trust each other. They realize some common security policy or security mechanism regarding the connection with external IP networks. Thanks to such an approach a trusted environment between them is created and they do not have to install any protection means on links connecting them. Circle of trust between the providers is also sometimes regarded as a federation [110]. Such a concept was already mentioned as one of the possible SPIT solutions (chapter 9.2.6. SPIT Protection). Each of the providers is realizing an anti-SPIT policy. Calls generated by users are controlled and no SPIT is allowed. Thanks to that no SPIT calls appear on interdomain trusted connections between providers. VoIP providers may be interconnected with TLS encrypted bridge connections. Thanks to that they may be always differentiated from calls coming from non-trusted networks. No SPIT transmission from other IP networks may have spoofed source address and pretend to be from within the circle of trust. Such a call can be detected momentarily and discarded, since it arrives on a wrong link. Obviously, it is possible that some SPIT call is not detected at the source provider and it is forwarded to another trusted network. Some after call feedback mechanism can be used in this case so that the callee (a few of them to be sure) could notify the trusted source
Figure 51: Circle of Trust / Federation - VoIP safe environment

1
Intermediate devices that have functionality of the layer, where authentication is performed.
Pawel Lawecki
Page 105
10.3. Possible Solutions
network from which the call originated that this call was SPIT. Such a notification is possible, since both VoIP providers cooperate. A notified provider may prevent next SPIT calls and the problem is not escalated further1. The described mechanism removes the problem of initial contact, as all the users inside the trusted network may call one another and the probability of SPIT is very low. Regarding outside VoIP calls, the mentioned white list mechanism may still be used. In Figure 51 a basic concept of Circle of Trust is shown, as described above. There is, however, one additional issue that is being proposed here. It is also possible to use trusted connections between VoIP providers and access networks. Introducing the same cooperation to the relation between VoIP provider and access provider might be very useful for ensuring high availability. Access scenarios shown in the chapter 7.1. Properties & Vulnerabilities provide many security solutions preventing DoS attacks. MAC and IP anti-spoofing mechanisms prevent the most dangerous Denial of Service attacks where the destination cannot be traced back. If VoIP provider establishes a trusted relationship with such access networks with security mechanisms, DoS may be prevented much easier. Obviously, DoS attacks with a correct source address may still occur, but since there is cooperation between voice and access providers it is much easier to stop the attack. As was shown in Figure 46 on page 95, DoS attack may be most easily detected at the target and filtered out at the source of an attack. Therefore the attacked VoIP provider could simply notify the access provider what addresses are carrying out a DoS attack and it could be filtered out at the user's access network2. Of course, DoS attacks carried out against the VoIP provider from the outside IP networks cannot be stopped in such a way. But what can be done, is assigning higher priority to the requests coming from the trusted network over the packets coming from external IP networks3. If there is a flood of DoS packets coming from the outside, they could be stored in some buffer and served as in FIFO (First In First Out) queue, but only if there are no packets from the trusted network (where probability of DoS is much lower). This way users from the trusted access network would not suffer from a DoS attack and an uninterrupted availability could be ensured for them. Additional protection against DoS could be easiness of detecting spoofed packets that pretend to be from the trusted network. They would come from a wrong link and could be discarded without being analyzed just as in case of SPIT. Introduction of such circles of trust among VoIP and access providers could be profitable for every subject of the network. While it is obvious and probably implemented for NGN-like networks with a combined architecture, it could also be used in case of open architecture. Access network provider may add in his marketing offer that through its infrastructure a very reliable VoIP services may be offered. For VoIP provider it is a clear advantage of being able to provide very high availability (probably close to the PSTN availability) for some users. Admittedly, the user may be a subject of some security policies, what in worst case may lead to temporary cutting off their services, but on the other hand their VoIP telephony is much more secure and reliable. Enforcement of policies is not the only trade off of security. Another complex problem is the
1 Such an anti-SPIT policy would probably mean that a user generating SPIT may be cut off. Since users know that, most of the SPIT cases inside the trusted network would be caused by compromised bot machines, where SPIT calls are generated without knowledge of the legitimate user. Therefore some way of notification the user also has to be established. Additionally, the user should be warned/notified. He/she is either an aware or unaware (bot) attacker. In both cases he/she should undertake some countermeasures. This is, if one assumes that the architecture stays open. Circle of trust/federation technique could be also used to close the network and completely cut off calls from and to other external IP networks. In such a case security may be provided on a much higher level since it is a controlled environment, but one closes architecture and looses many advantages of VoIP.
2 3
Pawel Lawecki
Page 106
anonymity (privacy) issue. Since the access provider usually knows the physical identity of the user, cooperation between VoIP and access providers could lead to compromising user's anonymity. VoIP provider could possibly couple VoIP virtual identity with user's physical identity. However, this would happen only if the access provider shares such information. Fortunately, law requirements mentioned earlier (chapter 5.2.Legislative Issues) compel providers to ensure users' privacy. Circle of trust approach described here, is a solution that is provided independently from the end-user and is not vulnerable to the problem of weak end-devices. It is actually a way to create a safe environment in the public IP network. It provides protection from external IP networks without cutting them off and enforces security inside the trusted networks. At the same time it mitigates greatly the consequences of attacks like Denial of Service, Distributed DoS and VoIP spam. It allows identifying attackers (authenticating them). This regards authentication of the device in case of a DoS attack and authentication of virtual identity in case of SPIT. The only technical problems connected to federations are the scalability of TLS connections and communication protocol that could be used between providers. In big federations necessity to establish connections from every provider to all other providers might be a problem. However, it can be probably solved with closer cooperation of trusting networks and sharing some bridge connections in order to limit their amount.
10.3.2.
Biometrics
Another of the mentioned attacks that is very difficult to solve in the public IP platform, is identity theft. Compromising user end-device may lead to loosing credentials. Keyboard sniffing software, programs for retrieving credentials stored in the device (see chapter 8.2.8. Identity Theft) make it extremely easy for the attacker. Biometrics, so the study of methods for uniquely recognizing humans based upon one or more intrinsic physical or behavioral traits [3], is one of the best solutions for identity theft problem in VoIP networks. Your body's physical properties are the only credentials that cannot be stolen1 or lost. Forging biometric data is also very difficult, so any hacker trying to fool biometric verification system would have to posses extremely specialist knowledge. [111] [112] [113] [114] [115] Obviously, in case of VoIP or any other telephony technology, voice is the natural choice for the biometric that is verified. The
Figure 52: Biometric voice verification (partially [111])

1 At least not in the predictable future.
Pawel Lawecki
Page 107
authentication system that works basing on voice verification comprises of two basic steps. First, the user is enrolled his/her voice sample (usually quite long) is transmitted to the voice biometrics server and using this sample a mathematical model describing the biometric is created. This model is also called master voiceprint. Once the user is enrolled he/she might try to access the system and be verified by the voice biometrics server. In Figure 52 a typical event sequence by accessing a voice system is shown. First, a short sample of user's voice is captured (1). Server receives it and builds a mathematical model of the sample (2). Percentage similarity of both voiceprint and the sample is compared (3). Decision is made basing on the outcome of comparison and the configured sensitivity threshold (4). Reliability of a voice verification system depends on two basic issues:
ability to create a mathematical model of the voice, which is as exact as possible voice physical, behavioral and psychological properties have to be distinguished from other noises that are also transmitted (noise, weather, etc), intelligence of the algorithm also a mathematical operation that compares two voice samples. It has to take into account possible problems and factors that may have influenced the voice sample (stress, illness, etc.). Problem with any biometric based verification system is that it might be wrong. There are two types of mistakes. The system either grants access to an unauthorized person or denies access to a legitimate user. The first is called False Acceptance (FA) and the latter False Rejection (FR). The actual FA and FR Rate for a given system depends on the system reliability and the sensitivity threshold set in the system. FAR and FRR are inversely related, which means that one is always a trade off of the other. The higher sensitivity is set in the system (the more two samples have to coincide), the lower is FAR (less unauthorized accesses granted) and the higher is FRR (more legitimate users rejected). These relations are shown in Figure 53. However, voice verification is not the only problem in biometrics. Apart from determining, if the biometric came from the owner (matches the master biometric in the database), one also has to determine if the biometric was captured at the time of verification.
Authentication that bases on fixed phrases, which is also called text-dependent, is Figure 53: Tolerance and reliability of a vulnerable to reply attacks. In those attacks the biometric verification system (composed biometric indeed comes from the owner, but from [112]) was not captured during verification. Attacker uses the fact that in order to get access into the system one always needs to repeat the same phrase. Therefore in order to prevent reply attacks a text-independent method is often used. It allows the user to talk freely. Conversational speech is carried out either with a computer system1 or human. Such an approach allows to eliminate reply attacks and ensures that it is really the user speaking.
1 Voice recognition is then necessary to determine if what user says makes any sense.
Pawel Lawecki
Page 108
The latter of the mentioned verification methods is often applied in todays systems. It improves reliability of such systems greatly. Actual values may amount for example:

FAR=0.001% / FRR=1% in case of a text dependent, adaptive1 system, with computer system interacting with the user [112], FAR=0.00001% / FRR=0.8% in case of a text dependent, adaptive system, with user credentials and human interaction [113].
System with such high reliability could definitely solve the problem of identity theft in VoIP. Certainly, biometric solutions are still quite complex and expensive, therefore it is always a trade-off between simplicity and cost on one side and security on the other. Depending on the required security level, biometrics could be used in different applications:
only for highest security when user calls some institution related with for example finances, health or administration. In such case voice verification server would be probably deployed at the institution (one could treat it theoretically as a content provider), for unusual calls most of the time user calls some typical numbers (family, work, friends, etc.) where he/she is well known and no misrepresentation could occur. However, if some unusual call not dialed yet, or to an institution (as above) would be chosen, then user would have to identify his/her voice at the VoIP provider before the call may be set up. A kind of trusted numbers list is actually created and all numbers not in the list, would require voice authentication. for all calls highest security requirement. Probably unfeasible for public networks.
Such a solution is also independent from the user's end device. Its weak protection cannot affect the voice recognition at the biometric server. Voice authentication method is independent from credentials that could be stolen, if stored in the end-device. It allows determining physical identity of the user directly. The whole security system intelligence is on the network side, while the whole service control stays by the user. The threat of user identity theft is therefore eliminated without limiting functionality of the VoIP system. Biometrics have one more advantage any update, upgrade or modification of the voice verification system is simple, as it occurs only at the server. User devices do not even need any software update, as they do not require any software for voice biometrics at all. Obviously, both providers and clients want a reliable authentication. The only question is if the biometric system is not too expensive and does not require to much computational power to be deployed in VoIP systems (many users, real-time processing). One also has to provide authentication transitivity to make biometrics useful in end-to-end authentication. Anyway, considering risks and threats in public IP networks, it is probably just a question of time, when biometric systems will be widely deployed.
10.3.3.
Encryption Enforcement
Encryption is probably the most obvious and simplest issue that could increase VoIP security and ensure confidentiality. Open architecture of the Internet and easy access to the shared medium by other users make encryption necessary. Only this way one can provide a level of security similar to this known from the PSTN. In previous chapter (9.2.3.VoIP Security Mechanisms) many available solutions for VoIP encryption were presented. However, it was also described (see 9.3.Risk Analysis) that encryption is seldom used, what endangers the traffic stream to many serious attacks. Therefore the biggest problem in communication channel security is not what technique to use, but how to enforce it.
1 In adaptive systems the master voiceprint stored in the database is updated with time (user ages, etc).
Pawel Lawecki
Page 109
It might seem quite simple, as the security mechanisms are there, but there are many issues that complicate it: providers usually do not care if the content or signaling is encrypted (confidentiality is not their security requirement), users are not aware that their calls may be so easily eavesdropped (they assume confidentiality is granted just as in the PSTN), it is not in governments interest to encrypt users' calls (lawful interception is easier if one does not have to decrypt the traffic stream), there are compatibility problems between communication nodes (open protocol architecture causes there are many software/hardware clients not all compatible with one another), most encryption solutions are complicated (they usually require complicated background in computer networks, encryption, authentication mechanisms and expertise of available technologies). There are two subjects of VoIP public network that could enforce usage of encryption: providers and VoIP software/hardware manufacturers. As said above, government in most cases is not interested in confidentiality of user communication data. There is some legislation concerning privacy and user personal data, but not the communicated data. One could, of course, imagine that some laws could be created that oblige providers or manufacturers to enforce encryption and ensure security of communication channel. Anyway, it would be the provider realizing this policy, since manufacturers are usually international and are not limited to single jurisdiction. If not obliged by law, providers will probably not enforce encryption. Provider always tries to sell its product to all users, also these who do not want to use any encryption. Users do not want to use encryption, as they are not aware of the built-in vulnerabilities of IP platform and assume security granted. This way a vicious circle is created. Anyway, even if provider enforced encryption, it would in most cases 1 regard only signaling. As was already explained, only signaling travels between users through providers' servers. Media is transported directly between end-users just as shown in Figure 54.
Figure 54: Encryption background - media & signaling There are therefore two separate problems: encryption of media between the end-users as it may compromise confidentiality and integrity of data, encryption of signaling between users and providers2 - as it may lead to misrepresentation, compromise integrity of signaling, privacy or traffic analysis requirements. Providing signaling integrity and protection from misrepresentation should be already a part of some strong authentication method, like for example biometrics that was presented in the
1 2 Relying media through some provider gateway is also possible. This way provider would have control of both media and signaling and could enforce encryption in both cases. As the traffic is traveling through user's local access network. Security of the traffic stream between both providers is relatively higher, but it actually depends on the VoIP providers access connection. We assume here that VoIP providers' administrators ensure security of their part of the communication channel.
Pawel Lawecki
Page 110
previous section. Privacy issues related to traffic analysis are rather secondary. Due to this, the most important task of the encryption is to protect media and ensure confidentiality. However, the biggest problem is that since media travels directly between the end-devices only manufacturers could enforce encryption independently of the users. This could be done, in the same way as it is implemented in Skype. Calls between are always encrypted, but users are never burdened with any details concerning it. In Skype's GUI there is not even one option concerning encryption. Unfortunately, such an approach is possible only because Skype creates a closed environment. There are no calls between Skype VoIP clients and others 1. In the latter there are always compatibility problems. Different users use different VoIP devices (both software and hardware) that use various encryption protocols. It is highly improbable that all devices are compatible with absolutely all encryption mechanisms or the whole VoIP industry agrees on one encryption method. Therefore it is impossible to enforce encryption independently of the users in the current circumstances. Therefore, probably the most feasible way to provide encryption to the end users is usage of Philip Zimmerman's Zfone. It is an independent encryption software that works independently of the user's VoIP client. It simply captures all outgoing (or incoming) RTP packets and secures (or decrypts) them on the fly. It does it completely automatically and the only thing it requires from the user is reading a short authentication stream to exclude possibility of MitM attack. It is therefore very simple and does not require any special VoIP expertise. Zfone is now being integrated into many standalone VoIP clients. Its only disadvantage is that it is so far not available for hardware phones. Such a solution is obviously not perfect, but so far it is the only implemented and existing solution that can provide encryption to many users of public network without any compatibility problems on a large scale. It also has a simple GUI (Figure 55) and is fully automatic, so it can be easily used by average users without any specialist knowledge. Its disadvantages are that both users need to install the software and that it is still not available for hardware phones. However, since no enforcement is possible and encryption control has to stay by the user, the biggest problem is to make users aware of the dangers and convince them to use it.
Figure 55: Zfone - encryption with simple user GUI
10.4.
Security Platform Summary
Three additional VoIP solutions could considerably increase security of VoIP in public networks and help creating a security platform. Deploying and implementing them together with other existing security solutions described in the previous chapter can make VoIP security actually much higher than it was in the PSTN.
Introduction of circles of trust ensures high service availability to the users inside the trusted network and protects them from VoIP spam calls. It is achieved through mechanisms that allow tracing back any aware or unaware (infected bot machine) attackers. Biometric voice authentication makes VoIP telephony resistant to most vulnerabilities of IP public platform and IP based attacks concerning identity theft attacks. It allows to
Unless it is Skypeout service and a call is between Skype client and a PSTN gateway.
Pawel Lawecki
Page 111
Public Security Platform authenticate end-user directly on the physical layer.
10.4. Security Platform Summary
Usage of Zfone may automatically encrypt user media and ensure its protection from communication channel attacks in case of software phones. It is a good example of an automatic encryption software feasible for public network and its users.
First two solutions are completely independent from the user and the security is ensured on the network side, while leaving service control to the user. Encryption of media stream is in current circumstances probably impossible to perform without user's involvement, since media travels independently of the provider's infrastructure and without additional common encryption platform compatibility problems could occur between different VoIP clients. Certainly, even though the described security concepts might seem logical and feasible, in the real world the economical calculation has always the final word. Both service and access providers have to see a measurable economical gain in establishing circles of trust. Voice authentication systems are still quite expensive and it will be possible to use them once the servers are computationally powerful enough to handle real-time voice analysis of many users in parallel. Zfone encryption solution is free, but it requires users to install it additionally and it is still not available for hardware VoIP clients. Security in general does not come without some trade-offs. Establishing circles of trust in some way limits users' mobility, as the safe service may be accessed only in trusted networks. Communication between access and VoIP providers or deploying voice authentication systems may be seen as compromising clients' privacy. Any security measure adds some complication and, directly or not, increases the cost of the system. In most cases it also diminishes user control over some issues. One should also emphasize that no matter what the security measures are and how well the system is protected, they can only minimize probability of a successful attack. Determined, skillful and educated attacker may always succeed to compromise even the best protected network.
Pawel Lawecki
Page 112
Summary & Conclusions
11. Summary & Conclusions
11.
11.1.

Summary & Contribution
Security of Voice over IP in public networks problem was thoroughly investigated in this work. In order to perform a security analysis many background and initial research had to be carried out. VoIP general properties were studied, including VoIP's role in Next Generation Networks and comparison with the traditional PSTN services. Different issues like cost, switching, quality or mobility were analyzed. Structure of public IP network was also examined. Consequences of open and combined architecture on VoIP were studied in detail. Differences between access and service provider and their impact on security of public network were also investigated. Impact of access network properties, like mobility or shared medium (shared local access network) was studied on three examples of access scenarios - DSL, Cable and WiMAX. Internal architecture of service provider network was also analyzed in general and on example of SIP protocol architecture. Approach to security problem was also considered. Usefulness of security standards like ISO 17799, X.805 and NIST Risk Management Guide was assessed. However, while most of the standards are designed for specific networks, public network is general and vague system and therefore a more abstract method was designed to approach it. The chosen approach consisting of following steps: security requirements definition, threats analysis and classification, vulnerabilities & attacks investigation and security mechanisms assessment was used to perform a security analysis. Stating system security requirements were preceded by giving exact definitions of general security requirements and their description, since there is no common, agreed way to define them. Requirements like confidentiality, integrity, availability, authentication, authorization, accounting, privacy, non-repudiation, traffic analysis were considered. Additionally, some legislative issues were investigated, including lawful interception and emergency localization. All those mentioned general requirements were applied in definition of client's and provider's security expectations. Two exemplary types of clients were considered business and personal. In threat analysis all the unwanted occurrences that could compromise client's and provider's requirements were examined. Different factors that could be used to classify threats were researched and some available categorizations of VoIP threats were investigated. The chosen threat classification based on the VOIPSA Threat Taxonomy and included threat categories, like communication channel threats, interruption of service, unwanted contact, theft and abuse of service. Vulnerabilities and attack techniques were treated as realizations of threats and were investigated on two basic levels underlying VoIP and VoIP specific. In both cases attack techniques were analyzed concerning their origin, properties, vulnerabilities they exploit, threats they realize and security requirements they compromise. Different parts of the VoIP system were analyzed this way, including some examples of access networks, end-devices and provider's vulnerabilities. Attacks were additionally categorized into some basic and most often encountered types. Thanks to this categorization it was much easier to come up with some security solutions that could cover many problems. There are many existing security mechanisms that may be used to counteract vulnerabilities and prevent attacks. They were also analyzed, regarding their efficiency and extent to which they solve security problems was determined. Some vulnerabilities and attacks were recognized as very difficult to handle with existing security Pawel Lawecki Page 113 VoIP Security in Public Networks
11.1. Summary & Contribution
mechanisms and therefore some additional security enhancements were presented as a part of public security platform. The role of authentication was investigated in protecting VoIP transmissions, preventing attacks against VoIP and necessary condition for many other security mechanisms. It was also applied in the proposed security solutions, like circle of trust and biometric voice authentication. The first solution discussed possible cooperation between VoIP and access providers to counteract DoS and SPIT attacks, while the latter considered usage of voice analysis in VoIP authentication, to prevent identity theft. Idea of encryption enforcement was also investigated in detail and while no complete solution was found, usage of Zfone encryption tool was discussed as a partial solution for media encryption.
11.2.
Conclusions
The future of Voice over IP depends mostly on its security level. It will be possible for VoIP to fully replace traditional telephony only if high level security requirements are met. Confidentiality has to be granted by every single transmission and strong authentication mechanisms need to be deployed, otherwise VoIP will never become a service accepted by demanding business and private users, who expect the same security level as it was in the PSTN. Most of those requirements may be ensured with the existing security mechanisms. Great majority of the problems is technically solvable, however, many are difficult to deploy. Additionally, many security mechanisms require some expertise and attention from the end users. This is not a problem for highly organized enterprise networks that may afford hiring IT specialists who take care of the network security and ensure correct functioning of security mechanisms. Unfortunately, it is rather unfeasible for an average user of public network. Average user of public network is ignorant about security and does not want to be burdened with it and it is actually his/her undeniable right. Security of VoIP in public network should be taken care on the network, not on the user side. Security mechanisms should be independent from the end user, run in background and be as unnoticeable as possible, but at the same time not limit user's control over the service. Of course, this is far from simple in the open architecture of IP world, where services are offered by many independent providers. In order to increase security one can either close the architecture and limit some of the VoIP advantages, like it is for example in case of Skype or one can try to search for other solutions. One of the possible approaches discussed in this work was extended cooperation between access and service providers. Depending on the extent of the cooperation it may be realized with some circle of trust of the cooperating providers or even as a part of NGN network architecture, where Quality of Service may be also provided. Such a cooperation solves some other VoIP security problems that need to be addressed separately. Denial of Service and VoIP spam are just two most important examples that may be solved with such an approach. Other problem that also needs attention is identity theft. Stealing proof of virtual identity of a user may allow attacker to compromise many security issues. Biometric identification is probably the only mechanism where the proof of identity may not be stolen or lost. Text-independent identification schemes, where user interacts with the system in a free speech are additionally resistant to reply attacks. Therefore voice authentication is probably one of the best ways to identify VoIP users in the near future. One of the most serious problems in deploying security in any IP network is that there is no legal framework that supports protection of transmission. Such legal measures exist only for data protection, but not VoIP call. Due to this, providing security is free will of providers and may be enforced only by the users and their market choices. Providers will ensure services that are most feasible for the users and for which the users are willing to pay. Another issue is that security is usually a trade off of some other system property. A system Pawel Lawecki Page 114 VoIP Security in Public Networks
11.2. Conclusions
with deployed security mechanisms usually costs more, is more complicated and requires more resources. Providing strong authentication (for example voice biometric) may diminish anonymity and privacy of the users. There are obviously many other examples and many possible trade offs, but the bottom line is that security always requires some sacrifice.
11.3.
Outlook
There are many additional issues that need to be solved before VoIP public network security expectations may be satisfied. This regards most of all solutions proposed in the Public Security Platform chapter. Different issues need to be considered:

feasibility of voice authorization,
biometric
authentication
by
VoIP
client
identification
and
circle of trust implementation especially scalability problem in case of many trusted connections and communication protocol that could be used between trusted providers, common encryption platform that could be used to enforce application of encryption by every call.
Some other problems that are independent of the proposed solutions and are general for VoIP public network should also be considered. This includes:
authentication transitivity problem authentication platform for VoIP, exchange of authentication information between providers, secure mechanism for forwarding the information. The problem of trusting involved providers should be also considered, anonymity issue even though security is a major requirement in public networks, sometimes it is necessary to provide anonymity of the end users. As those two approaches exclude each other, independent solutions are probably necessary, legislative requirements implementation in VoIP public network this regards mostly lawful interception, emergency localization and privacy issues. All those problems should be considered for VoIP all over again and independently from the PSTN.
Pawel Lawecki
Page 115
Abbreviations
Abbreviations
Abbreviations
3GPP AAA ADSL AES AIN AP ARP ATM B2BUA BPDU BPI+ BPKM BRAS BS CA CGI CIA CLID CM CMTS CPL CPU DAD DDoS DHCP DNS 3rd Generation Partnership Project Authentication, Accounting Authorization, EER EULA FAR FRR GPS GSM HA HDSL HSRP HTTP ICMP ID IEEE IETF IKE IM IP IPTV IRDP ISDN ISO IT ITU LAN LEA LI MAC MAN MD5 MGCP MIKEY MitM NAT Equal Error Rate End-User Licensing Agreement False Acceptance Rate False Rejection Rate Global Positioning System Global System Communications Home Allocation High Data Rate DSL Hot Standby Router Protocol Hypertext Transport Protocol Internet Control Message Protocol Identification Institute of Electrical and Electronics Engineers Internet Engineering Task Force Internet Key Exchange Instant Messaging Internet Protocol Internet Protocol Television ICMP Router Discovery Protocol Integrated Services Digital Network International Standard Organization Information Technology International Union Telecommunication for Mobile
Asymmetric Digital Subscriber Line Advanced Encryption Standard Advanced Intelligent Networks Access Point Address Resolution Protocol Asynchronous Transfer Mode Back-to-Back User Agent Bridge Protocol Data Units Baseline Privacy Plus Baseline Privacy Key Management Broadband Remote Access Server Base Station Certification Authority Common Gateway Interface Confidentiality, Integrity, Availability Calling Line Identification Cable Modem Cable Modem Termination System Call Processing Language Central Processing Unit Distributed Attack Detection Distributed Denial of Service Dynamic Host Configuration Protocol Domain Name Server
Local Area Network Law Enforcement Agency Lawful Interception Media Access Control Metropolitan Area Network Message-Digest algorithm 5 Media Gateway Control Protocol Multimedia Internet Keying Man in the Middle Network Address Translation VoIP Security in Public Networks
DOCSIS Data over Cable Service Interface Specification DoS DQoS DSL DSLAM EAP ECPA Denial of Service Dynamic Quality of Service Digital Subscriber Line DSL Access Multiplexer Extensible Authentication Protocol Electronic Communication Privacy Act
Pawel Lawecki
Page 116
Abbreviations NGN NIC NIST OS OSI PBX PCM PCM PDA PIN PKI POTS PPP PPPoE PRS PSAP PSK PSTN QoS RAN RAS RPF RSA RSVP RT RTCP RTCP RTP RTSP Next Generation Network(ing) Network Interface Card National Institute of Standards and Technology Operation System Open Systems Interconnection Private Branch Exchange Personal Computer Pulse-Code Modulation Personal Digital Assistant Personal Identification Number Public Key Infrastructure Plain Old Telephone System Point-to-Point Protocol Point-to-Point Protocol over Ethernet Premium Rate Service Public Safety Answering Point Pre-Shared Key Public Switched Telephone Network Quality of Service Radio Access Network Reliability, Availability, Serviceability Route Based Packet Filtering Rivest, Shamir, Adleman Resource ReSerVation Protocol Real Time Real Time Control Protocol Real Time Control Protocol Real-time Transport Protocol Real Time Streaming Protocol SDP SDSL SIM SIP SMTP SP SPIT SRTP SS7 STP TCP TFTP TLS UA UAC UAS UDP UMTS URL VCR VDSL VLAN VoIP VPN WAN WEP WiMAX WPA WWW SDES
Abbreviations SDP Security Descriptions for Media Streams Session Description Protocol Symmetric Digital Subscriber Line Subscriber Identity Module Session Initiation Protocol Simple Mail Transfer Protocol Service Provider Spam over Internet Telephony Secure Real Time Transport Protocol Signaling System #7 Spanning Tree Protocol Transmission Control Protocol Trivial File Transfer Protocol Transport Layer Security User Agent User Agent Client User Agent Server User Datagram Protocol Universal Mobile Telecommunications System Uniform Resource Locator VideoCassette Recorder Very-high-bit-rate DSL Virtual Local Area Network Voice over IP Virtual Private Network Wide Area Network Wired Equivalent Privacy Worldwide Interoperability Microwave Access WiFi Protected Access World Wide Web for
VOIPSA VoIP Security Alliance
S/MIME Secure/Multipurpose Interned Mail Extensions SBC Session Border Controller
Pawel Lawecki
Page 117
References
References
References
1: Christina Chalastanis; A work parallel to this one, covering VoIP security problems in enterprise networks; Security of SIP-based Voice over IP in enterprise networks, December 2005 2: VOIPSA, Inc.; A portal of VoIP Security Alliance - organization carrying out many VoIP security related projects; http://www.voipsa.com, 2006 3: free content; Wikipedia - on-line encyclopedia; http://en.wikipedia.org, 4: Margit Brandl - Karl Franzens - UNI Graz, Dimitris Daskopoulos - GRNET, Erik Dobbelsteijn SURFnet, Rosario Giuseppe Garroppo - University of Pisa, Jan Janak - FhG Fokus, Jiri Kuthan FhG Fokus, Saviero Niccolini - Univeristy of Pisa, Jrg Ott - Universitt Bremen TZI, Stefan Prelle - Universitt Bremen TZI, Sven Ubik - CESNET Uni Graz, Egon Verharen - SURFnet; A reference document for setting up IP Telephony solutions from TERENA research project; IP Telephony Cookbook, March 2004 5: IETF; RFC 3261: Session Initiation Protocol; http://www.ietf.org/rfc/rfc3261.txt, June 2002 6: Dorgham Sisalem, Jiri Kuthan, Mobile Integrated Services, GMD Fokus; Presentation explaining SIP properties; Understanding SIP, 2002 7: Paul E. Jones, Rapporteur, ITU-T; Presentation describing features and characteristics of H.323 by ITU; Overview of H.323, June 2004 8: AT&T; VoIP protocol architecture description by AT&T company; Common VoIP Architecture, December 2003 9: IETF; RFC 3550: RTP, A Transport Protocol for Real-Time Applications; http://www.ietf.org/rfc/rfc3550.txt, July 2003 10: IETF; RFC 2205: Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification; http://www.ietf.org/rfc/rfc2205.txt, September 1997 11: IETF; RFC 2326: Real Time Streaming Protocol (RTSP); http://www.ietf.org/rfc/rfc2326.txt, April 1998 12: Keith G. Knighston, Industry Canada; Presentation from the ITU NGN Technical Workshop in March 2005; Basic NGN Architecture & Principles, March 2005 13: Paul Drew - MetaSwitch, Chris Gallon - Fujitsu; A paper identifying primary issues that must be addressed in defining a large scale VoIP network - from Multiservice Switching Forum; Next-Generation VoIP Network Architecture, March 2003 14: Analysys Consulting; An article about growth of VoIP service market in the US; http://research.analysys.com, April 2004 15: Siemens; White paper providing Siemens IP-tech portfolio and technology description; The Big Communications Picture, February 2004 16: Larkspur Group; A security analysis and comparison of the POTS and specific examples of VoIP systems (Skype and SIP); "A Comparison on the Security of VoIP and POTS", 2005 17: Heikki Kaaranen, Ari Ahtiainen, Lauri Laitinen, Siamaek Naghian, Valtteri Niemi; A reference to business chain, see page 195; UMTS Networks - Architecture, Mobility and Services, 2001 18: The Computer Language Company; Technology portal with an encyclopedia of terms; http://www.techweb.com/encyclopedia, 2006 19: Peter H. Gregory - Avaya, Wiley Publishing Inc.; A book about basic security problems in VoIP telephony; VoIP Security for Dummies, 2006 Pawel Lawecki Page 118 VoIP Security in Public Networks
References 20: Matthew J. Castelli - Cisco Press; Cisco book about access & service technologies; Network Sales and Services Handbook, November 2002
References
21: Motorola Incl.; A white paper with some access technology architectures; Motorola Seamless Mobility Connectivity Architecture, Overview, 2005 22: Wenzhan Song; Course information slides; CS455 Introduction to Computer Networks, Fall 2005 - WSU Vancouver, Engineering & Computer Science 23: Alcatel; Presentation about Alcatel WiMAX system; Alcatel WiMAX, 2005 24: Radvision Ltd.; Description of basic SIP elements, mechanisms and messages; Session Initiation Protocol (SIP), Technical Overview, 2005 25: Scott H. Sweren - ISACA, Journal Online; An article about ISO 17799 security framework; ISO 17799: Then, Now and in the Future, 2006 26: Initiative D21 - Projekt der Arbeitsgruppe 5; A paper from a German Initiative D21 group with comparison of available security criteria, methodologies, certificates, etc.; ITSicherheitskriterien im Vergleich, December 2001 27: Aleksei Resetko, Thorsten Henning - Lucent Technologies, Bell Labs Innovations; A white paper about implementation of a security infrastructure in VoIP network; Security in Voice over IP Networks, 2005 28: Zachary Zeltsan - Bell Laboratories, Lucent Technologies; A presentation from IETF meeting about X.805 security recommendation; IETF 63 meeting, August 2005 29: Gary Stonebumer, Alice Goguena and Alexis Feringa - National Institute of Standards and Technology; NIST special publication with recommendations for IT system security; Risk Management Guide for Information Technology Systems, July 2002 30: Edward Amoroso - Bell Laboratories; A book introducing critical issues in computer security technology; Fundamentals of Computer Security Technology, 1994 31: Lexico Publishing Group, LLC; A set of electronic dictionaries; http://dictionary.reference.com/, December 2006 32: Farlex, Inc.; A set of dictionary, thesaurus, encyclopedia, computing dictionary; http://www.thefreedictionary.com/, December 2006 33: Microsoft MSN Encarta; Electronic Encarta dictionary; http://encarta.msn.com/encnet/features/dictionary/dictionaryhome.aspx, December 2006 34: Ofir Arkin - Sys-Security Group; An article about security issues in IP telephony; Why E.T. Can't Phone Home? Security Risk Factors with IP Telephony based Networks, November 2002 35: Harald Orlamnder, ETSI SPAN 8; ETSI SPAN 8 presentation; "Charging" in the Internet, January 2007 36: Donn B. Parker; A chapter about security framework and security requirements; Computer Security Handbook, Toward a New Framework for Information Security, 2002 37: VOIPSA, Project Director: Jonathan Zar; A threat taxonomy created by VoIP Security Alliance in worldwide team collaboration; VoIP Security and Privacy Threat Taxonomy, October 2005 38: AOL - America Online Inc; A short description of the American "Electronic Communication Privacy Act of 1984"; http://legal.web.aol.com/resources/legislation/ecpa.html, 2003 39: Privacy International ; A list of existing legislation in field of Data Protection and Privacy; http://www.privacyinternational.org, January 2005 40: Newport Networks; A company white paper about emergency call issue; Emergency Call Handling in VoIP Networks, 2006
Pawel Lawecki
Page 119
References
References
41: Hannes Tschofenig, ECRIT IETF WG Chair, Siemens AG Corporate Technology; A presentation from the Third Annual VoIP Security Workshop in Berlin (2006); Standardization and Regulation, Emergency Call Standardization, 2006 42: Newport Networks; A company white paper about Lawful Interception principles; Lawful Interception Overview, 2005 43: Hendrik Scholz; A presentation about Lawful Interception in Germany; Lawful Interception in German VoIP-Networks, 2006 44: D. Richard Kuhn, Thomas J. Walsh, Steffen Fries - National Institute of Standards and Technology; NIST Recommendations of NIST concerning VoIP security; Security Considerations for Voice Over IP Systems, January 2005 45: Andre Adelsbach, Ammar Alkassar, Karl-Heinz Garbe, Mirko Luzaic, Mark Manulis, Edgar Scherer, Jrg Schwenk, Eduard Siemens - Bundesamt fr Sicherheit in der Informationstechnik; Security analysis of VoIP from German Federal Office for Information Security. Source is not available in English.; VoIPSEC, Studie zur Sicherheit von Voice over Internet Protocol, October 2005 46: Amarandei-Stavila Mihai - XMCO Partners; SIP and RTP related threat layered analysis; Voice over IP Security, A layered approach, 2005 47: Jeffrey Albers, Bradley Hahn, Shawn McGann, Seungwoo Park, Rundond Zhu - University of Colorado; SIP related threats and tools; An Analysis of Security Threats and Tools in SIPBased VoIP Systems, April 2005 48: Chris Roberts - Centre for Critical Infrastructure Protection; Description of most popular threats together with some security solutions overview; Voice over IP Security, May 2005 49: Henning Schulzrinne; Henning Schulzrinne web page at Columbia University with resources. SIP Security Threats presentation.; http://metronorth.cs.columbia.edu:8080/display/~hgs/SIP+security+threats, January 2007 50: Manfred Stockmann; A presentation from ECCCO - European Confederation of Contact Centre Organisations; Legal situation on telemarketing in the EU, May 2004 51: Symantec Corporation; Threats to a computer system in the Internet overview, trends of attacks and vulnerabilities. ; Symantec Internet Security Threat Report, Trends for January 06June 06, September 2006 52: Harald Orlamnder - Alcatel; Presentation with background information for IPTV, includes DSL protocol architecture description; Collection of Infos for IPTV/THS, March 2006 53: Agilent Technologies; A paper giving overview and background for DSLAM and BRAS functionalities and properties; Understanding DSLAM and BRAS Access Devices, 2006 54: Alcatel; System overview of DSL implementation devices; Alcatel 7302 Intelligent Services Access Manager, Release 3.0, Feature Group 3.1; Alcatel 7330 Intelligent Services Access Manager Fiber to the Node, Release 3.0, Feature Group 3.1, 2006 55: Alcatel; Product information paper; Alcatel 7302 ISAM Intelligent Services Access Manager, June 2005 56: Alcatel; Application note; Alcatel Business Access Solution, Enhanced Security, October 2003 57: Alcatel; A product paper; Optimizing the Broadband Aggregation Network for Triple Play Services, November 2004 58: Cable Labs; Web page with Cable TV access networks interface specifications DOCSIS; http://www.cablemodem.com/specifications/, January 2007
Pawel Lawecki
Page 120
References 59: Cable Labs; Web page with PacketCable specifications downloads; http://www.packetcable.com/specifications/, January 2007
References
60: Ajay Gummalla - Broadcom; A presentation with DOCSIS overview; DOCSIS Overview, July 2001 61: Cable Television Laboratories; Enhanced security specifications for Cable TV access networks; Baseline Privacy Plus Interface Specification; Document Number: SP-BPI+-I05000714, July 2000 62: Cable Television Laboratories; This report provides availability requirements for network elements in PacketCable environment; VoIP Availability and Reliability Model for the PacketCable Architecture, 2000 63: Wolfgang Klenner - Alcatel; A presentation from "Acterna Technologie-Symposium fr Carrier und Unternehmensnetze" in September 2005 about multimedia services in Cable TV networks environment; Multimediale Dienste im Kabelfernsehnetz, September 2005 64: Alcatel; Solution Bulletin; Security in WiMAX Alcatel Solution, July 2005 65: Alcatel; Presentation with product's security mechanisms description; WiMAX Security, Broadband Wireless Business Unit, January 2006 66: Matthias Hofherr; A book with analysis and overview of authentication methods for wireless networks; WLAN - Sicherheit, Profesionelle Absicherung von 802.11-Netzen, 2005 67: Alcatel; A presentation with product description - WiMAX Radio Access Network with VoIP solution; Alcatel 9100 WiMAX RAN, VoIP Service, 2006 68: IETF; Address Resolution Protocol RFC; http://www.ietf.org/rfc/rfc826.txt, November 1982 69: Gerald Combs and others; A web page of the Wireshark packet analyzer. A program replaces and further develops Ethereal.; http://www.wireshark.org/, January 2007 70: Massimiliano Montoro; Cain & Abel program home page. Program may be used to perform a MitM attack in Ethernet. A flash presentation with description for ARP Poison Routing technique (or ARP spoofing) is also given there. ; http://www.oxid.it, June 2001 71: Massimiliano Montoro; Cain & Abel program home page. Program may be used to perform a MitM attack in Ethernet. A flash presentation with description fo ARP Poison Routing technique (or ARP spoofing) is also given there. ; http://www.oxid.it, June 2001 72: Stuart Staniford - Silicon Defense, Vern Paxson - ICSI Center for Internet Research, Nicholas Weaver - UC Berkeley; A paper presenting magnitude of the threat of bot networks; How to 0wn the Internet in Your Spare Time, 2002 73: Rocky K.C. Chang - The Hong Kong Polytechnic University; A presentation describing basic properties of DoS and DDoS and some solution mechanisms; Defending Against Flooding Based DoS Attacks: A tutorial, 2005 74: Saverio Niccolini, Jrgen Quittek, Marcus Brunner, Martin Stiemerling - NEC, Network Laboratories, Heidelberg; A presentation from Saverio Niccolini and others in NEC with different attack techniques listed; VoIP Security Threat Analysis, 2005 75: Adreas Steffen, Daniel Kaufmann, Andreas Sticker - Security Group, Zrcher Hochschule Winterthur; Comparative overview of the security mechanisms recommended by the SIP standard; SIP Security, 2004 76: Hendrik Scholz; A presentation from "3rd Telephony Summit" in Wiesbaden, Germany 2006.05.02. It treats about different ways of hacking SIP. It was retrieved from: http://www.wormulon.net; SIP Hacking, May 2006
Pawel Lawecki
Page 121
References
References
77: Ari Takanen - Codenomicon; A presentation treating about VoIP security, threats, vulnerabilities and solutions; VoIP Security Threats: Rebuilding Trust in Communication Networks, January 2006 78: Peter Thermos; An article about two attacks against SIP - MitM attack with eavesdropping and Registration Hijacking. Retrieved from: http://www.voiponder.com/posts/examining_two_well_known_attacks_on_voip/; Examining Two Well-Known Attacks on VoIP, April 2006 79: Joachim Posegga, Jan Seedorf, Felix Klckmann, Dirk Kver, Malko Steinorth, Lars Westphal; A web page summarizing a seminar project getting an overview of the authentication mechanisms of the leading VoIP-providers in Germany at the time. Retrieved from: http://www.informatik.uni-hamburg.de/SVS/teaching/ws200405/projseminar/VoIP/index.php; Voice over IP-Security, Aktuelle Probleme der IT-Sicherheit WS 2004/05, 2005 80: IETF; RFC - HTTP Authentication: Basic and Digest Access Authentication; http://www.ietf.org/rfc/rfc2617.txt, June 1999 81: Mark Spencer - Digium Inc.; Home page of Asterisk software - an open source, freeware implementation of IP PBX; http://www.asterisk.org, January 2007 82: SNOCER: Tasos Dagiuklas, Dimitris Geneiatakis and George Kambourakis - University of Aegean, Dorgham Sisalem and Sven Ehlert and Jens Fiedler - Fraunhofer Fokus, Ji Markl and Michal Rokos - Nextsoft, Olivier Botron - Telip, Jesus Rodriguez - VozTelecom, Juntong Liu Embiron; A deliverable of SNOCER project ("Low Cost Tools for Secure and Highly Available VoIP Communication Services"), retrieved from: http://www.snocer.org; General Reliability and Security Framework for VoIP Infrastructures, 2005 83: Dorgham Sisalem and Sven Ehlert - Fraunhofer Fokus, Dimitris Geneiatakis, George Kambourakis and Tasos Dagiuklas - University of Aegean, Ji Markl and Michal Rokos Nextsoft, Olivier Botron - Telip, Jesus Rodriguez - VozTelecom, Juntong Liu - Embiron; A SNOCER deliverable - see previous reference; Towards a Secure and Reliable VoIP Infrastructure, May 2005 84: Tom Berson - Anagram Laboratories; An independent evaluation of Skype security; Skype Security Evaluation, October 2005 85: Massimiliano Montoro; A web page with program retrieving passwords stored with Windows CryptProtectData API - source code and description; http://www.oxid.it/creddump.html, January 2007 86: Saverio Niccolini - NEC Corporation; A presentation from "VoIP Security Workshop" in Berlin, May 2005; SPIT prevention: state of the art and research challenges, 2006 87: BorderWare; A company presentation about emerging VoIP threats; VoIP Security: The Rise of VoIP Threats, 2005 88: Kevin Mitnick, William Simon; A book of a very successful hacker - Kevin Mitnick, presenting social engineering techniques; The art of deception: controlling the human element of security, 2002 89: Mitel; General overview of security problems in a VoIP network. An appendix with fundamentals of encryption; Security Technology Brief, 2005 90: Stephan Rupp, Gerd Siegmund; A book describing problems of telecommunication applications. Contains also a chapter about security; Telecommunication Software Engineering, November 2004 91: P. Zimmerman - Zfone Project, A. Johnston - Avaya, J. Callas - PGP Corporation; ZRTP draft from Philip Zimmerman; ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement for SRTP draft-zimmermann-avt-zrtp-02, October 2006
Pawel Lawecki
Page 122
References 92: IETF; RFC 3711: The Secure Real-time Transport Protocol (SRTP); http://www.ietf.org/rfc/rfc3711.txt, March 2004
References
93: Dan Wing; A presentation comparing different media key exchange methods. Retrieved from: http://www3.ietf.org/proceedings/06mar/slides/raiarea-1/raiarea-1.ppt; Overview of SIP Media Security Options, March 2006 94: IETF; RFC 3830: MIKEY: Multimedia Internet KEYing; http://www.ietf.org/rfc/rfc3830.txt, 95: Christian Stredicke; A presentation from the Third Annual VoIP Security Workshop in Berlin (2006); Securing VoIP media communication, June 2006 96: IETF; RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams; http://www.ietf.org/rfc/rfc4568.txt, July 2006 97: IETF; RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security; http://www.ietf.org/rfc/rfc3207.txt, February 2002 98: IETF; RFC 2409: The Internet Key Exchange (IKE); http://www.ietf.org/rfc/rfc2409.txt, November 1998 99: Internet Mail Consortium; A web page with information concerning S/MIME working group; http://www.imc.org/ietf-smime/, January 2007 100: David M. Davis; Checklist with general IT security policies; Checklist: IT Security Policy, April 2005 101: Val Thiagarajan; Detailed audit checklist for IT systems; Information Security Management, BS 7799.2:2002, Audit Check List for SANS, August 2006 102: Edwin E. Mier and Randall E. Birdsall - Miercom; Detailed coverage of security problems in VoIP. Contains security comparison of some VoIP market devices; 2004: A VoIP Security Assessment, May 2004 103: Systems and Network Attack Center (SNAC), National Security Agency (NSA); IP telephony guideline for mitigation of VoIP vulnerabilities; Security Guidance for Deploying IP Telephony Systems, February 2006 104: Defense Information Systems Agency (DISA), Department of Defense (DoD); VoIP network implementation guide; Internet Protocol Telephony & Voice over Internet Protocol, Security Technical Implementation Guide, Version 2, Release 2, April 2006 105: Hong Yan and Hui Zhang - CMU, Kunwadee Sripanidkulchai - NECTEC, Zon-Yin Shae and Debanjan Saha - IBM T.J. Watson Research; A presentation from the Third Annual VoIP Security Workshop in Berlin (2006); Incorporate Active Fingerprinting into SPIT Prevention Systems, June 2006 106: Alexander Hoffman - IPTEGO; A presentation from the Third Annual VoIP Security Workshop in Berlin (2006); Securing Large Scale VoIP Infrastructure, June 2006 107: Bogdan Materna - VoIPshield Systems; A paper describing active approach to VoIP vulnerabilities; A Proactive Approach to VoIP Security, 2005 108: Tim Weber - BBC; An article describing problems concerning the Internet, mentioned during World Economic Forum in Davos (2007). Retrieved from: http://news.bbc.co.uk/1/hi/business/6298641.stm; Criminals 'may overwhelm the web', January 2007 109: Tim Weber - BBC; An article describing problems concerning the Internet, mentioned during World Economic Forum in Davos (2007); Criminals 'may overwhelm the web', January 2007 110: Michael Haberler and Otmar Lendl - enum.at; A presentation from the Third Annual VoIP Security Workshop in Berlin (2006); Selective Peering with Federations, June 2006
Pawel Lawecki
Page 123
References 111: Diaphonics; A description of Voice Verification mechanism; http://www.diaphonics.com/verification.php, January 2006
References
112: Saurav Bhattacharyya and T. Srikanthan - Centre for High Performance Embedded Systems (CHiPES), Nanyang Technological University; ITSC Synthesis Journal 2004 Retrieved from: http://www.itsc.org.sg/synthesis/2004/2004index.html; Voice Biometrics - Emerging Trends & Challenges for Deployment, 2004 113: Authentify Inc.; A paper about multi-factor authentication schemes including biometrics; Two-Factor Authentication Employing Existing Infrastructures, February 2006 114: Bruce Schneier; An article about general issues in biometrics. Retrieved from http://www.schneier.com/essay-019.html; Biometrics: Uses and Abuses, August 1999 115: Ariana-Michele Moore - Celent, LLC; A paper about biometrics in general; Biometric Technologies: Are We There Yet?, January 2006
Pawel Lawecki
Page 124

VoIP Security in Public Networks

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VoIP Security in Public Networks

Uploaded by

Copyright:

Available Formats

Master Thesis