Transcript OpenFlow Controller DDoS Vulnerability

MITIGATING LAYER 2 ATTACKS:
RE-THINKING THE DIVISION OF LABOR
M.Sc Final Project
Nir Solomon
Supervised by: Prof. Anat Bremler-Barr
December 2015 | IDC Herzliya
General Idea in One Slide

While OpenFlow’s whole-view enables to gather network statistics to
prevent attacks, it is also susceptible to some

Specifically: ARP Poisoning and Controller DDoS

We will show how these attacks are executed

Also –the Controller cannot support the load of handling all the
forwarding decisions by itself

Our solution – called Reactive ARP Query, helps mitigate these attacks

By shifting Control-plane responsibilities back to the switch!
Controller
SDN Switch
Outline

OpenFlow – Intro

Legacy Network Layer 2 Attacks

Our Contribution

Related and Previous Work

SDN Layer 2 Attacks

Proposed Solution

Evaluation

Conclusions
OPENFLOW – INTRO
OpenFlow - Introduction
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION

Provides a scalable way to manage SDN networks
EVALUATION

Control-Plane and Data-Plane
CONCLUSIONS

A centralized Controller

“Whole” view of the network

The ability to gather information and statistics from every network
component
OPENFLOW – INTRO
OpenFlow – Flow Tables
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION

Every flow that has been installed by the Controller, is added to a “flow
table” residing on the Switch
Rule
SRC MAC
DST MAC
Action
Rule 1
AA:BB:CC:DD:EE:EE
00:20:B9:CC:2D:A8
Output to port 1
Rule 2
00:11:22:33:44:BE:EF
00:6F:25:1B:99:0C
Output to Port 2
Rule 3
* (Don’t Care)
* (Don’t Care)
Send to Controller
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
OpenFlow – Learning Switch
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION

An application running on the Controller

Reactively installs flows on the switch for every packet that don’t have a
matching flow and arrives an the Controller

This event is called a packet-in

The next time that a packet is received by the switch, it will be handled and
forwarded automatically
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
OpenFlow – Reactive & Proactive
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
Reactive
Proactive
PROPOSED SOLUTION
triggers controller to insert
flow entries
 Efficient use of flow table
 Every flow incurs small
additional flow setup time
 If control connection lost,
switch has limited utility
table in switch
 Must know the network
topology ahead of time
 Zero additional flow setup time
 Essentially requires
aggregated (wildcard) rules
 Hard to install new flows after
the network starts operating –
problematic in BYOD networks
CONCLUSIONS
 Packet not matching any flow
 Controller pre-populates flow
EVALUATION
OPENFLOW – INTRO
The ARP Protocol
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
 ARP Request:
EVALUATION
–
CONCLUSIONS
Argon broadcasts an ARP request to all stations on the network:
“What is the hardware address of 128.143.137.1?”
OPENFLOW – INTRO
The ARP Protocol
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
 ARP Reply:
EVALUATION
–
CONCLUSIONS
Router 137 responds with an ARP Reply which contains the
hardware address
OPENFLOW – INTRO
The ARP Protocol - Cache
 Hosts maintain a table (ARP Cache) of current entries for each NIC installed
 The entries expire after some time (implementation dependant – e.g.
Windows XP - 2 mins, RedHat - 60 secs).
 For example, an ARP cache in Windows (“arp -a” ):
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
The ARP Protocol – Gratuitous ARP
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
Gratuitous ARP - an ARP request/reply that is not normally needed according to the RFC
but could be used in some cases

Request: the packet has the source and destination IP both set to the IP of the machine
issuing the packet and the destination MAC is the broadcast address

Reply: is a reply to which no request has been made
Useful for:
 Detecting IP conflicts

Push update to other machines’ ARP tables (e.g. when host changes its IP address)

Inform switches of the hosts’ address on a given switch port
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
Layer 2 Attacks – ARP Poisoning
 A forged ARP Request or Reply can be used to update the ARP cache of a
