HSDT: Table-Overflow Attack Defender with Historical Statistics Based Dynamic Timeout in Software Defined Networks ^†

Abstract

A Software Defined Network (SDN) provides efficient network management by decoupling two planes: the control plane and the data plane. However, although SDN provides efficient network management, it also causes several critical vulnerabilities. In particular, the lack of memory for a flow table in the data plane can be exploited to conduct a flow table overflow attack. This paper proposes a history-based dynamic timeout scheme to mitigate the flow table overflow attack. The proposed scheme dynamically sets up both hard timeout and idle timeout based on statistical history for each flow, which can quickly remove attack flows from a flow table. Consequently, it can keep the occupancy of the flow table low and secure the robustness against the flow table overflow attack. The experiment results show that the proposed HSDT can mitigate the overflow attack with reasonable overhead by effectively evicting attack flow rules from the flow table while it has a minimal impact on the other normal flow rules and bandwidth.

1. Introduction

The Software Defined Network (SDN) has become one of the most prominent network architectures for efficient network management [1]. The two key features, the programmability of the network and separation of control and data planes, enable flexible network configuration and efficient network monitoring and management.

Although SDN has overcome the limitations of traditional networks, it has other varying problems caused by the centralized structural characteristics. SDN switches ask a controller how to handle an arrived packet if the packet does not match any of the predefined rules called flow tables. In response, the controller installs appropriate rules for them. In this protocol, a lot of unknown incoming traffic may incur a Denial of Service (DoS) attack at either the controller or the switches [2].

The controller can be overwhelmed by control packets for the unknown traffic, which may paralyze the entire network. On the other hand, the switches may suffer from the storage lack of the rules. SDN switches use TCAM (Ternary Content-Addressable Memory) as a storage for flow tables. Because TCAM is expensive and has high power consumption, the memory capacity of SDN switches is limited [3]. So, attackers can easily consume the flow tables with attack flows, which results in no space left for normal flows. Because of overflowed flow tables, incoming normal packets will be dropped, which leads to a DoS and performance degradation [4]. Since this flow overflow attack can be easily launched by an attacker with hosts in the target network, it should be considered a serious security threat. Therefore, this paper focuses on DoS at switches.

Although various defense mechanisms have been proposed, they have limitations. Some research has proposed mechanisms for adjusting timeouts dynamically [5,6,7]. However, they need too much extra memory for caching or assign timeouts inefficiently. We will discuss the usage of timeouts in detail in Section 2.1. Zhang, J, Zhang, M proposed an architecture evicting flow rules in order of the flow’s priority when a flow table is full, but they must collect statistics periodically [4,8]. Meanwhile, a scheme to make table-miss flows detour a victim switch was suggested [9]. Still, it needs to install a large number of additional flow rules for the detour and further monitoring.

To protect SDN switches from flow overflow attacks, we propose a dynamic timeout adjustment mechanism that determines both hard timeout and idle timeout based on historical statistics. The proposed scheme is inspired by a simple intuition, which is that a flow with more packets in the past is less suspicious or more trustable [10]. Under the intuition, a longer timeout is given to the flow. On the other hand, a flow with fewer packets is given a shorter timeout since it is more likely to be from an attacker. Since a long timeout avoids unnecessary control traffic between a controller and switches and a short timeout reduces the number of flows that unnecessarily occupy the flow table, the proposed scheme can prevent SDN switches from the flow table overflow attack without an additional control plane overhead. However, we encountered two problems to realize the intuition: how to maintain the historical statistics of each flow, and how to overcome control message increase for newly incoming normal traffic.

Firstly, to manage the flow historic statistics efficiently, we develop a 2D counting bloom filter that stores the past statistics, i.e., the number of packets for each flow during a certain amount of time. It might be a network management overhead to maintain the statistics for several flows. The proposed 2D bloom filter can manage them efficiently. Each flow is hashed in two dimensions, respectively, by the source and by the destination, and the number of packets of the flow is recorded in the 2D indexed cell. Afterward, when a flow is incoming, the flow’s statistics can be easily taken from the 2D counting bloom filter by the same hashing. Although it may have false positives like a typical bloom filter, this is ignorable because the worst case is just to adjust a wrong timeout.

