Computer Networks 52 (2008) 2432–2446

Contents lists available at ScienceDirect

Computer Networks

journal homepage: www.elsevier .com/locate /comnet

Assessing the risk of intercepting VoIP calls

M. Benini *, S. SicariUniversità degli Studi dell’Insubria, Dipartimento di Informatica e Comunicazione, via Mazzini 5, IT-21100 Varese, Italy

a r t i c l e i n f o

Article history:Received 6 February 2007Received in revised form 29 January 2008Accepted 5 May 2008Available online 8 May 2008

Responsible Editor: Chuang Lin

Keywords:VoIP securityRisk assessment

1389-1286/$ - see front matter � 2008 Elsevier B.Vdoi:10.1016/j.comnet.2008.05.001

* Tel.: +39 0332 218933; fax: +39 0332 218919.E-mail addresses: marco.benini@uninsubria.it (

sicari@uninsubria.it (S. Sicari).

a b s t r a c t

Voice over-IP (VoIP) solutions and services for corporate telephony are usually marketed as‘cost-free’ and ‘secure’: this paper shows that both statements are false in general. Thoughbeing no doubt about the economical benefits resulting from the adoption of VoIP productsinstead of the standard telephony, hidden costs related to VoIP services security arisewhenever a company intends to assure the privacy of its phone conversations. This conclu-sion is extensively justified in the literature and this article aims at reasserting it by anal-ysing the risk that a VoIP phone call may be intercepted when travelling across theInternet. The purpose of deriving a well-known conclusion consists in proving that a gen-eral and formal risk assessment method can be used in place of ad-hoc methods not onlywithout losing the strength in the results but also adding up a sound mathematical andengineering foundation.

� 2008 Elsevier B.V. All rights reserved.

1. Introduction

Voice over IP (VoIP) services have seen a great raise ofinterest and popularity in recent years, probably becausesimple yet effective products, i.e. Skype [1], have appearedin the market, promising high-quality and low-cost substi-tutes for the traditional telephony. However, they arebeginning to cause a new set of problems, despite beingmature enough to partly fulfil these expectations. In thisrespect, security is undoubtedly the most questionable as-pect of VoIP: in the world of traditional telephony, the pri-vacy and security of conversations are guaranteed up tothe physical layer of a network; a phone call can be heardby an intruder either by directly listening to the call, i.e.being in the same room, or by violating the physical secu-rity of the phone network itself or its devices, i.e. by putt-ing a phone in parallel on the same line.

The problem of VoIP security has been addressed bymany researchers in the telecommunication and in theInternet security fields [2–7] (see also Section 6 for furtherdiscussion), as well as by newspapers, i.e. see [8–10]. What

. All rights reserved.

M. Benini), sabrina.

emerges so far is that VoIP security is more than just Inter-net security because of the service’s distinctive features: aphone call is in fact a real-time communication, thus anyexternal action causing a delay does actually interfere withits normal flow, disturbing what is meant to be observed.

The intrinsic security problems are also increased byVoIP technology marketing strategies, which have engen-dered a number of misbeliefs and wrong expectations evenimpairing the evaluation of the risks connected with theadoption of VoIP-based solutions. In particular, marketingslogans such as ‘a cost-free solution’1 and ‘a solution as se-cure as your network’ convey the misleading informationaccording to which VoIP services are both secure and (al-most) cost-free, thus evidently underestimating security-re-lated costs and efforts. Hence, despite the presence ofmature, stable and solid VoIP products offering importanteconomical benefits, it is to be pointed out how a knowledgeof the security and privacy risks associated to their useunfortunately is still lacking.

In the light of the above sketched considerations, thepresent paper discusses the application of a simple yet

1 This slogan represents an extreme situation, since lots of VoIP-relatedservices actually require the payment of small fees, i.e. a Skype call to aPSTN number.

2 As usual, the term ‘gateway’ refers to a device connecting differentnetworks; from now on the term ‘gateway’ alone is reserved to routergateways, the devices connecting networks on the Internet, while ‘VoIPgateway’ is used when referring to the device translating VoIP intoswitched telephony and vice versa.

M. Benini, S. Sicari / Computer Networks 52 (2008) 2432–2446 2433

effective formal risk assessment methodology to analysethe risk of intercepting a VoIP phone call traversing theInternet. This situation is perceived as a major threat bythose companies moving from traditional telephony toVoIP services as for their internal phone system: the riskanalysis will prove that the ‘cost-free solution’ and ‘as se-cure as your network’ slogans are both false, since theadoption of VoIP solutions can involve a factual risk and,all the more, the natural and effective countermeasuresaimed at mitigating it, are not cost-free and can evenstrongly impact on the overall security system of the com-pany network itself.

In particular, this article takes into consideration thecase of a multi-branched company internally communicat-ing and exchanging information through the Internet: thepotential attacker operates in the Internet and her/his goalconsists in capturing a live conversation between twophones within the private networks. Besides, here it isgoing to be considered a more specific situation involvingfour diverse scenarios: an isolated hacker, a maliciousInternet Service Provider (ISP) lying somewhere in theInternet, a malicious ISP on the route of the phone calland, finally, the case of the VoIP traffic travelling in a virtualprivate network (VPN). The above listed cases are quitecommon in those geographically distributed organisationsplanning to move from traditional telephony to VoIP.

A distinctive and unusual aspect of the present analysisand of the scenarios taken into consideration lies in theassumption that the attacks cannot compromise the pri-vate networks. Such a postulation has to be regarded as alimitation allowing to confute the slogan ‘as secure as yournetwork’; it will in fact be demonstrated that there is a realrisk of intercepting phone calls even presupposing ‘yournetwork’ as being perfectly secure. Moreover, since the at-tack vectors to break the security of VoIP services inside aprivate network are well studied, see Section 6, ‘internal’threats are widely covered by the existing literature.

However, since it is here taken into account only a sub-set of the possible threats, aggregating the others (i.e. DNSpoisoning, WiFi interception, etc.) as subclasses of generalvulnerabilities, the related countermeasures will be gen-eral when addressing a class of specific vulnerabilities.

Therefore, by expanding the results in [11], where onlythe scenario of an isolated attacker has been accounted for,this essay evaluates in depth the risk of the call intercep-tion coming from the Internet. It will be concluded thatVoIP solutions are cost-effective and their security can beensured up to a reasonably high level; however they aredefinitely not cost-free and have a significant impact onthe overall security of the networks hosting them. It is tobe pointed out that these conclusions are well-knownwhen the literature dealing with the same problem is con-sidered. Hence, the novelty of this contribution lies in theway the results are derived.

The method allowing us to draw these conclusions on astrong scientific basis is in fact used to analyse a generalscenario rather than a specific case. Moreover, this workshows how to draw conclusions from a risk analysis notstrictly depending on the analysts’ expertise,since diverseexperts will achieve equivalent (in a strict mathematicalsense, see [15] and Sections 3 and 5) results.

Therefore, although the above reported weaknesses arewell-known due to a wide number of empirical studies, seeSection 6, their structured analysis has been thus far con-ducted only by means of ad-hoc methods: this paper in-tends to convey the idea that general and formal riskassessment methodologies are as suitable as ad-hoc meth-ods, since they lead to the same results, though being sim-pler to apply because of their standardisation. They evenproduce sounder results because their reliability is certi-fied by a supporting mathematical theory.

