A New SDN Traffic Control Application for Security Routing in

Critical Infrastructures

Davide Adami

, Stefano Giordano

, Giuseppe D’Amore

, Mauro Alberto Brignoli

Enrique de la Hoz

and German Lopez Civera

CNIT Research Unit, University of Pisa, Via Caruso 16, Pisa, Italy

Vitrociset S.p.A., via Tiburtina 1020, Rome, Italy

Computer Engineering Department, University of Alcala, Alcala de Henares, Spain

Keywords: SDN, Satellite Networks, Security Routing.

Abstract: In the framework of the EU-FP7 SCOUT project, RECOVER is a subsystem that enables a satellite

infrastructure, and more specifically the ground control segment, with traffic control capabilities. Basically,

RECOVER applies rules (forward, drop, re-route) to traffic flows. In this paper, we discuss the preliminary

architecture of the RECOVER subsystem. The design is based on SDN, a novel approach for computer

networking that allows network administrators to manage network services through the abstraction of

higher-level functionalities. The core of the subsystem is a new traffic control application that provides

policy-based secure routing, i.e., the ability to take on routing decisions driven by physical or network

security targets.

1 INTRODUCTION

In the last years, Software Defined Networking

(SDN) has emerged as a novel paradigm for

computer networking. By decoupling control and

data planes (ONF, 2012), (Nunes 2014) SDN

provides an abstraction of the network infrastructure

and opens up unprecedented opportunities

concerning networks programmability. The most

deployed SDN protocol, OpenFlow (Lara, 2013)

(McKeown, 2008) (ONF, 2013), allows to add or

modify, on OpenFlow-compliant switches,

forwarding rules established by a centralized

intelligence, called controller. A large variety of

network applications, such as traffic engineering,

traffic monitoring and measurements, data center

networking, security and dependability can be

designed and deployed according to the SDN

approach.

This paper focuses on security routing for critical

infrastructures and proposes a new controller that is

able to forward traffic flows along security-

constrained paths as well as to put in place different

countermeasures (e.g., traffic flows rerouting,

blocking, site isolation) in case of physical or cyber-

attacks addressed to specific assets of the

infrastructure. Indeed, through its centralized control

and traffic management architecture, SDN may

ensure the deployment of automated security

policies that also are adaptive and scalable. It is

worth highlighting that the activity has been carried

out in the framework of the Multitech security

system for interconnected space control ground

stations (SCOUT) project that has been funded by

EU under FP7 Security program (SCOUT, 2016).

The aim is to protect the main assets composing the

control segment of a satellite network from physical

and cyber- attacks through specific countermeasures.

SCOUT relies on a modular architecture with 4

subsystems: SENSNET (for the detection of

physical attacks), CYBERSENS (for the detection of

cyber-attacks), Main Control Unit (for system

control, coordination and super-vision), RECOVER

(for restoring the operation of the network

infrastructure in case of attacks).

The paper is organized as follows. Section 2

discusses the state of art concerning SDN in satellite

networks. Section 3 provides a short overview on

SDN, whereas Section 4 focuses on the architectural

choices for the design of the RECOVER subsystem.

Next, section 5 provides a detailed description of

RECOVER functional blocks. Finally Section 6

concludes the paper with some final remarks.

Adami, D., Giordano, S., D’Amore, G., Brignoli, M., Hoz, E. and Lopez-Civera, G.

A New SDN Trafﬁc Control Application for Security Routing in Critical Infrastructures.

DOI: 10.5220/0006017501290138

In Proceedings of the 13th International Joint Conference on e-Business and Telecommunications (ICETE 2016) - Volume 1: DCNET, pages 129-138

ISBN: 978-989-758-196-0

129

2 SDN AND SATELLITE

NETWORKS

Terrestrial and satellite networks have always

followed a very different evolutionary trend. Indeed,

terrestrial networks are in continuous, rapid change,

for the greater ease of applying new standards to

pre-existing infrastructures, and, nowadays,

terrestrial networks are going to take advantage of

the features made available by SDN and Network

Function Virtualization (NFV) technologies. On the

other hand, in the past, satellite networks have

followed a slower development path, mainly due to

the cost for upgrading the overall infrastructure

(space and ground segments), and the reticence of

the involved actors to modify or change operational

and service technologies.

The programmability of the network gives the

possibility to reduce CAPEX and OPEX in addition

