Performance and Security Evaluation of SDN

Networks in OMNeT++/INET
Marco Tiloca Alexandra Stagkopoulou Gianluca Dini
SICS Swedish ICT AB, Security Lab KTH Royal Institute of Technology University of Pisa
Isafjordsgatan 22, Kista (Sweden) Isafjordsgatan 22, Kista (Sweden) Largo Lazzarino 1, Pisa (Italy)
Email: [email protected] Email: [email protected] Email: [email protected]

Abstract—Software Defined Networking (SDN) has been re- can be infeasible to perform the same evaluations in real,
cently introduced as a new communication paradigm in computer large-scale, networks. Especially for evaluating SDN-based
networks. By separating the control plane from the data plane monitoring systems and the impact of security attacks, it is
and entrusting packet forwarding to straightforward switches,
SDN makes it possible to deploy and run networks which are convenient to perform such assessments at design time, so not
more flexible to manage and easier to configure. This paper de- interfering with the regular operations of real networks. On the
other hand, an analytical approach is often infeasible, unless
arXiv:1609.04554v1 [cs.NI] 15 Sep 2016

scribes a set of extensions for the INET framework, which allow

researchers and network designers to simulate SDN architectures oversimplifying assumptions are made.
and evaluate their performance and security at design time. So far, there have been only a few contributions for simula-
Together with performance evaluation and design optimization
of SDN networks, our extensions enable the simulation of SDN- tion of SDN networks. Mininet is a common tool to perform
based anomaly detection and mitigation techniques, as well as the functional testing of emulated networks based on OpenFlow
quantitative evaluation of cyber-physical attacks and their impact [1]. However, it focuses on real-time functional testing rather
on the network and application. This work is an ongoing research than on the simulation and evaluation of arbitrary network
activity, and we plan to propose it for an official contribution to scenarios. The network simulator NS-3 provides an OpenFlow
the INET framework.
Index Terms—SDN; Security; OMNeT++; INET; Simulation simulation model [9]. However, the SDN controller is not
modeled as an external entity, and thus it is not possible to
quantitatively evaluate the impact of the control channel or
I. I NTRODUCTION
to consider multiple switches connected to the same SDN
In the recent years, Software Defined Networking (SDN) controller. More recently, [2] has proposed the implementation
[10] has been more and more adopted as a new network of OpenFlow components integrated in the INET framework
communication paradigm [3]. Unlike the traditional Inter- [5], based on the network simulation environment OMNeT++
net model, SDN separates the actual forwarding of network [15]. However, it models only the basic flow establishment
packets (data plane) from the management of network traffic between OpenFlow switches and a basic SDN controller. Also,
and routes (control plane). In principle, a centralized SDN it implements only flow-matching rules solely based on MAC
controller determines how to handle different traffic segments, address fields.
namely flows, and installs related forwarding rules on simple In this paper, we describe a set of extensions for the INET
switch devices responsible for the actual packet forwarding. framework that enable performance and security evaluation in
The SDN controller and the switches rely on a common set SDN networks. In particular, we have extended the model ini-
of APIs and control messages to interact with each other, so tially proposed in [2], in order to support additional OpenFlow
preventing interoperability issues among devices from differ- messages and enable the processing of network packets based
ent vendors. To this end, OpenFlow [4] has become the de- on flow-matching rules of arbitrary complexity. Also, we have
facto protocol implemented in SDN controllers and switches. provided support for SDN-based monitoring systems, accord-
By entrusting all the monitoring and decision processes to the ing to which the SDN controller: i) collects flow statistics from
SDN controller, SDN considerably simplifies the management the connected switches; ii) analyzes collected samples in order
of large-scale networks. Also, it results in a faster and more to detect possible anomalies; and iii) possibly determines and
flexible re-configuration of traffic patterns, if compared with disseminates policies to mitigate anomalies and restore normal
traditional network architectures. operating conditions in the network. Finally, we have enabled
To deploy SDN networks that operate according to ex- the simulation of effects of security attacks in SDN network
pectations, it is vital that, far before deployment, network scenarios. To this end, we consider the INET-based attack
designers can quantitatively evaluate: i) network and commu- simulation framework SEA++ that we previously described
nication performance; ii) effects and impact of security attacks in [8] and whose functionalities have been adapted to support
against the network; and iii) accuracy and effectiveness of attack simulation in SDN networks. Intuitively, the user can
anomaly detection systems [6]. To this end, network simulation describe different cyber-physical attacks by means of a high-
represents a convenient and helpful tool to adopt, since it level attack specification language, without altering the actual
implementation of any of the INET software components.
Events that reproduce the effects of the described attacks
are injected at runtime during the simulation experiments.
The approach devoted to reproducing and evaluating security
attacks is not strictly related to SDN, i.e. it can in principle
be reused together with any network architecture and scenario
sopported by the INET framework.
We believe that our extended simulation tool allows re-
searchers and network designers to effectively and conve-
niently evaluate SDN architectures at design time, both in
attack-free scenarios and in case different security attacks are
performed. In particular, it makes it possible to evaluate an
SDN scenario in terms of: i) network and communication
performance in an attack-free case; ii) effectiveness and re-
activeness of SDN-based monitoring systems; iii) quantitative Fig. 1: Flow establishment and packet forwarding.
effects of security attacks, as to how attacks affect performance
indicators in the same network scenario; and iv) quantitative
effectiveness of security countermeasures. This work is an all ports different than Port 1. Later on, upon receiving a reply
ongoing research activity, and we plan to propose it for an packet on a specific port, the switch contacts again the SDN
official contribution to the INET framework. Our extended controller, which modifies the action associated to that flow
simulation framework is currently under development, and the by specifying the exact outgoing port to consider. Finally, the
source code is available at [7]. switch forwards packet P to host B (step 7).
The paper is organized as follows. Section II overviews
Software Defined Networking. Section III describes our exten- III. SDN EXTENSIONS FOR INET
sions to the INET framework which support SDN, OpenFlow, This section overviews our extensions for the INET frame-
SDN-based monitoring systems, and simulation of effects of work. Section III-A presents the support for flow establish-
security attacks. In Section IV, we evaluate a simple Denial of ment and packet forwarding based on OpenFlow. Section
Service attack against a server host, and present preliminary III-B presents the support for SDN-based monitoring systems.
results. Finally, Section V concludes the paper and anticipates Section III-C presents the support for the evaluation of se-
future works and research directions. curity attacks. Our extended simulation framework is under
development, and the source code is available at [7].
II. PACKET FORWARDING IN SDN
SDN essentially relies on the separation of data plane and A. Support to SDN architecture and OpenFlow
control plane. In particular, the data plane is entrusted to sim- SDN relies on two fundamental elements: i) the SDN
ple switches that forward network packets according to stored controller and switches; and ii) the exchange of OpenFlow
flows and related matching rules. The control plane is entrusted messages to establish flows and install them on the switches.
to a centralized SDN controller, which establishes packet flows We have considered the model initially proposed in [2], that
and installs them on the switches. The SDN controller and provides a number of essential OpenFlow messages and the
switches interact with each other through dedicated control implementation of the switches and SDN controller nodes. In
messages and APIs, such as the ones provided by the common particular, the SDN controller is essentially a host running
OpenFlow protocol [4]. an application which relies on a typical TCP/IP stack and
Figure 1 shows an example of flow establishment and packet models a specific controller behavior. Instead, the switches
delivery. First, host A sends a packet P to host B (step 1). are modelled as a new type of node, where a control plane
Upon receiving packet P, the switch looks for a possible match running a TCP application on top of a TCP/IP stack interacts
between P and the flows installed in its flow table (step 2). If with multiple data plane instances, by means of the OMNeT++
no matching rule to process packet P is found, the switch asks signal concept. Both the SDN controller and the switches rely
the SDN controller for further instructions (step 3). Then, the on a specific time model to take into account the processing
SDN controller creates a new flow (step 4), and installs the time of real OpenFlow units.
related matching rule and actions on the switch (step 5). That We extended the model implemented in [2], providing
is, it instructs the switch that all packets coming from Port 1, additional functionalities that enable the evaluation of SDN-
with IP source address 192.168.0.1 and IP destination address based monitoring systems and impact of security attacks (see
192.168.0.2 must be sent out over Port 2. After that, the switch Sections III-B and III-C). In particular, we provided additional
installs the new flow on its flow table, as a pair of matching support to: i) exchange and process the OpenFlow control mes-
fields and actions to be performend on any packet matching sages OFPT STATS REQUEST and OFPT STATS REPLY
with that flow (step 6). If more output ports are available, the between the SDN controller and the switches for collection
switch is initially instructed to send out this first packet P over of flow statistics; ii) exchange and process the OpenFlow
 B. SDN-based monitoring systems
