A New SDN Traffic Control Application for Security Routing in
Critical Infrastructures
Davide Adami
1
, Stefano Giordano
1
, Giuseppe D’Amore
2
, Mauro Alberto Brignoli
2
,
Enrique de la Hoz
3
and German Lopez Civera
3
1
CNIT Research Unit, University of Pisa, Via Caruso 16, Pisa, Italy
2
Vitrociset S.p.A., via Tiburtina 1020, Rome, Italy
3
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 Traffic 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
Copyright
c
2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
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 Traffic 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
Physical/Cyber
Attack
Attack
A New SDN Traffic 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
DB
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 Traffic 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
DB
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
DB
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 Traffic 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