to improve the performance in terms of QoS at end-

users level, increase the number of applications of

satellite communications and simplifies the

integration with terrestrial networks. SDN

simplifies network management and enables

automated, customized, on-demand networking with

optimize network resource utilization. The main

advantage is related to the creation of multiple and

independent virtual networks on a shared physical

infrastructures. The ground segment of a typical

satellite network can be thought as a collection of

multiple hubs interconnected via a dedicated

backbone network with some access points (e.g.,

PoP, gateways) to external networks (typically

Internet).

In satellite communication, ground segment hubs

support bidirectional communication: the use of high

frequency bands (e.g., Ka, Ku) may produce high

signal degradation, due to meteorological events,

such as clouds or rain, that might not respect the

QoS required by the service. In this case, the use of

another distant ground station can be taken into

account, following a principle, called site diversity,

that offers the possibility to connect a satellite to

several ground stations. SDN may significantly

contribute to present and future satellite networks

development simplifying the management of inter-

Ground Station handover, enabled by site diversity,

and by extending theirs capabilities (Bertaux et al.,

2015). In addition, SDN can also ease the integration

between satellite and terrestrial networks,

guaranteeing: capacity aggregation and load

balancing, through the ability to dispatch any data

stream, or portion of it, over the best available link.

Finally, SDN can make a hybrid architecture

more efficient and ease its deployment, guaranteeing

flexibility, automation, and customization to the

network.

3 SDN IN A NUTSHELL

The term SDN was originally coined to represent the

ideas and work around OpenFlow (ONF, 2012). As

originally defined, SDN refers to a network

architecture where the forwarding state in the data

plane is managed by a control plane decoupled from

the former. The networking industry has, on many

occasions, shifted from this original view of SDN by

referring to anything that involves software as being

SDN. Following (Kreutz et al., 2015), we define

SDN as a network architecture with four features:

a. The control and data planes are decoupled.

b. Forwarding decisions are flow based, instead

of destination based.

c. The control logic is moved to an external

entity, the so-called SDN controller or Network

Operating System (NOS).

d. The network is programmable through

software applications running on top of the NOS that

interacts with the underlying data plane devices.

The SDN model is depicted in Figure 1.

Figure 1: SDN Abstractions and Main Blocks.

4 RECOVER SUBSYSTEM

DESIGN PRINCIPLES

The architecture of the RECOVER subsystem is

designed keeping in mind a general scenario

involving critical infrastructures, such as satellite

DCCI 2016 - SPECIAL SESSION ON DATA COMMUNICATION FOR CRITICAL INFRASTRUCTURES

130

networks. This section reports the results of a

preliminary study before the design of the proof of

concept that is going to be used to implement the

RECOVER subsystem demonstrator in SCOUT.

4.1 SDN Deployment Models

Network virtualization is the first and simplest

deployment model to be considered. Such model

was originally introduced by NICIRA, a start-up

company that has been incorporated by VMware. In

this model, the goals are to eliminate the restrictions

on LAN partitioning (VLAN standards).

To achieve this objective, network virtualization

platforms can use hypervisor software, but

OpenStack could also be used. Here an interface

creates VLANs that are based on tunnels running on

top of traditional Ethernet. In this way, network

equipment and operations are not modified and in

theory, thousands of VLANs could be created. One

of the greatest benefit of network virtualization is

the support of multi-tenant clouds without requiring

changes to the network itself. The disadvantage is

that virtual networks, being "above" the network

layer, simply appear as traffic to the network

devices. Those devices cannot leverage their features

and prioritize individual virtual networks or monitor

their status unless a deep packet inspection is used to

identify the virtual network header. Last, but not

least, since software that is part of the cloud server

stack creates the virtual networks, these can only

link Virtual Machines (VMs) and not users and

devices.

The second model is the one most commonly

associated with the term SDN, the OpenFlow SDN

model. This model is implemented by using

OpenFlow protocol. In fact, it replaces the

traditional, distributed creation of the routing tables

in the networks devices with a centralized

forwarding. A central controller configures each

network device's flow table. This behaviour allows a

central control point where specific rules can decide

how the network is segmented or virtualized, how

traffic is managed and so forth. Any combination of

controllers and switches that supports compatible

versions of OpenFlow can be used in this SDN

model. Nowadays, nearly all networking devices

vendors have explicitly committed to supporting

