SMART: Shared Memory based SDN Architecture to Resist DDoS

ATtacks

Sana Belguith

1 a

, Muhammad Rizwan Asghar

2 b

, Song Wang

, Karina Gomez

and Giovanni Russello

School of Computing, Science and Engineering, University of Salford, Manchester, U.K.

Cyber Security Foundry, The University of Auckland, Auckland, New Zealand

School of Engineering, RMIT University, Melbourne, Australia

Keywords:

SDN, Security, Shared Memory, Tuple Spaces, DDoS, Availability, OpenFlow.

Abstract:

Software-Deﬁned Networking (SDN) is a virtualised yet promising technology that is gaining attention from

both academia and industry. On the one hand, the use of a centralised SDN controller provides dynamic

conﬁguration and management in an efﬁcient manner; but on the other hand, it raises several concerns mainly

related to scalability and availability. Unfortunately, a centralised SDN controller may be a Single Point Of

Failure (SPOF), thus making SDN architectures vulnerable to Distributed Denial of Service (DDoS) attacks.

In this paper, we design SMART, a scalable SDN architecture that aims at reducing the risk imposed by the

centralised aspects in typical SDN deployments. SMART supports a decentralised control plane where the

coordination between switches and controllers is provided using Tuple Spaces. SMART ensures a dynamic

mapping between SDN switches and controllers without any need to execute complex migration techniques

required in typical load balancing approaches.

1 INTRODUCTION

Software-Deﬁned Networking (SDN) is a virtualised

yet promising technology that is gaining attention

from both academia and industry. The SDN architec-

ture provides a clear separation between a data plane

and a control plane. The former one is for forwarding

trafﬁc and the latter one deals with routing decisions

made by SDN switches. In SDN, a centralised control

plane is responsible for giving directions to the data

plane (Scott-Hayward et al., 2016). A control plane

is formed by one or more SDN controllers; whereas,

SDN switches constitute a data plane. An SDN con-

troller is a powerful tool and is considered the brain

of an SDN network.

In SDN, a controller installs ﬂow rules on SDN

switches. These rules allow SDN switches to han-

dle network ﬂows. When a new ﬂow, which does

not match any existing ﬂow rules, is encountered, the

switch sends a packet-in message to the SDN con-

troller for receiving instructions on how to deal with

that trafﬁc (cf. Fig. 1). The use of a centralised

https://orcid.org/0000-0003-0069-8552

https://orcid.org/0000-0002-9607-376X

SDN Controller

Control Plane

Data Plane

Switch Switch Switch

Packet In

Flow Rule

Flow

Table

Flow

Table

Flow

Table

Figure 1: The SDN architecture illustrating a logical and

physical separation of both control and data planes, place-

ment of ﬂow tables, and high-level interactions between an

SDN controller and SDN switches.

SDN controller enables conﬁguration, management,

and optimisation of network resources dynamically

through SDN applications in an efﬁcient manner, in-

dependent from the underlying network infrastruc-

ture.

Despite its beneﬁts, the centralised nature of an

SDN controller raises several concerns mainly re-

lated to scalability and availability. Indeed, a cen-

608

Belguith, S., Asghar, M., Wang, S., Gomez, K. and Russello, G.

SMART: Shared Memory based SDN Architecture to Resist DDoS ATtacks.

DOI: 10.5220/0009864906080617

In Proceedings of the 17th International Joint Conference on e-Business and Telecommunications (ICETE 2020) - SECRYPT, pages 608-617

ISBN: 978-989-758-446-6

tralised SDN controller may not be suitable for appli-

cations involving multi-domain and multi-technology

features, such as the architecture of Internet Service

Providers (ISPs) interconnecting each other, where

each ISP owns different types of equipment and tech-

nologies. Moreover, a centralised SDN controller

may be a Single Point Of Failure (SPOF), which

causes the vulnerability of SDN architectures to at-

tacks (Dixit et al., 2013; Scott-Hayward et al., 2016).

To mitigate these issues, there are proposals to use

logically centralised, but physically distributed SDN

controllers (Phemius et al., 2014) to avoid the SPOF

and to offer better network scalability. Although scal-

ability and availability of the SDN architecture can

be improved using distributed controllers, such an ap-

proach has one main drawback when it comes to link-

ing switches to controllers; actually, a switch is stati-

cally connected to a controller, which prevent the con-

trol plane from adapting trafﬁc load variations. To

address this drawback, a naive solution is to over-

provision controllers in order to deal with the ex-

pected peak load (Dixit et al., 2013). However, this

solution is inefﬁcient due to its high cost and energy

consumption.

A key limitation of SDN is its vulnerability to Dis-

tributed Denial of Service (DDoS) attacks (Bhushan

and Gupta, 2019). Indeed, there is a paradoxical rela-

tionship between SDN and DDoS attacks. On the one

hand, the separation of the control and data planes

results in an easier detection and optimised defence

against DDoS attacks. On the other hand, the cen-

tralisation of the control plane introduces new DDoS

threats as the control plane may be a target of these

attacks (Yan and Yu, 2015). In DDoS attacks, an

attacker could generate data packets for which SDN

switches might have no ﬂow rule, thus forcing them

to forward those packets to the SDN controller. By

sending a large number of new data packets, SDN