Secondly, we introduced a new metric, Average Flow Duration (AFD). AFD is an average time duration in which all flow rules remain in a flow table. A newly incoming normal flow as well as an attack flow are also given a short timeout because they have no record. Even a normal flow is erased too early from the flow rule table, which causes control overhead by frequent control messages. Therefore, each flow is installed with the initial timeout based on AFD. The AFD can avoid excessive control messages caused by the early flow rule removal. AFD also works well under attack. As attack flows dominate, AFD decreases because the attack flow’s duration is short. The shortened AFD, in turn, makes the timeouts of attack flows shorter and shorter, and finally, attack flows can be removed quickly.

Figure 1 shows the overall control flow of the proposed scheme. In the proposed scheme, at first, every flow is installed with the initial hard timeout based on AFD. Once installed, the flow remains until the timeout. A controller receives a Flow_removed message for each expired flow after the timeout, which includes the duration and packet count for the flow. Then the controller updates the packet count for the flow in the 2D counting bloom filter and calculates the AFD for all the flows using the exponential moving average. The calculated AFD is the baseline of the hard and idle timeouts for new incoming flows, and the historical statistics are used for fine adjustments of the timeouts. When a new flow comes, the controller looks up the historical statistics for the flow in the 2D bloom filter and calculates the hard and idle timeouts based on the statistics and AFD and installs the corresponding rule.

The proposed scheme can mitigate the flow overflow attack without performance degradation caused by excessive control messages for flow rule installation. The paper makes the following contributions:

• We developed an algorithm that determines a history-based dynamic timeout using a 2D counting bloom filter.
• We implemented the defense system that alleviates the flow table overflow attack using the algorithm.
• We proved how effectively our scheme reduces the number of flows through comprehensive experiments in a real testbed.

2. Materials and Methods

2.1. Timeout Revisit and Intuition

2.1.1. Timeout

Prior to describing the details of our scheme, let us revisit two types of timeouts: the hard and idle timeouts in OpenFlow. A timeout defines the duration of each flow rule, i.e., how long a flow rule can remain in a flow table. The idle timeout is the number of seconds after which a flow rule is removed from the flow table because no more packets of the flow arrive. The hard timeout is the number of seconds after which a flow rule is removed from the flow table unconditionally.

If the hard timeout is non-zero, the flow rule should be removed after the given timeout regardless of the number of arrived packets in the flow. On the other hand, the idle timeout removes the flow rule only if no more packet of the flow has arrived for the idle timeout since the last packet came. We need to understand the purposes of the timeouts. The hard timeout prevents unnecessary control messages. Due to the hard timeout, a flow rule is maintained for the timeout duration even if no packets of the flow arrive. Otherwise, switches would make frequent control messages, e.g., PacketIn message in OpenFlow, which may cause overhead. The idle timeout prevents a dispensable flow rule from occupying a flow table. Similar to the hard timeout, too-long and too-short idle timeouts may cause flow table overflow and control plane overhead, respectively.

2.1.2. Intuition

This work began with the intuition that an appropriate time-out value can avoid both flow table overflow and unnecessary control traffic. Figure 2 shows the intuition. Although a shorter timeout can make more available space in a flow table, it may result in excessive rule re-installation overhead caused by unnecessary control traffic as shown in Figure 2a. In contrast, a longer timeout is more likely to overflow a flow table as shown in Figure 2b since flow rules are not removed for a long time.

The key point is how to decide the appropriate value of the timeout. Our strategy is to set a longer timeout to a more trustable flow, and we derive the index of trust from history under the assumption that a flow with more packets in the past is more trustable. Since attackers spoof a number of packets with different match fields, e.g., different source and destination IP addresses and ports, to make the rules for the flows overflow a flow table, the assumption is reasonable.

For the strategy execution, we needed a tactic, how we can get the historical information for flows, and introduced a 2D counting bloom filter. Different from an original bloom filter, the 2D counting bloom filter has two dimensions, the source and destination identifiers as shown in Figure 3 in order to distinguish each flow. Each element has 8 bits to count the number of packets. When a flow arrives, the timeout of the flow is calculated based on the packet count recorded in the 2D bloom filter.

