DENIAL OF SERVICE ISSUES IN VOICE OVER IP NETWORKS

Jason Reid, Andrew Clark, Juan M Gonz

alez Nieto, Jason Smith

Information Security Research Centre, Queensland University of Technology

GPO Box 2434, Brisbane Q 4001, Australia

Kapali Viswanathan

Society for Electronic Transactions and Security

21 Mangadu Swamy Street, Nungambakkam, Chennai - 600 034, India

Keywords:

Denial of service, voice over IP, H.323, security.

Abstract:

In this paper we investigate denial of service (DoS) vulnerabilities in Voice over IP (VoIP) systems, focusing

on the ITU-T H.323 family of protocols. We provide a simple characterisation of DoS attacks that allows us to

readily identify DoS issues in H.323 protocols. We also discuss network layer DoS vulnerabilities that affect

VoIP systems. A number of improvements and further research directions are proposed.

1 INTRODUCTION

The telephony service is an integral part of the oper-

ation of the vast majority of organisations. Provid-

ing and operating highly reliable systems is a signif-

icant engineering challenge requiring skilled design,

critical component redundancy and a highly available

maintenance capability. Ensuring the availability of

the telephony service when voice and data are shared

over IP networks and in the face of malicious adver-

saries makes this challenge all the more demanding.

The distinct nature of threats to availability pre-

sented by Denial of Service (DoS) attacks have been

known for some time (Needham, 1994). It is impor-

tant to note that the goal of a DoS attack is not to

gain unauthorised access to a machine or data, but

to prevent legitimate users accessing a service. DoS

prevention continues to be an active area of research,

especially in the context of Internet protocols (Aura,

2000; Schuba et al., 1997). There is, however, a clear

lack of DoS literature speciﬁc to IP telephony.

The main contribution of this paper is the identi-

ﬁcation and analysis of vulnerabilities in Voice over

IP (VoIP) systems that may result in denial of service

when maliciously exploited by individuals. We focus

our attention on the ITU-T H.323 family of protocols

for VoIP. Some familiarity with the standards is as-

sumed from the reader; in particular Recommenda-

tions H.323 (ITU-T, 2003c), H.225 (ITU-T, 2003a),

H.245 (ITU-T, 2003b) and H.235 (ITU-T, 2003d), as

well as IPv4 protocols.

Different classiﬁcations of DoS attacks can be

found in the literature (e.g. (Aura, 2000; Millen,

1992; Center, 1997; Leiwo et al., 2000)), however

they are not entirely suitable for our purpose of iden-

tifying DoS vulnerabilities in VoIP protocols. In Sec-

tion 2 we present a characterisation of host behaviours

that may indicate DoS vulnerabilities. This character-

isation leads to a simple classiﬁcation of DoS attacks.

In Section 3, we discuss denial of service threats to

H.323 VoIP systems that exploit IP or network layer

vulnerabilities. Sections 4 and 5 investigate vulner-

abilities that relate to speciﬁc H.323 protocol mes-

sages, with and without the optional security services

deﬁned in Recommendation H.235. For each of the

most commonly used messages we classify their DoS

behaviour according to the criteria described in Sec-

tion 2. We discuss the effectiveness of the crypto-

graphic authentication mechanisms deﬁned in H.235

in mitigating DoS threats. In Section 6, we suggest

research directions that may improve H.235 authenti-

cation mechanisms. Throughout the paper we provide

various recommendations to assist in alleviating the

identiﬁed DoS issues. To the best of our knowledge,

this paper presents the ﬁrst comprehensive study of

DoS vulnerabilities in H.323 based VoIP systems.

2 CLASSIFICATION OF DoS

ATTACKS

A general way of distinguishing between different

types of DoS attacks is to separate them into ﬂooding

and non-ﬂooding (or logical) attacks. A logical attack

results in a denial of service through exploiting a vul-

nerability in the logic or syntax of processing. A pro-

cess is forced or induced to perform an action that is

inconsistent with the correct operation of the system.

230

Reid J., Clark A., M González Nieto J., Smith J. and Viswanathan K. (2004).

DENIAL OF SERVICE ISSUES IN VOICE OVER IP NETWORKS.

In Proceedings of the First International Conference on E-Business and Telecommunication Networks, pages 230-237

DOI: 10.5220/0001403302300237

 SciTePress

To illustrate, consider a logical attack example from

the H.323 domain; an attacker sends forged H.225

RAS unregistration request messages (URQ) for tar-

geted endpoints to the Gatekeeper. Once they are un-