2. The VoIP architecture

The standard VoIP architecture, see Fig. 1, is based on aset of hardware or software IP phones over an IP network;moreover, the IP network, usually the Internet, can be con-nected to a traditional phone system (PSTN) by means of aVoIP gateway transforming VoIP calls and conversationsinto phone calls to/from a PBX. In addition, the IP phonesmay benefit from a voice server providing auxiliary supportto the VoIP services, i.e. translation from user names to IPaddresses and vice versa.

The main components of the architecture are:

� IP phone: a terminal (A and B in the figure) with nativeVoIP support and the possibility to directly connect toan IP network;

� VoIP gateway2: a network device (VG in the figure) con-verting signals from/to the telephony interfaces (POTS,T1/E1, ISDN, E&M trunks) and the VoIP protocols;

� Voice server: a network server providing the manage-ment and administrative functions with the necessarysupport to the routing of the calls across the network;in a system based on H.323, the server is known as thegatekeeper; in SIP/SDP, the server is called SIP server; ina system based on MGCP or MEGACO, the server isnamed call agent;

� IP network: an interconnection structure based on theTCP/IP protocol family; the IP network can be a privatewide-area network, an intranet, or the Internet.

As it has been stated in the Introduction, this work aimsat evaluating the wire tapping risk in a VoIP system, i.e. therisk of successfully intercepting a live conversation be-tween two IP phones. The core principle lying at the basisof the approach selected for the present risk analysis [12]consists in taking into consideration the dependenciesamong the system vulnerabilities: evidently, these depen-dencies are strictly related to the system architecture.

The most direct way to perform a wire tapping attack isto break the security of the private networks hosting thetwo communication end-points: if an intruder is allowedto enter them, s/he can dispose of a wide range of tech-niques to listen to VoIP conversations. These threats havebeen analysed at length in the literature [13,14] as

Fig. 1. The VoIP architecture.

2434 M. Benini, S. Sicari / Computer Networks 52 (2008) 2432–2446

discussed in Section 6. However, this form of attack is usu-ally seen as unrelated to the VoIP traffic; on the contrary, itis usually believed – as far as the commercialisation of VoIPservices is concerned – that ‘a secure network gives a se-cure VoIP system’. The absolute security of private net-works is thus assumed in this paper so as to confute thefalse beliefs according to which VoIP services security is re-duced to private network security. Not only will the anal-ysis finally prove, see Section 5, the importance of privatenetworks security – which constitutes the major weaknessas for the security of VoIP conversations – but it will alsohighlight further ways to break the security of VoIP sys-tems, whose protection will involve significant economicalcosts. As a matter of fact, the balance between VoIP tech-nology security and its economical advantages seem notas clear as the market typically promises.

In this respect, four scenarios can be identified, where itseems possible to carry out a VoIP phone call interceptionwithout breaking the private networks’ security:

� Scenario I: an isolated attacker in the Internet. In this sce-nario, represented in Fig. 2, the IP phones A and B lie in

Fig. 2. The first scenario: an isola

Fig. 3. The second scenario: a malicious ISP

two private networks delimited by the G1 and G2 gate-ways (the border gateways) connecting them to theInternet. Here a hacker is supposed to be in the publicInternet with the scope of intercepting a conversationcrossing the Internet from A to B.

� Scenario II: a malicious ISP outside the route of the conver-sation. The difference between this scenario, see Fig. 3,and the previous one lies in the presence of a maliciousISP outside the route of the conversation instead of theisolated hacker: it is to be pointed out how an ISP’sknowledge and ‘status’, availability of devices as wellas possibility of managing a piece of the Internet areusually deemed as a major advantage when securityattacks are at issue, especially as opposed to a maliciousindividual’s more modest opportunities.

� Scenario III: a malicious ISP on the route of the conversa-tion. In this context, Fig. 4, the point where the wire tap-ping attack is performed is located in a malicious ISPlying on the route of the conversation. ISPs are usuallyreliable companies providing their clients with a securetransport of data and communications: however, a fewrecent cases, i.e. see [9,10], have revealed that even

ted attacker in the Internet.

outside the route of the conversation.

Fig. 4. The third scenario: a malicious ISP on the route of the conversation.

Fig. 5. The fourth scenario: the conversation travels in a VPN.

M. Benini, S. Sicari / Computer Networks 52 (2008) 2432–2446 2435

major telecommunication companies have sometimesbeen involved in security incidents where they actedas attackers. It seems thus worth considering whatmay happen when VoIP conversations are exposed tothe action of a malicious ISP.

� Scenario IV: the conversation travels in a VPN. In Fig. 5 aVPN is adopted to improve the level of security in thearchitecture. The VPN links together the private net-works where the IP phones are located. In this context,the conversation between A and B takes place as a com-munication between the private networks embedded inthe VPN channel: the VPN traffic is usually encrypted bythe border gateways before being transmitted throughthe Internet. This is the reason why it is interesting toevaluate the possibility of intercepting a VoIP phone callin this situation.

The above outlined scenarios are exhaustive covering asthey do any possible position of a potential attacker oper-ating in the Internet both in the case the VoIP traffic isinspectable and it is not (scenario IV). These scenarioscan and should quite obviously be dealt with more specif-ically when analysing a concrete situation: for instance, ifcountermeasures have been taken to protect a system traf-fic such as BGP, some of the attacks considered in this pa-per cannot be launched. This is the reason why thescenarios should be regarded as general frameworks wheredetailed analyses of concrete situations should be con-ducted: interestingly enough, it should be noted that thedetailed analyses are direct extensions of the scenarios ta-ken into account.

3. Measuring the risk

Risk assessment aims at quantitatively evaluating thedanger of an undesired event occurring in a given environ-ment. As far as this paper is concerned, the environmenthas been described in Section 2 as one of the referencearchitectures represented in Figs. 1–4; furthermore, the

undesired event is evident, that is to say the interceptionof a VoIP phone call.

Therefore, this section intends to define a specific no-tion of risk as well as illustrating the methodology em-ployed to evaluate it. The risk assessment procedure is infact based on a general engineering methodology de-scribed in other publications; some introductory informa-tion could be found in [12] while, as for the relatedmathematical treatment, the reader is referred to [15]. Thissection offers a concise overview of the risk assessmentprocedure in order to allow a better understanding of itsapplication to the VoIP phone call interception.

As for the present paper’s approach, the risk is a func-tion on two variables: the damage potential, that is tosay the average loss caused by an attack, and the level ofexploitability measuring the easiness to break a systemcomponent, as defined in [16]. In this specific case, the riskassessment procedure intends to determine the exploit-ability levels.

In brief, the risk assessment procedure consists of fivesteps:

(1) The possible threats to the system are modelled bymeans of an attack tree [17]: the root node repre-sents the attack goal and, recursively, the childrencan be alternative subgoals, each one satisfying theparent goal (or subtree) or partial subgoals, whosecomposition satisfies the parent goal (and subtree).The tree’s leaves stand for the vulnerabilities of thesystem enabling the attacks modelled by thesubtrees.

(2) The dependencies among the identified vulnerabili-ties are determined: a vulnerability v depends on avulnerability w if and only if v may become easierto utilise to attain the attack goal when w hasalready been compromised.