could be ﬂooded, thus resulting in a DDoS attack (cf.

Fig. 2). Basically, these are table-miss packets that

will trigger massive packet-in messages from SDN

switches to the controller, that is incurring an exces-

sive consumption of the bandwidth, CPU resources,

and memory in the control plane as well as the data

plane.

A promising approach could be to balance load

dynamically among distributed controllers to handle

table miss-packets in normal use as well as during

ﬂooding attacks. This requires the introduction of a

load balancer to efﬁciently distribute the control plane

requests among different controllers. Moreover, dedi-

cated switch migration algorithms have to be executed

to map switches to controllers while performing the

load balance strategy.

Switch

Honest User

Attacker

SDN Controller

Consume Ressources

Exhaust bandwidth

Overload flow table and memory

Figure 2: An illustration of DoS attacks on SDN: An at-

tacker generates table-miss packets and forwards them to

the SDN controller. By sending a large number of new data

packets, an SDN controller could be ﬂooded.

A more logical solution would be to use a coordina-

tion layer between switches and controllers to handle

the control plane requests and ensure dynamic map-

ping between SDN switches and controllers. To this

end, we introduce the use of Tuple Spaces as a decou-

pling mechanism for coordinating the communication

between SDN switches and controllers. Tuple spaces

were introduced as part of the LINDA language in

(Gelernter, 1985) for building parallel/distributed ap-

plications. Tuple spaces are basically shared mem-

ory objects that provide a simple API to store and re-

trieve ordered sets of data, called Tuples. Using tu-

ple spaces as a coordination layer enables the decou-

pling of the communication between SDN switches

and controllers in space and time: in space as SDN

controllers and switches are not statically bound to

each other; in time as SDN switches and controllers

are not required to be online at the same time to trans-

fer data. Through this decoupling, it is possible to

balance requests across all the active available con-

trollers. Moreover, one can dynamically activate new

controllers when there is a trafﬁc peak.

In this paper, we present SMART, a Shared

Memory based SDN Architecture to Resist DDoS

aTtacks. SMART leverages a decentralised con-

trol plane where tuple spaces are used to coordinate

the communication between SDN switches and con-

trollers. In SMART, SDN switches can execute opera-

tions to store packet-in requests as tuples as well as to

retrieve ﬂow rules. SDN controllers consume packet-

in tuples inserted by switches, generate related ﬂow

rules and put them back in the tuple space.

Our proposed architecture is multi-fold. First,

SMART is based on using a distributed control plane

involving several controllers, which makes the net-

work more scalable. Second, thanks to the use of

tuple space, SMART ensures a dynamic mapping be-

tween switches and controllers. Unlike other decen-

SMART: Shared Memory based SDN Architecture to Resist DDoS ATtacks

609

tralised SDN networks, SMART allows a switch to

communicate in a decoupled manner with controllers

through tuple space instead of being statically mapped

to a master controller. Third, through this decou-

pling, we provide a smooth load balance among con-

trollers, which can be useful to defeat DDoS attacks

as the trafﬁc may be efﬁciently distributed among

controllers without ofﬂoading any node. Last but

not least, tuple space can detect excessive accesses

from switches during DDoS attacks that could trigger

a mitigation strategy. For instance, when an attack

is detected, packet-in requests are detoured to a data

plane cache. This module is used to store the table-

miss packets received during DDoS attacks, which

are ﬁltered to distinguish benign ones and then move

them to tuple space to be addressed by the controllers.

Therefore, this technique maintains system availabil-

ity during a ﬂooding attack.

The remainder of this paper is organised as fol-

lows. Section 2 reviews related work. In Section 3,

we describe research challenges to be addressed by

the solution. Section 4 provides background infor-

mation on tuple spaces and their features relevant to

SDN. Section 5 gives an overview of SMART as well

as its building blocks. In Section 6, we provide solu-

tion details before concluding in Section 7.

2 RELATED WORK

SDN architectures have been widely studied in the

literature to enhance their scalability and security

against attacks. In the following, we ﬁrst review

the literature covering load balancing solutions for

SDN. Then, we discuss existing DDoS mitigation

techniques.

2.1 Load Balancing for Distributed

SDN

Several research works have proposed load balance

algorithms for SDN architectures. Obviously, load

balance solutions in SDN can be categorised into two

types: centralised and decentralised algorithms.

To ensure dynamic load balance on distributed

SDN networks, ElastiCon (Dixit et al., 2013) has been

designed so that the workload is dynamically bal-

anced to enable the controllers to perform at a pre-

speciﬁed load window. When the aggregate over-

head changes over time, the system dynamically adds

or removes controllers from the controllers cluster as

needed.

COLBAS (Selvi et al., 2016) is a controller load

balancing scheme for hierarchical networks that relies

on controller cooperation via cross-controller com-

munication. COLBAS assigns one of the controllers

as a super controller that can ﬂexibly manage ﬂow re-

quests handled by each controller. This super con-

troller is located at the network node closest to the ge-

ographical centre of the topology. All controllers pub-

lish their own load information periodically through a

cross-controller communication system. When traf-

ﬁc conditions change, the super controller reassigns

different ﬂow setups to proper controllers and installs

allocation rules on switches for load balancing. Bal-

Con (Cello et al., 2017) has been designed to improve

load balance between controllers by implementing a

dedicated switch migration algorithm. This solution