The SDN controller can run additional application services
to perform security monitoring of the network. This practically
relies on three modules, namely flow statistic collection,
anomaly detection, and anomaly mitigation. That is, the SDN
controller periodically sends an OFPT STATS REQUEST
OpenFlow message to the switches, according to a pre-
configured polling interval. The switches reply with an
OFPT STATS REPLY OpenFlow message, reporting the
Fig. 2: Overview of a SDN controller and switch.
packet matches and the accesses to their flow tables occurred
during the current time window. Given this information, the
SDN controller can analyze the collected statistics, and look
messages OFPT FLOW REMOVED sent by the switches to
for possible anomalies or ongoing attacks, such as Denial of
the SDN controller to report expired flows; and iii) allow the
Service (DoS) or wormhole propagation. The actual anomaly
switches to perform the matching of incoming packets with
detection process can rely on several different techniques, e.g.
installed flows based on arbitrary packet fields (rather than on
machine learning [14], data mining [13], or entropy based
MAC addresses only).
algorithms [11] [12].
Figure 2 shows the architectural overview of the SDN When the SDN controller identifies traffic anomalies or
controller (a) and a SDN switch (b). The elements coloured ongoing attacks, it performs mitigating actions to limit or
in red have been extended in our implementation, in order neutralize their impact. That is, the SDN controller sends
to enable statistic collection and network monitoring, as well OFPT FLOW MOD messages to specific switches, to install
as the reporting of flow expiration and the arbitrary-complex or update flows in their flow tables. Such flows and related
matching of packets with flows installed on switches. The policies aim at blocking malicious traffic, e.g. by dropping or
SDN controller is simply modelled as a generic host, running caching packets that are addressed to presumed victim hosts
a traditional TCP/IP stack. Then, a specific Controller appli- or coming from suspected attack sources.
cation is responsible for the establishment of flows, and their
installation, update and revocation on the switches. Of course, C. Simulation of security attacks
the Controller application can be entrusted with additional ser- Our extensions allow network designers to quantitatively
vices, such as network monitoring and anomaly detection (see evaluate the impact and effects of security attacks against SDN
Section III-B). Policies, algorithms and parameters according networks, i.e. how attacks affect performance indicators with
to which the Controller application behaves are specified in respect to the same scenario in the attack-free case. This makes
the Controller behavior module. it possible to rank different attacks according to their severity,
The switch is composed of two different segments, sharing and hence to easier select effective countermeasures to adopt.
the same Flow table. That is, the Control plane is also Rather than executing security attacks by implementing their
modelled as a typical TPC/IP stack, through which a Flow actual performance, we reproduce their effects against the
processing application can exchange control messages with network and applications. Evaluation of security attacks relies
the SDN controller. Instead, the Data plane is a set of minimal on two fundamental components, i.e. a high-level Attack Spec-
communication stacks, each one relying on a dedicated MAC ification Language and an Attack Simulation Engine, described
interface. Then, all MAC interfaces are connected to the in Sections III-C1-III-C3.
same Forwarding application, which forwards packets from We previously presented an earlier version of such compo-
an incoming MAC interface to an outgoing MAC interface, nents as part of the INET-based attack simulation framework
according to the flow-matching rules and related forwarding SEA++ [8], and adapted their functionalities to support attack
actions stored in the Flow table. If no matching is produced, simulation in SDN networks. Note that the approach adopted
the Forwarding application asks the Flow processing applica- to reproduce and evaluate security attacks is not strictly
tion to contact the SDN controller and establish a new flow, related to SDN, i.e. it can in principle be reused for any
before proceeding. network architecture sopported by INET. At the same time,
The following OpenFlow messages are considered in order our extended simulation tool makes it possible to evaluate the
to support the establishment and updates of flows. impact of security attacks that specifically consider switches
• OFPT PACKET IN. Sent by the switch to the SDN con- as actual attack victims (e.g. injection of fake flows to install)
troller, when a packet is received and no match is produced. or compromised units contributing to the attack execution (e.g.
• OFPT PACKET OUT. Sent by the SDN controller to a through packet dropping or replication). Our implementation
switch, specifying to send a packet over a specific interface. activity is currently focused on enabling the evaluation of such
• OFPT FLOW MOD. Sent by the SDN controller to a attacks involving switches.
switch, specifying to install/modify a flow in its flow table. 1) Attack description: The Attack Specification Language
• OFPT FLOW REMOVED. Sent by a switch to the SDN (ASL) allows the user to describe attacks to be evaluated, in
controller, notifying that a flow in the flow table has expired. terms of their final effects. That is, the user assumes that
attacks can be successfully performed, regardless how an
adversary can specifically mount and execute them. Then, the
user describes attacks as sequence of events that atomically
take place during the network simulation. To this end, the
ASL provides a collection of primitives organized into two
sets, i.e. node primitives and message primitives.
Node primitives account for physical attacks against
network nodes. A physical attack is composed by a single
node primitive. The following node primitives are available:

• destroy(nodeID, t) - Remove node ’nodeID’ from the

network at time ’t’, after which it cannot take part to network Fig. 3: Architecture of the Attack Simulation Engine.
communication any longer.
• move(nodeID, t, x, y, z) - Change the current position of
node ’nodeID’ to a new position {x,y,z} at time ’t’. the impact and effects of the described attacks. To this end,
the Attack Simulation Engine (ASE) considers network nodes
Message primitives account for cyber attacks and describe as implemented by an Enchanced Network Node module. The
actions on network packets. Packet fields are addressed by latter is in turn composed of: i) an Application module possibly
means of the dot notation packet.layer.field. The following including different sub-modules modelling the actual node
node primitives are available: application(s); ii) an arbitrarily complex collection of protocols
composing the communication stack; and, finally iii) a Local
• drop(pkt) - Discards the packet ’pkt’. Event Processor (LEP) module. Notice that all such modules
• create(pkt, fld, content, ...) - Creates a new packet ’pkt’ but LEP can be off-the-shelf.
and fill its field ’fld’ with ’content’. It is possible to specify The LEP module manages the attack events and operates
the content of multiple fields through a single invocation. transparently with respect to the other components of the En-
• clone(srcPkt, dstPkt) - Produces a perfect copy ’dstPkt’ hanced Network Node module. Specifically, the LEP module
of the packet ’srcPkt’. intercepts incoming and outgoing network packets traveling
• change(pkt, fld, newContent) - Writes ’newContent’ through a node’s communication stack, acting as gate-bypass
into the field ’fld’ of packet ’pkt’. between each pair of INET modules implementing the differ-
• send(pkt, d) - Schedules the transmission of a packet ’pkt’ ent communication layers. Then, depending on the considered
produced by ’clone()’ or ’create()’, after a delay ’d’. attacks to be evaluated, it can inspect and alter packets’
• retrieve(pkt, fld, var) - Assigns the content of the field content, inject new packets, or even discard intercepted ones.
’fld’ of packet ’pkt’ to the variable ’var’. Finally, the LEP module can also alter the node’s behavior at
• put(pkt, dstNodes, TX | RX, updateStats, d) - Inserts the different layers, change its position in space, or even neutralize
packet ’pkt’ either in the TX or RX buffer of all nodes in the the node by making it inactive.
’dstNodes’ list, after a delay ’d’. To address the presence of multiple network nodes and
enable the simulation of complex attacks, we instantiate an
The ASL provides statements to specify conditional attacks, Enhanced Network Node module for each network node, and
i.e. lists of events described through message primitives that a single Global Event Processor (GEP) module that connects
occur on a declared list of nodes if a condition is evaluated all the Enhanced Network Node modules with one another.
as TRUE. That is, as a general example: The GEP module is separately connected with every LEP
module, so allowing them to synchronize and communicate
from T nodes = <list of nodes> do {
with one another in order to implement more complex, possi-
filter(<condition>) <list of events>
bly distributed, security attacks. Finally, the LEP and GEP
}
modules handle packets at different communication layers
Also, it is possible to specify unconditional attacks, and conveniently access their header fields by means of the
i.e. list of attack events described through message OMNeT++ descriptor classes.
primitives, and reproduced on a periodical fashion or Figure 3 shows the overall architecture of the ASE, with
upon the occurrence of specific conditions evaluated by reference to two interconnected network nodes. Our exten-
network nodes at runtime. For instance, the statement sions integrate the Local Event Processor and Global Event
from T every P do {<list of events>} Processor modules highlighted in green within the INET
specifies that the list of events takes place periodically framework, in order to correctly manage simulation events and
on the declared list of nodes, since time T and with period P. network packets. This requires particular attention for the SDN
2) Attack Simulation Engine: After having described the switches, to maintain the separation between the Control plane
attacks to be evaluated, the user simply runs a simulation cam- and the Data plane, and to correctly manage the multiple MAC
paign on the enhanced INET framework, in order to evaluate interfaces (see Figure 2(b)).
 Note that the ASE consists in additional components inte- some node primitives may involve also the GEP as well as the
