A whitelist-based countermeasure scheme using a Bloom filter against SIP flooding attacks

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

Available online at www.sciencedirect.com

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

A whitelist-based countermeasure scheme using a Bloom filter against SIP flooding attacks Byeong-hee Roh a,*, Ju Wan Kim b, Ki-Yeol Ryu b, Jea-Tek Ryu c a

Dept. of Software Convergence Technology, Ajou University, San 5 Wonchon-dong Youngtong-gu, Suwon, Gyeonggi-Do 443-749, South Korea b Dept. of Computer Engineering, Graduate School, Ajou University, Suwon 443-749, South Korea c IP Service Team, Korea Institute of Patent Information, Seoul 146-8, South Korea

article info

abstract

Article history:

Since SIP uses a text-based message format and is open to the public Internet, it is exposed

Received 22 August 2011

to a number of potential threats of denial of service (DoS) by flooding attacks. Although

Received in revised form

several approaches have been proposed to detect and counteract SIP flooding attacks, most

19 March 2013

of these do not provide effective countervailing schemes to protect normal messages from

Accepted 8 April 2013

abnormal ones after attacks have been detected. In addition, these approaches have some limitations in large user environments for SIP-based multimedia services. In this paper, a

Keywords:

whitelist-based countermeasure scheme is proposed, to protect both normal SIP users and

SIP (Session Initiation Protocol)

servers from malicious flooding attacks. To construct the whitelist, a Bloom filter approach

Flooding attack

is used, to reduce memory requirements and computational complexity. We use the non-

Bloom filter

membership ratio as a measure for the attack detection, instead of using the message rate

Whitelist

usually used in conventional schemes. It is shown that the proposed method can provide

Countermeasure

more robust detection performances. ª 2013 Elsevier Ltd. All rights reserved.

1.

Introduction

The Session Initiation Protocol (SIP) (Rosenberg et al., 2002) has been widely adopted as the main signaling and session management protocol for most recent multimedia applications and systems, such as VoIP, IP Multimedia Subsystem (IMS), and others. Because SIP is a text-based message format and is open to the public Internet, it is exposed to a number of potential threats of denial of service (DoS) by flooding attacks. In SIP flooding attacks, attackers generate massive numbers of malicious SIP request messages to a target SIP server, to force the server to disconnect.

To deal with DoS attacks on SIP services, encryption-based approaches have been proposed (Bremler-Barr et al., 2006; Geneiatakis and Lambrinoudakis, 2007; Wang and Zhang, 2008). Because of the computational overhead required for encryption and decryption of individual messages at servers, these approaches may be ineffective in flooding-attack environments in which massive numbers of SIP messages are arriving at the server. Various threshold-based detection methods have been proposed to detect SIP flooding attacks, such as cumulative sums (CUSUM) (Rebahi et al., 2008), Hellinger distance (HD) (Sengar et al., 2008), adaptive threshold (Siris and Papagalou, 2006; Akbar et al., 2008), upper bound of the possible number of SIP messages (Ryu et al., 2009), and

* Corresponding author. Tel.: þ82 31 219 1601; fax: þ82 31 219 1607. E-mail addresses: [email protected] (B.-h. Roh), [email protected] (J.W. Kim), [email protected] (K.-Y. Ryu), ryujeatek@hotmail. com (J.-T. Ryu). 0167-4048/$ e see front matter ª 2013 Elsevier Ltd. All rights reserved. http://dx.doi.org/10.1016/j.cose.2013.04.001

47

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

thresholds using Bloom filters (Geneiatakis et al., 2009; Ryu et al., 2011). However, these methods have focused only on the detection of flooding attacks, without providing effective countermeasure schemes to protect normal messages from abnormal ones after attacks have been detected. To counteract SIP flooding attacks, filtering-based schemes have been proposed. In Huici et al. (2009), a blacklist of malicious SIP traffic sources is created by using an intrusion detection system (IDS), then the attack traffic from the sources listed in the blacklist is filtered. However, the method has a limitation, in that all network controllers must have both IDS and filtering mechanisms. Whitelist-based filtering schemes (Zhou et al., 2009; Chen and Itoh, 2010) have also been proposed. When flooding attacks are detected, only SIP messages sent from sources on the whitelist are accepted, while others are denied. They also have some limitations when used in environments with large numbers of VoIP users, because of the heavy storage requirements for huge whitelists, and the corresponding computational complexity of searching such a large list. In this paper, we propose a whitelist-based detection and countermeasure scheme to protect normal SIP users and servers from malicious flooding attacks. The main contribution of the paper is two-fold: First, the proposed method detects SIP flooding attacks by using a Bloom filter as the whitelist, which reduces both memory requirements and computational complexity. To maintain SIP session information for the Bloom filter, the proposed method uses three parameters: the source IP address, and the caller and callee’s URIs. Second, the proposed method makes SIP servers provide sustainable services to normal users, even while flooding attacks are going on. The rest of the paper is organized as follows: Section 2 briefly describes SIP and Bloom filter theory. Section 3 presents the proposed scheme, and Section 4 gives the experimental results. Section 5 reviews more related works. Finally, Section 6 concludes the paper.

2.

Background

2.1.

SIP overview

SIP (Rosenberg et al., 2002) is an application layer protocol which enables multimedia sessions or calls to be set up, maintained, modified, or terminated. As with HTTP, SIP entities exchange text-based messages as request-and-response pairs. SIP messages consist of a header, which includes signaling information, and a body, which provides additional information, like audio and video codecs when setting up a call. The SIP session setup is a three-way handshake with INVITE, 200 OK, and ACK, as shown in Fig. 1. A calling SIP user agent (UA) transmits an INVITE request message to a callee UA, to create a session through SIP proxy servers. Proxy servers receive and forward the INVITE message, without disruption of the message. When the receiver UA receives the INVITE message, it sends a 200 OK message to accept the session request. Then the sender UA confirms the session setup by sending ACK, and the session setup is completed.

UA (Caller)

SIP Proxy

INVITE

200 OK ACK

SIP Proxy INVITE

200 OK

UA (Callee) INVITE 200 OK

ACK ACK

Established Session for Media Delivery (RTP)

Fig. 1 e Basic procedure for SIP session setup.

Every single SIP message has a text-based format with the same three-part structure: start line, message header, and message body, as shown in Fig. 2. A start line identifies the type and forwarding information of the message. A message header includes signaling information, such as caller (From) and callee (To), in the form of URIs, the path taken by the message so far (via), a unique message identifier (Call-Id), the actual location where a user can be reached (Contact), and so on. A message body contains additional information, e.g. a description of the voice streams between the two parties.

2.2.

Overview of the Bloom filter