registered, the endpoints cannot make or receive calls.

If the protocol design allows the gatekeeper to act on

unauthenticated unregistration requests, a logical at-

tack vulnerability exists since an attacker can easily

forge them.

Cryptography provides useful authentication and

integrity techniques to avoid logical attacks. It is

theoretically possible to eliminate denial of service

vulnerabilities based on logical attacks through ap-

propriate protocol design and careful implementation.

However a design that is immune from logical attacks

may be more susceptible to ﬂooding attacks. The

inter-relationship exists because the protections that

ensure that a process will not act on a forged or altered

message require the process to perform calculations

to assess message integrity. The calculations require

additional time and effort. By sending the process bo-

gus messages, the attacker consumes ﬁnite processing

resources of the target with a minimal commitment of

its own.

There is an asymmetry between the minimal ef-

fort required of the attacker to commit the receiving

process to a much greater amount of work. If the at-

tacker can access sufﬁcient bandwidth to send a large

number of unauthentic messages, the process’s ca-

pacity to authenticate them can be overwhelmed to

the point where legitimate requests cannot be handled

in a timely fashion. Denial of service results. Once

again, using the example of a H.323 gatekeeper, the

attacker could send a constant, high volume stream

of forged H.225 RAS admission request (ARQ) mes-

sages. These forged messages include bogus integrity

protection data. They will fail the integrity check and

be discarded. Nonetheless, legitimate requests for ad-

mission will be swamped in the ﬂood of forged re-

quests.

To avoid this problem the process must be able to

authenticate messages at the highest possible rate that

they could arrive, i.e. the message processing capac-

ity must be matched to the message carrying capacity

(bandwidth) of the connection. With the growth in

network bandwidth currently outstripping the growth

in processing power, this is an increasingly difﬁcult

balancing act. It also results in the over-engineering

of processing capacity, a potentially inefﬁcient allo-

cation of resources, since the message handling capa-

bility may far exceed the requirements of legitimate

trafﬁc.

The overhead of cryptographic message integrity

protection only exacerbates the imbalance. There is

no simple solution to this issue. Logical attacks that

exploit unauthenticated messages are powerful and

highly effective. Flooding attacks that consume all

processing and storage resources are powerful and

highly effective. There are however some promising

general approaches to address this apparent conﬂict,

which we discuss in Section 6.

We can further classify DoS attacks based on the

behaviour of hosts in response to incoming proto-

col messages (requests) that makes attacks feasible.

Our approach, contrary to others (Aura, 2000; Millen,

1992; Center, 1997; Leiwo et al., 2000), is thus host

centric, avoids modelling the unpredictable nature of

attackers, and allows us to readily identify potential

DoS vulnerabilities in protocols. The attacks with an

intent to ﬂood will be classiﬁed under Class F and that

of non-ﬂooding attacks under Class NF.

2.1 Flooding Attacks

The behaviour leading to ﬂooding attacks can be clas-

siﬁed based on the amount of computation required

for the response computation. The classiﬁcation is as

follows:

• F.C1: the host performs response computations for

unauthenticated requests;

• F.C2: the host performs response computations for

authenticated requests;

• F.S1: the host accepts large request sizes;

• F.S2: the host sends large response sizes;

Every behaviour of the host that is of type F.C1

could be a potential denial of service vulnerability.

Therefore, the response computation with behaviour

type F.C1 must be as small as possible to prevent

ﬂooding attacks. Also, the number of procedures

in the system that have behaviour type F.C1 must

be minimal. These observations are crucial because

the attacker will essentially remain unidentiﬁed and

therefore cannot be blacklisted. In other words, it is

impossible to control access to network services that

possess behaviour type F.C1.

It can be seen that every host that provides some

form of network service will provide at least one ser-

vice with behaviour type F.C1. Consider the pro-

cess that authenticates the requests. The requests to

the authentication process are essentially unauthenti-

cated. Only the responses of the authentication pro-

cess may be authenticated. Therefore the authenticat-

ing behaviour is of type F.C1. Clearly the authenti-

cation procedure that authenticates the requests must

perform small response computations.

Procedures with behaviour type F.C2 will also be

susceptible to ﬂooding attacks. But, due to the as-

sumption that such procedures respond only to au-

thenticated requests, it may be possible to protect the

host from its protocol peer. Note that the behaviour

type of the procedure for authenticating requests is

DENIAL OF SERVICE ISSUES IN VOICE OVER IP NETWORKS

231

F.C1. So, care must be taken to design a request au-