(3) To each vulnerability v in the attack tree is associateda numerical index E0(v), called its initial exploitability,measuring the chances that v may be successfully

2436 M. Benini, S. Sicari / Computer Networks 52 (2008) 2432–2446

used to break the security of the system. Similarly,the dependencies between pairs of vulnerabilitiesare weighted on the same metric: a value E(vjw) isassigned to each pair (w,v) of dependent vulnerabili-ties, meaning that the exploitability of v becomesE(vjw) when w has been compromised.

(4) The exploitability Ei(v) of each single vulnerability vis updated to a new value Ei+1(v) to take into accountits dependencies, until the values reach a fixed point,that is to say when the effects of the dependencieshave been fully considered. As proved in [15], theiteration process converges in finite, bounded time,ensuring the termination of the process.

(5) The risk associated to the threat under examinationis finally computed by recursively aggregating theexploitabilities along the attack tree. The exploit-ability of an or subtree is the easiest (maximumvalue) of its children, and the exploitability of anand subtree is the most difficult (minimum value)of its children. Finally, the aggregated exploitabilityof the root node, which measures the level of feasi-bility of the attack, is combined with the damagepotential to assess the risk of the threat.

The first step generates an attack tree, whose leavesform set V of the system vulnerabilities. Likewise, Step 2produces the dependency graph G = hV,Di, whose nodesare the system vulnerabilities and whose edges are thedependencies: an edge (v, w) 2 D means that the exposi-tion of w seems easier when v has been compromised.

In Step 3, the evaluations E0(v) of the initial exploitabil-ity of every vulnerability and the weightings E(vjw) of theidentified dependencies are produced. The values E(vjw)obey the constraint E(vjw) > E0(v), meaning that the exploi-tation of w eases the abuse of v. These numerical values liein the range [0,10] where 0 means impossible to exploit and10 means immediate. The exploitability values are chosenby security experts conducting the risk analysis by takinginto account the relative difficulty in making use of thevarious vulnerabilities. Although this evaluation is subjec-tive depending on to the experts, it is remarkable the factthat the whole risk assessment procedure depends juston the ordering of the exploitability values, as mathemat-ically proved in [15]. As a matter of fact, since differentmetrics with the same ordering structure are equivalent,it follows that most of the seemingly different evaluationsare actually the same, despite using different values.

Then, in Step 4, the notion of exploitability is general-ised by means of the function family E : N� V ! ½0;10�mapping the vulnerabilities to [0,10]; thus the valuesEi(v), with i varying over natural numbers, are associatedto the vulnerability v. The initial value E0(v) has been fixedin Step 3, while the other values are calculated by meansof

Eiþ1ðvÞ ¼maxðEiðvÞ; fminðEðvjwÞ; EiðwÞÞ : ðw; vÞ 2 DgÞ ð1Þ

whose rationale is to include the potential influence of thedependencies in evaluating the exploitability of a vulnera-bility v. This influence manifests itself when it is easier toattack a connected vulnerability w both because Ei(w) ishigher, that is to say that w is easier to exploit, and, when

w is compromised, the misuse of v is simplified, that is itsexploitability becomes E(vjw).

Finally, during Step 5, the outcome of Step 4, that is thefixed point values in the iteration of the formula (1), isdistributed along the nodes of the attack tree. The resultis an attack tree where every node is decorated by anexploitability value: then, by applying the risk function,one may calculate the risk of the root node and, if needed,the risk of every subtree as the risk of the root of thesubtree.

4. The risk analysis of the VoIP scenarios

4.1. Step 1: construction of the attack tree

An attack tree [17] describes how an attacker may breakthe security of a system: the attacker’s goal is the root ofthe tree. In the present case, the goal consists in intercept-ing a VoIP phone call crossing the Internet. Intercepting acall means that the attacker is able to listen to the commu-nication and understand its content: in particular, it is tobe pointed out that the exact copy of an encrypted VoIPcommunication is not considered as an interception, sinceits content, that is the conversation, is not disclosed. On thecontrary, a real-time listening is not different from makinga copy. Therefore, the main goal of the attack tree gener-ates two subgoals whose aim is to get a copy of the com-munication and to understand its content. The latter goal,although difficult, is quite standard: given an encryptedcommunication and being able to know how the data is en-coded, the attacker would have to break or guess theencryption key and decode the data to retrieve the originalconversation. The goal of copying the communication ismore interesting: in fact, the scenarios of Section 2 play acrucial role in the way an attacker may act.

The attacker is assumed to know how to identify thecommunication s/he is interested in intercepting: thishypothesis implies that the attacker knows somethingabout the structure of the private networks at the end-points of the communication of interest. This knowledgeusually allows to determine the IP addresses of the gate-ways on the frontiers of the private networks: accordingto the initial information, the attacker may either use thenetworks registration data the Domain Name System, thewhois service or trace the routes to some known internalpoint within the private networks. Alone or combined,these information disclosure techniques enable the attack-er to learn the IP addresses of the frontier gateways; thiswill be therefore taken for granted from now on.

Moreover, because of the scenarios taken into consider-ation, and because this article focuses on confuting themisleading thesis according to which VoIP services canbe added to existing private networks without alteringtheir security posture and economical costs, the risk anal-ysis will begin by presupposing that private networks can-not be directly attacked. As already hinted at in theIntroduction, this attitude is quite common during thetransition period from traditional telephony to VoIP ser-vices employment: this is the reason why the assumptioninevitably confines the risk analysis to those scenarios

M. Benini, S. Sicari / Computer Networks 52 (2008) 2432–2446 2437

recognised as risky. The most dangerous scenarios will beeventually result to be those usually considered as trust-worthy, that is to say the attack from a ‘reliable’ ISP andthe one inside the private networks.

The attack tree is shown in Fig. 6: it has been con-structed by expanding the main goal in two subgoals, as al-ready described. The second one (case 2) has beendecomposed in two subgoals: the first one exploits the fact(case 2.1.2) that the information about the voice encodingis written in the control channel. In fact, a VoIP call oper-ates on a double connection [18]: a control channel, uti-lized to determine the parameters of the communication,start and stop voice transfers, identify the connection of

Fig. 6. The combine

the media channel, etc.; and a media channel, whose func-tion consists in transporting the voice from one end-pointto the other.

The vulnerabilities, i.e. the leaves of the attack tree,marked with a (*), are considered to be immediate since,when the attack reaches that point in the tree, the difficul-ties in exploiting its vulnerabilities will already be over-come. On the contrary, the (+) marks on the vulnerabilitiesmean that they cannot be evaluated in isolation: for in-stance, in (case 2.2), if the voice is not encrypted, as in mostcases, it is possible to immediately exploit the vulnerabil-ity; however, if the media channel makes use of a strongencryption, the same vulnerability becomes almost

d attack tree.

Table 1Detected vulnerabilities

Vulnerability Description

V1 The identified gateway has a weak authenticationmechanism

V2 A link connected to the identified gateway can be sniffedV3 Information disclosure on the private networksV4 The source routing option is enabled in one of the

gateways on the frontier of the private networksV5 The identified gateway can be remotely controlled from

the attacker’s position in the InternetV6 The identified gateway exchanges OSPF announces with

its neighboursV7 The identified gateway exchanges BGP announces with

its neighboursV8 The encryption algorithm or the encryption key of the