A Bloom filter is a space-efficient data structure for the probabilistic representation of a set to support membership queries within a constant delay (Fan et al., 2000). With a Bloom filter, a set A ¼ {a1,a2,.,an} of n elements is described by a vector V of m bits, initially all set to zero. A Bloom filter is implemented by k independent hash functions, h1,h2,.,hk. By applying the k hash functions to each element of the set A, k random numbers over a range {1,., m} are obtained, and the bits in the vector V corresponding to the resulting numbers are set to one. Once all the elements of the set A have been indexed to the vector V, the procedure to judge whether an element a belongs to A is carried out, simply by checking whether all the bit positions obtained by applying the hash functions to the element a are equal to one. If so, then a is a member of A; otherwise a is not a member of A. However, there is a probability that this conclusion could be wrong.

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP mmcn.ajou.ac.kr:5060 To: K. Ryu From: B.H. Roh Call-ID: 123456789 CSeq: 1 INVITE Subject: Whitelist-based SIP Security Content-Type: application/sdp Content-Length: 157

Start Line

Message Header



Separator

V=0 o=2890844526 2890844526 IN IP4 mmcn.ajou.ac.kr s=SDP Media Session … The rest is omitted

Message Body

Fig. 2 e Example of an SIP message.

48

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

3. Proposed whitelist-based countermeasure scheme 3.1.

System architecture

The system architecture of the proposed scheme is shown in Fig. 3, in which a preprocessor with three components, namely a whitelist manager (WM), a filter, and an attack detector (AD), is placed in front of an SIP server. The role of the AD is to detect attack symptoms. When the AD detects an SIP flooding attack symptom, then it passes the attack symptom to the filter. When no attack symptom has been detected, all SIP messages are passed through the filter. In an attack situation, however, only those messages that match the whitelist provided by WM can be passed, while all other messages that do not match the whitelist are dropped. To construct the whitelist, the WM uses a Bloom filter mechanism, which will be explained in the next subsection.

3.2. Whitelist manager: construction of a whitelist using a Bloom filter In most flooding attacks, attackers generate massive numbers of malicious packets to a target by alteration of major packet attributes, such as source/destination IP addresses and port numbers, to hide their existence. Once the attributes have been altered by attackers, it is very hard to differentiate normal packets from abnormal attack ones, even though attack symptoms may have been detected. To solve this problem, a whitelist-based scheme is here proposed to protect both normal SIP messages and servers from flooding attacks. In contrast to whitelists in existing approaches (Chen and Itoh, 2010; Deng and Shore, 2009) that directly include individual entries, the whitelist in the scheme proposed here is represented by a Bloom filter vector, as described in Section 2.2. Each SIP session is established through a three-way handshake with INVITE, 200 OK, and ACK, as shown in Fig. 1. The SIP session between two UAs is identified basically by a pair of the two UAs’ URIs, which appear in the From and To fields included in the SIP messages, as shown in Fig. 2. SIP messages include other fields, such as via, Call-ID, and Contact, as described in Section 2.1. Since these fields are changed whenever sessions between the same two UAs are newly established, they are not meaningful to be used to construct

Whitelist Manager Bloom filter (vector V)

Attack Detector attack symptom Incoming SIP Messages

Filter

SIP server

Pre-Processor

Fig. 3 e Proposed system architecture.

the whitelist. Since an SIP session setup process is started by sending an INVITE from a caller UA, the source and destination IP addresses included in the header of the IP datagram that delivers the INVITE may be another meaningful parameter to identify the session. The caller UA can be indicated by the source IP address, and hence the caller’s source IP address can be a good parameter to define the session. On the other hand, since destination IP addresses included in INVITEs are the same as the IP address of the SIP server, they are not meaningful for the construction of the whitelist. Based on the facts mentioned above, we represent each SIP session normally established through the SIP signaling procedure as the combination of the three tuples , where SIP denotes the source IP address, and FRURI and TOURI are respectively the caller and callee URIs extracted from the and fields in the SIP message header. The procedure for constructing a Bloom filter-based whitelist from the session information is shown in Fig. 4. The whitelist construction requires a database called Session_DB, in which the session information for ongoing INVITE messages is maintained. Each element stored in Session_DB consists of the session information, its session_state and its initial_arrival_time. The session_state can be “INVITE” or “200 OK”, according to the type of message that the SIP server receives. The initial_arrival_time represents the time when the first INVITE message for the session arrives at the server. If no “ACK” message for the session is received at the server until a certain time threshold, the element for the session is removed from Session_DB. We use the time threshold as the maximum bound of retransmission of INVITE messages defined in RFC 3261 (Rosenberg et al., 2002), where it is given 62.5 s by default. For each incoming SIP signaling message, the SIP server extracts its session information. If the type of the incoming message is INVITE, the WM checks whether it is a member listed in the whitelist vector V or not. It is noted that all the bits in the vector V are initially set to zeros. If the message is a member of the whitelist, no further task is needed. When it is not a member of the whitelist, i.e. it is a new INVITE message, its session information is stored in Session_DB, with the session_state of “INVITE”, and the initial_arrival_time as its arrival time. When the callee accepts the request, it sends a 200 OK message to the SIP server, as shown in Fig. 1. If the session information extracted from the 200 OK message at the server is included in Session_DB, only the change of session_state as “200 OK” is done. Otherwise, the message is ignored, and it can be filtered, since it may be a misused message. If the incoming message is ACK and its session information exists in Session_DB, the whitelist V is updated by applying the Bloom filter mechanism for the session information; otherwise, the message is ignored. Then, the element for the session information is removed from Session_DB, since it is no longer used. The Bloom filter mechanism is shown in Fig. 5. It is assumed that there are k independent hash functions, h1,h2,.,hk. As mentioned in Section 2.2, the Bloom filter vector V of length m bits is initially set to zero. For the Bloom filter mechanism, the SIP session information is comprised of one string with a concatenated sequence of SIP, FRURI, and TOURI. Then k independent hash functions are applied to the string.

49

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

Incoming SIP Message (only for INVITE, 200 OK, and ACK) Extract session information

NO

YES INVITE Message ? YES

Lookup Session_DB with the session information

Is it a member of whitelist vector V ? NO

NO Does the information exist in Session_DB ?

Store the session information with session_state=“INVITE” and initial_arrival_time in Session_DB

YES 200 OK Message Type ? Change session_state as “200 OK”

ACK

Update whitelist vector V by applying Bloom Filter Mechanism

Remove the session information from Session_DB

Fig. 4 e Basic procedure for constructing the Bloom filter-based whitelist.

The bit positions in the whitelist vector V corresponding to the hash function results are set to one.

3.3. Attack detector: detection of flooding attack symptoms The previous work of (Ryu et al., 2011) assumed that callers tend to make sessions more frequently with callees with whom they have already made successful ones. By including the normal session information in the whitelist, the flooding attack symptom can be detected. However, it is impossible to include all possible session information in the whitelist at once, since a person’s call pattern may vary with time. In addition, although individuals make calls with other individuals they frequently call, they may contact new