grated within the INET framework to support the processing of LEP modules of other nodes than n.
attack events. That is, we do not fundamentally modify INET • If A is an unconditional attack, from then on the ASE starts
as to the handling and scheduling of simulation events, and executing the corresponding list of message primitives, and
we do not modify any of the available applications, communi- repeatedly performs A according to the occurrence frequency
cation protocols, or physical models. Most important, the user in the attack description. The GEP is responsible for starting
is not required to implement or customize any component of the actual reproduction of uncondintional attacks.
the simulation platform.
3) Injection of attack events: The attack description based IV. E VALUATION OF A D ENIAL OF S ERVICE ATTACK
on ASL is converted into a XML configuration file by In this section, we simulate a simple Denial of Service
means of a Python Attack Specification Interpreter, and then attack against a server host, and present some preliminary
provided as input to INET upon simulation startup. Such results. We refer to the scenario in Figure 4, which includes:
configuration file is composed of three different sections, i.e i) a SDN controller and a switch; and ii) four client hosts and
a first part listing all the specified physical attacks, a second three server hosts, running a UDP application. Besides, Client1
part listing all the specified conditional attacks, and a final sends 10 packets per second to Server1; Client2 and Client3
third part listing all the specified unconditional attacks. At send 5 and 3.33 packets per second to Server2, respectively;
simulation startup, the ASE parses the XML configuration Client4 sends 5 packets per second to Server3.
file and proceeds as follows. For each node n involved in at Each flow installed on the switch expires every 30 seconds.
least one attack, the ASE: When this happens, the switch notifies the SDN controller,
• Creates one list LPn , each element of which includes the removes the flow and possibly re-establishes it upon receiving
description of one physical attack involving node n. The new packets from/to the involved host(s). The SDN controller
list elements are cronologically ordered according to the periodically collects flow statistics from the switch, according
respective attack’s occurrence time. to a configurable interval I. Besides, the SDN controller
• Creates one list LCn , each element of which includes the runs a monitoring application that analyzes flow statistics
description of one conditional attack involving node n. The in order to detect possible traffic anomalies. In particular, it
list elements are cronologically ordered according to the relies on: i) entropy-based techniques for anomaly detection
respective attack’s starting time. [11] [12]; and ii) bounded rates for transmission/reception of
• Creates one list LUn , each element of which includes the packets on a single-node basis. If traffic anomalies are detected
description of one unconditional attack involving node n. on a given flow, the SDN controller sends an OpenFlow
The list elements are cronologically ordered according to the message OFPT FLOW MOD to the switch, in order to install
respective attack’s starting time. a selective drop policy and discard all packets matching with
that flow until further notice. In this scenario, we consider
After that, the ASE starts a number of timers, each one an adversary that has compromised Client3, and exploits it to
associated to a specified attack. That is, for each node n transmit additional network packets to Server2, starting from
involved in at least one attack, the ASE: time t = 90 s, and according to a packet injection rate R.
• Creates a set of attack timers T Pn , each one of which
Figures 5 and 6 show the packet reception on Server2,
associated to one physical attack involving node n.
considering the attack-free case “No attack” as baseline. A
• Creates a set of attack timers T Cn , each one of which
value plotted at second t = s indicates the number of packets
associated to one conditional attack involving node n.
overall received by Server2 during the last second, i.e. between
• Creates a set of attack timers T Un , each one of which
t = s − 1 and t = s. Specifically, Figure 5 considers
associated to one unconditional attack involving node n.
• Starts all the timers in T Pn , T Cn , and T Un , in order to
schedule the respective attack’s occurrence.