OpenFlow as part of their evolutionary SDN

approach (Doyle, 2016). The controller provides

network abstraction with an integrated network

control plane, thus enabling network

programmability and services management. The

controller will be based on nowadays SDN standard

OpenFlow protocol. This protocol establishes a

common format for the exchanges of information

between the controller and the associated virtual and

physical switches by using the southbound APIs.

The solution separates the data plane from the

control plane and centralizes network control logic

into a single logical server.

The controller northbound API enables network

applications to be deployed on top of a unified

network hardware abstraction. This API exports

information about the actual network status to SDN

applications and enables them to dynamically

program the network, possibly triggered by any

event and following the controller logic.

Another deployment model is the integrated

SDN model, where the goal is to enhance the

software control of the network and its operations,

but within the “boundaries” of current networking

technology. To achieve this objective, networking

vendors are likely to align themselves with specific

standards (MPLS, VXLAN, GRE and BGP) and use

them to partition the network, manage traffic and

QoS. This could be possible by combining their

solutions into a set of management interfaces that

can be used from the cloud. Network devices that

implement this SDN model are fully integrated with

network operations like fault, configuration,

accounting, performance, security management and

network monitoring. Traffic engineering principles

can be applied, and the virtual networks can

theoretically extend from server to user, as long as

the devices support the standards used (Nolle, 2016).

Nowadays, there are several disadvantages with

this model. The first issue regards legacy devices

still present and currently used in production that do

not all support these standards and a greater problem

is the interoperability of equipments from different

vendors.

As highlighted before, there are different

approaches for the deployment of SDN,

and technology vendors do not have a unique vision

on how to implement SDN. For instance, in the

ONF community, most implementations include

an OpenFlow controller. Other SDN solutions do not

always include a controller. For example, VMWare

implements SDN protocols in its vSwitch software,

which does not require an OpenFlow

controller. ONE, the Cisco SDN architecture,

supports OpenFlow, but does not necessarily require

an SDN controller, because it prefers to embed

intelligence in its Ethernet switches and network

management software.

A New SDN Trafﬁc Control Application for Security Routing in Critical Infrastructures

131

4.2 Architectural Design Choices

Having defined the SDN deployment model based

on OpenFlow, other design choices are possible and

necessary to take in order to design a suitable SDN

solution for the SCOUT RECOVER subsystem. A

communication network can be seen as a system

with specific architectural elements, such as nodes

(i.e., switches, routers) and edges (logical

connection among nodes), interacting in two

different planes: control and data.

As previously highlighted, OpenFlow-compliant

devices allow separation between the two planes.

Routes path are decided at control plane by the SDN

Controller and a higher-level by an application.

Forwarding paths can be decided statically or

dynamically in proactive or reactive manner.

Instead, non SDN devices have built with their own

local, distributed logic at data plane level and its

evolution is controlled by the vendor without many

possible modifications by the final user. Combining

how SDN devices and not SDN devices work

together redefine the chosen model in a hybrid way.

In fact, different models can be defined according to

which paradigm provide the network service, by

who is controlling the control plane entries and in

which nodes are controlled or not (Vissicchio et al.,

2014). Some possible scenarios using an hybrid

SDN model are discussed in more details, and

shown in Figure 2, Figure 3, and Figure 4. Devices

represented in the pictures in yellow colour have

SDN capabilities, the blue ones do not have it and

the mixed-coloured ones (blue and yellow) have

both capabilities. Here we define as “node” any

network device (router or switch) independently of

having or not SDN capabilities, as “edge” the

physical or logical connection between couples of

nodes. Different scenarios can be defined according

to several device parameters: number, type (SDN-

enabled or not), position in the network. Moreover,

each of them has its own characteristics and

properties, and is more or less indicated to meet

specific business requirements than another one.

In the first scenario (see Figure 2), there is a

topology separation between different types of

nodes, i.e., a type of node can only belong to a type

of zone. In this case, the network shows three

different zones (two SDN based and one legacy).

For instance, this model can be adopted to maximize

bandwidth utilization (Jaine et al., 2013) (Hong et

al., 2013).

Figure 2: Hybrid Topology-based Model.

In the second scenario, called hybrid service-

based model, both types of devices can overlap in

some nodes and control different portion of traffic,

thus some of them can be controlled by SDN

paradigm to realize some specific type of services,

