Protection against Flow Table Overflow Attack in

Software Defined Networks

Sichul Kevin Noh1 , Minjae Kang2 , and Minho Park∗1,2
1
Department of Information Communication, Materials, and Chemistry Convergence Technology,
2021 International Conference on Information Networking (ICOIN) | 978-1-7281-9101-0/20/$31.00 ©2021 IEEE | DOI: 10.1109/ICOIN50884.2021.9333889

Soongsil University, Seoul 156-743, South Korea

2
School of Electronic Engineering, Soongsil University, Seoul 156-743, South Korea
scn@soongsil.ac.kr,minjaekang@ssu.ac.kr,mhp@ssu.ac.kr

Abstract—In this paper, we propose a history-based dynamic
timeout scheme to alleviate the flow table overflow attack which is
one of typical attacks against Software Defined Networks (SDN).
We investigated hard timeout and idle timeout used in OpenFlow
which is the most popular protocol for SDN, and developed the
proposed scheme that dynamically adjusts both hard timeout and
idle timeout to reduce the number of flow rules. The experiment
results shows it can protect SDN switches from the flow table
overflow efficiently.
Index Terms—Software-Defined Network, Flow Table Over-
flow, Dynamic Timeout.
I. I NTRODUCTION
As a network getting advanced, a new network architecture
has appeared, Software-defined Network (SDN). Unlike a
traditional network, SDN network can be divided into three
layers; application layer, control layer, and the data layer. The
control layer is a logically centralized controller managing the
whole network by installing rules into the data layer. The data
layer is the others just forwarding packets according to the
rules. The data layer has to inquire controller where to forward
an arrived packet if the packet does not match any of the rules.
Lastly, the application layer is where SDN applications work.
SDN brings about a lot of advantages. Because the centralized
controller takes charge of routing computation, the data plane
can concentrate on forwarding packets. The programmability
of SDN and decoupled structure makes managing and chang-
ing a network much more flexible. The controller can handle
frequently changing network topology and deploy flow rules
that are suitable at that time.
Because of the structural difference between traditional
network and SDN, existing security solutions are not suitable
for SDN. In addition, SDN also has some problems that cannot
be ignored. Those have continuously been addressed by other
researches. One of the problems is the limited capabilities of
SDN switches. SDN switches use TCAM(Ternary Content-
Addressable Memory) as a device for a flow table. Because
TCAM is expensive and has high power consumption, the
memory capacity of SDN switches is limited. So the storage
for flow table is targeted by malicious attackers. When many
flow rules caused by a lot of traffic overflows the memory
capacity, incoming packets of new flows will be dropped.
Then this will lead to a denial of service and performance
∗ Corresponding author
degradation [12]. To prevent incoming packets from being
dropped, OpenFlow [4] that is the most common SDN protocol
supports a flow eviction mechanism since version 1.4.0. It
makes switches able to automatically remove flow rules with
low importance when the flow table is full.
OpenFlow produces new flow rules for corresponding flows
and processes packets according to rules. Therefore insuf-
ficient memory capacity for the flow table may cause an
overflow. In the same context, this kind of DoS attack can be a
significant threat to SDN. Although the DoS attack is simple,
it may affect not only switch also a communication channel
between switch and controller or computational resource of
the controller. In other words, it can affect whole network
performance in the SDN environment. Furthermore, low rate
DDoS having a broad IP address range is more threatening
since low rate DDoS is hard to distinguish with naive traffic.
To protect SDN networks from the flow overflow attack, We
propose a history-based dynamic timeout that can effectively
reduce the number of flow rules. The intuition is simple.
Because a flow having more packets in the past is less
suspicious, a long timeout is given to the flow. On the other
hand, a flow having less packet is given a short timeout since
it might be from an attacker.
A long timeout avoids unnecessary traffic between a con-
troller and switches, and a short timeout reduces the number
of flows that unnecessarily occupy the flow table. To manage
the flow history efficiently, we develop a 2D counting bloom
filter that stores the past statistics, i.e., the number of packets
of each flow for a certain amount of time. We also propose
a dynamic timeout adjustment mechanism that determines
both hard timeout and idle timeout according to the historical
statistics. In our scheme, at first, every flow is installed with
static timeouts. Then a controller derives flow duration and
packet count from each Flow removed message. Packet count
should be saved in the bloom filter at this time and the
controller calculate average flow duration using Exponential
Moving Average. Once an average flow duration is calculated,
the controller starts to install flow rules with a dynamic
hard/idle timeout computed according to the packet count
of corresponding flow. With the dynamic timeouts based on
historical statistics, the proposed scheme can protect SDN
switches from the overflow attack efficiently.