thenticating procedure that performs small response

computations.

Procedures with behaviour type (F.S1, F.C1) must

be avoided because large request sizes require more

computation than small request sizes. Procedures

with behaviour type (F.S2, F.C1) must also be avoided

because such procedures can be used as ampliﬁers to

attack other hosts on the network.

2.2 Non-Flooding Attacks

The behaviour leading to non-ﬂooding attacks can be

classiﬁed based on the decision making behaviour of

the host’s response computation. Attackers employ

non-ﬂooding attacks to force the victim host to make

incorrect decisions. The following are the classiﬁca-

tion of behaviour that may lead to non-ﬂooding at-

tacks:

• NF.UA: the response computation of the host

makes crucial decisions when an unauthenticated

request arrives;

• NF.A: the response computation of the host makes

crucial decisions only on the arrival of authenti-

cated requests;

Behaviour NF.UA poses the biggest risk of denial

of service attacks. To mitigate the threat of DoS due

to NF.UA behaviour authentication mechanisms can

be applied. Even then, denial of service may occur

when the authenticated peer misbehaves. Examples

of behaviour type NF.UA include the H.225.0 RAS

Unregistration (URQ) request and the H.225.0 Q.931

Release Complete message.

3 NETWORK LEVEL

VUNERABILITIES FOR H.323

ENTITIES

In this section we discuss denial of service threats to

H.323 VoIP systems that exploit network layer vul-

nerabilities. The focus is on the impact of IP denial of

service attacks on H.323 system availability. Table 1

present a partial list of known DoS vulnerabilities in

IPv4. We do not exhaustively review the details of

each attack.

Each component of an H.323 VoIP system (termi-

nals, multipoint controller units, gateways and gate-

keepers) uses TCP and UDP protocols with both ﬁxed

and dynamically assigned port numbers. Since an

H.323 VoIP system employs the full suite of IP pro-

tocols, it inherits the complete set of IP vulnerabili-

ties. The more important vulnerabilities are now sum-

marised.

Table 1: DoS vulnerability classiﬁcation of IPv4.

Protocol Message Classiﬁcation

IP Fragment Datagram F.C1

ICMP Destination Unreachable F.C1

Time Exceeded NF.UA

Source Quench NF.UA

Redirect F.C1, NF.UA

Echo F.C1

TCP SYN F.C1

RST / FIN NF.UA

RIP Responses NF.UA

CDP Neighbor announcements F.C1

DNS Name server queries F.C1, F.S1

Name server responses NF.UA

• ICMP Source Quench: can be used to degrade

the quality of a media channel by effectively reduc-

ing its bandwidth. The attacker masquerades as a

router and sends ICMP source quench messages to

an upstream router on the media stream path to re-

duce the packet ﬂow rate coming from the targeted

router.

• ICMP Redirect: messages can be sent by an at-

tacker to dynamically alter routing tables in hosts.

Since the source is not authenticated, redirect mes-

sages can be used in a ﬂooding attack if the update

process is computationally resource intensive, as is

the case on a number of Windows platforms.

• TCP SYN Flood: the SYN ﬂood (Bernstein, 1996)

is a powerful attack that can be directed at a num-

ber of listening ports on H.323 devices. It is imple-

mented in the majority of denial of service attack

tools. The attack exploits the fact that the TCP pro-

tocol allocates memory to store protocol state on

the basis of unauthenticated requests.

• TCP RST and FIN: because the source of TCP

packets is not authenticated, an attacker can send

RST and FIN packets to terminate TCP connec-

tions (Harris and Hunt, 1999). H.225.0 call con-

trol and H.245 media control channels could be tar-

geted. Knowledge of TCP sequence numbers is re-

quired. An attacker can monitor a TCP connection

to access the sequence number via: an ARP poison-

ing attack in the case of switched Ethernet; through

an interface device running in promiscuous mode

in the case of broadcast Ethernet; or through com-

promising an intermediate router.

It is difﬁcult to say whether in general terms, appli-

cation or network layer denial of service vulnerabili-

ties pose a greater threat. While a general ranking is

not possible due to individual variations in the local

ICETE 2004 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS

232

threat environment, it is clear that IP-based denial of

service attacks present a high level of risk in an H.323

context for a number of reasons:

• the proliferation and broad availability of sophisti-

cated, user friendly IP DoS attack tools;

• as the attacks target the network layer, attackers

do not need to investigate the details of the H.323

family of protocols. Consequently, the time cost in

preparing an attack is low and very little specialised