like load-balancing or tunnelling between specific

nodes. An example of this model is shown in Figure

3, where SDN can support a specific task, such as

providing full traffic visibility monitoring to specific

services (Big Switch, 2013), while other services can

still rely on legacy technologies and protocols, like

MPLS VPNs (Virtual Private Networks), or IPSec.

The most appropriate choice for this separation can

be done by design.

Figure 3: Hybrid Service-based Model.

This scenario offers wide and interesting

possibilities when deployed, for instance, in a WAN.

IT staff has a lot of options to choose from and some

of the most interesting are the following:

• bandwidth aggregation for any application;

• traffic management across links;

• traffic splitting for one application across

multiple paths for better throughput;

• assure packet delivery with multi-path;

• flexibility in controlling performance;

• increasing security.

The hybrid class-based model is the last SDN

design choice presented here and it is possible to see

in Figure 4 the partition of the traffic in classes. This

model is best suited when almost all devices have

SDN capabilities. One possible scenario suitable for

this model is when few flows generate the most of

the traffic (Sarra et al., 2012). Those flows can be

DCCI 2016 - SPECIAL SESSION ON DATA COMMUNICATION FOR CRITICAL INFRASTRUCTURES

132

aggregated in a single class and forwarded along a

specific path in order to achieve, for instance, a

better load balancing. Another possibility is to

reserve a privileged treatment to a specific traffic

class and best-effort to the other ones.

Figure 4: Hybrid Class Model.

4.3 Demonstrator Preview

This sub-section shortly discusses the architectural

choices that will be at the basis of the SCOUT

demonstrator. In the RECOVER subsystem, the SDN

controller is the central entity that makes possible

policy-based secure routing, real-time reaction to

specific events, etc. The SDN Controller could be

developed starting from open source implementations

(e.g., OpenDayLight, FloodLight, Ryu, ONOS) as

well on proprietary solutions. Virtual Switch and

Virtual Tap are examples of other applications that

can be developed by leveraging controller APIs.

Custom applications need to be written to properly

satisfy use cases scenarios.

The controller communication with the network

devices is granted by the southbound APIs and,

specifically,by the OpenFlow protocol, which can

deliver a complete instructions set to all OpenFlow

devices (physical and/or virtual) and dynamically

change the Flow Table (FT) of each device.

Adequate design and implementation are

necessary to provide the entire architecture with

security and availability features. Logical

centralization (Blial et al., 2016) and abstraction using

OpenFlow enables network and system administrators

as well as applications to access and retrieve a large

amount of information about the network (e.g.,

topology, network devices and host statistics).

Scalability and resilience are challenges, but can

be addressed properly also when a physically

centralized approach is followed. In fact, some SDN

controllers have a distributed control plane

containing a cluster of one or more physical servers

(Blial et al., 2016). The solution can be designed

with a distributed and redundant data store offering

enterprise class resilience and scalability. Multiple

controller can also be deployed in a cluster

configuration: if a controller fails, another controller

instance is automatically made available. Controller

can operate in clusters of virtual or physical systems.

For the motivations above highlighted, the final

choice in designing the architecture of the

RECOVER subsystem demonstrator, is considering

a combination of hybrid models. In fact, lots of

trade-off are obtained by combining them together.

SDN can improve network performance by

enabling multiple links to be created for reaching

any site in affordable and easy way, thus making

also network resilience a reality for many sites that

could not previously afford it. SDN approach is

appealing because it abstracts and automates some

of the most complex aspects of making use of

mixed, redundant network connections. In addition,

that abstraction makes it easier and more effective to

incorporate broadband Internet links.

Proof of concept constraints, like the fact that the

demonstrator should be tested in real Ground Station

where ICT systems must be “unchanged” and some

other should support legacy devices impose that

some nodes (subnetworks) will not have SDN

support and should necessary leave unchanged the

technology used, for example: WAN technology

based on MPLS VPNs and IPSec. One possible

scalable strategy to design the recovery subsystem

architecture is to provide different deployment

phases. Steps can be based on service-based

transition path where progressively assigning new

services to the SDN controller.

5 RECOVER ARCHITECTURE

In this section, we describe the architecture of the

RECOVER subsystem. Figure 5 shows the SCOUT

reference scenario.

Primary Path

Secure Rerouting Path

IP/MPLS or SDN

Network

Physical/Cyber

Attack