978-1-7281-9101-0/21/$31.00 ©2021 IEEE 486 ICOIN 2021

Authorized licensed use limited to: UNIVERSITY OF WESTERN ONTARIO. Downloaded on May 25,2021 at 15:10:07 UTC from IEEE Xplore. Restrictions apply.
 II. R ELATED W ORK
A. Denial of Service Attack
A Denial of Service(DoS) attack is addressed as a severe
issue for SDN. A DoS attack has been around since traditional
networks, but centralized control of SDN makes SDN more
vulnerable to DoS attack. Despite its simplicity, it can cause
many critical problems like buffer saturation, flow table over-
flow, congestion of control-data plane channel, and controller
saturation [5]. Moreover, these may occur simultaneously.
Once these occur, the performance of the entire network
decrease, and also the whole network may even stop working.
In this paper, we concentrated on a flow table overflow attack
that is a kind of DoS attack.
B. Flow Table Overflow Attack
Because of the seriousness of a DoS attack, a lot of
papers about mitigating DoS attack or table overflow attack
have been published. We classify those researches into two
categories by approach: dynamic timeout method, and others.
1) Dynamic Timeout Method: Timeout is a basic compo-
nent of OpenFlow and many SDN controllers use a static
value for a default timeout. The fixed timeout brings some
problems like flow table overflow, so there has been very
much research to mitigate flow table overflow using a dynamic
timeout method [6] – [9].
L. Zhang et al. proposed AHTM that optimizes hard timeout
using the analyzed truncated times and blocking probability
[6]. Intelligent Timeout Master in [7] and a scheme in [9]
adds a cache module in the controller. They cache a flow rule
with a timestamp and its timeout value after the flow rule
expired. Then if the same flow triggers a packet in event, the
controller assigns a new timeout value using the information in
the cache. Unlike other researches mentioned above, [8] uses
hard timeout and idle timeout both, but not simultaneously.
In case of that a flow is too short or doesn’t 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.
2) Other Methods: There were also many other studies
that do not use the dynamic timeout method [10] – [13].
The author of [10] proposed a scheme detecting an attacker
and limiting attack rate using a token bucket. It considered a
complicated topology and attack case that 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.
Then it monitors the potential target using three predefined
traffic features. If the attack is detected, the controller creates
a token bucket. And 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
[11], when an attack occurs it diverts attack traffic to adjacent
switches of a victim. And [13] calculates per-flow scores
according to some predefined features. Then the eviction
process would be performed in the order of importance. [12]
487
Authorized licensed use limited to: UNIVERSITY OF WESTERN ONTARIO. Downloaded on May 25,2021 at 15:10:07 UTC from IEEE Xplore. Restrictions apply.
Fig. 1: System Design
takes a similar method to [13]. It first filters forged packets,
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. [13], however, relies
on the OpenFlow eviction mechanism. Since the eviction
mechanism starts to work when a flow table is full, this could
be less effective. [12] resolved this problem by defining a
countermeasure according to flow importance. But it requires
additional configuration depending on network environments.
Existing studies that are using a dynamic timeout method
use either a hard timeout or idle timeout. Assigning only a
hard timeout can block new flows to be installed when a
network burst occurs. On the other hand, assigning only an idle
timeout could be inefficient because calculating the exactly
fitting timeout is not easy. So we introduce our new scheme
that can mitigate table overflow attack during also handle the
timeout problem we mentioned above.
III. P ROPOSED SCHEME
In this section, we propose a new scheme to calculate hard
and idle timeouts dynamically using historical statistics.
A. System Design
Our scheme is implemented as a single application over the
control plane so that additional modifications on the Openflow
or core modules of SDN controller are not required. The
proposed scheme consists of three modules: Statistics Module,
Timeout Calculation Module, and 2D counting Bloom Filter.
1) Statistics Module: As we mentioned above, the proposed
scheme needs to collect and keep historical statistics. For this
reason, the statistic collect module takes charge of collecting
statistical information and updating the corresponding. After
the stage of a handshake between a controller and switches,
all flow rules will be installed with a flag that makes switches
to raise a flow removed message when flow rules expire.
If the controller receives a flow removed message, the
statistic collect module extracts packet-count, duration, and
source/destination information from the message. Then it
updates the average flow duration according to Exponential
Moving Average and records the packet-count in the bloom
filter using the source/destination information. We used
source MAC and destination MAC in our experiment. By
using the exponential moving average to update average flow
duration, we can expect that average flow duration becomes
more sensitive to a recent change of the network.
Algorithm 1: Statistic Collect Module
Input: AFD
1 msg ← F low Removed
2 src ← msg.src
3 dst ← msg.dst
4 dur ← msg.dur
5 count ← msg.packet count
6 update AFD with dur
7 update bloom filter with src, dst, count
2) Timeout Calculate Module: The timeout calculate mod-
ule calculates both a hard timeout and idle timeout using the
average flow duration and packet-count from the bloom filter.
The equation for calculating timeouts is as follows:
T H = AF D + log2 (packet count)
 