remote system with a forged entry
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
EVALUATION
To:
00:00:00:00:00:03
192.168.1.2
CONCLUSIONS
Alice
MAC: 00:00:00:00:00:01
IP: 192.168.1.1
Bob
MAC: 00:00:00:00:00:02
IP: 192.168.1.2
Switch
192.168.1.2 is at
00:00:00:00:00:03
192.168.1.1 is at
00:00:00:00:00:03
Eve
MAC: 00:00:00:00:00:03
IP: 192.168.1.3
OPENFLOW – INTRO
Layer 2 Attacks - DDoS
 The attempt to make a machine or service unavailable to its legitimate
users, by consuming its resources by a large group of attackers
 A DDoS scenario may quickly worsen, such as when sending a packet to
the victim will cause him to send a reflected packet to another host
 In many cases, the best solution to contain the damage is to use Rate
Limiting
 We will show that it is possible to create a Layer 2 DDoS on the
OpenFlow Controller, while using only ARP packets
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
Our Contribution
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
In summary, our work makes the following contributions:

Overview of an ARP Poisoning attack and its execution in an OpenFlow network

Presentation of a new attack vector on OpenFlow - ARP level Distributed Denial of
Service (DDoS) attack on the OpenFlow Controller

Extension of the current implementation of OpenFlow to include new mechanisms
to mitigate Layer 2 attacks, and an evaluation
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
Related & Previous Work
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION

Legacy ARP Poisoning Mitigation:


OpenFlow Vulnerability Assessments – including DDoS:


[Shin and Gu, 2013]
Shifting responsibilities from the Controller to the Switch:


[Yan et al, 2015], [Kloti et al, 2013], [Benton et al, 2013]
Using specially-crafted packets to attack OpenFlow networks:


[Nam et al, 2010]
[Shin et al, 2013], [Curtis et al, 2011]
Using the Whole-View of SDN to mitigate network attacks:

[Braga et al, 2013], [Phaal et al, 2013], [Porras et al, 2013], [Porras et al,
2012]
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
LEGACY LAYER 2 ATTACKS
SDN Attacks - ARP Poisoning
OUR CONTRIBUTION
RELATED WORK
Table 0
SRC MAC
IN PORT
Action
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
To:
00:00:00:00:00:03
192.168.1.2
00:00:00:00:00:01 1
GOTO Table 1
00:00:00:00:00:02 2
GOTO Table 1
00:00:00:00:00:03 3
GOTO Table 1
Table 1
Alice
MAC: 00:00:00:00:00:01
IP: 192.168.1.1
Bob
MAC: 00:00:00:00:00:02
IP: 192.168.1.2
SDN Switch
DST MAC
Action
00:00:00:00:00:01 OUTPUT to 1
00:00:00:00:00:02 OUTPUT to 2
00:00:00:00:00:03 OUTPUT to 3
192.168.1.2 is at
00:00:00:00:00:03
192.168.1.1 is at
00:00:00:00:00:03
Eve
MAC: 00:00:00:00:00:03
IP: 192.168.1.3
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
SDN Attacks – Controller DDoS

We would like to overload the Controller with multiple packet-in events

An attacker can spoof a packet as he likes

Let us create a specially crafted packet that will cause a packet-in

This attack is unique to OpenFlow and inherent in its design
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
LEGACY LAYER 2 ATTACKS
SDN Attacks – Controller DDoS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
No Flow
available
OpenFlow Controller
PROPOSED SOLUTION
EVALUATION
 Send to
Controller
CONCLUSIONS
Packet-in
OpenFlow
Switches
Crafted
Packet
OPENFLOW – INTRO
SDN Attacks – Controller DDoS

Controller: running on a MacBook Pro with 16GB of RAM and Core i7 CPU

Attacker: simulated with Cbench on an Ubuntu machine with Core i5 CPU and 4GB
of RAM