A New SDN Trafﬁc Control Application for Security Routing in Critical Infrastructures

133

Figure 5: Reference Scenario.

The critical infrastructure to be protected

consists of several (at least two) satellite ground

stations interconnected through a terrestrial network.

Both the assets belonging to each ground station and

to the interconnection network could be subjected to

physical and/or cyber- attacks. The RECOVER

subsystem should be able to apply different

countermeasures based on the type of attack and the

instructions received from the MCU.

For instance (see Figure 5), if a network device

of the terrestrial network is physically attacked,

traffic flows exchanged among ground stations (blue

path) must be rerouted to another “secure“ path

(green path). In this case, the RECOVER subsystem

should be able to reroute traffic flows following a

pre-defined strategy.

RECOVER Capabilities

The RECOVER subsystem should have the

following capabilities:

• Forward Traffic Flows: this is the default

behavior when no attack is being carried out.

Routing policies are centralized and, if required,

policy-based secure routing (e.g., avoiding specific

network segments for security reasons) can be

implemented.

• Drop Malicious Traffic Flows: when an

attack is detected by the MCU and the malicious

traffic flows are identified, policy-based secure

routing allows to block the flows and discard

malicious flows packets.

• Reroute Malicious Traffic Flows: when an

attack is detected by the MCU and the malicious

traffic flows are identified, policy-based secure

routing allows to reroute the flows to the HoneyNet

for being analyzed.

• Reroute Traffic Flows: when a portion of the

network is under attack, policy-based secure routing

allows to reroute traffic flows to another network

portion. Traffic flows can also be rerouted in case of

links or nodes failure, i.e., for network resilience

objectives.

RECOVER Interfaces

The RECOVER subsystem will be interfaced

with the following elements:

• MCU: it is expected that in case of attack, the

MCU informs the RECOVER subsystem about the

action to be taken (drop or re-route malicious traffic

flows, re-route traffic flows) and provides flows

identifiers when necessary.

• Network Devices: the RECOVER subsystem

interacts with the network devices belonging to the

critical infrastructure for retrieving information

about the network (e.g., topology, statistics) or

configuration purposes (i.e., forward, drop, re-route

traffic flows).

5.1 Architecture

In satellite networks, the Network Management

System (NMS) is typically centralized

Therefore, the architectural model of the

RECOVER subsystem we proposed for the SCOUT

framework is designed according to a centralized

approach. and following the emerging SDN

paradigm. In the SCOUT architecture, the ground

control segment will be managed by an SDN

controller that implements a policy-based secure

routing application. Moreover, the SDN controller

will provide traffic recovery in case of links or nodes

failures.

This section discusses the architecture of the

RECOVER subsystem focusing, in particular, on the

modules that compose the network controller. i.e.,

the component responsible for security-based

routing and resilience

Figure 6 shows the structure of the controller in

case an SDN-based approach is adopted. It is

relevant to highlight that the architecture we present

in this section includes mandatory and optional

functional modules.

Topology Discovery Module

This module provides and updates information

about the network infrastructure, i.e., hosts, switches

and interconnection links. Such information is

archived in the Topology database. The Topology

Discovery module may leverage library functions

that are part of the controller platform. For instance,

if POX SDN controller is chosen for the

development of SCOUT, the topology discovery

service can be designed starting from two already

existing software components: the host.tracker and

the openflow.discovery. The first one keeps track of

the hosts in the network (where they are and how

they are configured, i.e., at least their MAC/IP

addresses). When a change occurs, this component

raises a specific event. The openflow.discovery is the

key element to perform network discovery through

the usage of Link Layer Discovery Protocol (LLDP)

packets. The Topology Discovery module interacts

with the network devices using the OpenFlow

protocol and may exchange information with the

Controller Logic module. This module is optional

for the operation of the controller and can be

disabled in case the automatic discovery and

DCCI 2016 - SPECIAL SESSION ON DATA COMMUNICATION FOR CRITICAL INFRASTRUCTURES

134

dynamic update of the topology is not required.

Indeed, the topology could be “statically” provided

by the system administrator using a specific XML

file.

Figure 6: RECOVER Architecture.

Network Statistics Handler

Using the OpenFlow protocol, the Network

Statistics Handler module retrieves port statistics

(e.g., Transmitted/Received bytes or packets) from

each OpenFlow switch of the network, calculates

