Security Considerations of
Software-defined Networks
Felix Klaedtke
NEC Labs Europe, Heidelberg
SDN Security
Background
Software-defined Networking in a Nutshell
▌Networks
▌How networks operate is currently undergoing a major change
control plane
network controller
control plane
data plane
control plane
data plane
control plane
control plane
data plane
3
© NEC Corporation 2015
data plane
data plane
Software-defined Networking in a Nutshell (cont.)
▌SDN eases network operation
▌Standardized protocols between data plane and control plane
 OpenFlow is the most prominent one
 Supported by switch manufacturers
▌The network becomes “programmable”
 Automate network operation tasks
 New/better/richer network services
 Network virtualization is seen as the killer app for SDN
 Various start-ups that build network applications (software!)
▌An analogy:
In the ‘60s and ‘70s:
specialized
applications
specialized
OS
specialized
hardware
4
Still true today (mostly):
app
app
app
app
OS
(Windows, OSX, Linux)
microprocessor
© NEC Corporation 2015
specialized
features
specialized
control plane
specialized
hardware
app
app
app
app
controller
(ONOS and OpenDaylight)
switching hardware
A Software-defined Network
▌State of the art: network applications are built into the controller
 Developed/customized and deployed by the network administrator
 Controller specific
 A few exist for core network tasks (e.g., routing and monitoring)
▌Envisioned: network applications as apps on your phone
 Developed by third parties and run by all kind of network users
 Controller independent
 Various apps for all sort of tasks