string of session information

hash functions h1

1

h2

1

h3

hk-1

1

hk

1

m bits vector V (Bloom Filter)

Fig. 5 e Bloom filter mechanism.

1

individuals also. In this Section, we explain our proposed attack detection method to overcome the limitation of the previous work by reflecting the call patterns. The proposed method can make SIP servers provide sustainable services to normal users, even while flooding attacks are going on. Let us consider a non-member counter (M), as well as a total counter (M ). To obtain the counters, we assume that time is divided into a constant period D, and therefore D can be used as a basic unit of attack measurement. Then, we define Mn and Mn as the counters for the total number of incoming INVITE messages and the number of non-member messages, respectively, during the n-th time period. That is, Mn is the number of INVITE messages that are not members of the whitelist constructed just before these messages arrive at the SIP server during the n-th time period. The counters are calculated according to the procedure shown in Fig. 6. At the start of each time period, the counters are initialized to zero. When an i-th INVITE message arrives during an n-th time period, i ¼ 1,2,., its session information string b(n,i) is formed. Let V(n,i) be the whitelist constructed just before the i-th message during the n-th time period arrives. It is noted that the whitelist vector is continuously updated according to the procedure shown in Fig. 4, whenever each normal session setup through three-way handshake with INVITE, 200 OK, and ACK is established. Then the Bloom filter membership test is applied to the string b(n,i) using the whitelist vector V(n,i) provided by WM. V(n,i)[hj(b(n,i))], j ¼ 1,2,.,k, in Fig. 6 represents the bit position in V(n,i) indicated by the hash function result of hj(b(n,i)). If the membership test fails, then the counter Mn is increased by one. It is noted that all non-member INVITE messages are not attack ones. As we mentioned before, normal users may

50

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

Fig. 6 e Non-membership counter calculation.

contact other normal users whose sessions are not included in the whitelist. However, we can assume that the probability that sessions included in the whitelist are made again during a time period is much larger than that for non-member sessions. That is, if the ratio of non-member session trials to the total number of session trials during a time period is greater than a certain level, it is inferred that a flooding attack may have occurred. With the fact illustrated above, in order to detect SIP flooding attacks, we define a new measure Rn as the weighted average of the ratio of non-members to total counters, i.e. Mn =Mn during the n-th time period. That is, Mn Rn ¼ a$Rn1 þ ð1  aÞ$ ; Mn

n ¼ 0; 1; 2; .

(1)

where a is a constant weighting factor ranging between zero and one. In Eq. (1), we use the non-membership ratio (Mn =Mn ), instead of using the number of arrived messages usually used in other flooding attack detection methods, such as Rebahi et al. (2008), Siris and Papagalou (2006), Akbar et al. (2008), Ryu et al. (2009, 2011). Conventional methods based on the number of messages have the following problem. For example, since traffic behaviors change with time, it is possible for normal call setup messages to be generated excessively more than a pre-defined forecasted level during a certain period. Then, the conventional methods may make a decision that the SIP element is being attacked, even though all the messages are sent from legitimate users. By using the non-membership ratio as a measure for the attack detection, the problem of the existing methods can be solved. That is, even though the number of messages exceeds a given threshold, the nonmembership ratio may be kept a certain level, if all these are legitimate. We will show the effect in Section 4.2. We can imagine that the non-membership ratio in a stationary state varies within a forecastable range when no attack occurs. Therefore, we can set a threshold value to detect a flooding attack, based on actual measurement. In this paper, we use the threshold value during a certain period, as follows Thr ¼ Eext ½Rn  þ h,sest ðRn Þ

(2)

where Eext[Rn] and sest(Rn) are mean and standard deviation estimated from normal INVITE flow during a certain period

when no flooding attacks occur, respectively, and h denotes an appropriate positive number. To determine the threshold value, seasonal (hourly, daily and weekly) variations and trends for call patterns should be considered. Accordingly, there can be different threshold values with different time periods. Given a threshold value, we define the three states of NORMAL, ALERT, and ATTACK to determine a situation in which flooding attacks occur, as in Ryu et al. (2009). No attack is presumed in the NORMAL state. The ALERT state is a state in which an attack is in question, but an attack has not yet been completely decided. The ATTACK state infers that it is being attacked. The transition between those states is shown in Fig. 7. With the three states, we can detect the INVITE flooding attacks according to the following algorithm, as shown in Fig. 8. When the weighted average of Rn at the end of the n-th time period, n ¼ 1,2,., exceeds a given threshold value, the counter is increased up to its maximum value of coutner_max. To adapt to an abrupt fluctuation in traffic behaviors, the upper bound values for NORMAL and ALERT, such as normal_limit and alert_limit, respectively, are defined. When it is in ATTACK state, it is inferred that the server is being attacked, which enables the filter operation.

3.4. Filter: protection of normal SIP messages and servers As mentioned in Section 3.1, all SIP messages can be passed through the filter under normal conditions when no attack symptom has been detected. However, in an attack situation, messages that fail the membership test are dropped at the filter. On the other hand, messages that match the whitelist are forwarded to the server. The filter algorithm is shown in Fig. 9. Note that the service rate of the server may deteriorate when a severe flooding attack is going on, and hence, without any countermeasure against the attack, SIP services gradually become unavailable. On the other hand, with the filter, SIP servers can work well even in severe flooding-attack situations, because only SIP messages from legitimate users are forwarded to the server. Note that in general, servers have enough capability to process the number of SIP messages forwarded by the filter, and these servers need never be down. In a similar manner, the proposed method can protect both SIP servers and legitimate SIP messages, even in severe flooding attack situations.

4.

Experimental results

To perform experiments to demonstrate the effectiveness of the proposed scheme, we used the OPNET simulation tool

NORMAL state

ALERT state

ATTACK state

Fig. 7 e Transition between states for attack detection.

51

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

Fig. 8 e Flooding Attack detection algorithm.

4.1.

Design of a Bloom filter

As mentioned in Section 2.2, a Bloom filter is represented by the number of hash functions (k), the size of the vector V (m), and the number of member elements (N ). We made a scenario to build a Bloom filter as a whitelist for the proposed method as follows. Assume that legitimate UAs establish sessions through a common SIP proxy server. By having all these UAs establish normal sessions with each other, the whitelist, i.e. the Bloom filter vector V, was generated. N was set to 20,000 for the experiments.

for each incoming SIP message of any type if ( an attack symptom is detected ) then get a string b from the session information of the SIP message; for each hash function h j (j=1,2,…,k) if V[h j (b)] != 1, then DROP the message and RETURN; endfor

Given the Bloom filter parameters, k, m and N, the probability of a false positive is (Fan et al., 2000): perr z 1  ekN=m