H.323 knowledge is required;

• the extensive use of dynamically negotiated, high-

numbered protocol ports makes it difﬁcult to apply

best-practice, restrictive ﬁrewall rule sets. H.323

components are therefore, more difﬁcult to protect;

• registered H.323 ports present an attractive packet

ﬂooding attack target as their values are ﬁxed and

published;

• the critical functions performed by the Gatekeeper

make it an attractive ﬂooding attack target. The op-

eration of an entire zone can be affected by attacks

that target the gatekeeper, e.g. attacks directed at

the Gatekeeper uni-cast RAS port can block end-

point registration requests and call admission re-

quests

;

• the Gatekeeper is difﬁcult to protect because its

functions typically require communication with de-

vices on remote (potentially) untrusted networks;

Many network layer vulnerabilities are addressed

in the latest version of the Internet Protocol, IPv6.

3.1 Source Address Spooﬁng

A number of network layer attacks employ source ad-

dress spooﬁng, either to enhance the effectiveness of

the attack, or as a required element. For example,

SYN, UDP and ICMP ﬂoods are more difﬁcult to re-

spond to and are therefore more effective when source

spooﬁng is used, as the typical reaction technique

of blocking based on source address will not work.

An attack that uses forged ICMP source quench mes-

sages to reduce the throughput of time-critical media

streams requires source address spooﬁng. The smurf

attack

also requires the ability to spoof source ad-

dresses.

Experience has shown that source address spoof-

ing is a signiﬁcant problem on the public Internet. It

also presents a threat in the context of attacks conﬁned

to private IP networks. However, in private networks

If a gatekeeper cannot receive call admission requests,

endpoints cannot receive or initiate calls.

In the smurf attack, a request is sent to a broadcast ad-

dress with the forged source address of the attack target. All

hosts in the broadcast domain respond to the forged source

address, generating a ﬂood of trafﬁc directed at the target.

different mitigation strategies are possible. One such

strategy involves segmenting a private network into a

number of IP subnets that are connected by layer 3

devices implementing egress ﬁltering. This strategy

ﬁlters out packets where the network portion of the

source address is spoofed. Preventing forgery of the

host portion of a source IP address is a considerably

more difﬁcult problem to solve.

In any case, the elimination of source address

forgery only prevents a subset of attacks. Network

and application layer ﬂooding attacks are still pos-

sible, though identiﬁcation of the offender is trivial.

Being able to identify the source of a trafﬁc ﬂood is

only useful if this allows some form of response. For

example, router or ﬁrewall rules can be dynamically

updated to ﬁlter packets from that source. To be ef-

fective, swift detection and reaction are required. If

there is no dynamically reconﬁgurable ﬁlter between

the target and the source of the trafﬁc ﬂood, as is the

case when attacker and attacked are in the same trans-

port network domain, it appears that the target must

defend itself.

3.2 Self Defense

If VoIP services are to be provided reliably, H.323

entities must be capable of identifying and reacting

to denial of service attacks in a timely manner. The

typical response strategy involves ﬁltering the ﬂood

trafﬁc. Filtering trafﬁc at the physical layer offers ef-

ﬁciency advantages over network or application level

ﬁlters as the malicious packets can be dropped before

any higher layer processing resources are consumed.

Using a MAC address black-list, the physical layer

can drop malicious packets as quickly as they arrive.

More research is needed to investigate how in-

trusion detection concepts (DoS identiﬁcation) could

be integrated with physical layer ﬁltering (DoS re-

sponse). We brieﬂy describe this approach in the

context of a UDP ﬂood. Assume that a number of

hosts are directing a UDP ﬂood attack at listening

UDP ports on a Gatekeeper that resides on the same

segment. An IDS application detects the ﬂood traf-

ﬁc, noting the source IP addresses. Using a trans-

port layer API, the IDS places a blocking request

for those IP addresses. The transport layer resolves

the IP to MAC address mapping and includes the

relevant MAC addresses in a black-list. The gate-

keeper’s transport layer stops passing IP packets ar-

riving in Ethernet frames with with the black-listed

source MAC address up to the network layer. The

performance of network and application layers is no

longer affected by the ﬂood.

It is clearly important that MAC addresses cannot

be spoofed

. Were this not the case, the defence

To address this problem, some Ethernet switches al-

DENIAL OF SERVICE ISSUES IN VOICE OVER IP NETWORKS

233

mechanism itself could be used to launch a denial of

service attack by forging the MAC address of the real

target, thereby having it black-listed. Certain MAC