We added one more feature that can enhance the performance, the Average Flow Duration (AFD) for timeout calculation. AFD is the average time how long flow rules stay in the flow table. Our strategy gives a new flow a short timeout, which works very well under attack. However, this might cause the rule re-installation overhead in a normal situation since a normal but new flow without any record also has a short timeout at first. The new flow is removed in a short time, which makes more control messages sent to a controller. To handle this, we introduced AFD as a base of timeout. In a normal situation, even the flow rule for a new flow remains in the flow table for a longer time because of the AFD-based timeouts, which reduce packets in messages. Let us consider when attack packets are incoming. Since the purpose of attack packets is to occupy and overflow the flow table, the number of the attack flows is high but the number of packets in each attack flow is very low, which means the duration of each attack flow is short. As the attack flows dominate, AFD decreases gradually. The attack flows have a shorter and shorter timeout, and they finally are removed from the table shortly. On the other hand, normal flows can have a relatively long timeout because they have records in the past. Therefore, the excessive rule re-installation overhead in a normal situation can be avoided.

In the next subsection, we describe the details of the proposed scheme, how this strategy is implemented and how timeouts are calculated.

2.2. Proposed Scheme

In this subsection, we describe what the components of the proposed system are and how they work.

2.2.1. Procedure Overview

For easier understanding, this subsection describes how the proposed scheme works with Figure 4 before the system design details.

• A flow comes. If there is no rule that the flow matches, the packet in the message is forwarded to the Timeout Calculation Module via the controller.
• The timeout calculation module retrieves the historical statistic of the flow from the 2D counting bloom filter.
• The timeout calculation module calculates the flow’s hard timeout and idle timeout.
• Installs the rule for the flow into the switch.
• When a flow rule expires due to the timeouts, flow-removed messages are forwarded to the Statistics Module via the controller.
• The statistics module updates AFD and the flow’s statistics.

2.2.2. System Design Details

Since the proposed mechanism is implemented as a single application over the control plane, any modifications on the OpenFlow or core modules of the SDN controller are not required. The proposed system consists of three components: 2D counting Bloom Filter, Statistics Module, and Timeout calculation module.

• 2-dimensional Counting Bloom Filter

The 2-dimensional Counting Bloom Filter is devised to store and look up the historical statistics of flows, i.e., the number of packets for each flow during a certain amount of time. An original bloom filter is a probabilistic data structure for testing whether an element is a member of a set [11]. It feeds an element to k hash functions to get k positions in an array vector and sets the bits all the positions to one. To query whether an element is a member of the set, it checks if all the positions are set to one. If they are, the element is probably in the set. Otherwise, the element is definitely not in the set. Although a conventional bloom filter provides large data storing and fast look-up, it is not suitable for flow statistics because three types of information for each flow, i.e., the sender, receiver and packet count, must be stored. Therefore, we devise a 2-dimensional counting bloom filter to manage the historical statistics efficiently. It is a 2-dimensional extension of a counting bloom filter [12].

The 2D counting bloom filter is a kind of 2-dimensional counter as shown in Figure 5. While each position of a conventional bloom filter is 1-bit, each one of the 2D counting bloom filters is more than one bit for counting. In this work, we made it 8 bits to count up to 255. One more different thing is to calculate two positions, the column index and the row index. The source and destination of a flow decide the column index and the row index by a hash function, respectively. Then the packet count of the flow is added up to the indexed position. The size of the 2D bloom filter, i.e., the numbers of columns and rows, and the number of hash functions should be calculated based on the network size, i.e., maximum current users accessing a network, and the acceptable false positive with given conditions, which is described later.

There are three operations in the 2D counting bloom filter: count, decline, and query as shown in Figure 5. The count operation is the packet number add-up process. This process records the number of packets matching a flow rule during a certain amount of time. The decline operation is called periodically and decreases the number of packets for each flow rule as time goes on. Even if a flow has 100 packets, the flow should be considered a new flow after a long period. The decline in operation reflects a reduction over time in the statistics. The query operation retrieves the statistics of the requested flow. Similar to the count operation, it calculates the column and row positions for the requested flow and obtains the number of packets at the position.

• Statistics Module

The statistic module takes charge of collecting and updating the statistics for all flows as shown in Figure 6a. After the connection is established by the handshake between a controller and switches, all flow rules are installed with a flag that makes SDN switches send a flow-removed message to the controller when flow rules expire. After a flow rule expires, the flow-removed message for the expired flow rule is forwarded to the statistics module via the controller. Then the statistics module extracts the packet count, duration, and source/destination information from the message. It updates AFD by Exponentially Weighted Moving Average (EWMA) and adds up the packet count to the corresponding position of the 2D counting bloom filter by the count operation. AFD is simply calculated as (1)