Reaching a certain threshold of about 1.3 Mpps (million packet-ins per second), the
number of responses does not increase correspondingly
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
Solution - Desired Properties


A “normal” Reactive learning switch enables both ARP Poisoning and
a DDoS attack
We would like to define a solution with the following properties:
 Little
load on the Controller
 Lesser number
A

Reactive solution
We can use multiple or distributed Controllers to mitigate DDoS
 This

of flows installs on the Switch
is an orthogonal solution
We will compare our proposed solution to the Reactive
approach, and the tradeoffs of using it
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
Solution - Shifting Control-Plane
Responsibilities
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION

Usually, separation between the control plane and the data plane
 Creates

a load on the Controller
Shifting responsibilities from Controller  Switch
 Allowing
the switch to hold the IP to-MAC mappings of the hosts
connected to it


Similar to all the mappings usually held by the Controller
Shifting control plane responsibilities has been suggested:
 AvantGuard
[Shin et al, 2013]
 DevoFlow [Curtis
et al, 2011]
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
Solution – General Idea
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION

In both Layer 2 attacks, spoofed ARP packets are used
EVALUATION

We aim to retain:
CONCLUSIONS


IP-to-MAC mappings and MAC-to-Physical port mappings

Of each host connected to the switch

Saved in the switch, in the form of OpenFlow flows
When a new host connects to the network, we want to “authenticate” it

No matching flow for a packet sent from the new host

We will send a “Reactive ARP Packet”

If and only if the host is validated, we will send a packet-in to the Controller

Else: drop the packet
OPENFLOW – INTRO
Solution – Attacker Types
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION

When discussing the use of spoofed ARP packets, there are two kinds of
attackers:

Naive Attacker: will not reply to an ARP request for the (MAC, IP) he
spoofs

Sophisticated Attacker: will reply to an ARP request for the (MAC, IP)
he spoofs
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
Solution – Possible Scenarios
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
When sending the Reactive ARP Query, there are three possible scenarios:

Two ARP replies (one with expected MAC, one with other MAC)

Invalid ARP reply (a packet is returned with a different MAC address
than expected/No reply)

Valid ARP reply (matching IP and MAC)
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
LEGACY LAYER 2 ATTACKS
Solution – Scenario 1
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
Scenario 1: Two ARP replies (one with expected MAC, one with other MAC)
EVALUATION
This is a sophisticated attacker!
CONCLUSIONS
192.168.1.1 is at
WHO HAS 192.168.1.154?
00:00:00:00:00:99
Spoofed SRC MAC:00:00:00:00:00:99
Spoofed SRC IP: 192.168.1.1
DROP!
(no packet-in)
WHO HAS 192.168.1.1?
Controller
Eve
MAC: 00:00:00:00:00:03
IP: 192.168.1.3
SDN Switch
192.168.1.1 is at
00:00:00:00:00:01
Alice
MAC: 00:00:00:00:00:01
IP: 192.168.1.1
SRC MAC
SRC IP
SRC PORT
Action
00:00:00:00:00:01
192.168.1.1
1
GOTO Table 1
OPENFLOW – INTRO
LEGACY LAYER 2 ATTACKS
Solution – Scenario 2
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
Scenario 2: Invalid ARP reply (a packet is returned with a different MAC
address than expected/No reply)
EVALUATION
CONCLUSIONS
DROP!
WHO HAS 192.168.1.154?
Spoofed SRC MAC:00:00:00:00:00:99
WHO HAS 192.168.1.1?
Spoofed SRC IP: 192.168.1.1
(no packet-in)
Controller
Eve
MAC: 00:00:00:00:00:03
IP: 192.168.1.3
SDN Switch
192.168.1.1 is at
00:00:00:00:00:01
Alice
MAC: 00:00:00:00:00:01
IP: 192.168.1.1
SRC MAC
SRC IP
SRC PORT
Action
00:00:00:00:00:01
192.168.1.1
1
GOTO Table 1
OPENFLOW – INTRO
LEGACY LAYER 2 ATTACKS
Solution – Scenario 3
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
Scenario 3: Valid ARP reply
EVALUATION
CONCLUSIONS
Packet-out+
Install Flow
192.168.1.99 is at
WHO HAS 192.168.1.2?
00:00:00:00:00:99
Spoofed SRC MAC:00:00:00:00:00:99 WHO HAS 192.168.1.99?
Packet-in
Spoofed SRC IP: 192.168.1.99
Controller
Eve
MAC: 00:00:00:00:00:03
IP: 192.168.1.3
Alice
MAC: 00:00:00:00:00:01
IP: 192.168.1.1
Host
(or attacker)
is validated
SDN Switch
SRC MAC
SRC IP
SRC PORT
Action
00:00:00:00:00:01
192.168.1.1
1
GOTO Table 1
00:00:00:00:00:99
192.168.1.99
3
GOTO Table 1
OPENFLOW – INTRO
Solution – What About the Last
Scenario?
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION

A sophisticated attacker may still be validated – he can still create packet-ins!
EVALUATION

We can use a Rate Limiting mechanism
CONCLUSIONS


Rate limit only the table misses

Only the physical port of the sender
Also used against DNS DDoS Amplification attacks
OPENFLOW – INTRO
Solution – Rate Limiting
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION

“With regard to denial-of-service vulnerabilities, controller vendors need
to emphasize the importance of rate-limiting.”

“Even for an application as simple as this one (Learning Switch) protecting it
requires implementing MAC spoofing protection through port counters (with
timers if network flexibility is required), rate limiters for traffic to unknown
hosts, and switch rules for multicast.”

“Networks that rely heavily on PacketIn messages (i.e. reactive designs)
can be exposed to denial-of-service attacks against the switches and
controller(s) without complex rate-limiting logic in the controller.”
OpenFlow Vulnerability Assessment, [Benton et al, SIGCOMM 2013]
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
Solution – Rate Limiting
(Continued)
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION

Work is being done to gather network statistics in OpenFlow
EVALUATION

Flow Collector - Percentage of Pair-flows (PPf) – [Braga et al, 2013]
CONCLUSIONS

“Pair-Flow”:

The source IP of flow 1 must be equal to the destination IP of flow 2

The destination IP of flow 1 must be equal to the source IP of flow 2

Both flows must have the same communication protocol

DDoS increases the number of “single-flows”

A switch that has a host suspected as a sophisticated attacker, may use these
statistics to decide if the physical port has a large number of single-flows, and
limit it accordingly

Out of the scope of this work
OPENFLOW – INTRO
Solution – Assumptions
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION

We assume a steady state when the network starts operating

If an attacker binds the victim’s IP address to its MAC address before
the victim connects, the victim’s packets will be dropped

Can be prevented:

By using our solution as soon as the network starts operating

Or by installing proactive rules for all known safe hosts ahead
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
Solution – The Division of Labor
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION

There is a fine line between the Control Plane and the Data Plane
EVALUATION

Only some suggested that this line should be crossed
CONCLUSIONS

‫״‬When thinking of the default component used to mitigate network
attacks in an SDN network, we think of the Controller‫ ״‬- [Braga et al,
2013]

We conclude that the Controller, by itself, cannot hold these
responsibilities, as the load may cause it to stop function correctly