link utilization (in both directions) and updates the

Topology database with the current value of link

utilization. Moreover, Network Statistics Handler is

able to retrieve statistics at flow level and to keep

track of mappings between flow-table entries and

flows average rate, obtained through an estimation

procedure similar to the one adopted for calculating

links utilization. This information is contained in the

so–called Flows database and used for rerouting

purposes. This module is optional. If enabled, the

Network statistics (e.g., link utilization) can be used

by the Path Computation Algorithm, implemented in

the Controller Logic module or in the MCU, to

calculate routing and re-routing paths according to

the link load.

Controller Logic

Using a Path Computation Algorithm, such as

the Shortest path First (SPF), this module computes

the forwarding paths for incoming and outgoing

traffic flows, taking eventually into account specific

constraints and targets (e.g., bandwidth, latency,

load balancing). Moreover, this module is used to

compute the forwarding paths for traffic flows to be

rerouted in case of physical or cyber-attacks

addressed to specific network links and devices

(switches or routers). This module is mandatory and

interacts with the MCU, the OpenFlow Rules

Handler, TOWER (if enabled) or directly Topology

DB (if TOWER is disabled).

Traffic Flow Routing

When a new traffic flow is detected by one of

the edge OpenFlow-enabled network devices, the

Controller Logic calculates a path between the

source and destination nodes of the flow, retrieving

the topology stored in the Topology DB and filtered

by the TOWER subsystem.Next, OpenFlow rules

are installed on the network devices along the

forwarding path by means of the OpenFlow Rules

Handler module and the Flows Database is updated

in order to keep track of all installed paths and

associated traffic flows (see Figure 7).

Update

Flows Database

Flows

Database

Traffic Flow

TOWER

Topology

Run

Path Computation

Algorithm

Topology

install

Path

Figure 7: Policy-Based Secure Routing.

Traffic Flows Re-routing or Dropping

These operations occur when physical or cyber-

attacks are detected. In such situations, the MCU

implicitly or explicitly instructs the RECOVER

subsystem to “re-route” or “drop” traffic flows.

-Physical Attacks: the MCU triggers a “topology

change”. The new topology differs from the old one

because switches and links under attacks are pruned.

New forwarding paths for re-routing traffic flows

passing through those links and switches are

calculated using the Path Computation Algorithm

implemented by the Controller Logic. Then, using

the OpenFlow Rules Handler, OpenFlow rules are

modified (added or removed) on the network

switches along the old and the new forwarding

paths. The Flows Database is updated to keep track

of all active forwarding paths and associated traffic

flows (see Figure 8).

A New SDN Trafﬁc Control Application for Security Routing in Critical Infrastructures

135

Select Flows

to be rerouted

Flows

Database

Physical Attack

(Nodes, Links)

TOWER

New Topology

Run

Path Computation

Algorithm

Topology

Secure

Paths

Tear-Down under attack paths

Set-Up Secure Paths

Update Flows DB

Figure 8: Traffic Flows Rerouting (Physical Attack).

-Cyber-attacks: the MCU may request the

RECOVER subsystem to perform two different

actions: drop traffic flows or re-route traffic flows.

Action

(Drop, Reroute)

Flows

Database

Cyber Attack

TOWER

New Topology

Run

Path Computation

Algorithm

Topology

Secure

Paths

Tear-Down under attack paths

Set-Up Rerouting Paths

Update Flows DB

Tear-Down Flow Path

Update Flows DB

Drop

Reroute

Figure 9: Traffic Flows Rerouting (Cyber Attack).

In the first case, i.e., when the malicious traffic

flows are identified, the MCU sends to the

RECOVER subsystem a list with the identifiers of

the flows to be blocked. The Controller Logic

retrieves from the Flows Database information about

the forwarding paths of the flows and instructs the

OpenFlow Rules Handler to remove the related

forwarding rules from the switches along the

forwarding paths.

In the second case, the MCU triggers a “topology

change”. The new topology is different from the old

one because links and switches under attacks are

pruned. New forwarding paths for re-routing traffic

flows passing through those links are calculated

using the Path Computation Algorithm implemented

by the Controller Logic module. Next, using the

OpenFlow Rules Handler, forwarding rules are

modified (added or removed) on the network

switches along the old and new forwarding paths.

The Flows Database is updated to keep track of

active forwarding paths and associated traffic flows