VPN channel is weak

Table 2The difficulty in exploiting the vulnerabilities in the scenarios

Vulnerability Isolatedhacker

Off-pathmalicious ISP

On-pathmalicious ISP

VPN

V1 easy easy very easy ?V2 very

difficultvery difficult very easy ?

V3 onaverage

on average very easy ?

V4 difficult difficult easy ?V5 difficult difficult very easy ?V6 very

difficultdifficult very easy ?

V7 verydifficult

difficult very easy ?

V8 ? ? ? verydifficult

2438 M. Benini, S. Sicari / Computer Networks 52 (2008) 2432–2446

impossible to attain, thus the whole (case 2) subgoal resultsimpracticable.

Going into further detail, it is to be highlighted that thefirst subgoal (case 1 in the attack tree) may be reachedeither by gaining control of a gateway on the route fol-lowed by the communication to be copied, or by divertingthe route. In the first case, the attacker can access the gate-way as system manager (case 1.1.2) and then single out thecommunication of interest in the crossing traffic (case1.1.3): if the communication does not travel in a VPN tun-nel (case 1.1.3.2 in the attack tree, corresponding to thescenarios I, II and III), the attacker can easily obtain theRTP ports of the media channels involved in the communi-cation by inspecting the control channel and consequentlycopy them; if the communication travels in a VPN tunnel(case 1.1.3.1 and the fourth scenario), the control channelcannot be directly inspected, thus the VPN traffic has tobe decoded.

In the second case, if the attacker chooses to divert thetraffic (case 1.2), s/he will consequently poison the routein such a way that the communication will flow through amalicious gateway under her/his control (case 1.2.2): then,he may go on listening to the communication as already de-scribed (cases 1.1.1, 1.1.2 and 1.1.3 in the attack tree). Inboth cases, the first step consists in individuating a suitablegateway in the route followed by the communication (cases1.1.1 and 1.2.1): the gateway may be either a border gate-way, i.e. a gateway on the frontier of one of the private net-works, or an intermediate gateway; the selection willdepend on its vulnerability to attacks, a feature which canbe easily tested for every gateway on the identified route.

As a matter of fact, VoIP protocols peculiarities limit thepossibilities of an attacker and, as a consequence, the shapeof the attack tree: in fact, the admissible attacks must notinterfere with the existing connections on the gateways,otherwise the VoIP call will be influenced and thereforedrop. This is due to the fact that VoIP calls are real-time,streaming connections, hence any loss or detour will highlyprobably bringing the communication to conclusion, thusdestroying what an attacker intended to observe.

Moreover, an attack to a gateway involves a strictersubset of the techniques the Internet attacker has generallyat her/his disposal: the attacker can reach his/her goalsonly by avoiding influencing any existing connection. Forinstance, the category of denial of service attacks is banned,since they aim at substituting a device after its collapsedue to resource shortage: as for the VoIP traffic, a gatewaycollapse can delay the voice call due to a network conges-tion, thus causing the call to drop. Similarly, since the goalis to copy an existing connection, the attacks to access agateway limit to trying to login as system manager: mostexamples of threats involving the exploitation of softwarebugs in the operative system are either not deep enough topermit to copy the desired connections, or even too inva-sive, making the existing connections die or be delayed.Consequently, the attack tree in Fig. 6 can be deemed quiteexhaustive in the development of the scenarios taken intoaccount.

To sum up, the identified vulnerabilities are listed inTable 1. A few remarks are all the more worth reportingas follows:

� Identification of a gateway’s address is fundamental inorder to attack it, either by accessing it or diverting itstraffic. V3 vulnerability implies that, from the informa-tion regarding the conversation target of the attack,which has been assumed to be learnt, the potentialintruder may reconstruct the IP addresses of the gate-ways on the frontiers of the private networks.

� The case 1.1.1.2.1 in the attack tree requires to trace theroute between the conversation end-points and, in par-ticular, between the two gateways on the frontiers of theprivate networks. This goal can be accomplished bymeans of the traceroute service, calculating the routebetween two nodes in the Internet as well as reportingan estimate of the round trip time. By using the sourcerouting option of the IP protocol [19], one can make atraceroute from a malicious host to one of the bordergateway follow a route crossing the other border gate-way. In this manner, it is possible to see the optimalroute between the two border gateways as well as esti-mating the round trip time between every pair of nodesin the route. This is the reason why the source routingoption enabled in one of the border gateways has beenlisted as V4 vulnerability in the table.

� V6 and V7 vulnerabilities have been introduced to modelthe fact that, in order to poison the route between theborder gateways, one has to announce a false route to

Fig. 7. The dependency graph.

M. Benini, S. Sicari / Computer Networks 52 (2008) 2432–2446 2439

a neighbour that is a legitimate gateway on the legalroute. This is hardly ever possible, since only ‘important’gateways are used to announce long-range routes,though it is still likely to construct false announces ifone has the control of a malicious gateway credited asa legal OSPF or BGP gateway by its neighbours.

� V8 vulnerability has been introduced because decryptinga VPN, see case 1.1.3.1.1, depends on the adoption of aweak algorithm or a weak set of encryption keys.

The identified vulnerabilities are differently importantin the light of the diverse scenarios. Table 2 shows a qual-itative evaluation of the difficulty in exploiting the vulner-abilities in the scenarios taken into consideration. V8

vulnerability makes sense only within the fourth scenario,while the vulnerabilities ranging from V1 to V7 influencethe possible attacks only within the other scenarios, hencethe ‘?’ signs.

Table 3The difficulty in exploiting the dependencies

V1 V2 V3 V4

V1 – very easy difficult difficultV2 difficult – difficult –V3 difficult – – –V4 – – easy –V5 on average – – –V6 – – – –V7 – – – –V8 – – – –

Table 4Conversion of the qualitative evaluations into quantitative ones

very easy easy on average

9 7 5

4.2. Step 2: the dependency graph

The identified vulnerabilities are not independent: infact, it suffices to break one of them to easier exploit theothers as well. The overall framework, encoded as a depen-dency graph, see Section 3, is represented in Fig. 7.

Its edges can be explained as follows:

� exploiting a weak authentication in the identified gate-way, i.e. V1 vulnerability means having control of thegateway, thus V2 vulnerability is immediately achieved;moreover, if the identified gateway is a border gateway,V3, V4 and V8 vulnerabilities are achieved as well.

� misusing V2 vulnerability means that the traffic on a linkconnected to the identified gateway can be observed bythe attacker; if the administrator of the gateway con-nects via the sniffed link, V1 is attained; moreover, thecontent of the traffic allows the attacker to acquireinformation about the private networks when the gate-way forwards the traffic originated from or directed to aprivate net, thus simplifying the exploitation of V3

vulnerability.� exploiting V3 vulnerability means collecting useful infor-

mation about the private networks; if the identifiedgateway is a border gateway, then the collected infor-mation may reveal that the gateway is controlled alsofrom outside, simplifying V5, and may even give sugges-tions to guess the password of the gateway, thus simpli-fying V1.

� It is evident that achieving V4 means discovering theroute between the two border gateways, thus implyingan information disclosure, i.e. V3.