packet count
T I = log2 ( ) (2)
AF D
where TH is hard timeout, TI is idle timeout, and AFD is
average flow duration. At the initial state of the network, an
average flow duration is zero. Therefore, we cannot calculate
timeouts with (1) and (2). For this reason, predefined values
are assigned to the hard and idle timeout. Once the average
flow duration is updated, the timeout calculate module starts
to calculate timeouts with formulas equation 1 and equation 2.
According to equation 1, a hard timeout uses the average
flow duration as its baseline. This makes a hard timeout able
to assign a short hard timeout to a new and unreliable 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, a hard timeout of a relible flow could be shortened as
well. To prevent this situation, the timeout calculate module
determines a hard timeout by adding additional seconds to
the average flow duration. The extra seconds logarithmically
increase in proportion to corresponding packet-count. We can
expect that nearly the same value as the average flow duration
will be assigned to new and malicious flows. Because the
average flow duration decrease when an attack occurs, the
shorter hard timeout will be set to new flows.
After the hard timeout calculation, the timeout calculate
module calculates and assigns an idle timeout to detect
long packet interval within the calculated hard timeout. The
idle timeout calculation follows equation 2 that increases in
Authorized licensed use limited to: UNIVERSITY OF WESTERN ONTARIO. Downloaded on May 25,2021 at 15:10:07 UTC from IEEE Xplore. Restrictions apply.
proportion to a packet-count and inversely proportional to the
average flow duration. In other words, a longer idle timeout
is assigned to a flow with more historical records.
Algorithm 2: Timeout Calculate Module
Input: AFD, packet count
Output: TH , TI
1 if packet count == 0 then
2 T H ← AF D + 0
3 else
4 T H ← AF D + log2 (packet count) + 1
5 t = packet count / AFD
6 if t ≤ 1 then
7 TI ← 1
8 else
9 T I ← log2 (t)
10 return TH , TI
3) 2-dimensional Counting Bloom Filter: A bloom filter is
a probabilistic data structure for testing whether an element
is a member of a set. It adds an element to a position of the
set calculated by several hash functions. To query whether an
(1) element is a member of the set, we need to check that all
positions are set to one. If they are, that element is probably
in the set otherwise, the element is definitely not in the set.
We utilized a bloom filter to store the historical statistics
because of its space-efficiency and fast look-up speed for
large data. However, the usual bloom filter could not store
our desired data since we express a flow with two keys; a
source and destination of the flow. Therefore, We extended a
counting bloom filter to 2-dimensional so that we can store
and query per-flow value by defining rows and columns of
the bloom filter as source MAC and destination MAC.
In short, our bloom filter has m*n buckets and each bucket
consists of 8-bit. And we used source/destination MAC as a
key to select a bucket for packet count.
IV. E VALUATION
We implemented the proposed scheme using a Ryu con-
troller in a virtual machine. To test the proposed scheme
properly keep the number of flow rules low under the DoS
attack, we recorded the number of flow rules and bandwidth
between a controller and a switch that is a target of the attack.
The topology of an experiment network is like Fig. 3 and the
process of the experiment is as follows:
i) one of the hosts replay captured packets [14].
ii) another host, an attacker, generates packets that have
random source/destination IP/MAC address and forward
them to a victim a little after the replay begins. We used
Scapy, a python program, to generate packets.
488
 Fig. 2: 2D Counting Bloom Filter