addresses should not be blockable, including those of

router interfaces, otherwise all trafﬁc coming from the

router will be blocked. Where the ﬂood trafﬁc is com-

ing from a router interface, the targeted host needs a

way of notifying that router that it would like traf-

ﬁc with a nominated source IP address and the host’s

destination IP address, blocked. If the source MAC of

the malicious trafﬁc is blockable, the router adds the

address to its blacklist, otherwise it sends a similar

request to another router, the source of the trafﬁc.

This approach appears to offer some promising fea-

tures, facilitating adaptive defense in the context of

private IP networks.

4 APPLICATION LEVEL

VULNERABILITIES IN H.323

WITHOUT H.235

We will ﬁrst consider the scenario where the H.323

protocol stacks do not implement the H.235 standard.

To be more precise, we ﬁrst consider the protocol

stacks that do not possess any form of request authen-

tication during the signalling phase. Subsequently,

the protocol stacks that implement the H.235 stan-

dard are investigated. It should be noted that some

of the attacks described here may be dependent upon

the implementor’s interpretation of the H.323-related

standards.

4.1 H.225.0 RAS Messages

Recommendation H.225.0 speciﬁes the Registration,

Admission and Status (RAS) signalling protocol.

RAS messages are transmitted between gatekeepers

and end-points over an unreliable protocol such as

UDP. RAS allows a gatekeeper to manage endpoints

within its zone. Table 2 summarises DoS vulnerabili-

ties found in RAS messages. RAS protocol messages

are stateless in the sense that an entity could receive

any RAS message at any time. H.323 entities must

maintain an internal state in relation to requests and

responses (conﬁrm or reject). This behaviour leads

to almost all RAS messages being suitable candidates

for ﬂooding type attacks.

When the response computation performed by the

host (terminal or the gatekeeper) is large, then the par-

ticular response computation (and thereby the gate-

keeper) can be overloaded by ﬂooding the host with

low each port to be associated with a ﬁxed MAC address.

Changing the MAC address to port binding requires admin-

istrative access to the switch.

Table 2: DoS classiﬁcation of RAS messages.

RAS Message Classiﬁcation

Gatekeeper discovery GRQ F.C1

Registration RRQ F.C1

Unregistration URQ F.C1, NF.UA

Admission ARQ F.C1

Bandwidth change BRQ F.C1, NF.UA

Location LRQ F.C1

Disengage DRQ F.C1

Status IRQ F.C1, F.S1, F.S2

IRR F.C1, F.S2

many request messages. Since messages are unau-

thenticated, it may be difﬁcult to black-list the at-

tacker, who is unidentiﬁed.

The messages IRQ and IRR could potentially be

susceptible to DoS if the behaviour of the gatekeeper

or the terminal falls under classiﬁcation F.S2. If a

large response is generated by a response computa-

tion with behaviour F.C1, then these messages can be

used to ﬂood other terminals in the network. That is,

the gatekeeper or the terminal with behaviour (F.C1,

F.S2) can be used as ampliﬁers to attack other hosts

in the network.

The messages URQ and BRQ could also pose a

denial of service risk of type NF.UA if they could

be spoofed. For example, an attacker can manufac-

ture an unregistration request with knowledge of the

targeted terminal’s IP address and RAS port num-

ber. If the gatekeeper acts on the request, the terminal

will be unable to make or receive calls until it is re-

registered.Similarly, if bandwidth request messages

can be fabricated, it may be possible to cause a denial

of service by an attacker causing the gatekeeper to al-

locate all of the available bandwidth to non-existent

calls. This type of attack could also be used to send a

fabricated reject message to an endpoint in response

to a valid request message, causing the endpoint to in-

correctly believe that a requested service is not avail-

able.

4.2 H.225.0 (Q.93x) Messages

The call signalling channel (H.225.0/Q.931/Q.932)

messages are transmitted between endpoints and/or

between endpoints and gatekeepers (depending on the

routing model). They allow the establishment and

tear-down of connections between endpoints. A re-

liable protocol such as TCP is used for the transport

of H.225.0 call signalling messages. A number of the

messages are susceptible to various DoS activity, as

summarised in Table 3.

H.323 entities must always be prepared to receive

ICETE 2004 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS

234

Table 3: DoS classiﬁcation of H.225.0 (Q.93x).

H.225.0 (Q.93x) Message Classiﬁcation

Setup F.C1, F.S2

Facility NF.UA

ReleaseComplete NF.UA

CallProceeding NF.UA