k

(3)

Fig. 10 shows the filter size required for a false-positive probability of less than 0.1% for the given number of hash functions. The filter size is derived from using Eq. (3). We can see that as the number of hash functions increases, the required filter size decreases. In Fig. 11, the false-positive, false-negative and overall false probabilities for given k and m values are depicted, which are obtained from Fig. 10. To obtain Fig. 11, we carried out the following experiments: First, we made N normal SIP messages by using SIPp. Given each k and m, a Bloom filter vector has been constructed for the N normal SIP messages. Abnormal messages for SIP flooding attacks were generated by using 1400000 1244800 1200000

Bloom Filter Size (m) (in bits)

(OPNET), which has an SIP simulation module. We implemented a normal SIP traffic generation model from legitimate users on the OPNET by reference to SIPp (SIPp), which is a free open source for traffic generation using the SIP protocol. An attack SIP traffic generator was constructed based on INVITE Flooder (Endler and Coller, 2007), which is an open source, to generate a flurry of SIP INVITE messages to a phone or proxy server.

1000000 800000 569470

600000

408570 400000

345700

315680

300160

200000

endif FORWARD the message to the SIP server Endfor

0 2

3

4

5

6

Number of Hash Functions (k)

Fig. 9 e Filter algorithm.

Fig. 10 e Filter size and the number of hash functions (required false-positive ratio £ 0.1%, N [ 20000).

7

52

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

0.30

False Ratio (%)

0.25

0.20

0.15 Overall False Ratio False-Negative Ratio

0.10

False-Positive Ratio 0.05

0.00 2

3

4

5

6

7

Number of Hash Functions (k)

Fig. 11 e False ratios (when N [ 20,000).

INVITE Flooder at a rate of 600 messages/sec, and randomly selected normal messages out of N were generated at the same time at a rate of 60 messages/sec. Then, the abnormal and normal messages were mixed and input into the Bloom filter. The Bloom filter distinguishes whether input messages are normal or not. We carried out the experiment 5 times, and the average values are shown in Fig. 11. As we can see from Fig. 11, false-positive ratios are much less than 0.1%, while false-negative ratios show around 0.2%. This is because the possible number of abnormal messages is much larger than N, the number of normal messages used for the construction of the Bloom filter. In order to reduce the false-negative ratio, the Bloom filter size should be much larger than the one to meet the requirement of the false-positive ratio. However, we think that the 0.2% of false-negative ratio in our experiments can be acceptable, since the number of abnormal messages that are determined as normal ones can be acceptable at the SIP server, even when an SIP flooding attack is going on. To show how the modification of three tuples affects the false-ratio performance, we carried out further experiments shown in Fig. 12, for the number of hash function of 3, 4 and 5. In Fig. 12, the values represented as three bits on the horizontal axis indicate respectively whether the three-tuple (source IP address, caller’s and callee’s URIs) are modified or not. If a parameter out of the three-tuple is modified, then the corresponding bit is represented by ‘1’. Otherwise, the bit is 0.30 k=3 k=4 false-positive

k=5

k=3(Positive)

k=4(Positive)

k=5(Positive)

k=3(Negative)

k=4(Negative)

k=5(Negative)

0.25

False Ratios (%)

false-negative

0.20

0.15

0.10

0.05

0.00 000

001

010

011

100

101

110

111

Attack Pattern

Fig. 12 e False ratios when three tuples are modified by attackers.

represented by ‘0’. For example, the value of ‘010’ means that only the caller’s URIs are modified by randomly generated ones, which are different from those of normal sessions, while the other two fields are the same as those from normal sessions; and the value of ‘111’ means that all the three-tuple are modified. The value of ‘000’ means that individual fields of the threetuple are the same as those that appeared in normal sessions, but the combination of the individual fields are different from those of normal sessions. The value of ‘000’ reflects the case where attackers modify the fields by using known UAs’ information. In Fig. 12, the false-positive and false-negative ratios are shown for all the possible modifications of the three-tuple. For all the cases, the false-positive ratios are all less than 0.03%, which meet our design objective of less than 0.1%. On the other hand, the false-negative ratios show robust levels of around 0.2%. From the experiment of Fig. 12, we expect that the threetuple can be effectively used for the construction of the Bloom filter as the whitelist.

4.2. Performances on the proposed flooding attack detection With the above results from Section 4.1, the parameters k ¼ 5 and m ¼ 345,700 given for N ¼ 20,000, which provide a falsepositive ratio of less than 0.1%, were chosen for the experiments. 1) Unexpected abrupt increases of normal messages without attacks: In Eq. (1), the proposed method uses the non-membership ratio (Mn =Mn ) for the detection of flooding attacks, instead of using the message rate (Mn) represented by the number of arrived INVITE messages per second. As mentioned in Section 3.3, conventional schemes usually use the message rate to detect flooding attacks. To show the robustness of the use of the non-membership ratio, we generated normal INVITE messages, as shown in Fig. 13(a). We assumed that the interarrival times of normal messages during a certain stationary period are exponentially distributed with a mean of 1/60 s. Then, we considered the situation where two abrupt increases of normal flows (i.e. there is no attack) occurred at 400 and 600 s with message rates of 120 and 180 messages/s, respectively, each during a 200 s period. With the measurement of the generated message sequence, we obtained the threshold value of Eq. (2) with D ¼ 1, h ¼ 3 and a ¼ 0.7. Fig. 13(b) and (c) shows the attack counter and the decision state for the sequence of Fig. 13(a), respectively, when the message rate (Mn) is applied to Eq. (1) and the flooding attack detection algorithm shown in Fig. 8, instead of using Mn =Mn . We chose the upper bound values as normal_limit ¼ 1, alert_limit ¼ 3, and counter_max ¼ 5. As we can see from Fig. 13(c), the time periods where unexpected abrupt increases of normal messages occur are classified as attack ones, although all the messages are sent from legitimate users. In Ryu et al. (2011), the non-membership count (Mn ) is used for the attack detection instead of using Mn. Though the count Mn is used for the attack detection, the same wrong result as shown in Fig. 13(c) is obtained.

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

Weithed Average or Message Rate

250 Message Rate Threshold

200

150

100

50

0 0

100 200 300 400 500 600 700 800 900 1000 1100 1200

Time (sec)

(a) Weighted averages of M n 6 Attack Counter

Attack Counter

5

4

3

algorithm provides the attack detection points at around 400 and 600 s. It is noted that there is no attack situation in the sequence of Fig. 13(a). On the other hand, Figs. 15 and 16 show the attack detection results when the non-membership ratio is used instead of the message rate. Fig. 15 shows the detection results where the proposed method shown in Fig. 8 is used. As we can see from Fig. 15(a), even though there are unexpected abrupt increases of message rates, the non-membership ratio keeps a certain level, given by the probability ( p) that the session information of a new normal INVITE message is not included in the current whitelist. To obtain Fig. 15(a), we set p ¼ 0.1. With the non-membership ratio, no attack is detected, as shown in Fig. 15(b) and (c). Fig. 16 shows the attack detection results by CUSUM for the same non-membership sequence shown in Fig. 15(a). As we can see from Fig. 16(b), no attack is detected. From the experiments of Figs. 13e16, we can see that the use of the non-membership ratio provides more robust detection performance than that of the message rate. This is derived from our intuitive assumption that the nonmembership ratio may be kept a certain level if all the messages are sent from legitimate users, even though the message rates are severely fluctuated and exceed a given threshold.

2

2) Unexpected abrupt increases of normal messages with attacks:

