FEAROL: Aging Flow Entries Based on Local Staircase Randomized Response for Secure SDN Flow Tables

Abstract

Software-Defined Networking (SDN) systems are sensitive to the lifespans of flow entries in flow tables as such lifespans affect the overall network-forwarding latency and the flow table space usage, particularly when the systems are under cyber attack. Instead of developing extra approaches to reactively detect the attacks and mitigate the impact of the attacks, this paper views the lifespans of flow entries as the privacy of the SDN systems and proposes a Flow-Entry Aging RandOmization Layer (FEAROL), which applies the staircase randomized response mechanism in the flow-entry-aging process at switches. FEAROL locally perturbs the lifespan of each flow entry in the flow table. Since the true lifespan of each flow entry is different from the lifespan set in the entry by the controller and dynamically perturbed by FEAROL, Low-rate Denial-of-Service (LDoS) attacks based on the sniffed flow-entry timeouts cannot be effectively organized. FEAROL proactively prevents LDoS attacks from overflowing the flow tables and legitimate flow packets from being dropped due to the broken synchronization between attack flows and the network settings. FEAROL can adjust its aging policies and privacy budget based on the real-time monitored network performance. FEAROL is prototyped in an open-source soft switch (OpenVSwitch) and evaluated through simulations on real network traces. The results show that FEAROL increases the overhead of aging a flow entry. However, this overhead can be significantly reduced by adjusting the interval at which the aging process is triggered. FEAROL also effectively defends against flow table overflow LDoS attacks by significantly reducing the table usage of LDoS attack flows. When the aging strategy is carefully chosen, the table space used by attack flow entries can be reduced to 0.

1. Introduction

Network infrastructure and service providers require a highly manageable network architecture to support communications flexibility and application innovation. Software-Defined Networking (SDN) meets these needs by providing a layered architecture with separate control and data planes, between which the open and standardized interfaces are provided to enable the interaction between the planes. Such properties make the SDN controllers in the control plane easier to abstract the underlying topology globally and program the network functionalities dynamically. However, as shown in Figure 1, they also raise serious security concerns for SDN systems—for example, the logically centralized controllers in the control plane, the centralized data collection and policy enforcement mechanisms between the two planes and the resource limitations in SDN switches that open the door to cyber attacks, such as Denial-of-Service (DoS) attacks [1]. Current research has focused on improving the security of centralized SDN controllers and mechanisms [2], and this work targets the security of flow tables in SDN switches.

Flow tables are the places where SDN switches maintain the forwarding rules used to process the packets they receive. The forwarding rules, also known as flow entries, are typically generated by SDN controllers and installed on the switches in a reactive manner, since switches in the data plane are “dumbs” with no “brains”. SDN switches typically store flow tables in their Ternary Content Addressable Memory (TCAM). As TCAM is expensive and power hungry, TCAM has limited space.

Since SDN systems need to enable flow-based entries to provide network flexibility, while the number of flows in SDN systems increases as things increasingly join the networks, it is difficult for an SDN switch to maintain the fine-grained flow entries for all received flow packets. Therefore, SDN systems enforce each flow entry in the flow table to have a lifespan defined by the flow-entry timeouts to better utilize the flow table space [3].

Flow-entry timeouts are extremely critical for SDN systems, because they determine the lifespan of flow entries, which significantly affect the flow table space utilization and the network-forwarding latency. SDN systems typically enable a flow setup procedure in which the controller reactively generates and installs an appropriate flow entry for each new flow in the network. This procedure is triggered by a flow-entry-lookup miss at a switch and adds an extra flow setup delay that increases the overall network-forwarding latency [4].

In current SDN systems, a flow-entry-lookup miss can occur in three typical cases: (1) the received packet belongs to a new flow that has never appeared on the network; (2) the received packet belongs to an old flow that has appeared on the network but its matching flow entry has been removed from the flow table due to the timeout; and (3) the received packet belongs to an old flow but its matching flow entry has never been installed due to lack of flow table space. Although case (1) can be avoided by generating and installing flow entries proactively, cases (2) and (3) are strongly influenced by the flow-entry timeouts set by the controllers when the flow entries are created.

Although current research has made great efforts to optimize flow-entry management and timeouts and to achieve a low network-forwarding latency under the constraints of flow table space, such approaches are often designed for normal SDN systems without considering possible cyber attacks [5]. Since flow tables are a critical resource in SDN systems, they have become one of the potential targets for attacks. For example, flow tables can be flooded by the DoS attacks, which use one or more sources to send a large volume of flow packets to a target SDN switch during a very short period of time [6], resulting in cases (2) and (3) and causing the legitimate flow packets to be dropped and significantly increasing the network-forwarding latency.

Since the DoS attacks are often accompanied by the rapidly and significantly increased network packet rate, they can be detected quickly and accurately. Therefore, Low-rate Denial-of-Service (LDoS) attacks, which are not sensitive to the existing DoS attack detection techniques, were developed to attack networks in a “hidden” manner [7].