Alerting NF.UA

Connect F.S2, NF.UA

an incoming Setup message (if they want to re-

ceive incoming calls!). Thus, there is the potential for

ﬂooding an entity on the port on which it listens for

connections. Since an entity receiving a setup mes-

sage performs a relatively large amount of processing

and responds with several messages, there is also the

potential for attacks of type F.S2.

As with the RAS messages, there is also the poten-

tial for spoofed messages to wreak havoc with entities

communicating over the call signalling channel (vul-

nerabilities of classiﬁcation NF.UA). For example,

ReleaseComplete could be abused to prematurely

terminate a call. A fabricated Connect message,

sent prior to being expected, could cause the calling

endpoint to initiate call control messages to which the

receiver would not be prepared to respond. A sim-

ilar approach might be successful for Facility ,

CallProceeding and Alerting messages.

4.3 H.245 Messages

Recommendation H.245 speciﬁes a control protocol

for managing multimedia bearer streams. An H.245

channel must be carried over reliable transport, either

on an individual TCP connection or tunnelled through

an H.225.0 call control channel. H.245 speciﬁes four

classes of messages:

1. Request: entities send request messages for spe-

ciﬁc actions. Every request message requires an

immediate response message;

2. Response: entities receiving a request message are

required to return the corresponding response mes-

sage;

3. Command: commands initiate a mandatory action

but require no response;

4. Indication: entities send an indication message

when no speciﬁc action or response message is re-

quired.

Command messages are of the greatest interest in

terms of their capacity for misuse resulting in de-

nial of service. H.245 commands force the receiv-

ing terminal to perform an action related to the con-

trol of media streams. Where no integrity protection

or source authentication services are provided, the

H.245 commands have the potential for serious de-

nial of service consequences as command messages

can be forged or modiﬁed and the receiving terminal

must perform the required action. The scope of ser-

vice denial is limited to the disruption of calls that are

in in the process of being established or currently in

progress.

Table 4: DoS characteristics of H.245 commands.

H.245 Command Messages Classiﬁcation

SendTerminalCapabilitySet F.S2

FlowControlCommand NF.UA, F.S2

EndSessionCommand NF.UA

MiscellaneousCommand NF.UA

ConferenceCommand NF.UA

H223Multiplex

Reconfiguration NF.UA

NewATMVCommand NF.UA

MobileMultilink

ReconfigurationCommand NF.UA

Table 4 lists the H.245 commands that have poten-

tial denial of service consequences when H.235 in-

tegrity protection is not implemented. NF.UA indi-

cates a non-ﬂooding attack based on an unauthenti-

cated message. The following commands are of par-

ticular note:

• SendTerminalCapability: when sent as a

genericRequest this command requires the re-

ceiving terminal to send its entire terminal capabil-

ity set. Since the response is potentially large, this

command may be used as an ampliﬁer.

• FlowControlCommand: issued by one termi-

nal to instruct another terminal to restrict the bit-

rate for a logical channel to the speciﬁed value, i.e.

“don’t send data any faster than x”. The receiving

terminal must comply. If the speciﬁed value is not

compatible with the codec being used, the terminal

must stop sending data on that logical channel so

denial of service results when a ﬂow control limit

is set at a smaller value than the lowest bit-rate the

codec supports.

• EndSessionCommand: instructs the other ter-

minal to immediately cease sending H.245 mes-

sages. Denial of service results as the call is effec-

tively terminated without an H.245 control channel.

• MiscellaneousCommand: the encryptionUp-

date ﬁeld of this command can be used to specify a

new encryption key for the nominated logical chan-

nel. An attacker could forge a message instruct-

ing an encryption update, forcing one terminal to

DENIAL OF SERVICE ISSUES IN VOICE OVER IP NETWORKS

235

switch to a new key without the other’s knowledge.

The receiver will not be able to decrypt the stream

correctly resulting in a denial of service.

5 APPLICATION LEVEL

VULNERABILITIES IN H.323

WITH H.235

Recommendation H.235 speciﬁes authentication and

integrity security mechanisms for H.225.0 RAS and

call signalling and H.245 call control messages. Ad-

ditionally for media channels, it deﬁnes a conﬁden-

tiality mechanism based on symmetric encryption.

H.235 provides both network level and application-

speciﬁc security mechanisms. At the network level,

the speciﬁcation states that H.323 signalling may be

secured by IPSec or the Transport Level Security

(TLS) protocol. At the application level, it deﬁnes

speciﬁc authentication and integrity mechanism to be