Throughout the network simulation, the ASE proceeds as

follows. When an attack timer associated to a node n expires,
the ASE retrieves the associated attack A. Then:
• If A is a physical attack, the ASE executes the associated
node primitive, and removes A from the attack list LPn .
• If A is a conditional attack, from then on the ASE starts
intercepting packets flowing through node n’s communication
stack, by means of node n’s LPE. Intercepted packets are
filtered, based on the condition specified in the conditional
statement of attack A. For each packet that satisfies the
conditional statement, the ASE executes the list of events
described by the message primitives in A. The execution of Fig. 4: Evaluated SDN network scenario.
 70 improve the technical quality of the paper. This project has
Attack injection rate: 40 packets/s
Packets received during each second 60
Attack injection rate: 25 packets/s
Attack injection rate: 14 packets/s
received funding from the EIT Digital HII project ACTIVE,
No attack and the European Union’s Seventh Framework Programme for
50
research, technological development and demonstration under
40 grant agreement no. 607109.
30 R EFERENCES
20 [1] B. Lantz, B. Heller and N. McKeown, “A network in a laptop: rapid pro-
totyping for software-defined networks,” in The Ninth ACM SIGCOMM
10
Workshop on Hot Topics in Networks, October 2010, pp. 1–6.
[2] D. Klein and M. Jarschel, “An OpenFlow extension for the OMNeT++
0
0 50 100 150 200 250 INET framework,” in 6th International ICST Conference on Simulation
Time (s) Tools and Techniques (SimuTools ’13), March 2013, pp. 322–329.
[3] D. Kreutz, F. M. V. Ramos, P. E. Verssimo, C. E. Rothenberg, S. Azodol-
Fig. 5: Packet reception on Server2 (I=30 s). molky and S. Uhlig, “Software-Defined Networking: A Comprehensive
Survey,” Proceedings of the IEEE, vol. 103, no. 1, pp. 14–76, January
2015.
70
Statistic collection interval: 15 s
[4] D. Pitt, “Open Networking Foundation,” 2012. [Online]. Available:
Statistic collection interval: 30 s http://opennetworking.org
Packets received during each second