1

0 0

100 200 300 400 500 600 700 800 900 1000 1100 1200

Time (sec)

(b) Attack counter using M n state

(0:NORMAL, 1: ALERT, 2: ATTACK)

2

Attack State

53

1

0 0

100 200 300 400 500 600 700 800 900 1000 1100 1200

Time (sec)

(c) Decision state based on M n Fig. 13 e Attack detection using Mn for abrupt increases of normal messages only, i.e. there is no attack.

The CUSUM (Rebahi et al., 2008; Siris and Papagalou, 2006) is a widely used anomaly detection algorithm based on change point detection theory. Fig. 14 shows the attack detection results by CUSUM using the same message rate sequence (Mn) of Fig. 13(a). We chose the same parameters used in Siris and Papagalou (2006) to obtain the CUSUM counts shown in Fig. 14(b). As shown in Fig. 14(c), the CUSUM

Fig. 17(a) shows the sequence that four attack sequences with the rate of 60 messages/sec and the duration of 30 s at 120, 500, 700 and 1000 s are added to the normal sequence, with abrupt increases of normal messages, as shown in Fig. 13(a). Fig. 17(b) shows the attack decision result for the sequence of Fig. 17(a) when Mn is applied to Eq. (1) and the algorithm shown in Fig. 8, instead of using Mn =Mn . As we can see from Fig. 17(b), the two attacks that occurred at 120 and 1000 s, where there is no abrupt increase of normal messages, are precisely detected. On the other hand, the other two attacks at 500 and 700 s are not differentiated from the false detection results, during the period of abrupt increases of message rates. Fig. 18 shows the detection results for the sequence of Fig. 17(a) by CUSUM. The CUSUM also provides the exact detection results when no abrupt change of normal message appears. On the other hand, it gives wrong decisions during the period between 400 and 800 s, in which abrupt increases of normal messages occur. The non-membership ratios for the same sequence of Fig. 17(a) are given in Fig. 19(a). As we can see from Fig. 19(a), the non-membership ratios are kept below a certain level for normal messages even though there are abrupt increases. However, we can see four peak non-membership ratio durations where attack sequences are added. With the nonmembership ratios, the attacks are exactly detected as shown in Fig. 19(b), regardless of whether there are abrupt increases of normal messages or not. 3) Increasing rate attacks: In an increasing rate attack, the attack rate is gradually increased, until it reaches its maximum attack rate. Fig. 20(a)

54

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

700 State for Message Rate

CUSUM Count for Message Rate Threshold

600

(0:NORMAL, 1: ALERT, 2: ATTACK) 2

Attack State

CUSUM Count

500 400 300

1

200 100 0

0 0

0

100 200 300 400 500 600 700 800 900 1000 1100 1200

100 200 300 400 500 600 700 800 900 1000 1100 1200

Time (sec)

Time (sec)

(a) CUSUM count

(b) Attack decision

Fig. 14 e Attack detection using CUSUM using Mn for the sequence of Fig. 13(a).

when p ¼ 0.2. Fig. 20(c) depicts the decision delays varying the probability p from 0.1 to 0.9. As p increases, the nonmembership ratio in normal messages also increases, the threshold value is also increased, and the time to detect the attack is more delayed. The decision delays are less than 5s when p is less than 0.3. Even when the probability p is 0.5, the decision delay is 10 s, which is a reasonable delay. We expect

shows an increasing rate attack scenario, in which the normal message rate is generated with a rate of 60 messages/s, and the attack is started at 300 s, with an incremental rate of 1 attack message/s, and ended at 900 s. The probability of nonmembership ratio of normal messages ( p) varies from 0.1 to 0.9, and Fig. 20(b) shows the non-membership ratio sequence for the aggregate flow with both normal and attack messages

6 Attack Counter

Non-Membership Ratio

5

Threshold

Attack Counter

0.2

0.1

4

3

2

1

0

0.0 0

100 200 300 400 500 600 700 800 900 1000 1100 1200

0

100 200 300 400 500 600 700 800 900 1000 1100 1200

Time (sec)

Time (sec)

(a) Weighted averages of

Mn

(b) Attack counter

Mn

2 state

(0:NORMAL, 1: ALERT, 2: ATTACK)

1

Attack State

Weigted Average of Non-Member Ratio

0.3

0

-1 0

100 200 300 400 500 600 700 800 900 1000 1100 1200

Time (sec)

(c) Decision state Fig. 15 e Attack detection using Mn =Mn for the sequence of Fig. 13(a).

55

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

8 CUSUM Count for Non-membership Ratio

State for Non-Membership Ratio

Threshold

2

(0:NORMAL, 1: ALERT, 2: ATTACK)

Attack State

CUSUM Count

6

4

1

0

2

0

-1 0

100 200 300 400 500 600 700 800 900 1000 1100 1200

0

100 200 300 400 500 600 700 800 900 1000 1100 1200

Time (sec)

Time (sec)

(a) CUSUM count for message rate

(b) Attack decision

Fig. 16 e Attack detection by CUSUM using Mn =Mn for the sequence of Fig. 15(a).

that the non-membership ratio may not be greater than 0.5, since it is intuitively presumed that people tend to make calls more frequently again with callees with whom they have previously made successful calls.

4.3. Effectiveness of the proposed countermeasure scheme To show the effectiveness of the proposed whitelist-based countermeasure scheme, two different patterns for attack message generation were considered. They are bulk-style and sampling-style attacks as shown in Figs. 21(a) and 22(a), respectively, in which attack messages with a rate of 600 messages/s are added to normal messages with a rate of 60 messages/s. In bulk-style attacks, a large number of attack messages are generated over a long period. Sampling-style attacks consist of semi-periodic, ONeOFF type traffic bursts, with a large number of attack messages during a relatively small ON period.