Typical LDoS attacks aim to significantly increase the network-forwarding latency by using low-rate pulse packets to periodically attack the network adaptive mechanisms, such as the congestion control in TCP protocols [8], the keepalive mechanism in HTTP protocols [9], border router buffers [10] and application server queues [11], instead of flooding the entire network in the DoS attacks. In SDN systems, flow-entry timeouts are the network settings that can be adjusted by the controllers. Therefore, LDoS attacks can exploit them to overflow the flow tables and degrade the network performance.

Typical flow table overflow LDoS attacks must first sniff the flow-entry timeouts of the target switch and then generate the attack flows to overflow the switch’s flowTable [12]. The attack flows used in such LDoS attacks can be the long flows that have a packets inter-arrival time is shorter than the configured flow-entry timeout. Although such flow table overflow LDoS attacks make the overall network packet rate only slightly higher than the normal networks without the attack, the attack flows can occupy most of the flow table space to significantly increase the likelihood of case (3).

Although current research has proposed some approaches to detect such LDoS attacks and alleviate the flow table space shortage under attack, such approaches typically work in attacked networks and often suffer from poor efficiency and accuracy in many network scenarios because attack flows can mimic the flows that periodically monitor the status of devices in today’s cloud data centers [13], Internet of Things (IoT) and Industry IoT Networks [14].

Instead of reactively detecting LDoS attacks and mitigating the flow table space shortage, this paper proposes a proactive approach that considers the lifespans of flow entries as the privacy of SDN systems and applies the local staircase randomized response to the aging process of each flow entry, so that the true lifespans of flow entries can be protected from sniffing, and the LDoS attacks cannot be effectively organized to overflow the flow tables. The major contributions of this paper are three-fold:

• A staircase randomized response mechanism [15,16] is proposed to protect the true lifespan of a flow entry from sniffing. This is a local mechanism that should be used in the aging process of each flow entry in an SDN switch. To the best of our knowledge, this work is the first effort that considers the lifespans of flow entries as the network privacy and proactively protects them from flow table overflow LDoS attacks.
• A Flow-Entry Aging RandOmization Layer (FEAROL) is proposed. FEAROL prototypes the proposed staircase randomized response mechanism based on an OpenVSwitch (OVS) soft switch [17]. FEAROL is a closed-loop process in which the privacy budget and probability can be adapted to the monitored network statistics [18]. It is lightweight and easy to implement.
• An extensive evaluation based on several real traffic traces from different campus and carrier networks is provided to demonstrate the effectiveness of the staircase randomized response mechanism and FEAROL.

The remainder of this paper is organized as follows, where Section 2 presents the background and related work, and Section 3 introduces the staircase randomized response mechanism in the aging process. FEAROL is proposed in Section 4 and prototyped in Section 5. The evaluation is given in Section 6 followed by the discussion in Section 7 and the conclusions in Section 8.

2. Background and Related Work

2.1. SDN Flow Setup and Flow Entry Aging Procedures

While the flow setup procedure in SDN systems is responsible for generating and installing new flow entries for SDN switches, the flow-entry-aging procedure is responsible for maintaining the lifespans of flow entries in the flow tables. As shown in Figure 2, the flow setup procedure relies on an SDN switch and its controller. An SDN switch looks up its flow table to find the matching flow entry for a received flow packet, and the received packet is directly forwarded out if a matching entry is found, otherwise a flow entry request is sent to the controller. The received packet will not be forwarded until the matching flow entry generated by the controller arrives at the switch. This procedure provides network programmability and flexibility through fine-grained flow-entry management; however, it introduces an interaction between switches and controllers that increases the network-forwarding latency.

Regarding the flow-entry-aging procedure, each SDN switch contains a timer to maintain the lifespan of its entries. Whenever the timer fires, the flow-entry-aging procedure is triggered, as shown in Figure 2, to update the current existence and idle time of each entry in the flow table. The current existence and idle time of an entry is compared to the hard and idle timeouts set by the controller and stored in the entry, respectively. Entries are timed out and removed from the flow table if their current existence and idle time are greater than their hard and idle timeouts. Such a procedure ensures that each entry in the flow table ages correctly and that the flow table consists of only the active entries to save space for the incoming entries.

2.2. Flow Table Management

As TCAM has constraints of capacity, power consumption, heat generation and cost, flow tables may not have the enough space for the fine-grained flow entries in high performance networks [4], which is a major concern for SDN systems. The current research typically involves three types of approaches to alleviate this concern: dynamic flow-entry timeouts and eviction, flow entry aggregation and compression as well as flow entry distribution and caching.