(see Figure 9).

Moreover, if required by the MCU, anomalous

traffic flows, instead of being dropped can be

redirected to the HoneyNet fot analysis.

This module is mandatory. If disabled, the

MCU is responsible for Path Computation in case of

attacks.

OpenFlow Rules Handler

This module translates the path information

generated by the MCU and passed to the Controller

Logic into OpenFlow rules. It is also responsible for

adding/removing them in each switch. As described

in Section 3, possible actions on the packet are:

1. forward it to outgoing port(s);

2. encapsulate it and forward it to the controller;

3. drop it;

4. send it to the normal processing pipeline; and

5. send it to the next flow table or to special

tables, such as group or metering tables introduced

in the latest OpenFlow protocol.

This module is mandatory.

Topology Database

This database maintains updated information

about the topology of the network, including end-

user LANs and attached hosts.

For each switch, detailed information about

interfaces, links and links costs are stored in the

database and refreshed when changes occur.

Flows Database

This database maintains updated information

about active flows, including source and destination

addresses, intermediate network devices addresses.

Topology Optimization for Network Enhanced

Resilience (TOWER)

The purpose of the TOWER module is to

provide a network topology which ensures, as far as

possible, certain service guarantees in critical

infrastructures when a malicious attack happens. The

process defined by TOWER is based on several

inputs: i) A threat analysis aims to create a detailed

analysis of the value, risks and attack resilience of

all the network elements that must be protected

against attacks. ii) A multilayer graph will be the

responsible of modeling the network structure of the

critical infrastructure to be protected. The multilayer

dimension of the model will let us to express the

hidden and complex dependencies between the

different elements of the network. This model also

lets to give us a wider understanding of the

consequences of an attack. iii) Information about

attacks will be provided to TOWER for being able

DCCI 2016 - SPECIAL SESSION ON DATA COMMUNICATION FOR CRITICAL INFRASTRUCTURES

136

to evaluate the status and performance of the

network and respond smartly. This information

includes the type of attack, location, elements under

the attack… For that reason, a link between a cyber-

physical IDS and the recovery module must be

created.

With all these inputs, TOWER proposes a

network topology that is able to tackle the malicious

attack isolating it and minimizing its impact in the

whole network as the consequence of the cascading

failure produced by the attack. The multilayer model

is basic to capture all the dependencies among the

different elements in the critical infrastructure,

enabling us to analyze the interdependencies that

may emerge from the network elements and the risk

analysis performed over them. It is important to note

that TOWER will not propose a unique network

topology but a ranked list of different topologies

ordered by a certain score metric. The final choice of

the topology will depend on the metric that the user

prefers to be optimized and in addition this list

provide different options for the rest of the recovery

module. It is of paramount importance to take into

account that the network topology the TOWER

proposes depends on the type of attack detected, as

different types of attacks can spread differently in

the network. This can be easily understood by means

of two examples. On the one hand, for a DDoS

attack TOWER will propose a network topology

where the paths under attack and traffic are cut and

traffic is rerouted to other backup paths. On the

other hand, if a server is compromised, the network

topology proposed by TOWER will isolate that

server and limit the communications made by all the

nodes that could have been reached from that server,

so pivoting attacks that employ accessible servers to

reach the internal network, that could not be attacked

otherwise, are also covered by the TOWER analysis.

Another important challenge of TOWER

consists in avoiding, or at least minimizing, the

possibility of exposing the network to new or even

worse weaknesses in the network topology proposed

by TOWER. The complex relations and

dependencies between nodes of the critical

infrastructure can be represented through different

metrics that let us to analyze the status of the

network and, at the same time, to compute how to

react to a malicious attack. Examples of such metrics

are: Wiener index, graph density, clustering

coefficient, degree centrality, hub and authority

centrality (Chakrabarti, 1999), PageRank centrality

(Brin, 1998), Katz centrality (Katz, 1953) or

betweenness centrality (Koschützki, 2005).

6 CONCLUSIONS

This paper focused on the preliminary design (i.e.,

functional specifications and architectural blocks) of

the RECOVER subsystem, in the SCOUT project,

according to the emerging SDN approach. Proposing

the introduction of SDN in satellite networks, and,

more specifically in their control segment, represents

a big challenge and outstanding innovation that are

being addressed by SCOUT. In most cases, satellite

networks are very static infrastructures, deployed for