Figs. 21 and 22 show the number of SIP messages arriving at the SIP server during a bulk- and sampling-style attack respectively. Without the proposed method, all the messages, including both normal and attack ones, arrive directly at the server, as shown in Figs. 21(a) and 22(a) for bulk- and sampling-style attacks, respectively. Hence, the server may go down if the number of messages exceeds a certain threshold level that the server can handle. On the other hand, with the proposed method, as shown in Figs. 21(b) and 22(b), because most of the attack messages are dropped at the filter once an attack symptom is detected, the server receives most of the normal messages along with a few attack ones as falsepositive cases, which can be maintained by the server. However, messages not included in the whitelist are also dropped, even though those messages are sent from legitimate users, not from attackers. It is noted that if any counteract mechanism is not provided, the server may be down during the flooding attack period, and all the normal and attack messages are dropped. On the other hand, the

300 state

Threshold

(0:NORMAL, 1: ALERT, 2: ATTACK)

2

200

Attack State

Message Rate (Messages/sec)

Message Rate 250

150

1

100

50

0

0 0

100 200 300 400 500 600 700 800 900 1000 1100 1200

Time (sec)

(a) Weighted average of M n

0

100 200 300 400 500 600 700 800 900 1000 1100 1200

Time (sec)

(b) Decision state using M n

Fig. 17 e Attack detection when four attacks are added to the normal sequence of Fig. 13(a).

56

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

800 state

CUSUM Count

700

Threshold

(0:NORMAL, 1: ALERT, 2: ATTACK)

2

500

Attack State

CUSUM Count

600

400 300

1

200 100 0

0 0

0

100 200 300 400 500 600 700 800 900 1000 1100 1200

100 200 300 400 500 600 700 800 900 1000 1100 1200

Time (sec)

Time (sec)

(a) CUSUM count

(b) Attack decision

Fig. 18 e Attack detection by CUSUM for the sequence of Fig. 17(a).

proposed method makes SIP servers provide sustainable services to normal users listed in the whitelist, even while flooding attacks occur. The longer the time passes, the more session information is included in the whitelist. Therefore, it is expected that only a few new session requests are dropped, while most of them are served during an attack period. Fig. 23 shows the processing-delay performance obtained by varying the message service rate at the application layer of the server during a bulk-style attack. The processing delay is defined as the time difference between the time when a normal packet arrives at the filter, and the time when it leaves the SIP server. The service rate depends on the CPU and the memory of the server. For example, a CISCO SIP proxy server is expected to handle 100 calls/s, and is susceptible to flooding attacks at the rate of 500 INVITEs/s (Sengar et al., 2008). It is assumed that the SIP server has an infinite FIFO (first in, first out) queue. To obtain the results shown in Fig. 23, the aggregate traffic sequence given in Fig. 21(a) was assumed, while the service rate of SIP messages by the server was varied. Fig. 23(a) shows the average processing delays obtained by varying the service rate without the proposed method.

Processing delays increase dramatically from the start of the flooding attack, and the duration of the delay, affected by the attack, becomes longer as the service rate decreases. On the other hand, Fig. 23(b) depicts the maximum delays when the proposed method is used. The maximum delays shown in Fig. 23(b) are experienced over only a short time period at the very beginning of the flooding attack; afterward, the processing delays are similar to those with no attack, because most of the attack messages are dropped at the filter. Fig. 24 shows the loss-ratio performance for various service and attack rates during a bulk-style attack without the proposed method. In this case, the aggregate traffic pattern is similar to that shown in Fig. 21(a), but the peak rates vary according to the attack rates. It is assumed that the SIP server has a finite FIFO queue that can store a maximum of 200 messages. With the finite size of the FIFO queue, messages arriving when the queue is full are dropped, even though the filter has passed them. The loss ratio is defined as Klost/Kgenerated, where Klost and Kgenerated denote the total number of normal messages lost and generated, respectively, during the

0.6 state

Non-Membership Ratio Threshold

(0:NORMAL, 1: ALERT, 2: ATTACK)

2

0.4

Attack State

Non Memberhip Ratio

0.5

0.3

1

0.2

0.1

0

0.0 0

100 200 300 400 500 600 700 800 900 1000 1100 1200

(a) Weighted average of

0

100 200 300 400 500 600 700 800 900 1000 1100 1200

Time (sec)

Time (sec) Mn

Mn

(b) Decision state using

Mn

Mn

Fig. 19 e Attack detection by the proposed method using Mn =Mn for the sequence of Fig. 17(a).

57

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

1 Non-Membership Ratio

0.9

700

Threshold

Message Rate 0.8

600

Non-Membership Ratio

Weithed Average or Message Rate

800

500 400 300 200

0.7 0.6 0.5 0.4 0.3 0.2

100

0.1

0

0 0

100

200

300

400

500

600

700

800

900 1,000 1,100

0

100

200

300

400

500

Time (sec)

600

700

800

900 1,000 1,100

Time (sec)

(a) Message rate with increasing attack

(b) Non-membership ratio (p=0.2)

120 decision delay

Decision Delay (second)

100

80

60

40

20

0 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

non-membership probability (p)

(c) Attack decision delay Fig. 20 e Attack detection for an increasing rate attack.

the attack messages are dropped at the filter, and therefore the actual message rates that the server has to deal with are less than the service rate. In Chen and Itoh (2010), a whitelist-based countermeasure scheme against SIP flooding attacks has been proposed. To

800

800

700

700

Message Rate (Messages/sec)

Message Rate (Messages/sec)

bulk-attack period. As can be seen in Fig. 24, the loss ratios increase as the average rates of flooding-attack traffic increase, and as the service rate of the server decreases. However, the loss ratios are close to zero when the proposed method is used. This can be explained by the fact that most of

600 500 400 300 200 100

600 500 400 300 200 100

0

0 0

500

1000

1500

2000

2500

3000

Time (sec)

(a) Without the proposed method

3500

0

500

1000

1500

2000

2500

Time (sec)

(b) With the proposed method

Fig. 21 e Number of messages arriving at the SIP server (during a bulk-style attack).

3000

3500

58

800

800

700

700

Message Rate (Messages/sec)

Message Rate (Messages/sec)

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

600 500 400 300 200 100

600 500 400 300 200 100 0

0 0

500

1000

1500

2000

2500

3000

0

3500

500

1000

1500

2000

2500

3000

3500

Time (sec)

Time (sec)

(a) Without the proposed method

(b) With the proposed method

Fig. 22 e Number of messages arriving at the SIP server (during a sampling-style attack).

5.

1600

2.00

1400

1.80

1200 Service Rate=200

1000 800

Service Rate=300

600 400

Service Rate=500 200 0 0

500

1000

1500

2000

2500

3000

3500

Time (sec)

(a) Average delay without proposed method

Related works