• Dynamic flow-entry timeouts adjust the type and number of timeouts [5,19]. Timed out flow entries should be evicted efficiently [20,21] to mitigate the impacts of lack of space in the flow table. Mechanisms for adjusting flow-entry timeouts and evicting flow entries are often based on predicting the flow type, flow duration and flow grouping interval using statistical data of the flows in a given time period [22,23]. Since flow-entry timeouts affect the flow table space utilization and network-forwarding latency, and different types of flows in the network have different quality of service requirements, dynamic flow-entry timeouts and eviction mechanisms can be very complicated in practice.
• Flow entry aggregation and compression schemes directly reduce the number of flow entries required by forwarding flow packets. Such schemes typically rely on the observation that each flow can have multiple flow entries based on the prefix classifiers using wildcards [4,24]. Source or/and destination addresses of flows are often included by the wildcard to significantly reduce the flow table occupancy [25,26,27]. However, such approaches may result in a loss of visibility and control flexibility over the aggregated flows.
• By deciding which rules to place on which switch while respecting memory constraints and rule dependencies, flow entries can be split up and distributed across the network to reduce the amount of flow table space used by a single switch [28,29]. Caching the timed out flow entries in memory instead of discarding them allows for an efficient use of the flow table while reducing the network latency [30,31].

All of these approaches can mitigate the flow table overflow attacks reactively but cannot identify attacks, as listed in

Table 1. Approaches to detect and mitigate flow table overflow LDoS attacks (a—reactive defense and b—proactive defense).

Approach	Type	Feature	Strength	Weakness
[5,19]	a	dynamic timeout	better table use	affect other metric
[20,21]	a	entry eviction	better table use	affect other metric
[4,24]	a	flow aggregation	flow based	entry invisibility
[25,26,27]	a	flow aggregation	address based	entry invisibility
[28,29]	a	entry distributing	long latency	inter-switches cooperation
[30,31]	a	entry caching	low latency	table-cache cooperation
[32,33,34]	a	ML alg. involved	identify attacks	low accuracy
[35]	a	monitor network	identify attacks	late detection
FEAROL	b	randomized aging	destroy attacks	overhead on switches

; however, our proposed approach can proactively protect against flow table overflow attacks and mitigate the flow table space shortage.

2.3. Flow Table Overflow LDoS Attacks

In addition to the centralized controller and the centralized mechanisms in collecting network statistics and controlling the policy enforcement [36,37,38], recent research found that flow table overflow LDoS attacks can be organized and eventually exhaust the flow table space when the flow-entry timeouts are sniffed [14].

As shown in Figure 3, flow table overflow LDoS attacks can have multiple long or short attack flows. While each of the long flows continuously occupies the space of a flow entry, the short flows are carefully organized to ensure that the space of a timed-out flow entry must be occupied by the entry of a short attack flow. By synchronizing the attack period and the timeouts of normal flow entries, the flow table space will eventually be exhausted by the attack flow entries, and the legitimate incoming packets will be dropped due to the lack of flow table space [39].

Since current SDN controllers typically configure static timeouts across flow entries, the flow-entry timeouts can be easily sniffed using the ping utility [12]. If the flow table size is also detected by applying the combination detection approaches as proposed in [40], attackers can effectively synchronize the attack period and the flow-entry timeouts; thus, the difficulty of overflowing the flow table becomes low in reality.

The state of the art in protecting flow tables from overflow by LDoS attacks typically relies on machine-learning algorithms to model and detect LDoS attack flows. However, this often suffers from a low detection accuracy [32,33,34] because the long attack flows used in LDoS attacks can mimic the flows that monitor the various devices in IoT networks, and the short attack flows used in flow table overflow LDoS attacks are very similar to the network legitimate short flows, in their packet inter-arrival time, packet count, flow count and packet size.

Although the detection accuracy can be improved by effectively monitoring the changes in the overall network performance [35], such approaches suffer from a long detection delay, causing late detection that can only be mitigated by using the flow table space-management mechanisms introduced in Section 2.2, rather than predicting or preventing flow table overflow attacks in advance. This work fills this gap.

2.4. Randomized Response

Randomized response is a data perturbation mechanism introduced by Warner [41] and is widely used in local differential privacy. Differential privacy provides a strong criterion for privacy preservation [42]. Differential privacy mechanisms can be centralized or localized. Centralized mechanisms require a trusted third party to collect the private data before distributing the randomized response; however, a fully trusted third party is hardly achievable in reality. Local differential privacy mechanisms address this problem by perturbing private data locally. A differential privacy method M has a privacy budget $ϵ$ if two records of t and $t^{{}^{\prime }}$ have the same output of $t^{*}$ ($t^{*}$ is in the range of M) and make the following statement true.

$$Pr[M\left(t\right)=t^{*}]>e^{ϵ}\ast Pr[M\left(t^{{}^{\prime }}\right)=t^{*}]$$

(1)

Randomized response is widely used to perturb binary data in local differential privacy. The basic idea is to make the “true” statement with some probability p less than 1 and with probability of $1-p$ otherwise. Consider a survey with n users being surveyed: the true ratio of users answering “yes” is $\pi$, which is not known and is estimated through the survey. Suppose $n1$ users answer “yes” and $n-n1$ users answer “no”, then the probability of users answering “yes” and “no” can be computed by Equations (2) and (3), respectively, and Equations (4) and (5) represent the likelihood function L and the estimated maximum likelihood, respectively. The expectation of ${\pi }^{-}$ is $\pi$ as computed by Equation (6). ${\pi }^{-}$ is the unbiased estimate of $\pi$, and the privacy budget $ϵ$ can be calculated using Equation (7) [41]. All symbols are listed in