Instead, our approach takes the a different direction; we shift these
responsibilities from the “default” component, the Controller (control
plane) into the switch (data plane)
OPENFLOW – INTRO
LEGACY LAYER 2 ATTACKS
Evaluation – ARP Poisoning
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
EVALUATION
192.168.1.2 is at
00:00:00:00:00:02
CONCLUSIONS
WHO HAS 192.168.1.2?
DROP!
Alice
MAC: 00:00:00:00:00:01
IP: 192.168.1.1
Bob
MAC: 00:00:00:00:00:02
IP: 192.168.1.2
SDN Switch
192.168.1.2 is at
00:00:00:00:00:03
192.168.1.2 is at
00:00:00:00:00:03
Eve
MAC: 00:00:00:00:00:03
IP: 192.168.1.3
(also: no packet-in)
Table 0 – Steady State
SRC MAC
SRC IP
IN
PORT
Action
00:00:00:00:00:01
192.168.1.1
1
GOTO Table 1
00:00:00:00:00:02
192.168.1.2
2
GOTO Table 1
OPENFLOW – INTRO
Evaluation – DDoS
Naive Attacker - Packet-ins
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION


Using a normal OpenFlow Switch, each spoofed packet requires a
packet-in to be received by the Controller
Using the Reactive ARP Query Switch, no packet-ins are received at the
Controller at all
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
Evaluation – DDoS
Naive Attacker - Flows Installed
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION


Using a normal OpenFlow Switch, two flows will be installed for each
packet-in - one matches on the source, and one on the destination
In our solution, we drop the attacking packet, without installing any
flows, and without informing the Controller
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
Evaluation – DDoS
Sophisticated Attacker - Packet-ins
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION

Using a normal OpenFlow Switch, each spoofed packet requires a packet-in
to be generated by the switch and received by the Controller

Using the Reactive ARP Query Switch, the rate of the packet-ins are limited
(in our case, to 100 packets per second, chosen arbitrarily)

If the Rate-Limiting rate is N pps, then we can assure that the maximum
packet-in rate at the Controller will be N pps as well
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
Evaluation – DDoS
Sophisticated Attacker - Flows Installed
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION


Using a normal OpenFlow Switch, two flows will be installed for each packetin - one matches on the source, and one on the destination
In our solution, we rate-limit the incoming packet-ins, so the rate of the
creation of new flows depends on the rate limitation
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
Evaluation – Network Overload
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION
The three possible scenarios are:

Two ARP replies (one with expected MAC, one with other MAC).

Invalid ARP reply (a packet is returned with a different MAC address than
expected/No reply).

Valid ARP reply (matching IP and MAC).
The attacker
Might
be the attacker’s
isAttacker.
naive and
packet
a single
or a valid
Reactive
hostsent
the
ARPby
connected
packet
isto
used
for
network. by the
Sophisticated
The
first
packet
him will
betheintercepted
the us
Let
packet
assume
to be
theReactive
dropped.
worst case
scenario
host is for
an attacker.
We will packet
send anto
ARP
switch.
A single
ARP
packet- that
will this
be issued
the attacker’s
validation,
and he will be validated. No more packets from him with his SRC MAC will be
be
dropped.
validated as a flow is being installed by the Controller. Thus the network overhead here is only
a single packet
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
Conclusions
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
We presented the execution of Layer 2 attacks in OpenFlow
network:
ARP Poisoning; and a Layer 2 DDoS on the Controller, which
is an inherent vulnerability in OpenFlow networks.
We have proposed an extension to OpenFlow –
Reactive ARP Query. While our solution has only a minor network
overhead, both attacks can be mitigated successfully.
This is a major step in changing our approach by
shifting the control plane responsibilities back to the switch.
PROPOSED SOLUTION
EVALUATION
CONCLUSIONS
OPENFLOW – INTRO
Future Work
LEGACY LAYER 2 ATTACKS
OUR CONTRIBUTION
RELATED WORK
SDN LAYER 2 ATTACKS
PROPOSED SOLUTION

We hope to allow the creation of a “smart” Rate-Limiting algorithm, by
gathering flow metrics from the whole network


Rate-Limit the physical port according to the flow metrics gathered
We hope to also implement the Reactive ARP Query extension on a physical
switch. This implementation will allow the evaluation of its performance while
running as a totally independent data plane component
EVALUATION
CONCLUSIONS
Questions?
Thanks!