There has been a lot of work dealing with DoS attacks on SIP services. Authentication- and encryption-based approaches have been proposed (Bremler-Barr et al., 2006; Geneiatakis and Lambrinoudakis, 2007; Wang and Zhang, 2008), but they may be ineffective, because SIP servers require computational overheads for encryption and decryption of individual messages. Subramanian and Dutta (2010) showed that the overhead by message authentication has a great effect on the performance degradation in call setup delay. These approaches become more ineffective in flooding-attack environments, since massive numbers of SIP messages are arriving at the server. With the nature of sudden changes in network traffic when flooding attacks occur, there have been various thresholdbased detection methods, such as cumulative sums (CUSUM) (Rebahi et al., 2008), Hellinger distance (HD) (Sengar et al., 2008), and adaptive threshold (AT) (Siris and Papagalou, 2006; Akbar et al., 2008). They detect SIP flooding attacks by investigating whether the number of incoming SIP messages exceeds a certain threshold level. In CUSUM, the threshold

Maximum Processing Delay (sec)

Processing Delay (sec)

construct the whitelist, the source addresses of users who have successfully completed an SIP registration process using REGISTER messages are used. It is noted that unlike the proposed method, Chen and Itoh (2010) did not use a Bloom filter to prepare the whitelist. The proposed method was compared with the Chen and Itoh method as a function of throughput. The throughput is defined as the ratio between the number of INVITEs sent from normal users, and the number of the INVITEs received by the server. The throughput performance comparison is shown in Fig. 25. To obtain Fig. 25, we assumed that an attacker is successfully registered, and generates massive malicious INVITEs to the proxy server from 1800s to 2400 s. Since the attacker’s registration was successfully done, its information has been included in the whitelist. Accordingly, all the INVITEs from the attacker pass the filter, and arrive at the server. As a result, the Chen and Itoh throughput decreases severely during the attack period. On the other hand, the throughput of the proposed method shows almost 1. That is, all the normal messages are delivered to the server during the attack period, since the proposed method makes the whitelist by considering source IP and callee’s URI, as well as caller’s URI, which is maintained at the REGISTER server.

1.60 1.40 1.20 1.00 0.80 0.60 0.40 0.20 0.00 100

200

300

400

500

Service Rate (messages/sec)

(b) Maximum delay with proposed method

Fig. 23 e Processing delay performance (during a bulk-style attack).

600

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

0.80 Service Rate=200

Loss Ratio of Normal Messages

0.70

Service Rate=300 Service Rate=400

0.60

Service Rate=500

0.50 0.40 0.30 0.20 0.10 0.00 50

150

250

350

450

550

650

Averate Rate of Bulk-attack (messages/sec)

Fig. 24 e Loss-ratio performance (without the proposed method).

value is given statistically using a priori-analyzed normal SIP traffic pattern when no congestion is assumed, and hence it cannot reflect the traffic behaviors changing with time. The threshold value in HD and AT is dynamically computed based on the observations of the history of previous traffic patterns. Tang and Cheng (2011) showed that CUSUM and HD-based detection schemes are not effective on the stealthy flooding attacks where attack traffic rate is gradually and slightly increased, and they proposed a discrete wavelet transform (DWT)-based detection method of the SIP stealthy flooding attacks. However, these threshold-based methods may identify a network congestion state as a flooding attack, because many SIP messages are retransmitted during the congestion periods. Ryu et al. (2009) proposed a flooding attack detection method considering the upper bound of the possible number of SIP messages during congestion periods. In addition, Geneiatakis et al. (2009) proposed a Bloom filter-based flooding attack detection method. However, these methods have focused on the detection of flooding attacks, without providing effective countermeasure schemes to protect normal messages from abnormal ones after attacks have been detected. Filtering-based schemes to counteract SIP flooding attacks have been proposed. In Huici et al. (2009), an intrusion

1.2

1

Throughput

0.8

0.6

59

detection system (IDS) at a victim’s site creates a blacklist of malicious SIP traffic sources, and sends filtering requests to controllers near the sources of the attack. However, the method has a limitation that all network controllers must have both an IDS and filtering mechanisms. To overcome the problem of excessive overhead for blacklist approaches when IDS schemes are used, whitelistbased filtering schemes (Zhou et al., 2009; Chen and Itoh, 2010) have been proposed. When flooding attacks are detected, only SIP messages sent from sources on the whitelist are accepted, while others are denied. To construct the whitelist, the source addresses of users who have successfully completed an SIP registration process using REGISTER messages (Chen and Itoh, 2010), or those who have frequently engaged in legitimate sessions (Zhou et al., 2009), are used. However, they have some limitations when used in environments with a large number of VoIP users, because of the heavy storage requirements for huge whitelists, and the corresponding computational complexity of searching such a list. In addition, because SIP supports various types of URIs and application-level mobility (Schulzrinne and Wedlund, 2000), the use of source addresses alone to construct the whitelist may be ineffective. Ryu et al. (2011) also proposed a white-list based flooding attack detection method using a Bloom filter. However, since the method is based only on the total number of non-member messages to detect flooding attacks, it cannot reflect the time-varying traffic behaviors described in Section 4.2. In addition, they did not provide any countermeasure scheme against the flooding attack. Hussain and Nait-Abdesselam (2011) introduced a new term of critical number (CN), which is the maximum number of calls that can be handled by a particular user during its call setup process. SIP server counts the total number of received requests for a particular user, and compares it with the CN for that user. If the total number of requests is less than the CN, the request is transferred to the callee. Otherwise, it is blocked. To implement the scheme, the server needs to maintain the arrival times, and the number of requests for individual users, as well as their SIP addresses. As the number of users increases, the required memory and the CPU load to process the calls also significantly increase. Kim et al. (2010) proposed a mask-based filtering rule to filter attack messages autonomously. They also proposed a random early detection (RED)-based scheme to protect SIP servers during flooding attacks. They assumed that flooding attack messages are nearly identical, i.e. only specific fields in the SIP header, such as Via, From, Call-ID and CSeq are a little changed, while all other fields have the same values, as in the INVITE Flooder (Endler and Coller, 2007) attack tool. Accordingly, their scheme becomes ineffective when the contents in the SIP header of attack messages are randomly changed.

0.4

6.

Conclusions

0.2 Proposed Method 0 1,500

Method (Chen and Itoh, 2010) 1,700

1,900

2,100

2,300

Time (sec)

Fig. 25 e Throughput comparison.

2,500

SIP-based multimedia services, such as VoIP and IMS, are becoming one of the most crucial communication services for human life. However, SIP-based services are exposed to a number of potential threats to DoS by flooding attacks. Flooding attacks intended for disturbing an infrastructure can

60

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