Table 2. Symbols and their descriptions.

Symbols	Descriptions
M	differential privacy method
$t,t^{{}^{\prime }}$	two different input
$t^{*}$	output of M over t and $t^{{}^{\prime }}$
$ϵ$	privacy budget
$Pr[·]$	the probability of ·
p	the probability of give true answer
$\pi$	the true number of users with answer “yes”
$n,n1$	the total number of users and the users giving “yes”
L	the likelyhood function
${\pi }^{-}$	the estimated maximal likelyhood of $\pi$
$E(·)$	expectation of ·
A	the set of actions
$A_j$	the element of A
$F{A}_i$	the aging action taken by flow entry i
T	the checking period
O	flow table space occupancy
F	packet forwarded to controllers
$AFE$	total number of current active flow entries
$FE$	total number of flow entries stored in flow table
$PP$	the set of packets
$p{p}_i$	a packet in set $PP$
$a_i$	the parameter indicating if $p{p}_i$ is forwarded to controllers

.

$$Pr(answer“yes”)=\pi p+(1-\pi )(1-p)$$

(2)

$$Pr(answer“no”)=(1-\pi )p+\pi (1-p)$$

(3)

$$L={[\pi p+(1-\pi )(1-p)]}^{n1}{[(1-\pi )p+\pi (1-p)]}^{n-n1}$$

(4)

$${\pi }^{-}=(p-1)/(2p-1)+n1/\left[(2p-1)n\right]$$

(5)

$$E\left({\pi }^{-}\right)=1/(2P-1)[P-1+\pi p+(1-\pi )(1-p)]=\pi$$

(6)

$$ϵ=lnp/(1-p)$$

(7)

Since randomized response only considers binary data, two typical approaches are used to extend it to scenarios with discrete data: (1) encoding or converting the response to binary and (2) adjusting the probability distribution of all responses. While RAPPOR [43] and S-Hist [44] are the typical mechanisms of (1), staircase randomized response mechanisms, such as k-RR [15] and O-RR [16] are the representations of (2).

Regarding the staircase randomized response, let $R^{{}^{\prime }}$ be the response of each input R, then we have Equations (8) and (9) in the privacy budget $ϵ$ [15]. This work does not make surveys over perturbed answers as most of the approaches have been conducted but instead incorporates the staircase randomized response in the flow-entry-aging process to randomize the lifespans of flow entries within a privacy budget so that the real lifespans of flow entries are unknown, and the sniffed flow-entry timeouts are useless for flow table overflow LDoS attacks.

$$Pr(R^{{}^{\prime }}=R|R)=e^{ϵ}/(k-1+e^{ϵ})$$

(8)

$$Pr(R^{{}^{\prime }}\ne R|R)=1/(k-1+e^{ϵ})$$

(9)

3. Aging Flow Entries with Staircase Randomized Response

As introduced in Section 2.1, each SDN switch has an aging procedure for flow entries that involves a timer to update the current existence time and idle time of each entry. Let the timer fire every 1 millisecond, and then the flow current existence time and idle time of each flow entry should increase by 1 millisecond compared to the timeouts written into the entry. This makes the timeouts become the lifespans of the flow entries in the flow table. However, such a procedure allows the flow-entry timeout to be easily sniffed, particularly when controllers apply static timeout across flow entries, thereby, leading to a flow table overflow attack that can cause the legitimate flows to be rejected for forwarding.

To protect the lifespans of flow entries, the flow-entry timeouts can be encrypted. Whether the timeouts are encrypted by controllers at creation or by switches at installation, the encrypted timeouts have to be decrypted in the flow-entry-aging process to maintain the correct lifespans of flow entries. Since the aging process is triggered by the timer, while encryption/decryption is typically computationally intensive, encryption/decryption approaches are not suitable for the aging process. Accordingly, in this paper, we consider the lifespans of flow entries as the privacy of SDN systems. We do not attempt to provide statistics surveys over perturbed flow entry lifespans. Instead, we make the real lifespans of flow entries dynamically change based on the perturbed aging method with a certain privacy budget to control the amount of perturbation.

Specifically, we apply the staircase randomized response in the aging process. Suppose the flow table consists of n flow entries. Let $A=[A_1,A_2,\dots ,A_j]$ be the set of aging actions that can be taken by a flow entry with the probability $P=[p,(1-p)/(\left|A\right|-1),...,(1-p)/(\left|A\right|-1\left)\right]$. $F{A}_i$ is the aging action taken by flow entry i when the timer fires, and the expectation of $F{A}_i$, denoted by $E\left(F{A}_i\right)$, is computed by Equation (10). Since the sets A and P are given for each flow entry, $E\left(F{A}_i\right)$ is an unbiased estimate of $F{A}_i$ for each flow entry i in the flow table. Intuitively, $E\left(F{A}_i\right)$ is an unbiased estimate of flow entry i that is aged and, therefore, correctly timed.