Fig. 4: The number of normal flows over time

Fig. 3: Experiment Topology

iii) the controller records the number of flow rules peri-

odically. The controller can be aware of which flow
rule is normal or DoS flow because all DoS flow has a
particular destination MAC address in our experiment.
We experimented with four different environments and each Fig. 5: The number of DoS flows over time
environment is detailed in Table I.

1) The number of flow rules: Because Statistics Module in the proposed scheme sends
The number of flow rules is the most important parameter messages to keep track of per-flow packet count, it could
to monitor whether the proposed scheme successfully alle- consume much more bandwidth than other schemes. In fact,
viates a table overflow attack. We made the controller issue however, we can see that the proposed scheme takes just a few
ofp flow stats request message periodically and log the reply hundred KiB more bandwidths than the others through Table
for the experiment. II.
Through Environment 2 in Fig. 4 and Fig. 5, we can see that
installing flow rules with only idle timeout keep the most flow
rules and DoS flow rules either. To alleviate this ineffectiveness Hard Timeout Idle Timeout
we set a hard timeout to 10 seconds and reduce an idle timeout Environment 1
to 5 seconds for Environment 3 by our intuition. By setting 1∼10 1∼8
(Propose Scheme)
both kinds of timeout simultaneously, we got a more improved Environment 2 None 10
result than Environment 2. However, setting timeouts with Environment 3 10 5
a static value doesn’t bring a satisfactory result because it Environment 4
doesn’t consider whether each flow rule is normal or not. None None
(FTGuard)
Fig. 4 and Fig. 5 shows that the proposed scheme outper-
formed the other environments. The proposed scheme effec- TABLE I: Evaluation Environments
tively reduced the number of DoS flow rules while it keeps
the number of normal flow rules at an appropriate level. It is Environment 1 Environment 2 Environment 3 Environment 4
also better than FT Guard in terms of the number of DoS flow Bandwidth RX: 304 KiB RX: 184 KiB RX: 190 KiB RX: 451 KiB
under attack TX: 344 KiB TX: 320 KiB TX: 328 KiB TX: 189 KiB
rules.
2) Bandwidth: TABLE II: Bandwidth Measurement under DoS attack

489

Authorized licensed use limited to: UNIVERSITY OF WESTERN ONTARIO. Downloaded on May 25,2021 at 15:10:07 UTC from IEEE Xplore. Restrictions apply.
 V. C ONCLUSION [13] Zhang, M., Bi, J., Bai, J., Dong, Z., Li, Y., & Li, Z. (2017). Ftguard: A