� abusing V5 means being aware that the identified gate-way can be remotely controlled, which simplies V1; theway to acquire this knowledge usually reveal some sug-gestions of the system traffic originating from the gate-way, in particular the enabled routing protocols, thusallowing the exploitation of V6 and V7 vulnerabilities.

Hence, from a different viewpoint, the difficulty inexploiting a vulnerability – given the successful misuse

V5 V6 V7 V8

– – – difficult– – – –difficult – – –– – – –– difficult difficult –– – – –– – – –– – – –

difficult very difficult impossible

3 1 0

Fig. 9. The weighted dependency graph in the off-path ISP scenario.

2440 M. Benini, S. Sicari / Computer Networks 52 (2008) 2432–2446

of a depending one – is summarised in Table 3: every entryin the table qualitatively measures the difficulty in attain-ing the vulnerability in the column, taking into account theprevious exploitation of the vulnerability in the row: forinstance, in the case the column is V3 and the row is V4,the table cell will measure E(V3jV4).

As a matter of fact, the dependencies change neither intheir presence nor in their evaluation in the scenariosintroduced in Section 2: in fact, the scenarios act by chang-ing the degree of exploitability of the single vulnerabilities,making dependencies useful or useless according to theinitial exploitability assessment.

4.3. Step 3: evaluating exploitabilities

In the previous steps, a qualitative evaluation of theability to exploit various vulnerabilities has been ac-counted for. The qualitative judgement is debatable tothe extent that it has been conceived by security experts,basing their evaluation on their experience and knowledge.The reader could either agree on the evaluations providedor continue applying the method starting with a differentviewpoint: further on, see Section 5, it will be highlightedthat the initial assessment will have a weak influence onthe conclusions of the present work. Nevertheless, theapplication of the risk assessment methodology, as de-scribed in Section 3, is needed so as to justify the conclu-sions themselves, as it will appear in the end.

Therefore, qualitative evaluations are converted intonumbers, following the metric shown in Table 4: theexploitability values are in the range 0–10. The resultingdependency graphs in the various scenarios are depictedin Figs. 8–11.

In the first scenario, the initial assessment reveals thatmost vulnerabilities are difficult to be exploited due tothe attacker’s low status: an hacker does not have directaccess to a trusted gateway, and thus s/he cannot poison

Fig. 8. The weighted dependency graph in the hacker scenario.

Fig. 10. The weighted dependency graph in the on-path malicious ISPscenario.

the Internet routes (V6 and V7); s/he cannot either sniff alink directly connected to a gateway on the path followedby the conversation (V2); he may use the source routingoption of a gateway (V4) or the control channel of a gate-way (V5), i.e. by trying to connect via the SSH or telnetprotocols; these vulnerabilities are nonetheless difficultto misuse in her/his position. On the contrary, a weakauthentication on the gateway (V1) or, to a less extent, col-lecting information about the private networks can be suc-cessfully used to harm.

Differently, in the second scenario, see Fig. 9, the attack-er holds a higher status in the Internet, that is the hacker is

Fig. 11. The weighted dependency graph in the VPN scenario.

M. Benini, S. Sicari / Computer Networks 52 (2008) 2432–2446 2441

an ISP with a trusted gateway exchanging routing informa-tion with its neighbours. As for the first scenario, V6 and V7

vulnerabilities are easier to exploit since, if the attacker’sgateway directly exchanges routing information with agateway located on the conversation path, it is easier topoison its routes. Of course, this is a relative judgement:a combination of proximity and clever misuse of the at-tacker’s gateway is required to successfully mount thiskind of attack, hence the corresponding exploitability va-lue is still ‘difficult’.

The third scenario, in Fig. 10, illustrates what happenswhen the attacker is an ISP lying on the route followedby the conversation. In this case, all vulnerabilities can bevery easily exploited, since the gateway through whichthe conversation flows is controlled by the attacker: it isjust a matter of identifying the conversation among themany connections.

The fourth and last scenario, see Fig. 11, describes thesituation where the VoIP call does not merely travel inthe Internet, being embedded as it is in a VPN channel;the conversation is thus encrypted and not easily separable

Table 5Propagation of dependencies

iteration E(V1) E(V2) E(V3) E(V4)

0 7 1 5 31 7 7 5 32 7 7 5 30 7 1 5 31 7 7 5 32 7 7 5 30 9 9 7 91 9 9 7 92 9 9 7 90 ? ? ? ?1 ? ? ? ?2 ? ? ? ?

from the other connections in the channel. In this case, it isusually very difficult to decrypt the VPN channel; more-over, the exploitation of the other vulnerabilities shouldnot influence the final difficulty in launching a successfulattack to the system. In Section 4.5 it will be proved that,in fact, the aggregated exploitability of the root node ofthe attack tree depends mainly on V8, as expected.

4.4. Step 4: propagating the dependencies

As it has already be pointed out in Section 3, the prop-agation of the dependencies is repeatedly calculated byapplying formula (1): the results are displayed in Table 5.

In particular, the unknown (‘?’) values on V8 vulnerabil-ity have been dealt with by establishing a lower bound forthe corresponding exploitability value. In this way, thereemerges the amount of influence induced by the depen-dencies on the exploitability of V8 in the scenarios I, IIand III. Instead, in the fourth scenario, the unknown valueshave not been lower-bounded since, as it will be high-lighted in the following section, their influence on theoverall risk assessment is limited to their upper boundingof V8 vulnerability.

4.5. Step 5: aggregation and risk assessment

In order to determine the exploitability of the root nodein the attack tree, i.e. the feasibility of intercepting a VoIPphone call, the exploitability values of the leaves are aggre-gated on every subtree as described in Section 3. The attacktree obtained as the result of the aggregation process isshown in Fig. 12: a label, indicating the exploitability val-ues in the four scenarios under examination, is attachedto every node; as already said, the nodes marked with (*)are immediate, i.e. their label is [I: 10, II: 10, III: 10, IV:10]. The case 2.2 is marked with the [I: x, II: x, III: x, IV:x] label, whose exact value depends on the employed in-stance of the VoIP protocol; in particular, the value x repre-sents the feasibility to decrypt the VoIP media channel.

Slightly surprisingly, the first and second scenarios getthe same results, which means that the different statusheld by an hacker and an off-path ISP does not affectthe risk under analysis. The final exploitability value inthe root node can be easily lowered by encrypting themedia channel, to the detriment of a wider bandwidth

E(V5) E(V6) E(V7) E(V8) scenario

3 1 1 ? I3 3 3 P33 3 3 P33 3 3 ? II3 3 3 P33 3 3 P39 9 9 ? III9 9 9 P39 9 9 P3? ? ? 1 IV? ? ? 63? ? ? 63

M. Benini, S. Sicari / Computer Networks 52 (2008) 2432–2446 2443

encryption, no security measure can be effective, since theorigin of the exploitability value of the root node is not asingle case in the attack tree, but the whole set of leavesin the subtree of case 1.

Finally, when the conversation travels in a VPN, it is dif-ficult to achieve the goal of the root node because of theVPN complex decoding, case 1.1.3.1.1.