60 Statistic collection interval: 45 s

Statistic collection interval: 60 s [5] INET Community. INET Framework Website. [Online]. Available:
No attack https://inet.omnetpp.org/
50
[6] K. Giotis, C. Argyropoulos, G. Androulidakis, D. Kalogeras V. Maglaris,
40 “Combining OpenFlow and sFlow for an Effective and Scalable
Anomaly Detection and Mitigation Mechanism on SDN Environments,”
30 Computer Networks, vol. 62, pp. 122–136, April 2014.
[7] M. Tiloca, A. Stagkopoulou, G. Dini, “INET SDN dev,” 2016. [Online].
20
Available: https://github.com/marco-tiloca-sics/INET SDN dev
10
[8] M. Tiloca, F. Racciatti and G. Dini, “Simulative Evaluation of Security
Attacks in Networked Critical Infrastructures,” in 2nd International
0 Workshop on Reliability and Security Aspects for Critical Infrastructure
0 50 100 150 200 250 Protection (ReSA4CI 2015), published in Lecture Notes in Computer
Time (s) Science, LNCS 9338. Springer International Publishing, September
2015, pp. 314–323.
Fig. 6: Packet reception on Server2 (R=40 pkts/s). [9] NS-3 Project. NS-3 v3.16 OpenFlow switch support. [On-
line]. Available: https://www.nsnam.org/docs/release/3.16/models/html/
openflow-switch.html
different injection rates R, and shows that the greater R [10] Open Networking Foundation, “Software-Defined Networking: The New
Norm for Networks,” 2012.
the more (attack) packets are received by Server2, until the [11] S. M. Mousavi and M. St-Hilaire, “Early detection of DDoS attacks
traffic anomaly is mitigated at t = 120 s. From then on, the against SDN controllers,” in 2015 International Conference on Comput-
switch discards all packets coming from Client3 and addressed ing, Networking and Communications (ICNC 2015), February 2015, pp.
77–81.
to Server2. Figure 6 considers different statistic collection [12] S. Oshima and T. Nakashima and T. Sueyoshi, “Early DoS/DDoS
intervals I, and shows the different times that it takes to detect Detection Method using Short-term Statistics,” in 2010 International
and mitigate the attack, depending on the interval I considered Conference on Complex, Intelligent and Software Intensive Systems
(CISIS), February 2010, pp. 168–173.
by the SDN controller. [13] S.-Y. Wu and E. Yen, “Data Mining-based Intrusion Detectors,” Expert
Systems with Applications, vol. 36, no. 3, pp. 5605–5612, April 2009.
V. C ONCLUSION [14] T. Ahmed, B. Oreshkin and M. Coates, “Machine Learning Approaches
to Network Anomaly Detection,” in Proceedings of the 2Nd USENIX
We have presented our extensions to the INET framework Workshop on Tackling Computer Systems Problems with Machine
to support the evaluation of performance and security attacks Learning Techniques, ser. SYSML’07. Berkeley, CA, USA: USENIX
Association, 2007, pp. 1–6.
in SDN scenarios. Our extensions allow the user to evaluate [15] A. Vargas. OMNeT++ Community Website. [Online]. Available:
performance of a SDN architecture, assess accuracy and reac- http://www.omnetpp.org/
tiveness of SDN-based monitoring systems, and quantitatively
evaluate the impact of security attacks. We have evaluated a
simple Denial of Service attack, and presented preliminary
results. This work is an ongoing research activity, and we
plan to propose it for an official contribution to the INET
framework. Future work will focus on evaluating different
classes of security attacks, considering different SDN-based
monitoring systems and adversary models.

ACKNOWLEDGMENTS
The authors would like to sincerely thank the anonymous
reviewers and the shepherd Michael Kirsche for their insight-
ful comments and suggestions that helped to considerably