used within H.225.0 and H.245 protocol messages.

Application level mechanisms come in two ﬂavours:

shared-secret based and public-key based. The au-

thentication and integrity mechanism based on shared

secrets employs a keyed message authentication code

such as HMAC-SHA1. The public-key mechanism

uses RSA-based digital signatures and certiﬁcates to

authenticate the source and integrity of protocol mes-

sages. Both methods include the choice of nonces

(time-stamps and sequence numbers) or random chal-

lenges to thwart replay attacks.

The most signiﬁcant improvement obtained

through the use of the H.235 cryptographic primitives

is the reduction in the threat of vulnerabilities of the

classiﬁcations F.C1 and NF.UA. These classiﬁcations

involve the receiving host performing response

computations on unauthenticated requests. So, by

introducing authentication (as the H.235 speciﬁca-

tions do), ﬂooding attacks and non-ﬂooding attacks

involving unauthenticated messages can be thwarted.

However, the authentication mechanism itself may

lead to ﬂooding attacks of type F.C2 if it cannot

perform the authentication computations quickly

enough.

H.235 recommends the use of TLS for securing the

call control channel. It should be noted that the TLS

handshake has a behaviour of type F.C1 regardless

of whether TLS mutual authentication is performed.

This has the potential to present a critical ﬂooding at-

tack target if the recipient cannot process the hand-

shake requests at a sufﬁciently high rate. Since TLS is

a computationally expensive protocol, an attacker can

commit the Gatekeeper to signiﬁcant processing on

the basis of an unauthenticated request, a highly risk-

prone design. The same analysis applies when the

public-key based authentication mechanism speciﬁed

by H.235 is used at the application level. Again, there

is a signiﬁcant risk of ﬂooding attacks as an unau-

thenticated attacker can commit a target to the expen-

diture of signature veriﬁcation.A delicate balance be-

tween robust authentication and speed of computation

must be achieved. The ease with which authentication

ﬁelds can be generated and validated will also have an

impact on the system’s susceptibility to vulnerabili-

ties of type F.S1 and F.S2.

The provision of integrity and/or conﬁdentiality

services on the communication channels prevents at-

tacks which involve monitoring and or data insertion.

These will typically be non-ﬂooding attacks which

exploit vulnerable behaviour at the application level

(for example, implementation ﬂaws). The H.235 se-

curity services do not prevent an authenticated user

from exploiting vulnerabilities due to protocol design

ﬂaws or implementation ﬂaws. Of course, the attacker

could be identiﬁed trivially in this instance.

6 IMPROVING H.235

AUTHENTICATION

There are promising avenues for improving the DoS

characteristics of H.235 authentication mechanisms.

As has already been indicated, the efﬁciency of the

algorithm is a major factor when resistance to de-

nial of service is desired. A trade-off exists between

the certainty of the authentication, and the resistance

to DoS activity. If strong authentication, with non-

repudiation, is required then public key algorithms

may need to be considered. Similarly, when the man-

agement of share secrets such as passwords is infeasi-

ble, public-key based schemes may be needed. How-

ever, in some cases a layering of weaker but faster au-

thentication mechanisms, followed by stronger ones,

may be appropriate (Meadows, 1999).

The essential difference between the authentication

methods mentioned above is the cryptographic prim-

itives which they employ to achieve authentication.

In general a hash function can be considered to be

faster, and more compact than a symmetric encryp-

tion algorithm, which can, in turn, be considered to

be more efﬁcient and more compact than a digital sig-

nature algorithm. Within each type of algorithm, the

concrete choice of algorithm and length of the cryp-

tographic keys results in different speeds of the prim-

itives. For example, the hash algorithm suggested in

the H.235 standard, HMAC-SHA1 is likely to be suit-

able in most instances. However, faster (and proba-

bly less secure) hash functions, such as MD5, may

be appropriate in instances where anticipated trafﬁc

loads dictate such a requirement. The lowest level

of authentication would be a simple reachability test,

whereby the veriﬁer checks the aliveness of the prover

ICETE 2004 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS

236

by sending the prover a challenge which the prover is

expected to return back. Cookies (Aura and Nikander,

1997) could be used here to dispense the veriﬁer from

maintaining state.

In all the authentication mechanisms deﬁned in

H.235 there is an asymmetry between the minimal ef-

fort required of the attacker to commit the receiving

process to a greater amount of work. One general ap-

proach to address this asymmetry lies in increasing

the resources that the attacker must commit before

the receiving process commits processing or storage

resources of its own (Aura et al., 2000).