As a matter of fact, the origin of the exploitability valuesin the root node, in the various scenarios, have been tracedin the attack tree to find out the single vulnerability or thecombination of vulnerabilities which determine the wholetree’s overall exploitability level. This analysis has revealedthat scenarios I and II are essentially equivalent and thatthe major source of risk consists in the ability to remotelycontrol a gateway on the route followed by the conversa-tion. Furthermore, the investigation has undoubtedlypointed out that by encrypting the media channel, i.e. thecontent of the conversation, the overall risk can be low-ered. Likewise, the fourth scenario has been reduced tothe VPN decoding by scrutinizing the aggregation process.On the contrary, the analysis has highlighted that it is notpossible to guarantee security in the case of the third sce-nario: any local countermeasure will have no chance to im-prove the security of the system, since the origin of the riskis spread on the whole tree.

3 The bandwidth-related costs are rapidly decreasing due to the increasein wide- bandwidth connections. Nevertheless, the structural costs of aVPN-enabled device are still not to be neglected.

5. Evaluation

The analysis has so far revealed that the only scenarioreally at risk is the third one, where a malicious ISP is lyingon the route followed by the phone call. It is also to bepointed out that small variations in the exploitability val-ues do not significantly change the final outcome, as thereader is invited to check: nonetheless, the final result ofStep 5 is similar to the one derived in Section 4.5. This sta-bility in the risk assessment is due to the origin of theexploitability of the root node in the attack tree: small vari-ations in the initial exploitability values and in the weigh-tings of the dependencies do not modify the prominentpart of the attack, i.e. the set of its enabling vulnerabilities.Therefore, combined with the invariance under orderingequivalence of the methodology, see [15], even different ex-perts would get the same qualitative conclusion.

It can be hence asserted that the application of the riskassessment methodology has effectively supported theconclusion that the only significant risk in the interceptionof a VoIP phone call is a malicious ISP, that is to say ‘whenthe attack comes from outside the private networks’. It hasbeen further demonstrated that the natural countermea-sures applied to contrast this significant risk consists intunnelling the traffic which travels between the privatenetworks through an encrypted VPN channel.

It can thus be further inferred that the adoption of theVoIP technology as a substitute for the traditional tele-phony is not cost-free at all: the encryption and decryptionof the voice in a conversation in fact requires time, thusresulting in a bandwidth consumption caused by the secu-rity solution; moreover, the encrypted traffic is larger insize than the decrypted one, thus magnifying the use ofthe VPN bandwidth. Furthermore, it is to be considered

that, if (1) a VoIP phone call requires 8 Kbit/s to ensurethe proper quality and the correct information exchangebetween the end-points, (2) the encryption/decryptionprocess introduces a delay of 1 ms every second, and (3)an encrypted VoIP communication needs twice the spaceof a plain conversation, then the VPN will need to allocatea bit more than 16 Kbit/s to the VoIP connection so as to al-low its correct development. Thus the adoption of a VoIPsolution requires (a) the installation and maintenance ofa VPN between the private networks and (b) the doublingof the bandwidth dedicated to the VoIP service. Both (a)and (b) obviously involve additional costs and specific re-source allocation.

It is also to be noted that in the scenarios taken intoconsideration the secure solution may require to increasethe security posture of the private networks (if the VPNis not already used) and, of course, it will introduce a widerresource allocation, that is to say the bandwidth, involvinga potential increase in economical costs.3 Anyway, it can beconcluded that the promise of a cost-free telephony provesto be a false illusion and that the possibility to adopt aVPN solution – and thus benefiting from a potential conve-nience – should be evaluated in the light of each single caseand context.

Oppositely and complementarily, one may trust the ISPsbetween the two private networks: it is clear that littlecontrol over their action is possible. Trust can be intro-duced in the analysis of Section 4.5 by considering a riskfunction parametrised by a measure of trustworthiness ofthe ISPs: the difficulty in developing a sound measure tocombine the exploitability values with a measure of trustis evident, and it comes from the different nature of thetwo elements. In fact, while the exploitability values arejustified on a technical basis, the trust in the ISPs’ correctbehaviour comes from a set of social rules granted by laws,contracts, etc.

Nevertheless, although it is a fact that the great major-ity of the ISPs are trustworthy, there have always been ru-mours about misbehaviours, see i.e. [9,10]. Despite thelarge amount of positive behaviours in comparison witha limited set of bad cases, the easiness of performing aninterception by an ISP, as shown in the previous analysis,justifies the question whether trust is enough as a protec-tion measure. Apart from the answer, the fact of relying onthe moral integrity of ISPs can engender a risk with a veryhigh exploitability, thus the promise of a telephony ‘as se-cure as your networks’ proves to be false.

Finally, the attack patterns breaking the security of theprivate networks – either because the attacker is insideone of these networks, or because the external attacker isable to gain control of a component in these networksand use it, once compromised, to intercept the phone call– have not been considered in this work. In Section 6, anoverview of related publications will confirm that ‘internal’attacks have already been widely touched upon and that anumber of technical countermeasures are possible: alsofrom these works it can be inferred that the internal attack

2444 M. Benini, S. Sicari / Computer Networks 52 (2008) 2432–2446

is the most dangerous one since, although less exploitablethan the on-path ISP scenario, it requires a less demandingstatus of the attacker. As far as the aims of the present arti-cle are concerned, it should be highlighted that an internalattack does not falsify the promise that the VoIP telephonyis ‘as secure as your networks’, since the fact that an inter-nal attack can be mounted means that the private net-works are, to some extent, insecure. On the contrary, theinternal attack patterns, specific to VoIP services, are dan-gerous allowing as they do to expand the actions an attack-er may perform on the private network. As a consequence,VoIP cannot be considered cost-free any longer, since thewidening of the possible targets of an attack can bringabout, sooner or later, an increase in the security mainte-nance costs of the networks.

6. Some related publications

Voice over IP, convergence and real-time communica-tion are concepts that undoubtedly triggered off a revolu-tion in the ICT market: also in the literature there aremany works [20–25] pointing out the advantages of sucha new and innovative way of communicating. On the con-trary, the scientific community agrees that the spread ofVoIP services has encountered limits exactly because ofsecurity problems. For instance, NIST [26] asserts that thefact that the digitised voice is assumed to travel in packets,just like other data, make people believe that the existingnetwork architecture and tools can be used without mod-ifying them – a consideration emerged also form the anal-ysis reported in Section 5.

It must be underlined that the VoIP technology actuallyincreases complications in the existing networks; it is thusdeemed to be utmost important, in agreement with theVoIP Security Alliance [27], to study ad-hoc security solu-tions for the VoIP system. Lots of publications can be founddealing with the general threats connected to the adoptionof VoIP technology and the related countermeasures; inparticular, in NIST [26] the challenge lying at the basis ofthe VoIP security concept as well as the necessary stepsto secure a VoIP network are illustrated; also in Tanase[28] the main VoIP technology-related threats and conse-quential countermeasures are reported; in Bruschi et al.[29] the voice performance over IPsec (a possible instanceof the scenario IV) is scrutinized. Several other works canbe found offering an overview of general threats and re-lated countermeasures, i.e. [30–32,5].

Also [33] provides a detailed survey of the main potentialthreats carried out to the reliability and security of IP-basedvoice systems; in particular, the threats to VoIP systems arehere divided up into categories; then potential attacks foreach of the threat categories are detailed and the variousmitigation techniques are presented; finally, diverse recom-mendations related to each category are introduced on thebasis of the previous analysis. As the above brief overviewtestifies to, it can be pointed out that [33] is a quite usefulstarting point to evaluate the risk associated to different at-tacks on a VoIP system. However, compared with the pres-ent paper, [33] cannot be considered as a risk analysis,firstly because it does not define neither a qualitative nor a