specific purposes and vendor locked-in.

Programmability, agility, manageability and open

standards adoption, which are basic features of SDN,

are essential ingredients to speed up the evolution of

satellite networks and to deliver new services to end

users.

More specifically, in this case SDN is the ground

for building a satellite infrastructure resilient to

physical and cyber-attacks: according to the

proposed architecture, the RECOVER subsystem is

provided with a traffic control application that

enables security routing and packet filtering by

leveraging an SDN control platform.

RECOVER subsystem architecture is going to

adopt a hybrid SDN model by using a centralized

Controller implemented by using the

OpenFlow standard protocol configuring each

network device's flow table.

ACKNOWLEDGEMENTS

This work has been carried out in the framework of

the EU FP7 SCOUT project (GA Number: 607019).

REFERENCES

ONF, Software-Defined Networking: The New Norm for

Networks”, ONF White Paper, 2012.

Nunes, B.A.A., et al. A Survey of Software-Defined

Networking: Past, Present, and Future of

Programmable Networks”, IEEE Communications

Surveys and Tutorials, vol. 16, no. 3, pp. 1617-1634,

2014.

Lara, A., et al. Network Innovation using OpenFlow: A

Survey”, IEEE Communications Surveys and

Tutorials, vol. 16, no. 1, pp. 493-512, 2013.

McKeown, N., et al. OpenFlow: Enabling Innovation in

Campus Networks”, ACM SIGCOMM Computer

Communication Review, vol. 38, no. 2, pp. 69-74,

2008.

A New SDN Trafﬁc Control Application for Security Routing in Critical Infrastructures

137

ONF, “OpenFlow Switch Specification”, Version 1.4.1

(Protocol version 0x05), 2013.

SCOUT Project Official Web Site Home Page:

[http://www.scout-project.eu/], May 2016.

Kreutz, D., et al. Software-Defined Networking: A

Comprehensive Survey, Proceedings of the IEEE |

Vol. 103, No. 1, January 2015.

Bertaux, L., et al. Software Defined Networking and

Virtualization for Broadband Satellite Networks, IEEE

Communications Magazine, March 2015.

Vissicchio, S., Vanbever, L., Baonaventure, O.

Opportunities and Research Challenges of Hybrid

Software Defined Networks, ACM SIGCOMM

Computer Communication Review, vol. 44, no. 2,

April 2014.

Nolle, T. Three models of SDN explained, Web Page

[http://searchtelecom.techtarget.com/tip/Three-models

-of-SDN-explained], Access on May 2016.

Doyle, L. Do I need to use an SDN controller for software

defined networking, Web Page [http://searchsdn.techta

rget.com/answer/Do-I-need-to-use-an-SDN-controller-

for-software-defined-networking], Access on May

2016.

Jaine, S., et al. “B4: experience with a globally-deployed

software defined wan”, SIGCOMM, 2013.

Big Switch, Open SDN for Network Visibility, Big Switch

Networks solution guide, 2013.

Sarrar, N., et al. Leveraging zipf’s law for traffic

offloading, SIGCOMM Comput. Commun. Rev., vol.

42, no. 1, pp. 16–22, 2012.

Blial, O., Ben Mamoun, M., and Benaini, R. An Overview

on SDN Architetture with Multiple Controllers,

Journal of Computer Networks and Communications,

vol. 2016 (2016),

Hong, C.Y., et al. Archieving high utilization with

software-driven wan, SIGCOMM, 2013.

Chakrabarti, S., Dom, B., Kumar, R., Raghavan, P.,

Rajagopalan, S., Tomkins, A., Gibson, and D.,

Kleinberg, J.: Mining the web’s link structure. IEEE

Computer 32, 60–67 (1999).

Brin, S., Page, L.: The anatomy of a large-scale

hypertextual web search engine. Computer Networks

and ISDN Systems 30, 107–117 (1998).

Katz, L. A New Status Index Derived from Sociometric

Index. Psychometrika, 39-43, 1953.

Koschützki, D., Lehmann, K.A, Peeters, L., Richter, S.

Tenfelde-Podehl, D. and Zlotowski, O.. Centrality

indices. Network analysis. Lecture Notes in Computer

Science. 3418:16–61, (2005).

DCCI 2016 - SPECIAL SESSION ON DATA COMMUNICATION FOR CRITICAL INFRASTRUCTURES

138