$${AFD}_{new}=\alpha \ast {AFD}_{old}+\left(1-\alpha \right)\ast duration$$

(1)

where $\alpha$  is a sensitive coefficient. The bigger $\alpha$  makes AFD more sensitive to the current expired flow. By the count operation of the 2D counting bloom filter, the statistics module also updates the historical record of the expired flow, i.e., how many packets of the flow have come so far.

• Timeout Calculation Module

When a flow rule is installed, the timeout calculation module decides both a hard timeout and idle timeout based on AFD and the statistics from the 2D counting bloom filter. It gets the record of the flow, i.e., how many packets of the flow have come so far, by the query operation of the 2D counting bloom filter. The timeouts are calculated as (2), (3)

$$T{O}_{hard}=AFD+⌈{\log }_{2}packet\_count⌉,$$

(2)

$${TO}_{idle}=⌈{\log }_2\frac{packet\_count}{AFD}⌉$$

(3)

where ${TO}_{hard}$  and ${TO}_{idle}$  are the hard and idle timeouts, respectively. In the timeout calculation, the trust level of a flow is assumed to be proportional to the logarithmic scale of the packet_count.

Consider an example that flow1 and flow2 have 1 packet and 31 packets, and flow3 and flow4 have 220 packets and 250 packets in the record, respectively. For now, because there is only one packet in flow1, we cannot rule out the suspicion that flow1 is from an attacker. On the other side, we could believe flow2 is not from an attacker because 31 packets have come so far and there has not been under attack. In this context, flow3 and flow4 can be considered safe since both of them already have more than two hundred packets. The packet count difference between flow1 and flow2 is 30, which is the same as the difference between flow3 and flow4. However, the trust level differences are not the same. While flow2 can be considered much more trustable than flow1, flow4 is not that much more trustable than flow3 because both flow3 and flow4 have already a sufficient number of packets. Therefore, it is reasonable that the logarithmically scaled packet count is added to AFD.

Since AFD is zero at the initial state of the network, we cannot calculate timeouts from (2) and (3). Therefore, the predefined values are assigned to the hard and idle timeout. Once AFD is updated, the timeout calculation module starts to calculate timeouts from (2) and (3).

According to (2), the baseline of the hard timeout is set to AFD. This gives a short hard timeout to a new (untrustable) flow. For example, if an attacker sends attack packets to a switch, the average flow duration of the network will be decreased. In this case, the hard timeout of a reliable flow could be shortened as well. To prevent this situation, the timeout calculation module determines a hard timeout by adding additional seconds to the AFD. The extra seconds logarithmically increase in proportion to the corresponding packet count. A hard timeout that will be assigned to both new normal and malicious flows is only AFD because both of them have no record. In a normal situation, AFD is not too short. If an attack occurs, the number of attack packets increases and AFD decreases gradually. Therefore, the shorter hard timeout will be set to all the flows. However, the normal flows will get a longer hard timeout due to the additional seconds as the number of incoming packets goes up. On the other hand, the attack flows with the short hard timeout will expire and be removed shortly.

After the hard timeout calculation, the timeout calculation module calculates and assigns an idle timeout to detect long packet intervals within the calculated hard timeout. The idle timeout calculation follows (3), which increases in proportion to a packet count and is inversely proportional to the average flow duration. In other words, a longer idle timeout is assigned to a flow with more historical records. shows the workflow of the timeout calculation module.

2.2.3. Consideration

We should consider how to design the 2D counting bloom filter, i.e., the numbers of rows and columns and the number of hash functions. Firstly, we can define the memory size for the 2D counting bloom filter

$$M=r\ast c\ast e$$

(4)

where the variables are defined in

Table 1. Variable definitions.