relies on measuring the load of each controller. Once

a controller’s load reaches a pre-ﬁxed threshold, it is

considered as overloaded and a set of switches are

chosen to be migrated into another controller.

Centralised load balancing solutions rely on the

use of a centralised node whose performance is lim-

ited by memory, CPU computation, and network

bandwidth. Besides, a centralised node should collect

all the controllers’ overheads in the network, which

requires exchanging data with them frequently. More-

over, if the central node collapses, the whole load bal-

ancing strategy is down. To this end, decentralised

load balance solutions have introduced (Zhou et al.,

2014; Ammar et al., 2017). DALB is a distributed

load balance architecture (Zhou et al., 2014) running

as a module of an SDN controller to enable load esti-

mation. This algorithm avoids the single point of fail-

ure problem, thus providing scalability and availabil-

ity. The controller periodically collects its own load

information. Then, it checks whether the load is be-

yond the threshold. If the load exceeds the threshold,

the controller gathers other controllers’ load informa-

tion. After aggregating all load information from the

controller cluster, the high load controller makes a mi-

gration decision and selects which switch will be mi-

grated to a low load controller.

Although distributed load balance approaches en-

sure an efﬁcient ﬂow distribution among the con-

trollers’ pool, SDN architectures remain an attractive

target for DDoS attacks. Indeed, an SDN controller

usually chooses an alternative route between entry

point and end point only if the ﬁrst current route is not

available, which ensure network reliability. Neverthe-

less, during DDoS attacks, this strategy is inefﬁcient

as attack trafﬁc will be redirected through a different

route. Thus, there is a high probability that the new

route will be overloaded as well.

SECRYPT 2020 - 17th International Conference on Security and Cryptography

610

2.2 Solutions against (D)DoS Attacks on

SDN

Several solutions have been proposed to mitigate

DDoS attacks in SDNs (Shin et al., 2013; Chen et al.,

2016; Wang et al., 2015). AVANT-GUARD (Shin

et al., 2013) has been introduced to countermea-

sure DDoS attacks impacts on SDN networks. First,

AVANT-GUARD extends SDN data plane using a

connection mitigation feature that reduces interaction

between data plane and control plane. This added

feature drops failed TCP sessions at the data plane

prior to any notiﬁcation to the control plane. Second,

AVANT-GUARD relies on actuating triggers which

enable the data plane to asynchronously report net-

work status and payload information to the control

plane. Nevertheless, this solution only defeats TCP-

based ﬂooding attacks but does not resist other kinds

of attacks such as UDP and ICMP. Moreover, the au-

thors do not propose any mechanism to handle pack-

ets during the attack. SDNShield (Chen et al., 2016)

incorporates two defence lines to mitigate DDoS at-

tacks on SDN. This solution is based on ﬁltering in-

coming ﬂows to identify the legitimate ones to be

routed directly to their destinations. SDNShield re-

lies on the use of a network of a specialised clus-

ter of virtual machines to double-check the rejected

packets. To mitigate ﬂooding attacks, Shang et al.

(Shang et al., 2017) have proposed four functional

modules (including attack detection, table-miss engi-

neering, packet ﬁlter, and ﬂow rule management) to

extend the SDN architecture in order to mitigate DoS

attacks. This solution mainly applies a packet migra-

tion mechanism to handle table-miss packets on sat-

urated switches. Obviously, missed packets are de-

toured to the attacked switches neighbours to be sent

later to the controller. In (Wang et al., 2018), the au-

thors introduced a set of triggers to resist DoS attacks

in SDN. The proposed solution, called SECOD, ex-

ecutes several functions to monitor and detect exces-

sive packet-in requests and launches a DoS mitiga-

tion mechanism. Recently, Alshra et al. (Alshra’a

and Seitz, 2019) have designed a hardware solution

to stop injection attacks. Indeed, this solution intro-

duces a new hardware component called INSPEC-

TOR, which is mainly responsible for verifying the

authentication of packet-in messages that access the

network before forwarding them to the data and con-

trol planes. This mechanism stops malicious packet-

in messages from being processed and reduces the

risks of DoS attacks.

Although these solutions ensure efﬁcient detec-

tion and mitigation of DDoS attacks, they do not con-

sider the scalability issue. Thus, the system may be

overloaded without a capability to be adapted to traf-

ﬁc variation in normal use or even during DDoS at-

tacks. Moreover, they incur complex migration tech-

niques to change switch mapping to controllers.

In this paper, SMART relies on a distributed

control plane to mitigate SPOF risks while deploy-

ing novel load balancing techniques based on Tuple

spaces. This enables a dynamic load balance among

distributed controllers to handle table miss-packets in

normal use as well as during ﬂooding attacks, without

executing complex migration algorithms.

3 RESEARCH CHALLENGES

In this paper, we address the following research chal-

lenges:

• R1 Scalability. Expand/shrink the resources pool

by dynamically adding/removing controllers to be

adapted to trafﬁc load variations with simple plug

and play approach.

• R2 Automatic/Efﬁcient Switch Migration. En-

sure dynamic mapping between SDN switches

and controllers to provide elasticity and efﬁciency

of the system during trafﬁc load variations.

• R3 Availability. Detect and prevent DDoS attacks

to guarantee the availability of both control and

data planes during DDoS attacks.