be counteracted by sharing the information on the attacks among distributed network systems. However, SIP flooding attacks are targeted on a certain SIP server. For such attacks targeted on a certain server, it is very effective for the detection and countermeasure processes to be done at a place very close to the target server. In this paper, a whitelist-based detection and countermeasure scheme against SIP flooding attacks has been proposed. To build the whitelist, a Bloom filter approach was used to reduce memory requirements and computational complexity. With the Bloom filter, the proposed scheme requires a computational complexity of O(1) to process each message, while other whitelist-based approaches such as proposed in Chen and Itoh (2010) require O(N). It has been shown that the proposed method not only detects SIP flooding attacks with a very low false-positive ratio, but also effectively protects normal SIP users and servers, even in severe flooding-attack environments. In addition, SIP session setup process may be done through several SIP servers when UAs are located at different management domains. In this case, since filtering on flooding attack messages is done at the first SIP server, the next servers can be protected from flooding attacks. The authors expect that the proposed method can contribute to providing secure SIP-based services and applications.

Acknowledgment This research was partially supported by Basic Science Research Program through the NRF of Korea funded by the MEST (NRF-2011-0025544). The authors would like to thank the anonymous reviewers for their valuable comments to improve the quality of the paper.

references

Akbar MA, Tariq Z, Farooq M. A comparative study of anomaly detection algorithms for detection of SIP flooding in IMS. In: Proc. IEEE IMSAA 2008. Bremler-Barr A, Halachmi-Bekel R, Kangasharju J. Unregister attacks in SIP. In: Proc. IEEE 2nd workshop on secure network protocols 2006. Chen EY, Itoh M. A whitelist approach to protect SIP servers from flooding attacks. In: Proc. IEEE CQR 2010. Deng X, Shore M. Advanced flooding attack on a SIP server. In: Proc. IEEE ARES 2009. Endler D, Coller M. Hacking VoIP exposed: voice over IP security secrets & solutions. McGraw-Hill Professional Publishing. http://www.hackingvoip.com/sec_tools.html; 2007. Fan L, Cao P, Almeida J, Broder AZ. Summary cache: a scalable wide-area Web cache sharing protocol. IEEE/ACM Transactions on Networking 2000;8(3):281e93. Geneiatakis D, Lambrinoudakis C. A lightweight protection mechanism against signaling attacks in a SIP-based VoIP environment. Telecommunication Systems 2007;36(4):153e9. Geneiatakis D, Vrakas N, Lambrinousdakis C. Utilizing Bloom filters for detecting flooding attacks against SIP-based services. Computer & Security 2009;28(7):578e91. Huici F, Niccolini S, d’Heureuse N. Protecting SIP against very large flooding DoS attacks. In: Proc. IEEE GLOBECOM 2009.

Hussain I, Nait-Abdesselam F. Strategy based proxy to secure user agent from flooding attack in SIP. In: Proc. IEEE IWCMC’2011 2011. Kim J, Roh B, Hong M, Kang S, Lee S. Autonomous defense against flooding-based denial of service of a SIP system. In: Proc. IEEE LISAT’2010 2010. OPNET Modeler, http://www.opnet.com. Rebahi Y, Sher M, Magedanz T. Detecting flooding attack against IP multimedia subsystem (IMS) networks. In: Proc. IEEE/ACS AICCSA 2008. Rosenberg J, Schulzrinne H, Cvamarillo G, Johnston A, Peterson J, Spark R, et al. SIP: Session Initiation Protocol. Internet Engineering Task Force Request for Comments 2002;3261. Ryu J, Roh B, Ryu K. Detection of SIP flooding attacks based on the upper bound of the possible number of SIP messages. KSII Transactions on Internet and Information Systems 2009;3(5):507e26. Ryu K, Kim J, Roh B. Whitelist-based SIP flooding attack detection using a Bloom filter. In: Proc. ICTA’2011 2011. Schulzrinne H, Wedlund E. Application-layer mobility using SIP. ACM Mobile Computing and Communications Review 2000;4(3):47e57. Sengar H, Wang H, Wijesekera D, Jajodia S. Detecting VoIP floods using the Hellinger distance. IEEE Transactions on Parallel and Distributed Systems 2008;19(6):794e805. SIPp, http://sipp. sourceforge.net. Siris V, Papagalou F. Application of anomaly detection algorithms for detecting SYN flooding attacks. Computer Communications 2006;29(9):1433e42. Subramanian SV, Dutta R. Comparative study of secure vs. nonsecure transport protocols on the SIP proxy server performance: an experimental approach. In: Proc. IEEE ARTCom’201 Oct. 2010. Tang J, Cheng Y. Quick detection of stealthy SIP flooding attacks in VoIP network. In: Proc. IEEE ICC’2011 2011. Wang F, Zhang Y. A new provably secure authentication and key agreement mechanism for SIP using certificateless public-key cryptography. Computer Communications 2008;31(10):2142e9. Zhou CV, Leckie C, Ramamohanarao K. Protecting SIP server from CPU-based DoS attacks using history-based IP filtering. IEEE Communications Letters 2009;13(10):800e2. Byeong-hee Roh received his B.S. degree in electronics engineering from Hanyang University, Seoul, Korea, in 1987 and his M.S. and Ph.D. degrees in electrical engineering from Korea Advanced Institute of Science and Technology (KAIST), Taejon, Korea, in 1989 and 1998, respectively. He worked with Korea Telecom and Samsung Electronics Co., Ltd. for several years before he joined Ajou University, Suwon, Korea, on 2000, where he is currently a professor at Department of Software Convergence Technology. His research interests include the areas of mobile multimedia networking, network security and military communications. Ju Wan Kim received his B.S. and M.S. degrees in computer engineering from Ajou University, Suwon, Korea, in 2009 and 2011, respectively. He worked for Ebay Korea, Co., from October 2011 to July 2012. He is currently a research engineer in Convergence R&D Lab., LG Electronics, Co., Ltd. His research interests include the areas of multimedia networking, and network security. Ki-Yeol Ryu received his B.E. degree in Computer Engineering from the Seoul National University in 1985, and his M.S. and Ph. D. degrees in Computer Science from KAIST in 1987 and 1992, respectively. From 1993 to 1994, he was a visiting researcher at Yonezawa

c o m p u t e r s & s e c u r i t y 3 7 ( 2 0 1 3 ) 4 6 e6 1

Lab., the Department of Information Science, Tokyo University. He was a visiting professor at the Department of Computer Science, University of Colorado, Boulder during 2000. He has been working at the Department of Information and Computer Engineering, Ajou University, since 1994. His interests include ubiquitous computing, service-oriented computing, object-oriented programming languages and computer security.

61

Jea-Tek Ryu received his B.S. and M.S. degrees in computer science from Ajou University, Suwon, Korea, in 2005 and 2007, respectively. He also received his Ph.D. degree in Computer Engineering in 2011 at Ajou University. Since February 2011, he has been with IP Service Team, Korea Institute of Patent Information, Seoul, Korea. His research interests include ubiquitous sensor networks, network security and multimedia network systems.