In reality, each element of A should be an integer, and any two elements in A should be different, suggesting two different aging actions. While positive integers imply that flow entries are becoming older, negative integers imply that flow entries are becoming younger. Specifically, $A_j=0$ means that flow entries will keep their current existence and idle time unchanged, and $A_j=1$ means that the existing and idle time of the flow entry will age normally as listed in

Table 3. Parameters and their descriptions: p is the probability of action $A_1$, and n is a positive integer.

Parameter	Probability	Value	Description
$A_1$	p	0	flow entry will not age
		1	flow entry is aging normally
		$+n$	flow entry is aging n times faster than normal
		$-n$	flow entry is aging n times slower than normal
$A_j(j>1)$	$(1-p)/\left(\right|A|-1)$	0	flow entry will not age
		1	flow entry is aging normally
		$-n$	flow entry is aging n times slower than normal
		$+n$	flow entry is aging n times faster than normal

.

Since $E\left(F{A}_i\right)=1$ implies how flow entry i ages normally, indicating the real lifespan of flow entry i, while $E\left(F{A}_i\right)$ is computed by the sets of A and P, we can adjust A and P to change $E\left(A_{it}\right)$. Consider the following three scenarios: $A=[1,0,0,0]$ and $P=[0.75,0.25/3,0.25/3,0.25/3]$, $A=[1,0,2,3]$ and $P=[0.75,0.25/3,0.25/3,0.25/3]$ and $A=[1,0,-1,2]$ and $P=[0.75,0.25/3,0.25/3,0.25/3]$. We compute their $E\left(F{A}_i\right)$ as 0.75, 1.417 and 0.833, respectively, using Equation (10). These imply that flow entry i ages 0.75-, 1.417- and 0.833-times normal.

$$E\left(F{A}_i\right)=A_{1}p+\sum _{j=2}^{\left|A\right|}{A}_j(1-p)/\left(\right|A|-1)$$

(10)

Since we can identify the actions in the set A as $A_1$ and not $A_1$ with the probability of p and $1-p$, respectively, we guarantee $ϵ$-differential privacy for the lifespan of each flow entry in the flow table, independent of the attacker’s prior knowledge, and $ϵ$ is given by Equation (7). In particular, $ϵ$ is 1.1 for $p=0.75$. Since $ϵ$ increases as p increases, and the smaller the $ϵ$ is, the more protection it provides, we need to reduce p to provide more protection. In reality, we might adjust A and P to balance the network performance and security.

4. Flow Entry Aging RandOmization Layer

FEAROL proposes to perturb the lifespan of each flow entry in the flow table locally, instead of involving a centralized differential privacy mechanism at controllers to directly protect the configured flow-entry timeouts. Since the lifespan of a flow entry is defined by the flow-entry timeout, which is typically configured by controllers, distributed to switches through the control channel and stored in flow tables in switches, flow-entry timeout information can be leaked at controllers, control channel and switches. When applying centralized differential privacy mechanisms for flow-entry timeouts, we may need to ensure that the controllers and the control channel are trusted, which is difficult to achieve in reality. Therefore, we chose the local randomized response instead of the central one to protect the flow-entry timeouts.

As shown in Figure 2, an SDN switch involves a timer to continuously update the existing and idle time of flow entries. Whenever the timer fires, the flow-entry management function updates the current existence and idle time of each flow entry in the flow table. To perturb the flow entry update procedure, FEAROL is implemented in the flow-entry management function as shown in Figure 4. After the timer fires, FEAROL applies a staircase randomized response to determine the aging action that each flow entry should take. FEAROL defines the aging action set A and the probability set P and allows each flow entry to take action $A_1$ with the probability of p and each of the other actions with the probability of $(1-p)/\left(\right|A|-1)$.

FEAROL is a closed-loop process that also consists of a module that can periodically adjust the sets of A and P based on the maximum flow table space occupancy O, the current packets forwarded to controllers F and the current privacy budget $ϵ$. Given an adjustment period T, the current privacy budget $ϵ$ is computed by Equation (5). The current flow table space occupancy O is computed using the maximum total number of the currently active flow entries ($AFE$) over the total number of flow entries that the flow table can store ($FE$) (as shown in Equation (11)) and the current packets forwarded to controllers F, which can be calculated using the packet count of all packets forwarded by the switch to the controller (as shown in Equation (12)), where $p{p}_i\in PP$ is a packet received by the switch, and $a_i$ is a binary parameter indicating whether or not $p{p}_i$ is forwarded to the controllers. Let $a_i$ be 1 if $f_i$ is forwarded and 0 otherwise.

FEAROL must effectively use the space of the flow table without forwarding too many packets to controllers and while maintaining a reasonable privacy budget. Particularly, FEAROL designs nine strategies, as listed in

Table 4. Strategies used to configure the sets of A and P.

p	$\mathit{ϵ}$	${\mathit{A}}_1$	${\mathit{A}}_2$	${\mathit{A}}_3$	${\mathit{A}}_4$	$\mathit{E}\left({FA}_{\mathit{i}}\right)$	Protection	Aging	Strategy #
0.25	−1.1	1	0	0	0	0.25	high	slow	1
		1	0	2	3	1.5	high	fast	2
		1	0	−1	2	0.5	high	no	3