Variable Definitions
M	Memory size of a bloom filter
r	The number of rows (filter length for source address)
c	The number of columns (filter length for destination address)
e	the size of an element (# of bits for each counter)
$k_s$	# of hash functions for source address
$k_d$	# of hash functions for destination address
p	Total false positive ratio
$p_s$	False positive ratio of a row for source
$p_d$	False positive ratio of a column for destination
S	# of items for source addresses (e.g., # of source IP/port pairs)
D	# of items for destination addresses (e.g., # of destination IP/port pairs)

. The numbers of hash functions $k_s$  and $k_d$  are calculated from [11]

$$k_s=\frac{c}{s}\ast \ln 2,$$

(5)

$$k_d=\frac{r}{d}\ast \ln 2$$

(6)

If we have acceptable false-positive rations, p_s and p_d, for the row and column, the size of the bloom filter can be calculated as

$$c=⌈-\frac{s\ast \mathrm{l}\mathrm{n}\left(p_s\right)}{{\left(ln2\right)}^2}⌉$$

(7)

$$r=⌈-\frac{d\ast ln\left(p_d\right)}{{\left(ln2\right)}^2}⌉$$

(8)

We also referred to [11] to calculate the false positive ratios for source and destination addresses

$$p_s={(1-e^{{-k_s}^{s/c}})}^{k_s},$$

(9)

$$p_d={(1-e^{{-k_d}^{d/r}})}^{k_d},$$

(10)

$$p=p_s\ast p_d$$

(11)

Since these variables affect each other, we began the 2D counting bloom filter design with a given memory size M because the cost is one of the important factors. For performance evaluation, we assume the limited memory size M is 12M bytes and set both false positive ratios, $p_d$  and $p_s$  for the row and column to 0.1. Each counter size e is 8-bit. Finally, we assume the number of destination IP/port pairs d is 256, which decides the row size r by Equation (8). We can get the column number c from Equation (4). The number of possible source IP/port pairs s is calculated from Equation (7). Then we can get the required number of hash functions, $k_s$  and $k_d$ , from Equations (5) and (6). We set the parameters for the bloom filter as shown in

Table 2. Parameters of bloom filter.

Parameters	Value
Number of counters (r × c)	1248 × 9248
Counter size (e)	8-bit
Number of ash functions ($k_s$)	3
Number of hash functions ($k_d)$	3
Probability of false positive ($p_s$ and $p_d$)	0.1

for the performance evaluation.

2.3. Evaluation Method

In this subsection, we explain the experimental environments and attack scenarios. Then we show the experiment results and analysis.

2.3.1. Experimental Setup

We set up a simple experimental network implemented with several virtual machines in a single physical computer. Figure 7 represents the network topology. For the simplicity of the experiment, there are only four virtual machines. One is a Ryu controller that runs the proposed scheme as an application. The other one is an Open vSwitch (OVS, Open vSwitch v2.17.0). An attacker and a normal host are connected to the OVS.

We experimented in four different experimental environments with this experiment topology.

Table 3. Evaluation Environment.

	Hard Timeout	Idle Timeout
Environment 1 (Proposed Scheme)	Dynamic	Dynamic
Environment 2	None	10 s
Environment 3	10 s	5 s
Environment 4 (FTGuard)	None	None

shows the four environments. Environment 1 runs the proposed scheme which calculates the hard and idle timeouts based on the historical statistics. In Environment 2 and 3, the timeouts are set statically. Environment 2 uses the default timeout policy of Ryu controller, which sets no hard timeout and 10 s idle timeout. The only difference between Env 2 and Env 3 is that Env 3 assigns the idle timeout and hard timeout on a single flow rule at the same time. Env 3 shows that using both timeouts simultaneously is more effective than the existing timeout methods in terms of flow table management. Finally, Environment 4 runs FTGuard [8] which protects flow tables from attacks.

2.3.2. Attack Emulation

To emulate a flow table overflow attack, we made and ran a script in the attacker. The script generates packets and sends them to the OVS to overflow the flow table. We also used a pre-captured pcap file to replay non-attack flows. The entire process of the experiment is as follows:

• Host 1 replays captured packets [13] to emulate normal flows.
• While Host 1 is sending packets, the attacker generates packets with random source/destination IP addresses and ports and sends them to a victim. We used Scapy v.2.5.0, a python library, to generate packets.
• As time passes, flow rules are installed in a flow table with timeouts. In the case of attack flow rules, they have a particular cookie to be distinguished by the controller.
• During this flow rules installation process, the controller receives Flow_removed messages [14]. Using the information in the messages, the controller updates the bloom filter.
• The controller records the number of flow rules periodically via aggregate flow statistics request message. The controller is aware of which flow rule is attack flow because all attack flow has a particular cookie in our experiment.

3. Results

3.1. The Number of Flow Rules

In the experiment, the number of flow rules in a victim switch is the most important metric to evaluate the performance of the proposed scheme. The smaller number of flow rules means more effective mitigation against flow table overflow attacks.

The controller sends the statistics request message ofp_flow_stats_request to the OVS periodically and collects the number of flow rules.

Figure 8 and Figure 9 represent the number of normal flow rules and that of attack flow rules, respectively.

3.2. Bandwidth

Because the Statistics Module in the proposed scheme sends messages to keep track of per-flow packet count, it could consume more bandwidth than other schemes. However, in fact, we can see that the proposed scheme takes just a few hundred KiB/s more bandwidths than the others through

Table 4. Bandwidth measurement while the experiment.

	Environment 1	Environment 2	Environment 3	Environment 4
Bandwidth consumption	RX: 302 KiB/s	RX: 184 KiB/s	RX: 190 KiB/s	RX: 451 KiB/s
	TX: 344 KiB/s	TX: 320 KiB/s	TX: 328 KiB/s	TX: 189 KiB/s

, which shows that the overhead does not affect the network performance.

4. Discussion

4.1. Related Works

A Denial of Service (DoS) attack is addressed as a severe issue for SDN. Although there have also been DoS attacks in traditional networks, the centralized control feature makes SDN more vulnerable to DoS attacks. Despite the simplicity of a DoS attack, it can cause critical problems like buffer saturation, flow table overflow, congestion of the control data plane channel, and controller saturation [15]. This paper concentrates on a flow table overflow attack since this attack can be easily launched by an attacker.

Because of the seriousness of a DoS attack, various countermeasures to mitigate the table overflow attack have been proposed. The authors of [16] proposed a scheme that detects an attacker and limits the attack rate using a token bucket. The scheme considers a complicated topology and an attack case where the attacker uses a victim as a middle hop. In the scheme, a controller predicts a potential target of the attack after a switch registration phase. It derives virtual graphs that are composed of a switch and paths that use the switch as a middle hop from the network topology. If the degree of the virtual graph is bigger than one, the switch of that virtual graph is treated as a potential target. Then it monitors the potential target using three predefined traffic features. If the attack is detected, the controller creates a token bucket. Then every time a switch that is connected with an attacker host tries to use a victim as a middle hop, the controller removes a token in the bucket. In the case of [9], when an attack occurs, it diverts attack traffic to adjacent switches of a victim.

Ref. [8] calculates per-flow scores according to some predefined features. Then the eviction process is performed in the order of importance. Ref. [4] takes a similar method to [14]. It first filters forged packets, and then it assigns importance to flow rules according to some predefined features. Then it makes a victim switch to drop or rate-limit malicious flow for a period. Ref. [8] relies on the OpenFlow eviction mechanism. Since the eviction mechanism starts to work when a flow table is full, this could be less effective. Ref. [4], however, resolved this problem by defining a countermeasure according to flow importance. But, it requires additional configuration depending on network environments.

Our work was inspired by some research utilizing dynamic timeouts [5,6,7,17]. Timeout, a basic component of OpenFlow, determines when a flow entry should be removed in a flow table. Most SDN controllers use a static value for a default timeout. Instead of the static timeout, their basic approach is to secure the flow table storage by shortening the timeout of attack flows.

L. Zhang et al. proposed an AHTM that optimizes hard timeout using the mathematically analyzed truncated times and blocking probability [17]. The Intelligent Timeout Master in [5] and a scheme in [7] add a cache module in the controller. They cache a flow rule with a timestamp and its timeout value after the flow rule expires. Then if the same flow triggers a packet in an event, the controller assigns a new timeout value using the information in the cache. Unlike other pieces of research mentioned above, [6] uses both hard timeout and idle timeout, but not simultaneously. In the case that a flow is too short or does not have sufficient history, or the flow table is almost overflowed, the controller assigns a hard timeout to the flow. Otherwise, it assigns an idle timeout.

The existing studies using the dynamic timeout use either the hard timeout or the idle timeout. The hard timeout is set to reduce unnecessary control traffic by maintaining flow rules for a certain duration, and the idle timeout is used to remove unused flow rules. Because the purposes of hard and idle timeout are different, it is not efficient to use only one type of timeout. Therefore, we propose a new scheme that adjusts both hard and idle timeouts dynamically and simultaneously.

Many researchers have brought ML/DL techniques to address DoS attacks in SDN [18,19] or P4 switch [20] recently. Although ML/DL techniques are very powerful and effective, they require heavy computational power and a good dataset to properly train the model as well. According to [21], the ML/DL for intrusion detection/prevention system still has several problems to solve. For instance, [22,23] showed either not enough performance or remarkable accuracy with a high false positive ratio. Since ML/DL-based techniques in the research area tend to take eviction mechanisms against the attack flow rules, a high false positive ratio is fatal. On the other hand, our proposed scheme is very lightweight and easy to scale due to its simplicity. The P4 switch has brought evolution in various fields of SDN. Moving some control logic back to the data plane again could solve the single point of failure problems and mitigate DoS attacks.

Recently, researchers have shown interest in applying ML techniques to deal with slow-rate flow table overflow attacks [18,23]. In particular, the authors of [18] showed that their proposed scheme can mitigate the attack with high real-time performance and timely response. However, their result shows that the scheme has higher flow table utilization than normal even though the proportion of the attack flows is decreased. This is because of the proportional eviction mechanism based on the detection result and it harms the efficiency of the network. Meanwhile, our scheme keeps 85% of the normal flow rules compared to the environment with hard timeouts and shows a low ratio of the attack flow rules. This means that it can maximize the flow table utilization by making the attack flow rules expire much faster than the normal rules while it effectively mitigates the flow table overflow attack as well.

Table 5. Comparison Table of related work.

	Domain	Solution/Techniques	Timeout Usage
[4]	SDN-aimed DoS	Source address validation/stateful packet monitoring	-
[5]	Efficient Timeout for Data Centers	Caching flow rules, dynamic timeout	Idle timeout only
[6]	Flow Table Overflow Attack	Categorizing flows and applying hard or idle timeout based on the categories	Hard timeout or Idle timeout
[7]	Efficient Flow Table Utilization	Caching flow rules, proactive eviction	Idle timeout only
[8]	Flow Table Overflow Attack	Proactive evicting based on the flow rule priority	-
[9]	SDN-aimed DoS	Dynamic monitoring/detouring	-
[16]	Flow Table Overflow Attack	Identifying possible victim switch and applying rate limiting	-
[17]	Efficient Flow Table Utilization	Optimized timeout based on the mathematical modelling	Mainly hard timeout
[18]	Flow Table Overflow Attack	Prediction/eviction/scoring flow rules with Machine Learning	-
[19]	DDoS in SDN	Deep Learning with LSTM + Autoencoder model	-
[20]	Flow Table Overflow Attack	Moving monitoring/mitigation logic to data plane using P4 Switch	-
Proposed Scheme	Flow Table Overflow Attack	Dynamic timeout based on the flow history	Hard timeout and Idle timeout

summarizes the research domain, solution, techniques, and timeout usage of the related works.

4.2. Evaluation

Through Environment 2 in Figure 8 and Figure 9, we can see that installing flow rules with only idle timeout keeps the most flow rules and attack flow rules as well. Because Environment 2 does not consider which flow rule is the most useless or suspicious, it allows even the attack flow rules to reside in the flow table. This characteristic may easily cause flow table overflow. Meanwhile, Environment 3 assigns a hard timeout and idle timeout on a flow rule to tackle the problem of Environment 2 according to our intuition. By setting both kinds of timeout simultaneously, we receive a more improved result than Environment 2. However, setting timeouts with a static value does not bring a satisfactory result because it still does not consider whether each flow rule is reliable or not. However, our proposed scheme assumes that a flow rule is dependable or not based on historical information. By doing so, Environment 1 could get rid of most of the attack flow rules from the flow table while sustaining the normal flow rules.

5. Conclusions

In this paper, we propose a new scheme called HSDT for mitigating flow table overflow attacks. We revisited the timeouts and utilized dynamic timeouts to remove attack flows from a flow table as quickly as possible. The appropriate timeouts are dynamically set up based on historical statistics, for which we devised the 2D counting bloom filter. The experiment results showed that the proposed scheme can mitigate the flow table overflow attack efficiently with reasonable overhead.

One of the major concerns about our proposed scheme is its memory efficiency problem coming from the nature of the bloom filter. Since the proposed scheme expands the data structure into two dimensions to abstract the history of network flows, it suffers from severe memory consumption problems. However, our proposed scheme is designed for the SDN environment. Hence, we can take advantage of its virtualized/distributed characteristic. In other words, we can deploy multiple SDN controllers that take control of small cells. A framework multi-layered with our proposed scheme would be our future research.