priority-aware strategy against the flow table overflow attack in sdn. In
In this paper, we propose a new scheme mitigating flow Proceedings of the SIGCOMM Posters and Demos (pp. 141-143).
table overflow attack. We address that using either timeout [14] Retrieved from https://s3.amazonaws.com/tcpreplay-pcap-
can cause some problems and propose using both. Next, we files/bigFlows.pcap
develop an application to assign proper dynamic timeouts
to flows by calculating based on the per-flow packet count.
The results of our experiments demonstrate that our proposed
scheme reduces the number of flow rules properly under the
DoS attack.
ACKNOWLEDGMENT
This work was partly supported by the National Research
Foundation of Korea(NRF) grant funded by the Korea govern-
ment(MSIT) (No. 2020R1F1A1076795), and by Institute for
Information & communications Technology Promotion(IITP)
grant funded by the Korea government(MSIT) (No.2018-0-
00254, SDN security technology development).
R EFERENCES
[1] Scott-Hayward, Sandra, Gemma O’Callaghan, and Sakir Sezer. ”SDN
security: A survey.” 2013 IEEE SDN For Future Networks and Services
(SDN4FNS). IEEE, 2013.
[2] Chica, Juan Camilo Correa, Jenny Cuatindioy Imbachi, and Juan Felipe
Botero. ”Security in SDN: A comprehensive survey.” Journal of Network
and Computer Applications (2020): 102595.
[3] Chuang, Ching-Chih, et al. ”Minimization of TCAM usage for SDN
scalability in wireless data centers.” 2016 IEEE Global Communications
Conference (GLOBECOM). IEEE, 2016.
[4] Open Networking Foundation, Openflow Switch Specification(2014),
http://www.opennetworking.org
[5] Ubale T., Jain A.K. (2020) Survey on DDoS Attack Techniques and
Solutions in Software-Defined Network. In: Gupta B., Perez G., Agrawal
D., Gupta D. (eds) Handbook of Computer Networks and Cyber Secu-
rity. Springer, Cham
[6] L. Zhang, R. Lin, S. Xu and S. Wang, ”AHTM: Achieving efficient
flow table utilization in Software Defined Networks,” 2014 IEEE Global
Communications Conference, Austin, TX, 2014, pp. 1897-1902, doi:
10.1109/GLOCOM.2014.7037085.
[7] H. Zhu, H. Fan, X. Luo and Y. Jin, ”Intelligent timeout master: Dynamic
timeout for SDN-based data centers,” 2015 IFIP/IEEE International
Symposium on Integrated Network Management (IM), Ottawa, ON,
2015, pp. 734-737, doi: 10.1109/INM.2015.7140363.
[8] B. Sooden and M. R. Abbasi, ”A Dynamic Hybrid Timeout Method
to Secure Flow Tables Against DDoS Attacks in SDN,” 2018 First
International Conference on Secure Cyber Computing and Communi-
cation (ICSCCC), Jalandhar, India, 2018, pp. 29-34, doi: 10.1109/IC-
SCCC.2018.8703307.
[9] X. Li and Y. Huang, ”A Flow Table with Two-Stage Timeout Mechanism
for SDN Switches,” 2019 IEEE 21st International Conference on High
Performance Computing and Communications; IEEE 17th International
Conference on Smart City; IEEE 5th International Conference on Data
Science and Systems (HPCC/SmartCity/DSS), Zhangjiajie, China, 2019,
pp. 1804-1809, doi: 10.1109/HPCC/SmartCity/DSS.2019.00248.
[10] T. Xu, D. Gao, P. Dong, C. H. Foh and H. Zhang, ”Mitigating
the Table-Overflow Attack in Software-Defined Networking,” in IEEE
Transactions on Network and Service Management, vol. 14, no. 4, pp.
1086-1097, Dec. 2017, doi: 10.1109/TNSM.2017.2758796.
[11] G. Shang, P. Zhe, X. Bin, H. Aiqun and R. Kui, ”FloodDefender:
Protecting data and control plane resources under SDN-aimed DoS
attacks,” IEEE INFOCOM 2017 - IEEE Conference on Computer
Communications, Atlanta, GA, 2017, pp. 1-9, doi: 10.1109/INFO-
COM.2017.8057009.
[12] M. Zhang, J. Bi, J. Bai and G. Li, ”FloodShield: Securing the SDN
Infrastructure Against Denial-of-Service Attacks,” 2018 17th IEEE In-
ternational Conference On Trust, Security And Privacy In Computing
And Communications/ 12th IEEE International Conference On Big Data
Science And Engineering (TrustCom/BigDataSE), New York, NY, 2018,
pp. 687-698, doi: 10.1109/TrustCom/BigDataSE.2018.00101.

490

Authorized licensed use limited to: UNIVERSITY OF WESTERN ONTARIO. Downloaded on May 25,2021 at 15:10:07 UTC from IEEE Xplore. Restrictions apply.