quantitative metric and secondly because the (potential)resulting dangers are never quantified. It is nonetheless tobe accounted for as a valuable support for a risk assessmentanalysis thanks to its being a methodical and detailed infor-mation source about VoIP security.

All these works relate to the present paper in that theyprovide the necessary tools and techniques to deal withthat scenario where private networks are under attack:the many analyses doubtless reveal that this scenario iswell-known and, at least theoretically, there are strongmethods to supply hardening solutions for it.

Taking a slightly different slant, [34] investigates theVoIP performance when traditional security solutions (fire-wall, encryption, etc.) are adopted: the work is quite inter-esting in that it directly contributes to establish scenarios I,II and III.

Another interesting study is offered by Wang et al. [35],where the tracking of anonymous peer-to-peer VoIP callson the Internet are taken into account: according to theanalysis actually there are many users willing to anony-mise their conversations, though several practical tech-niques allow to effectively track anonymous VoIP calls onthe Internet. [35]’s main aim consists in identifying theweakness of some of the currently deployed anonymouscommunication systems: these techniques are obviouslysupposed to be useful in the case 1.1.1.2.1 of the attack treein Section 4.1, where the goal is to trace the route betweenthe communication end-points.

In Peng et al. [36], the main focus is placed on the vul-nerabilities of the SIP proxies against denial of service,attacks (DoS); an overview of state-of-the-art countermea-sures against this type of attacks is provided. It should benoticed that the attacks taken into consideration refer tothe initial setup of the communication session since, as ithas been remarked in Section 4.1, DoS attacks usually dis-turb VoIP conversations up to their loss.

Compared with the above mentioned works, the ap-proach adopted in the present paper is different in that –in agreement with those considering security as a processcharacterised by ordered phases – risk is quantitativelyevaluated by means of a formal assessment methodologydefined in previous works: hence, instead of listing andclassifying threats affecting the VoIP system and theirrelated countermeasures, the present paper tries to sys-tematically analyse the attack patterns allowing to suc-cessfully use these threats.

Although it is evident that the wire tapping risk is worthanalysing, the reader may wonder on what basis the meth-odology described in Section 3 can be deemed adequate. Ingeneral, risk, trust, security requirements mapping andcomponent interdependence are concepts strictly inter-connected and which have been extensively debated thusfar: for instance, Baskerville [37] describes the evolutionof different methods aimed at measuring the risks thatcould sometimes be combined to improve result accuracy.As for the systematic approaches, in Sami Saydjari et al.[38] a system security engineering methodology is dealtwith to discover the system vulnerabilities and to deter-mine what countermeasures are best suited to deal withthem: the leading paradigm consists in analysing informa-tion systems through an adversary’s eyes. An interesting

M. Benini, S. Sicari / Computer Networks 52 (2008) 2432–2446 2445

method together with the related tools to address securityissues when VoIP services are employed is presented inAbdelnur et al. [39], where, in particular, it is mentionedthat, in order to estimate some VoIP’s vulnerabilities andthreats, specifically related to SIP [18] and RTP [40] proto-cols, a tool named ‘Fuzzy Packet’ has been developed. [39]’sfinal aim is the realisation of an intrusion prevention sys-tem for a smart VoIP infrastructure, capable of performingadvanced self-defence operations.

In comparison with the above reported contributions,the present paper’s approach – starting from its initial def-inition in [12] – has been based on the structured evalua-tion of the single vulnerabilities along with their mutualdependencies. In this respect, the results in [38,41] aresimilar, although they do not propose any formal method-ology based on a strict mathematical foundation. In fact,the distinctive aspect of the selected approach – especiallyas opposed to the previously briefly touched upon – is themathematical formalisation of the risk assessment methodto derive its characterising properties [15], which – in par-ticular the often repeated fact that the results depend onlyon the order of the values in the metric – allowed riskassessment methodology to be used to develop a generalanalysis of the wire tapping risk.

Though security risks have been extensively dealt within the framework of risk management methodologies [42–44], information security experts do not agree on the bestor most suitable method to assess the probability of com-puter incidents [45].

In the literature there are many works about risk man-agement methodologies [44,43,42,38,46,47] and, amongthese, there are some interesting practical applications[48,49]. Considering risk assessment as a decision supporttool, Fenton [46] proposed the use of Bayesian networks.Instead, since the present paper’s approach towards objec-tive risk assessment is based on the abstraction over val-ues, what matters is the structure of the metrics. Hence,objectivity is achieved by considering the values in themetric not as absolute measures, but as relative evaluationsof risks, see [15] for a detailed discussion. Therefore, inagreement with [50,38,46,51], the information computedby the present model can be specialised to a decisionalsupport to find out the ad-hoc security solutions for a spe-cific implementation of the VoIP system.

7. Conclusion

This paper has discussed the problem of assessing therisk of the interception of a VoIP phone call in the Internetwith the aim of confuting the usual marketing promise ofoffering a ‘cost-free’ and ‘secure’ telephone service. More-over, the ultimate scope was for this article to certify a gen-eral and formal risk assessment method by pointing outthat its results coincide with the well-known theses al-ready derived by means of ad-hoc methods.

The analysis has proved that, even limiting the possibleattacks to those not involving private networks, the onlyway to secure a VoIP conversation consists in encryptingits content, either by adopting a protocol which supportsencryption, or by tunnelling the conversation in a VPN.

Moreover, this solution is secure in the sense that no‘external’ (conducted exclusively within the Internet) at-tack has a significant probability to successfully interceptVoIP phone calls among private networks, though it im-pacts on the management and maintenance of private net-works in terms of economical costs.

The other possible attack vector is the compromising ofone of the private networks: this pattern has been exten-sively studied, thus the reader is referred to Section 6 forsome references. As a matter of fact, the hardening actionson private networks security posture are always welcome,though the ‘internal’ attack vector is not needed to dis-prove the false marketing slogans usually promoting VoIPsolutions.

The leit motiv concept unravelling through the wholepaper points to the method utilized to derive the conclu-sions: it has in fact been repeatedly highlighted that a gen-eral risk assessment methodology has been applied to thewire tapping threat; then, the risk analysis has revealedthat some general and objective assertions hold, for in-stance, the weakness of the non-encrypted conversationswhen travelling through a gateway owned by a possiblymalicious ISP.

The investigation has also shown – by means of a casestudy – that a risk assessment procedure, usually em-ployed to analyse concrete and specific situations, can befruitfully applied to derive useful conclusions also in amore general setting. Furthermore, since the derived con-clusions coincide with those derived in specific situationsby means of ad-hoc methods, it should be put in evidencethat the suggested approach can be fruitfully extended toother similar problems. This is all the more true, whenone considers that a supporting mathematical theory hasbeen utilized, thus providing the drawn conclusions withan objective value, since every expert conducting the sameanalysis will derive similar evaluations in a formal sense.

References

[1] S. Garfinkel, VoIP and Skype security, March 2005. URL <http://tacticaltech.org/skype_security>.

[2] A. Godber, P. Dasgupta, Secure wireless gateway, in: Proceedings ofthe Third ACM Workshop on Wireless Security, ACM Press, New York,NY, USA, 2002, pp. 41–46.