• R4 Flexibility. Be able to handle attacks for

different protocols (e.g., TCP-based attacks and

UDP-based attacks), i.e., design a solution that

works with all kinds of attack trafﬁc protocols.

• R5 Reliability. Efﬁciently deal with table-miss

packets during the DDoS attack without losing be-

nign trafﬁc.

In the following sections, we will describe how

SMART tackles these research challenges.

4 AN OVERVIEW OF TUPLE

SPACES

In this section, we start by presenting some back-

ground information about tuple spaces. Then, we de-

tail GSpace, the tuple space middleware we aim to use

in our solution.

4.1 Tuple Space

A tuple space can be considered as a shared mem-

ory object allowing different processes to execute op-

SMART: Shared Memory based SDN Architecture to Resist DDoS ATtacks

611

erations to store and retrieve ordered data sets (Car-

riero Jr, 1987). A tuple is an ordered sequence of

ﬁelds where a ﬁeld that contains a value is said to

be deﬁned. A tuple is called entry or tuple t if all

its ﬁelds are deﬁned while a tuple is called a template

t if at least one of its ﬁelds does not have a deﬁned

value. Templates are tuples used to retrieve tuples

from the tuple space, i.e., a template and a tuple match

if and only if they have the same number of ﬁelds and

all the values and types of the deﬁned ﬁelds in

t are

identical to the values and types of the corresponding

ﬁelds in t (Floriano et al., 2017). Three basic opera-

tions are executed to store and retrieve data in tuple