0.55	0.2	1	0	0	0	0.55	low	slower	4
		1	0	2	3	1.3	low	fast	5
		1	0	−1	2	0.7	low	slow	6
0.75	1.1	1	0	0	0	0.75	lower	slower	7
		1	0	2	3	1.42	lower	fast	8
		1	0	−1	2	0.83	lower	slow	9

. If the flow table space occupancy is greater than 0.8, the switch may be subject to flow table overflow LDoS attacks. FEAROL should use strategies 2 or 5 to reduce p to reduce the privacy budget $ϵ$ and make more space for new incoming flow entries. If the flow table space occupancy is less than 0.5, FEAROL can choose strategies 7 and 4 or strategies 9 or 6 to increase p and $ϵ$, depending on the flow-entry timeouts to control the lifespan of flow entries.

$$O=\underset{T}{max}AFE/FE$$

(11)

$$F=\sum _{i=1}^{\left|PP\right|}{a}_i$$

(12)

5. Prototype

Since FEAROL slightly changes the flow-entry management procedure in SDN switches, the software of the SDN switches has to be updated. We are currently implementing FEAROL in OVS, a product-level open-source soft-switch developed by Linux Foundation. As FEAROL is based on a local staircase randomized response, FEAROL does not change the existing protocols and SDN controllers.

As shown in Figure 5, OVS has a daemon called ovs-vswitchd that continuously manages flows and flow entries. An OVS may have multiple data-paths to receive ➀ and forward flow packets. Data-paths reside in the kernel space of an OVS. When a data-path receives a packet, it looks up its flow table to find the matching flow entry. If the matching flow entry is not found, the data-path sends a flow entry request message ➁ to its remote controller via the OVS daemon ➂. The remote controller generates the flow entry and delivers it to the flow table via OVS daemon along with the flow entry installation module (➃ and ➄). The data-path retrieves the matching flow entry ➅ and forwards the received packet out ➆.

The OVS daemon manages flow entries in the flow table using the flow-entry-management module. FEAROL is implemented in the flow-entry-management module to provide a staircase randomized response for updating the current existence and idle time of each flow entry so that the OVS can protect the true lifespan of each flow entry from sniffing and leakage.

The current FEAROL implementation defines nine combinations of A and P. As listed in Table 4, the update period of A and P is set to 60 s by default, based on the maximum flow table space usage O, the total number of packets forwarded to controllers F and the privacy budget $ϵ$ computed in the last period. Note that the total number of packets forwarded to controllers F must be counted by the modules sending or receiving flow entry requests. In the current implementation, we compute F in the OVS daemon to leave the software of the controllers unchanged. FEAROL remains the existing flow-entry-management timer in the unchanged OVS. As the timer fires every millisecond, each flow entry ages in milliseconds. FEAROL supports more aging strategies and finer timers.

6. Evaluation

This section provides five testing scenarios, as listed in

Table 5. Test scenarios.

Scenario	Table Limitation	Under LDoS Attack	Randomized Response
1	no	no	no
2	no	no	yes
3	no	yes	no
4	no	yes	yes
5	yes	yes	no
6	yes	yes	yes

, that consider whether SDN flow tables have space constraints or not, whether the network is under LDoS attack or not and whether the staircase randomized response mechanism is applied or not. Nine aging strategies are listed in Table 4. Four packet traces collected from the campus and backbone networks are used for the FEAROL performance evaluation.

As listed in

Table 6. Traces (5 min) used for evaluation (MAWI only collect the IPV4 flows.)

Traces	GUAT	Simpleweb	UNIV1	MAWI
Type	campus	campus	campus	backbone
Coun.	China	Netherlands	US	Japan-US
Year	2020	2003	2009	2013
Flows	571.009 K	70.116 K	7.562 K	504.637 K
Pcks/s	23.95 K	2.07 K	2.8 K	92.65 K