(network app store, see e.g., https://hpn.hpwsportal.com/catalog.html)
OFPT_FLOW_MOD
L3
L3
L4
L4
…
5
SCR:
DST:
SRC:
DST:
10.0.0.1
11.1.1.2
5433
80
OFPT_PACKET_IN
forwarding
element
L3 SRC
L3 DST
10.*.*.*
11.*.*.*
© NEC Corporation 2015
L3
L3
L4
L4
…
SCR:
DST:
SRC:
DST:
10.0.0.1
11.1.1.2
5433
80
ACTION
fwd to port 2
north-bound
interface
SDN
controller
app 1
app 2
south-bound
interface
SDN Architecture
▌ONF’s SDN architecture
SDN Architecture Overview (version 1.1).
ONF TR-504. November 2014.
▌SDN controllers
2008
2009
FlowVisor
2011
2013
2014
Ryu
 … and many more opensource projects
 Also various proprietary controllers, e.g., NEC’s ProgrammableFlow controller
6
© NEC Corporation 2015
SDN Security
Network applications
▌Enhance security of SDN networks and build new security services
 Secure SDN networks against attacks, e.g., DoS
 Restrict and verify controller-switch interactions and secure network flows, e.g., by multitenant access control for network applications
 Leverage SDN to build new security services, such as isolated network slices
…
7
© NEC Corporation 2015
Fingerprinting
Software-defined
Networks
Motivation
▌Packets are processed much faster at the data plane of an SDN
network than on its control plane
SRC
DST
protocol
…
out port
*
R
TCP
…
1
*
R
UDP
…
2
sender
SDN
controller
receiver
▌An attacker can measure the processing times of packets
▌Information leakage about the network’s control logic
9
© NEC Corporation 2015
Exploitations
▌Knowledge about the controller-switch interactions empowers an
attacker to launch powerful DoS attacks
 Overload the controller (e.g., too many packet-in messages)
 Overload the switch (e.g., fill TCAMs)
…
SDN
controller
▌Fingerprinting the network can also be exploited for rule scanning
▌Is it feasible to fingerprint an SDN network?
 Accuracy of predicting a controller-switch interaction?
 Impact of the number of switches?
 Active versus passive attacker?
10
© NEC Corporation 2015
Testbed
▌Simulation of a data-center architecture
 3 NEC PF5240 switches and 1 OpenVswitch
 Floodlight controller
 Cross-traffic also processed by OpenFlow switches
▌Probe from Internet  firewall  OpenFlow switches  receiver
 Multiple sender locations around the globe (Amazon EC2 and Microsoft Azure)
 Measurements conducted over several weeks
▌Time-based features measured at the sender
1. Dispersion
2. Round-Trip Time (RTT)
11
© NEC Corporation 2015
Results
3 hardware switches
▌PDFN: packet does not trigger rule installation
▌PDFY: packet triggers rule installation
▌Distributions (PDFN and PDFY) significantly differ
1. Dispersion
 Stable over time
 Less affected by network size
2. Delta-RTT
 Less stable over time
 Can be extracted from passive measurement
▌ Experiments provide evidence that fingerprinting an SDN network is feasible
 With high accuracy (>95%)
 Number of hardware switches has minor impact
 Fingerprinting remains feasible even in the presence of a software switch
 Even a passive attacker can fingerprint an SDN network
12
© NEC Corporation 2015
Countermeasure
▌Control plane cannot be made significantly faster (ns instead of ms)
▌Make processing times for packets indistinguishable
 Delay matching packets at a switch before forwarding them
 Severely harms network performance
▌Delay the first few packets of “old” flows
 The delay can be determined from our observations
 Obscure attacker whether additional delay is caused by “controller-switch” interaction
or our countermeasure
 No overhead for control plane, minor impact on network performance, and effective
13
© NEC Corporation 2015
Control Plane
Security Policies
Network Policies
▌Focus on what should and shouldn’t happen with the network packets
 Which network flows are allowed (e.g., which hosts can access which servers)
 For policy enforcement: firewalls and middleboxes
▌Verification of network configurations (and also network applications)
 H. Mai, A. Khurshid, R. Agarwal, M.Cesar, B. Godfrey, S. T. King. Debugging the data
plane with Anteater. SIGCOMM 2011.
 M. Canini, D. Venzano, P. Peresini, D. Kostic, J. Rexford. A NICE way to test OpenFlow
applications. NSDI 2012.
 A. Khurshid and X. Zou, W. Zhou, M. Cesar, B. Godfrey. VeriFlow: Verifying networkwide invariants in real time. NSDI 2013.
 P. Kazemian, M. Chang, H. Zeng, G. Varghese, N. McKeown, S. Whyte. Real time
network policy checking using header space analysis. NSDI 2013.
 T. Ball, N. Bjorner, A. Gember, S. Itzhaky, A. Karbyshev, M. Sagiv, M. Schapira, A.
Valadarsky. VeriCon: Towards verifying controller programs in software-defined
networks. PLDI 2014.
 … and many more; see also the tutorial at last year’s SIGCOMM
▌What about policies for the control plane?
 How should and shouldn’t network applications interact with each other?
 How should they react to certain network events?
 Mechanisms for policy enforcement or checking policy compliance of the control plane?
15
© NEC Corporation 2015
Network Applications
▌Examples: routing, traffic monitoring, …
▌Make use of the controller’s APIs
▌Access network resources through the controller
▌Interact (directly or indirectly) with each other
▌Operated buy different entities
▌Current controllers trust the network applications;
however, network applications:
 can
 can
 can
 can
 can
wrongly interact with the controller (e.g., wrong use of APIs)
wrongly interact with each other
have competing objectives
be vulnerable (e.g., because of software bugs)
be malicious
▌Note that we also trust the controller
 Its APIs can be buggy
 It can be vulnerable
 It even can be malicious
▌… and we trust the data plane components (e.g., switches)
16
© NEC Corporation 2015
Trustworthy SDN
▌Policy enforcement/compliance checking at runtime
▌Isolation and virtualization
 Also simplifies network operation
 Reduces the risk of interference between components and network parts
 Physical resources are still shared (side channels)
 We need a trustworthy isolation platform
▌Trusted computing
 Ensures that we run the intended software
 Support from hardware and software manufactures
 Need a root of trust
 Does, e.g., not protect from software bugs
▌None is a silver bullet
 No surprise and not expected
 Mechanisms complement each other
 All can be applied to increase the trustworthiness of SDN networks
17
© NEC Corporation 2015
Privileges of Network Applications
▌Apply security principle of least privilege [Saltzer, 1974]:
“Every program and every privileged user of the system should operate using the
least amount of privilege necessary to complete the job.”
▌Extend ONF’s SDN architecture
Reference
Monitor
▌Principles of a reference monitor [Anderson, 1972]:
1. complete mediation
2. tamperproof
3. Verifiable
▌Proof-of-concept implementation for the ONOS controller
18
© NEC Corporation 2015
Network Resources
OFPT_FLOW_MOD
OFPT_PACKET_IN
app 2
L3
L3
L4
L4
…
SCR:
DST:
SRC:
DST:
10.0.0.1
11.1.1.2
5433
80
forwarding
element
L3 SRC
L3 DST
10.*.*.*
11.*.*.*
L3
L3
L4
L4
…
SCR:
DST:
SRC:
DST:
10.0.0.1
11.1.1.2
5433
80
north-bound
interface
SDN
controller
ACTION
fwd to port 2
1. The flow tables
 Hierarchical structured in flow spaces at the control plane
 Read and modify permissions
 Ownership and delegation
2. The flow rules
 Read and modify permissions
 Ownership and delegation
3. (OpenFlow) messages from data plane
4. (OpenFlow) messages to data plane
19
© NEC Corporation 2015
app 1
reference
monitor
south-bound
interface
Access Control Scheme
▌The scheme is simple and
at the controller’s southbound (OpenFlow)
 Supports the principles of a reference monitor
 Can be complemented with schemes for
higher network abstractions
▌Resemblance with access control schemes of operating systems
SDN
OS
(hierarchical) flow table
↭
directory
flow rule
↭
file
▌Attributes to express relations between flow rules
 In addition to the flow rules’ attributes (e.g., priority and timeout values) in the
OpenFlow standard
 These new attributes are attached to flow rules and
only exist at the control plane
 Example: no overwrite prevents the installation of
overlapping flow rules with higher priority
20
© NEC Corporation 2015
Policy Compliance (work in progress)
▌Our reference monitor is limited in scope
 Basic access control at the SBI of the controller
 This limitation is on purpose
▌Some policies are not enforceable by runtime monitors
 An enforceable policy is a safety property [Schneider, 2000]
 And not even all safety properties are enforceable [Basin et al., 2013]
 Enforcement might also be too expensive
▌Aim for something weaker/stronger instead
 View the SDN network as a distributed system
 Monitor the behavior of the network components
 Check (offline or online) whether behavior is policy compliant, where policies
are expressed in a rich specification language
▌Current status
 Our policy specification language allows one to express temporal constraints
 Our online algorithm soundly handles message delays and message loss
 Our prototype implementation has a throughput of up to 200 message/second
21
© NEC Corporation 2015
Concluding
Remarks
Conclusions & Future Work
“Software is eating the world”
―Marc Andreessen, 2011
▌SDN will make networks cheaper, richer, and more reliable
 Less specialized hardware
 Standardized APIs
 Network abstractions
 Virtualized network functions
 Etc.
▌… and also more secure
▌However, SDN needs to be secured by itself
 Current state-of-the-art controllers still fall short in this respect
 The control plane (and everything above) is a valuable target
 Software is, e.g., buggy and vulnerable
▌We have a rich tool set for system security
 Adapt and extend existing methods and techniques from other areas to SDN
 SDN networks are large and highly distributed systems
 Performance is critical in networking
23
© NEC Corporation 2015
Personal Opinions
There is nothing clever about SDN. Why hasn’t it be
done like this in the first place?
The speed and achievements in SDN is amazing!
24
© NEC Corporation 2015