spaces: out(t) used to store tuple t in the space; in(

that reads and removes a tuple t that matches

t; rd(

that accesses a tuple t without removing it from the

space. in(

t) and rd(

t) are known as blocking opera-

tions: if no tuple t matches the template

t, the process

is blocked until it gets a matching one.

4.2 Bridging Gap between SDN and

Tuple Space

A tuple space is similar to a persistent storage mem-

ory: tuples can be stored in until they are retrieved by

a process. A process that creates a tuple is called a

producer while a consumer is a process that retrieves

the stored tuples. A process could be both a consumer

and producer. The communication between the pro-

ducer and consumer is decoupled in space because

any process can store a tuple which can be read by any

other process without the need to know the exact lo-

cation of the process producing the tuple. In addition,

it is decoupled in time as the tuple can be retrieved

by any process at any time. These features might be

useful in SDN architecture to allow switches to store

packet-in and then retrieve related ﬂow rules gener-

ated by controllers. Similarly, controllers have to read

and remove the packet-in from the tuple space, then

write ﬂow rules to be retrieved by the switch. This

decoupling in the communication between switches

and controllers provides more dynamic and efﬁcient

communication architecture.

Logically, a tuple space is a shared memory be-

cause the objects are shared between different pro-

cesses. However, the way in which tuple spaces are

implemented can be abstracted from its logical view.

In principle, a tuple space could be implemented as

a centralised repository. However, this would intro-

duce another SPOF. Recent implementations of tuple

spaces are built as distributed middleware where part

of the space is stored within each physical compo-

nents in the network. The main advantage here is

that it does not need any extra hardware as it can

be distributed over the switches and controllers in an

efﬁcient way. Each middleware component may be

applied to audit the accesses performed by the local

process. In this way, it becomes easier to measure

switches’ accesses to the tuple space and detect any

out of the norm access frequency which could indi-

cate a ﬂooding attack.

Finally, most of tuple space implementations

(Russello et al., 2004a; Hari, 2012) provide dynamic

load balancing features. When a node is overloaded

with tuples, the system automatically balances the

load by shifting the tuples to other nodes. This fea-

ture is extremely useful to ensure efﬁcient load bal-

ance among distributed controllers without requiring

any dedicated algorithms.

4.3 GSpace Middleware

In our proposed solution, we use GSpace which is an

adaptive middleware based on the distributed shared

data space model. In GSpace middleware, a number

of GSpace kernels are installed on several networked

nodes. Each kernel enables the storage of tuples lo-

cally besides establishing communications with other

kernels located in other nodes. GSpace kernels col-

laborate together to guarantee a uniﬁed view of the

shared data space to the components of the applica-

tion. Therefore, from the point of view of the appli-

cation, the shared data space is viewed as an only one

combined logic layer despite of being shared across

several nodes. Internally, each GSpace kernel is or-

ganised as follows.

• The System Boot Module: is responsible for ini-

tiating all the other modules of GSpace kernel.

Subsequently, it advertises its presence to other

GSpace nodes in order to establish communica-

tion channels and join a GSpace group.

• The Controller: provides the in, out and rd oper-

ations to be used by the GSpace nodes.

• The Dynamic Invocation Handler (DIH): deter-

mines which distribution policy to apply based on

the type and content of the tuple. When a node

executes a GSpace operation, DIH checks a distri-

bution policy descriptor to determine which dis-

tribution policy to apply. Once the policy has

been identiﬁed, DIH invokes a distribution man-

ager that implements the applicable policy.

• The Distribution Managers: are responsible for

enforcing distribution policies. For each distri-

bution policy supported by the system there is a

speciﬁc distribution manager. The manager may

impose that tuples are sent to or requested from

SECRYPT 2020 - 17th International Conference on Security and Cryptography

612

GSpace kernels on other nodes with respect to the

executed distribution policy.

• The Data Space Slice: provides local storage for

tuples together with the associative method for

retrieving them. In addition, a Memory Sensor

module associated with this module calculates the

memory used to store tuples on each kernel.

• The Communication Module: provides facili-

ties for sending or retrieving tuples to and from

other GSpace kernels.

• The Connection Manager: is responsible for

keeping track of information about network loca-

tions of other GSpace nodes that can be used by

distribution managers.

• The Logger: audits the executed operations on

the local kernel. Upon receiving a space opera-

tion request, the Logger is informed and then it

keeps records of all the operations executed for

each tuple type. If the number of operations for a

particular tuple type reaches a preﬁxed threshold,

the Logger informs its local Adaptation Module.

• The Adaptation Module (AM): makes the deci-

sion on starting the different phases of the adap-

tation mechanism. The adaptation mechanism en-

ables the selection of the most optimised distri-

bution policy for a speciﬁc tuple type during run-

time.

More details about GSpace functionalities can be

found in (Russello et al., 2004a; Russello et al.,

2004b).

5 SYSTEM DESIGN

To address the security challenges discussed in sec-

tion 3, we introduce SMART as an extension of the

SDN architecture to defeat DDoS attacks. In this sec-

tion, we begin by introducing a general overview of

the proposed SDN architecture 5.1. Then, we present

SMART building blocks in Section 5.2.

5.1 SMART General Overview

In this paper, we present SMART, a scalable and se-

cure SDN architecture (see Fig. 4). SMART ex-

tends the SDN basic architecture to defeat DDoS at-

tacks based on a novel use of the tuple space con-

cept. In SMART, switches are not directly con-

nected to a master controller, however they store their

packet-in requests in the tuple space as tuples. A

switch creates a tuple containing its identiﬁer and the

packet-in request and stores it in the tuple space us-

ing out(S

, Packet − in). Controllers can read stored

tuples in the space tuple by issuing in(∗, Packet −

in) (‘*’ denotes an undeﬁned ﬁeld, called wildcard).

Therefore, a controller can get any packet-in request

stored and process it regardless of the switch that

stores it. Afterwards, the controller generates a tu-

ple of the related ﬂow table entry out(S

, Flowtable)

using the same switch identiﬁer S

to ensure that it

is retrieved by the right switch. This latter issues an

in(S

, ∗) operation to retrieve the ﬂow table generated

as an answer to its packet-in request. The in operation

ensures that the switch waits until the ﬂow table rule

is stored by the controller to get it.

Beyond ensuring efﬁcient packet-in management,

SMART allows early detection of denial of service

attacks. Indeed, switches’ accesses to the tuple space

are audited to detect any ﬂooding attacks produced by

a compromised switch. When an attack is detected,

packet-in requests are detoured to a data plane cache.

This module is used to store the table-miss packets

received during DDoS attacks which are ﬁltered to

distinguish benign ones and then move them to the

tuple space to be addressed by the controllers. This

technique maintains the system availability during a

ﬂooding attack.

5.2 SMART Building Blocks

We ﬁrst assume that an initialisation phase has been

executed to grant access to the tuple space by differ-

ent controllers and switches in the network. SMART

components are detailed as follows:

• Space Tuple Access. A switch receiving a table-

miss packet generates a packet-in request and

stores it in the space tuple by executing an out

operation; out(S

, Packet − in). The switch in-

cludes its identiﬁer S

in the out operation in or-

der to retrieve later the ﬂow table generated by

a controller for its packet-in request. Then, the

switch may execute an in(S

, ∗) operation to seek

the ﬂow table related to its stored packet-in re-

quest. The in operation blocks the switch until

the expected ﬂow table is stored by a controller to

access and remove it from the tuple space. On

the other side, controllers store (∗, Packet − in)

tuple using in operation. By this, a controller

is blocked and waits for any packet-in request to

be stored without any restriction on the source of

the request, i.e., the switch that has generated the

request. A controller accesses and removes the

packet-in request, processes it and then stores the

generated ﬂow table using the switch identiﬁer

out(S

, Flowtable). Therefore, controllers dy-

SMART: Shared Memory based SDN Architecture to Resist DDoS ATtacks

613

Control Plane

SDN Controller

GSPACE Kernel

SDN Switch

Data Plane

SDN Controller

Dynamic

Invocation

Handler

System

Boot

Connection

Manager

Distribution

Manager

Distribution

Manager

Data Space

Slice

Communication

Module

Logger

Controller

Adaptation

Module

GSPACE Kernel

Dynamic

Invocation

Handler

System

Boot

Connection

Manager

Distribution

Manager

Distribution

Manager

Data Space

Slice

Communication

Module

Logger

Controller

Adaptation

Module

GSPACE Kernel

Dynamic

Invocation

Handler

System

Boot

Connection

Manager

Distribution

Manager

Distribution

Manager

Data Space

Slice

Communication

Module

Logger

Controller

Adaptation

Module

SDN Switch

GSPACE Kernel

Dynamic

Invocation

Handler

System

Boot

Connection

Manager

Distribution

Manager

Distribution

Manager

Data Space

Slice

Communication

Module

Logger

Controller

Adaptation

Module

SDN Switch

Figure 3: Deployment of GSpace components in the control and data planes of SDN. A typical setup consists of several

GSpace kernels instantiated inside all SDN controllers and switches. Each kernel provides facilities for storing tuples locally,

and for discovering and communicating with other kernels. GSpace kernels collaborate with each other to provide to the

application components a uniﬁed view of the tuple space.

namically access and process packet-in requests.

This ensures an efﬁcient and smooth communi-

cation between controllers and switches without

any need to execute sophisticated switch migra-

tion mechanisms. In addition, the space tuple

ensures an efﬁcient load balancing among con-

trollers. For instance, if a controller is ﬁlled, tu-

ples are dynamically shifted to others.

• Shared Memory Monitoring. As the tuple space

limits switches to store only one tuple by using

out primitive at a time, it is easy to count the num-

ber of tuples stored by each switch and detect if

a switch exceeds a threshold of packet-in. There-

fore, a ﬂooding attack can be detected on time and

a defence mechanism is executed.

• Scalability Module. As the tuple space man-

ages the load balance among controllers, it can de-

tect if the controllers cluster is not adapted to the

network trafﬁc. Consequently, a scalability mod-

ule can be executed to add new controllers to the

cluster. Obviously, thanks to the load balancing

feature offered by the space tuple, tuples will be

shifted to this new controller. For ease of presen-

tation, we assume that there is a number of con-

trollers dedicated to be added to each cluster.

• DDoS Detection. When the tuple space detects

an excessive number of stored packet-in requests

by the same switch, it is considered as a malicious

switch launching a ﬂooding attack. Hence, a ﬂow

entry is generated to make the switch drops all

mis-matched packets. If the switch continues to

send requests, then it is considered as an adver-

sary and the function Switch Defence is executed.

Otherwise, after executing the received ﬂow entry

by the switches, the source of the compromised

packets is identiﬁed. For instance, if it is a host

machine then the Host Defence module is acti-

vated. Meanwhile, if the malicious packets source

is another switch, then this detected switch is con-

sidered as malicious and the current switch is al-

lowed to access the tuple space again.

• Switch Defence. To mitigate DDoS attacks, the

compromised switch is prohibited from access-

ing the shared memory. Obviously, the switch

stores packet-in requests on the tuple space us-

ing its identiﬁer S

. Therefore, to block a mali-

cious switch, the tuple space routes all out opera-

tions containing the switch’s identiﬁer to the data

plane cache. During the DDoS attacks, most of

trafﬁc will be transmitted to the data plane cache

instead of ﬂooding the controllers to be ﬁltered by

the Packet Filter module. However, a switch may

forward packet-in requests received from another

switch to the tuple space. A compromised switch

may use an honest switch to launch a DDoS at-

SECRYPT 2020 - 17th International Conference on Security and Cryptography

614

Control Plane

Tuple space

Flow

Table

Data Plane

SDN Controller

Data Plane Cache

Packet

Filter

Switch (S

)

Switch (S

)

Switch (S

)

<(S

,Packet-in)>

<(S

,Packet-in)>

<(S

,Packet-in)>

<(S

,Flow Rule)>

SDN Controller

Southbound API

<in(*,Packet-in )>

<out(S

,Flow Rule)>

<(S

,Flow Rule)>

Switch (S

)

Flow

Table

Flow

Table

Flow

Table

<(S

,Flow Rule)>

<(S

,Packet-in)>

Figure 4: The SMART architecture: Switches store their packet-in requests in the tuple space as tuples without being statically

connected to a master controller. A switch stores an out(S

, Packet − in) in the tuple space. Then, it issues an in(S

, ∗)

operation to keep waiting for the ﬂow table generated by a controller. Controllers can read stored tuples in the space tuple

by issuing in(∗, Packet − in). The controller generates instructions for the packet-in request using out(S

, Flowtable) and

including the switch identiﬁer S

to be retrieved by the right switch.

tack. In this case, when a switch is blocked the at-

tack will continue through another honest switch.

To defeat this kind of attacks, before blocking a

switch the DDoS Detection module ﬁrst retrieves

the source of the attack, whether it is a switch or a

host machine.

• Packet Filter. This module uses trafﬁc informa-

tion and monitoring rules to identify normal traf-

ﬁc. If one packet-in request is regarded legal, it

will be moved to be processed by controllers.

• Host Defence. This module aims to identify the

sources of the DDoS attack when the switches are

not compromised. Then, all the packets coming

from this IP address are dropped.

6 SMART: TOWARD A SECURE

AND SCALABLE SDN

ARCHITECTURE

Basically, an SDN network consists of separating the

control plane from the data plane. Therefore, when a

switch receives a packet which does not match any

entry in its ﬂow table, it stores a packet-in request

on the control plane asking for instructions on how

to handle the received packet. The controller answers

by forwarding a ﬂow rule to the switch. To make this

communication efﬁcient and smooth, we introduce a

shared tuple space, GSpace, between the two network

layers. GSpace is a logically centralised shared mem-

ory but physically deployed inside all SDN nodes (see

Fig. 3). In our model, a GSpace kernel is imple-

mented inside all SDN controllers and SDN switches.

In the initialisation phase, the system boot module ad-

vertises its presence to all other GSpace nodes. Af-

terwards, it establishes a communication channel and

joins the GSpace group. The SDN controllers, ﬁrst,

store an out operation over a template (∗, Packet −in)

to seek for packet-in requests registered by switches.

When a switch stores a tuple on the local GSpace

kernel using out(S

, Packet − in) operation, the Dy-

namic Invocation Handler (DIH) checks the content

and the type of the tuple and executes the required

distribution policy. DIH matches the tuple against the

stored templates and invokes the Distribution Man-

ager (DM) to execute the distribution policy. After-

wards, DM follows the distribution policy and dic-

tates to which SDN controller node the packet-in tuple

needs to be forwarded. The communication between

the source distribution manager and the destination

distributed manager is done through the communica-

tion module. For each stored tuple in the GSpace

SMART: Shared Memory based SDN Architecture to Resist DDoS ATtacks

615

kernel, the data space module measures the amount

of memory that is used for storing tuples on each

kernel. This measurement is done on the switches’

kernels as well as on the controllers’ kernels. The

switch stores an out(S

, ∗) on its local kernel to keep

waiting for the instruction generated by a controller.

Following the packet-in processing by the SDN con-

troller, it stores an out(S

, Flowtable) on its local

GSpace kernel. Afterwards, the dynamic invocation

handler matches the stored tuple with the templates

already registered by the switches (out(S

, ∗)). Once

a matching tuple is found, DIH orders the distribution

manager to execute the related distributed policy in

order to forward the ﬂow table rule to the switch.

In each GSpace kernel deployed on SDN con-

trollers and switches, the memory sensor module lo-

cated in the data space module measures the tuple

stored locally by each node. For switch kernels, we

set a threshold for out(S

, Packet −in) operations. In-

deed, measuring out operations executed is used to

detect excessive accesses to the control plane by each

switch. If this threshold is reached, the logger mod-

ule considers the switch as malicious and notiﬁes the

DDoS Detection module to be activated. For instance,

this module invokes the dynamic invocation handler

on the SDN controllers’ kernels side to insert a drop

ﬂow instruction by storing an out(S

, DropFlow).

The switch which is already waiting for instructions

is notiﬁed of the generation of the ﬂow rule. Then, it

processes the received ﬂow rule.

Using information received from the memory sen-

sor module, the DDoS Detection module checks

whether the switch has stopped writing in its local

GSpace kernel or not. In this scenario, there are two

cases to be considered. On the one hand, if the switch

has installed the ﬂow rule and executed it carefully,

then the DDoS Detection module activates the host

defence module to ﬁnd out the source of the attack.

Once the IP address of the host machine is identi-

ﬁed, the host defence module orders a dynamic in-

vocation handler on the SDN controllers’ kernels to

generate a new ﬂow rule to invoke the switch to con-

tinue storing tuples on its kernel while dropping all

packets received from the identiﬁed IP address. In the

case that the identiﬁed IP address belongs to a switch

in the GSpace network, the DDoS Detection module

activates the switch defence module explained in the

following. On the other hand, if the switch ignores

the ﬂow rule generated by an SDN controller to drop

all mis-table packets and continues storing tuple on

its GSpace kernel, the DDoS Detection module con-

siders the switch as compromised. Therefore, it or-

ders the DIH to stop processing the generated tuples

and invokes the distribution manager to execute a spe-

ciﬁc distribution policy aiming that these tuples are

routed to the data plane cache module. Afterwards,

the packet ﬁlter module processes the packet-in re-

quests and moves the benign ones to the controllers

to process them. In this paper, we apply the packet

ﬁlter module concept in the same way as introduced

in (Shang et al., 2017).

In the GSpace kernels deployed on SDN con-

trollers, the memory sensor module measures tuples

stored locally by each node. A threshold is set to

monitor the SDN controllers overhead. If this thresh-

old is reached, the logger module notiﬁes the Adapta-

tion Module (AM) to select the best data distribution

policy to be adopted. In other words, a new policy

consisting of shifting tuples to other SDN controllers’

kernels is executed. In the case where the AM re-

ceives requests from all the loggers over the GSpace

network, it activates the scalability module. This lat-

ter proceeds by adding a new controller to the clus-

ter. While joining the cluster, the GSpace kernel de-

ployed in the new controller advertises its presence to

all other GSpace nodes using the system boot module.

Afterwards, the adaptation module selects a particu-

lar distribution policy aiming at shifting tuples to the

added controller. Therefore, an efﬁcient load balance

among controllers is achieved.

7 CONCLUSION

Although the popularity of SDN is increasing, it is

still facing several challenges related to scalability

and availability. In this paper, we have presented

SMART, a shared memory based architecture to re-

sist DDoS attacks. Our proposed solution combines

tuple spaces and decentralised SDN control plane. In-

deed, using a dedicated tuple space, SDN switches

may store their packet-in requests, which can be ac-

cessed by SDN controllers in a dynamic way. After

processing the packet-in requests, the controller stores

the related ﬂow rule as a tuple in the tuple space which

is retrieved by the switch. In addition to the dynamic

mapping between switches and controllers, the tuple

space can measure the number of packet-in requests

stored by a switch in order to detect any malicious ac-

tivity that triggers a mitigation strategy. Furthermore,

the controller overheads are monitored at runtime to

ensure an efﬁcient load balance among the network

nodes as well as executing a scalability process to add

new controllers when needed. In the future, we aim at

implementing a prototype of SMART and measuring

its performance in deployment scenarios.

SECRYPT 2020 - 17th International Conference on Security and Cryptography

616

REFERENCES

Alshra’a, A. S. and Seitz, J. (2019). Using INSPECTOR

device to stop packet injection attack in SDN. IEEE

Communications Letters.

Ammar, H. A., Nasser, Y., and Kayssi, A. (2017). Dynamic

SDN controllers-switches mapping for load balancing

and controller failure handling. In Wireless Communi-

cation Systems (ISWCS), 2017 International Sympo-

sium on, pages 216–221. IEEE.

Bhushan, K. and Gupta, B. B. (2019). Distributed denial

of service (ddos) attack mitigation in software deﬁned

network (sdn)-based cloud computing environment.

Journal of Ambient Intelligence and Humanized Com-

puting, 10(5):1985–1997.

Carriero Jr, N. J. (1987). Implementation of tuple space

machines.

Cello, M., Xu, Y., Walid, A., Wilfong, G., Chao, H. J., and

Marchese, M. (2017). BalCon: A distributed elastic

SDN control via efﬁcient switch migration. In Cloud

Engineering (IC2E), 2017 IEEE International Confer-

ence on, pages 40–50. IEEE.

Chen, K.-y., Junuthula, A. R., Siddhrau, I. K., Xu, Y., and

Chao, H. J. (2016). SDNShield: Towards more com-

prehensive defense against DDoS attacks on sdn con-

trol plane. In Communications and Network Secu-

rity (CNS), 2016 IEEE Conference on, pages 28–36.

IEEE.

Dixit, A., Hao, F., Mukherjee, S., Lakshman, T., and Kom-

pella, R. (2013). Towards an elastic distributed SDN

controller. In ACM SIGCOMM Computer Communi-

cation Review, volume 43, pages 7–12. ACM.

Floriano, E., Alchieri, E., Aranha, D. F., and Solis,

P. (2017). Providing privacy on the tuple space

model. Journal of Internet Services and Applications,

8(1):19.

Gelernter, D. (1985). Generative communication in Linda.

ACM Transactions on Programming Languages and

Systems (TOPLAS), 7(1):80–112.

Hari, H. (2012). Tuple space in the cloud.

Phemius, K., Bouet, M., and Leguay, J. (2014). Disco: Dis-

tributed multi-domain SDN controllers. In Network

Operations and Management Symposium (NOMS),

2014 IEEE, pages 1–4. IEEE.

Russello, G., Chaudron, M., and Van Steen, M. (2004a).

Dynamic adaptation of data distribution policies in a

shared data space system. In OTM Confederated In-

ternational Conferences “On the Move to Meaningful

Internet Systems”, pages 1225–1242. Springer.

Russello, G., Chaudron, M., and Van Steen, M. (2004b).

GSpace: Tailorable data distribution in shared data

space system. Technical report, Technical report

Technical Report 04/06, Technische Universiteit Eind-

hoven, Department of Mathematics and Computer

Science.

Scott-Hayward, S., Natarajan, S., and Sezer, S. (2016). A

survey of security in software deﬁned networks. IEEE

Communications Surveys & Tutorials, 18(1):623–654.

Selvi, H., G

ur, G., and Alag

oz, F. (2016). Cooperative load

balancing for hierarchical SDN controllers. In High

Performance Switching and Routing (HPSR), 2016

IEEE 17th International Conference on, pages 100–

105. IEEE.

Shang, G., Zhe, P., Bin, X., Aiqun, H., and Kui, R. (2017).

FloodDefender: Protecting data and control plane

resources under sdn-aimed dos attacks. In INFO-

COM 2017-IEEE Conference on Computer Commu-

nications, IEEE, pages 1–9. IEEE.

Shin, S., Yegneswaran, V., Porras, P., and Gu, G. (2013).

Avant-guard: Scalable and vigilant switch ﬂow man-

agement in software-deﬁned networks. In Proceed-

ings of the 2013 ACM SIGSAC conference on Com-

puter & communications security, pages 413–424.

ACM.

Wang, H., Xu, L., and Gu, G. (2015). Floodguard: A DoS

attack prevention extension in software-deﬁned net-

works. In Dependable Systems and Networks (DSN),

2015 45th Annual IEEE/IFIP International Confer-

ence on, pages 239–250. IEEE.

Wang, S., Chandrasekharan, S., Gomez, K., Kandeepan,

S., Al-Hourani, A., Asghar, M. R., Russello, G.,

and Zanna, P. (2018). SECOD: SDN secure control

and data plane algorithm for detecting and defending

against DoS attacks. In NOMS 2018-2018 IEEE/IFIP

Network Operations and Management Symposium,

pages 1–5. IEEE.

Yan, Q. and Yu, F. R. (2015). Distributed denial of

service attacks in software-deﬁned networking with

cloud computing. IEEE Communications Magazine,

53(4):52–59.

Zhou, Y., Zhu, M., Xiao, L., Ruan, L., Duan, W., Li,

D., Liu, R., and Zhu, M. (2014). A load balancing

strategy of SDN controller based on distributed deci-

sion. In Trust, Security and Privacy in Computing and

Communications (TrustCom), 2014 IEEE 13th Inter-

national Conference on, pages 851–856. IEEE.

SMART: Shared Memory based SDN Architecture to Resist DDoS ATtacks

617