, GUAT is collected from the border router of the campus network of Guilin University of Aerospace Technology (GUAT), Guilin, China, Simpleweb (https://www.simpleweb.org/wiki/index.php/Traces#Pcap_Traces, accessed on 1 Feburary 2019), UNIV1 ( http://pages.cs.wisc.edu/~tbenson/IMC10_Data.html, accessed on 16 March 2017) and MAW1 ( http://www.fukuda-lab.org/mawilab/, accessed on 24 May 2019) are public traces downloaded from the Internet. First, we estimate how the staircase randomized response affects normal networks. Then, we estimate how the staircase randomized response affects the network under attack. Finally, we evaluate the performance of FEAROL.

6.1. Staircase Randomized Response for Normal Networks

We developed a simulation application using Python to compute the flow table space occupancy O, the total number of packets forwarded to controllers F, given the nine strategies listed in Table 4 for the four networks listed in Table 6 with no attack. We use scenario 1 as the baseline, where each flow entry has an idle timeout of 1 s. We compute the flow table occupancy and the total number of packets forwarded to controllers in scenario 2 to see how the staircase randomized response affects the network. Scenario 2 suggests a normal network with a staircase randomized response with the aging process with no flow table space constraints and no LDoS attacks. The results are shown in Figure 6.

It was apparent that the network performed differently under different strategies. For all four data traces tested, the network had lower flow table occupancy and a greater number of packets forwarded to controllers when the networks aged faster than the baseline, such as when applying strategies 2, 5 and 8. When the network aged slower than the baseline, such as with the strategies 1, 3, 4, 6, 7 and 9, the network had higher flow-table utilization and forwarded fewer packets to the controllers compared to the baseline.

Larger $E\left(F{A}_i\right)$ resulted in lower flow table space usage and more packets forwarded to the controllers. Among all the strategies, strategy 1 generated the highest flow table usage and the lowest number of flow packets forwarded because it had the lowest $E\left(F{A}_i\right)$, suggesting that its flow entry aged only 1/4 of the normal and the real lifespan of flow entries was about idle 4 s. The value of $ϵ$ did not much influence the flow table occupancy and the total packets forwarded to controllers.

6.2. Staircase Randomized Response for Networks under LDoS Attacks

We estimate the network performance when the flow table has a size limitation and the network is under LDoS attacks as described in scenarios 5 and 6. We let the network have a space limitation of about 1.2 times the flow table space usage in scenario 1. To enable flow table overflow LDoS attacks, we used the long attack flows with an attack period slightly less than 1 s, as the timeout of normal flow entries was set to idle at 1 s as described in scenario 1. We computed the number of attack flows to ensure that the packet rate of each network under attack was not greater than 1.2 times that of the network without attacks. We generated the attack flows, inserted the flows into the networks and computed the the maximum flow table space occupancy O and the total number of packets forwarded to controllers F for each data trace. The results are shown in Figure 7.

It was apparent that the maximum flow table usage was not really affected by the staircase randomized response when under LDoS attacks. This is likely because the flow table usage that we computed is the maximum, which might happen when the LDoS attacks have only begun and the staircase randomized response needs more time to show its work.

We then recorded the flow table space usage every 10 s. We tested all four data traces with all nine strategies. We plotted the results under strategies 1, 2, 3 and 8, as shown in Figure 8, for a better visualization. The hard and dotted lines in Figure 8 indicate the numbers of normal and attack flow entries in the flow table, respectively. We also conducted statistical analysis of the flow table space usage.

Table 7. Confidential intervals of the flow table space usage for the traffic traces, 1—UNIV1, 2—SimpleWeb, 3—MAWI and 4—GUAT.

Type	Scenario5	Strategy1	Strategy2	Strategy3	Strategy8
1 (normal)	333 ± 35	607 ± 28	252 ± 22	474 ± 16	299 ± 23
1 (attack)	560 ± 0	494 ± 28	0 ± 0	519 ± 17	0 ± 0
2 (normal)	397 ± 22	737 ± 17	337 ± 1	609 ± 8	390 ± 4
2 (attack)	213 ± 4	276 ± 16	0 ± 0	370 ± 17	1 ± 0
3 (normal)	18,090 ± 1098	27,504 ± 720	14,440 ± 877	27,881 ± 985	16,680 ± 1015
3 (attack)	18,530 ± 0	17,045 ± 1029	0 ± 0	17,003 ± 1058	7 ± 0
4 (normal)	9793 ± 23	11,982 ± 573	7501 ± 80	11,992 ± 332	8921 ± 29
4 (attack)	4790 ± 0	3018 ± 573	0 ± 0	2976 ± 348	1.5 ± 0.28

lists the 95% confidential intervals of the legitimate and attack flow table space usage over the four traffic traces.

It was apparent that applying the staircase randomized response in the flow-entry-aging process affected the flow table LDoS attacks. As the baseline, the number of flow entries for the normal and attack flows in scenario 5, as represented by normalflow-5 and attackflow-5 in Figure 8, had relatively small standard deviations as listed in Table 7. The number of flow entries in the flow table for normal flows varied under different strategies. When the network had flow entries that aged slower than normal, such as the strategies 1 and 3 with $E\left(F{A}_I\right)$ greater than 1 (the baseline), the number of flow entries for normal flows in the flow table was greater than the baseline.

If the network had flow entries that age dfaster than normal, such as the strategies 2 and 8 with $E\left(F{A}_i\right)$ less than 1, then the number of flow entries for normal flows in the flow table was less than the baseline. However, the number of flow entries of attack flows was reduced regardless of which strategy was applied on the data traces. Specifically, applying strategies 2 and 8 reduced the number of attack flow entries to 0, indicating that the staircase randomized response mechanism mitigated the flow table overflow caused by LDoS attacks.

6.3. FEAROL

Since FEAROL is implemented in the flow-entry-aging process, which manages the lifespan of flow entries in the flow table, FEAROL does not directly affect the forwarding of flow packets. Therefore, FEAROL does not directly affect the overall forwarding latency of the network.

To estimate how FEAROL affects the management of flow entries, we compared the the time cost of the aging process with staircase randomized response to that without staircase randomized response. Specifically, we wrote a simulation program using Python. We limited each flow table to a maximum of 10,000 flow entries. Each time a flow entry is aged, the simulation program checks whether or not the entry is out of its lifespan after updating the current existence time and the idle time of the entry to simulate how the aging process of the OVS works. We ran the simulation 100 times and recorded the total time cost of each run.

We took the average total time cost and divided it by the number of the flow entries to obtain the time cost of aging a flow entry. We compared the time cost of aging a flow entry under Strategies 1 and 2 with the time cost without using a staircase randomized response. We used a laptop with Intel i7-8750H CPU@2.20 GHz and 16 G RAM to run the simulation. The results are shown in Figure 9.

It was apparent that the addition of FEAROL to the flow-entry-aging process increased the time cost of aging a flow entry. However, this increase was mainly contributed by the generation of the probability p to determine the aging action of each flow entry. When the probability p was given without randomization, as shown by the item strategy 2 without randomization in Figure 9, the time cost was reduced to the level without staircase randomization. This implies that we should optimize the random variable generation to reduce the time cost added by FEAROL. Although the time costs under strategies 1 and 2 are slightly different, this difference is too small and is most likely due to the overhead fluctuation of the laptop running the simulation program. A relationship between the time cost and the different strategies was not discovered.

We believe that the overhead of FEAROL is an implementation problem. We can choose an efficient random number generation function, use a host with a faster CPU and larger RAM and reduce the frequency of the aging process being triggered to reduce the time overhead of FEAROL. To estimate how the update frequency affects the overhead, we let FEAROL be triggered every 10, 50 and 100 ms and compared these to the baseline where FEAROL is triggered every 1 ms. We found that the average time to update each entry remained the same. However, the overhead that FEAROL adds to the aging process was reduced, since the time interval for the update increases considering the timeout of each flow entry in practice.

7. Discussion

Flow table overflow LDoS attacks are difficult to detect with the existing detection mechanisms for the LDoS attacks due to the low packet rates. This work chooses to change the attack surface by randomizing the real lifespans of flow entries at switches and breaking the synchronization between attack flows and the flow-entry timeouts to proactively protect from the flow table overflow LDoS attacks instead of designing reactive attack detection and mitigation mechanisms. This work is actually a moving target defense (MTD) approach that increases the security of SDN systems [45]. It provides a local differential privacy approach that keeps the true lifespan of each flow entry private without adding extra mechanisms on the controllers or the third parties.

It is lightweight and works on the aging process of flow entries that does not directly add overhead to the flow-packet-forwarding process. Since our proposed approach can proactively protect networks from LDoS attacks, while the state of the art of LDoS detection and mitigation techniques are typically reactive, it is difficult to compare the performance of these two types of approaches. Since we randomized the seeds to generate p for each time a flow entry was aged, we maximized the generality in the evaluation and avoided outperformance arising by chance, and curves with confidence intervals were not needed.

More advanced MTD mechanisms that change the attack surface, such as dynamically changing the network topology and IP addresses [46], can be investigated in our future work to increase the difficulty of probing network settings and, thus, launching flow table overflow LDoS attacks. Other LDoS attack detection and mitigation approaches using flow classification based on machine-learning mechanisms [23] can be added to further reduce the impact of LDoS attacks. As the proposed approach requires a minor update of the software of switches, the current prototype was implemented in OVS.

Although real traffic traces increase the variety of the legitimate flows, they create trouble in simulating the network topology and addressing the space of the traces and, hence, the complex test scenarios due to the lack of related information. However, further evaluations that estimate the performance of the current prototype in more complex network scenarios should be performed, and the prototype should be extended to programmable datapaths, such as P4-based [47] or netFPGA-based [48] SDN switches.

8. Conclusions

This paper applied a staircase randomized response to the flow-entry-aging process to randomly change the real lifespans of flow entries in the flow tables to break the synchronization between flow table overflow LDoS attacks and network settings. FEAROL was prototyped in OVS to show how the staircase randomized response was implemented in the aging process. Nine staircase randomized response strategies with various aging actions were proposed to show how probability p and the privacy budget $ϵ$ were combined to affect the real lifespans of flow entries. The staircase randomized response and FEAROL were evaluated over multiple traffic traces gathered from various campus and carrier data centers.

The results demonstrated that the parameters p and the privacy budget $ϵ$ in the staircase randomized response can adjust the real lifespans of flow entries and, hence, the flow table space usage and the number of packets forwarded to controllers. If flow entries age faster than normal, they will have a shorter lifespan than the timeout configured by the controllers, resulting in less flow table space usage and more packets forwarded to controllers. When networks are under flow table overflow LDoS attacks, applying a staircase randomized response to the flow-entry-aging process can reduce the flow table used by attack flows and mitigate the flow table space shortage.

Since the proposed FEAROL is applied to the aging process, which manages the lifespan of each flow entry in the flow table, it does not directly affect the flow-packet forwarding and the overall network-forwarding latency. More research should be conducted to evaluate the performance of FEAROL in more complex attack scenarios and to extend FEAROL to programmable datapaths in our future work.