7 SUMMARY

In this paper we have identiﬁed the types of host be-

haviour that may indicate a susceptibility to various

denial of service attacks. The broad categories of

ﬂooding and non-ﬂooding attacks allow us to classify

the behaviours which lead to these types of attack. In

each case, attacks are most likely when the host re-

ceiving a message performs actions without authenti-

cating it. However authentication mechanisms must

be carefully designed so as not introduce new vulner-

abilities themselves.

Network level vulnerabilities present a range of se-

rious threats to VoIP system availability. Flooding

attacks are particularly potent due to the source ad-

dress spooﬁng vulnerability in IPv4. Source spooﬁng

in private networks can be addressed in a number of

ways including careful IP network design combined

with ﬁltering, and providing trusted MAC address to

IP address binding. Where this binding is present,

ﬂooding attacks may be ﬁltered at the transport layer,

potentially the most efﬁcient point to perform ﬁlter-

ing. Transport layer ﬁltering combined with intrusion

detection is proposed as an area of future research.

This approach allows H.323 entities to be self defend-

ing against both network and application layer ﬂood-

ing attacks.

Importantly, this paper has also identiﬁed vulnera-

bilities in application level protocol messages that are

exchanged between H.323 entities. We have investi-

gated the problems associated with the weak or non-

existent authentication mechanisms present in unse-

cured H.323 implementations. We have also de-

scribed how the security mechanisms speciﬁed in the

H.235 standard (optionally implemented by H.323

entities) assist in preventing DoS activities which rely

on weak or non-existent authentication. These au-

thentication mechanisms speciﬁed in H.235, however,

introduce new vulnerabilities. We have discussed

such vulnerabilities as well as promising research di-

rections that may help in mitigating them.

REFERENCES

Aura, T. (2000). Authorization and Availability: Aspects of

Open Network Security. PhD thesis, Helsinki Univer-

sity of Technology.

Aura, T. and Nikander, P. (1997). Stateless connec-

tions. In Proc. International Conference on Informa-

tion and Communications Security (ICICS’97), LNCS

1334:87–97. Springer.

Aura, T., Nikander, P., and Leiwo, J. (2000). DOS-resistant

authentication with client puzzles. In Proc. Secu-

rity Protocols Workshop 2000, LNCS 2133:170–181.

Springer.

Bernstein, D. (1996). Syn cookies.

http://cr.yp.to/syncookies.html. Last access date:

10 June, 2004.

Center, C. C. (1997). Denial of Service Attacks.

http://www.cert.org/tech

tips/denial of service.html.

Last accessed: 10 June 2004.

Harris, B. and Hunt, R. (1999). TCP/IP security threats and

attack methods. Computer Communications, 22:885–

897. Elsevier Science.

Hussain, A., Heidemann, J., and Papadopoulos, C. (2003).

A framework for classifying denial of service attacks.

In Applications, technologies, architectures, and pro-

tocols for computer communications, pages 99–110.

ACM Press.

ITU-T (2003a). Call signalling protocols and media stream

packetization for packet-based multimedia communi-

cation systems. Recommendation H.225.0, ITU.

ITU-T (2003b). Control protocol for multimedia communi-

cation. Recommendation H.245, ITU.

ITU-T (2003c). Packet-based multimedia communications

systems. Recommendation H.323, ITU.

ITU-T (2003d). Security and encryption for H-series

(H.323 and other H.245-based) multimedia terminals.

Recommendation H.235, ITU.

Leiwo, J., Nikander, P., and Aura, T. (2000). Towards net-

work denial of service resistant protocols. In Inter-

national Information Security Conference (IFIP/SEC

2000).

Meadows, C. (1999). A formal framework and evaluation

method for network denial of service. In PCSFW:

Proceedings of The 12th Computer Security Founda-

tions Workshop. IEEE Computer Society Press.

Millen, J. K. (1992). A resource allocation model for denial

of service. In Proceedings of the IEEE Symposium on

Security and Privacy, pages 137–147.

Needham, R. M. (1994). Denial of service: an example.

Communications of the ACM, 37(11):42–46.

Schuba, C. L., Krsul, I. V., Kuhn, M. G., Spafford, E. H.,

Sundaram, A., and Zamboni, D. (1997). Analysis of a

denial of service attack on TCP. In Proceedings IEEE

Symposium on Security and Privacy, pages 208–223.

IEEE Computer Society Press.

DENIAL OF SERVICE ISSUES IN VOICE OVER IP NETWORKS

237