[3] E. Barrantes, D. Ackley, T. Palmer, D. Stefanovic, D.D. Zovi,Randomized instruction set emulation to disrupt binary codeinjection attacks, in: Proceedings of the 10th ACM Conference onComputer and Communications Security, ACM Press, New York, NY,USA, 2003, pp. 281–289.

[4] J. Myerson, Identifying enterprise network vulnerabilities,International Journal of Network Management 12 (3) (2002) 135–144.

[5] T. Walsh, D. Kuhn, Challenges in securing voice over IP, IEEE Securityand Privacy 3 (3) (2005) 44–49.

[6] D. Naccache, Finding faults, IEEE Security and Privacy 3 (5) (2005) 61–65.

[7] S. Landau, Security, wiretapping, and the internet, IEEE Security andPrivacy 3 (6) (2005) 26–33.

[8] K. Fiveash, VoIP – open season for hackers, November 2006. URL<http://www.theregister.co.uk/2006/11/29/voip_hack_calls>.

[9] Inchiesta Telecom, altri due arresti, Corriere della Sera, January2007. URL <http://www.corriere.it/Primo_Piano/Cronache/2007/01_Gennaio/31/arresti_telecom.shtml>.

[10] E. Galli Della Loggia, L’Idra italiana, Corriere della Sera, September2006. URL <http://www.corriere.it/Primo_Piano/Editoriali/2006/09_Settembre/27/dellaloggia.shtml>.

[11] M. Benini, S. Sicari, Risk assessment: intercepting VoIP calls, in:Proceedings of the VIPSI-2007 Venice Conference, International

Conferences on Advances in the Internet, Processing, Systems, andInterdisciplinary Research, Venice, Italy, 2007, pp. 1–10.

[12] D. Balzarotti, M. Monga, S. Sicari, Assessing the risk of usingvulnerable components, in: D. Gollmann, F. Massacci, A.Yautsiukhin (Eds.), Quality of Protection – Security Measurementsand Metrics, vol. 23 of Advances in Information Security, Springer,New York, NY, USA, 2006, pp. 65–78.

[13] S. Bakry, Development of security policies for private networks,International Journal of Network Management 13 (3) (2003) 203–210.

[14] D. Huang, Q. Cao, A. Sinha, M. Schniederjans, C. Beard, L. Harn, D.Medhi, New architecture for intra-domain network security issues,Communications of the ACM 49 (11) (2006) 64–72.

[15] M. Benini, S. Sicari, A mathematical framework for risk assessment,in: Proceedings of the First NTMS International Conference, 2007.

[16] M. Howard, D. Leblanc, Writing Secure Code, Microsoft Press, 2003.[17] B. Schneier, Attack trees, Dr. Dobb’s Journal 24 (12) (1999) 21–29.[18] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R.

Sparks, M. Handley, E. Schooler, RFC 3261: SIP: Session initiationprotocol, Junuary 2002. URL <http://www.ietf.org/rfc/rfc3261.txt>.

[19] J. Postel, RFC 791: Internet protocol, September 1981. URL <http://www.rfc-editor.org/rfc/rfc791.txt>.

[20] W. Hardy, VoIP Service Quality: Measuring and Evaluating Packet-Switched Voice, McGraw-Hill, 2003.

[21] P. Mehta, S. Udani, Overview of voice over IP, Technical report MS-CIS-01-31, Department of Computer and Information Science,University of Pennsylvania, February 2001.

[22] B. Goode, Voice over internet protocol (VoIP), Proceedings of the IEEE90 (9) (2002) 1495–1517.

[23] A. La Corte, S. Sicari, Assessed quality of service and voice and dataintegration: a case study, Computer Communications 29 (11) (2006)1992–2003.

[24] U. Varshney, A. Snow, M. McGivern, C. Horward, Voice over IP,Communications of the ACM 45 (1) (2002) 89–96.

[25] M. Decina, D. Vlack, Voice by the packet?, IEEE Journal on SelectedAreas in Communications SAC-1 6 (1983) 26–33

[26] D. Kuhn, T. Walsh, S. Fries, Security considerations of voice over IPSystems, National Institute of Standards and Technology (NIST),Gaithersburs, MD, USA, Computer Security Division, SpecialPublication 800-58, January 2005.

[27] The voice over IP security alliance. URL <http://www.voipsa.org/>.[28] M. Tanase, Voice over IP security, Security Focus (Mar. 2004). URL

<http://www.securityfocus.com/infocus/1767>.[29] R. Barbieri, D. Bruschi, E. Rosti, Voice over IPSec: Analysis and

solutions, in: Proceedings of the 18th Annual Computer SecurityApplications Conference, IEEE Computer Society, Washington, DC,USA, 2002, pp. 261–270.

[30] J. Halpern, IP Telephony Security in Depth, Cisco Systems Inc., Whitepaper, 2002.

[31] M. Marjalaakso, Security requirements and constraints of VoIP, Tech.Rep., Department of Electrical Engineering and Telecommunications,Helsinki University of Technology, 2000. URL <http://www.tml.tkk.fi/Opinnot/Tik-110.501/2000/papers/marjalaakso/voip.html>.

[32] J. Larson, T. Dawson, M. Evans, J. Straley, Defending VoIP networksfrom distributed DoS (DDoS) attacks, in: Proceedings of the Voiceover IP Workshop, IEEE Global Telecommunications Conference,2004.

[33] W. Rippon, Threat assessment of IP based voice systems., in:Proceedings of the 1st IEEE Workshop on VoIP Management andSecurity, Vancouver, Canada, 2006, pp. 19–28.

[34] P. Hochmuth, T. Greene, Firewall limits vex VoIP users, NetworkWorld, July 2002. URL <http://www.networkworld.com/news/2002/0708voip.html>.

[35] X. Wang, S. Chen, S. Jajodia, Tracking anonymous peer-to-peer VoIPcalls on the Internet, in: Proceedings of the 12th ACM Conference onComputer and Communications Security, ACM Press, New York, NY,USA, 2005, pp. 81–91.

[36] T. Peng, C. Leckie, K. Ramamohanarao, Survey of network-baseddefense mechanisms countering the DoS and DDoS problems, ACMComputing Surveys 39 (1) (2007) 1–42.

[37] R. Baskerville, Information system security design methods:implications for information systems development, ACMComputing Survey 25 (4) (1993) 375–412.

[38] C. Salter, O. Saydjari, B. Schneier, J. Wallner, Toward a secure systemengineering methodology, in: Proceedings of the 1998 Workshop onNew Security Paradigms, ACM Press, New York, NY, USA, 1998, pp.2–10.

[39] H. Abdelnur, V. Cridlig, R. State, O. Festor, VoIP security assessment:Method and tools, in: Proceedings of the 1st IEEE Workshop on VoIPManagement and Security, Vancouver, Canada, 2006, pp. 29–34.

[40] H.Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RFC 3550: RTP: Atransport protocol for real-time applications, July 2003. URL <http://www.ietf.org/rfc/rfc3550.txt>.

[41] I. Moskowitz, M. Kang, An insecurity flow model, in: Proceedings ofthe 1997 Workshop on New Security Paradigms, ACM Press, NewYork, NY, USA, 1997, pp. 61–74.