1. Security in SDN
An Introduction
Wen-Pai Lu, Ph.D.
Luxoft
July 14, 2015
(ISC)2 Silicon Valley

2. Agenda
• Status of Networks – How they evolve?
• Why SDN?
• What is SDN?
• SDN Threat Analysis
• Deep Dive at each Layer …
• How SDN can Help to Enhance Security
• Conclusion

3. STATUS OF NETWORKS TODAY –
HOW THEY EVOLVE

4. Network Today
• Networks used to be simple: switches, routers,
LAN, protocols, switching, routing, etc.
• Add more switches, routers and networks
increases the complexity because of multiple
regions, domains, routing exchanges, loop
avoidance, etc.
• Changes in routers/switches, links, etc. takes time
to converge
• Add new elements requires careful configurations
• Networks are static and cannot adapt to today
business demands

5. More Complex in the Networks
• New and more controls required in the networks -> increase
complexity
– Traffic Engineering
– QoS
– VLANs
– ACLs
– MPLS, BGP, etc.
– Appliances
• Firewall
• NATs
• DPI
• Load Balancer
• middlebox
• Etc.
• The protocols are added to solve specific problems and they
deployed independently

6. Network Communication Protocols Today

7. Key to Internet Success: Layers
Applications
…built on…
…built on…
…built on…
…built on…
Reliable (or unreliable) transport
Best-effort global packet delivery
Best-effort local packet delivery
Physical transfer of bits
Source: Scott Shenker: The Future of Networking, and the Past of Protocols

8. WHY SDN?

9. What are the Problems
• Today’s network architecture cannot meet the demand of users,
enterprises and carriers
• Complexity in the Network
– Protocols are defined in isolation
– Networks are relatively static
– VM migration challenges many aspects of traditionally networking
– Network cannot dynamically adapt to changing traffic applications and user
demands
• Inconsistent Policies
– Difficult to apply a consistent set of access, security, QoS and other policies
• Inability to Scale
– Scaling challenges based on unpredictable traffic pattern
– Multi-tenancy and customized performance control/on-demand delivery
• Vendor Dependence
– Vendor product cycle
– Lack of standards and open interfaces

10. What are in today’s networks and
Vendor Equipment?
• Many Complex Functions
embedded in the networks
• Routing (OSPF, BGP, etc.)
• MPLS
• Metro Ethernet
• Layers 2 and 3
• Multicast
• Differentiated Services
• Traffic Engineering
• QoS
• Security (NAT, Packet Filtering,
IPSec, etc.)
Million of
lines
of source
code
Billions of
gates
Specialized Packet
Forwarding Hardware
Operating
System
Feature Feature
Routing, Switching, Device Management,
Access Control, Packet Filtering, VPN,
Mobility Management, etc.
Adapting to dynamic changes in the network is very challenging

11. WHAT IS SDN?

12. SDN
• “Software Defined Networking”
• Original works were done at UC Berkeley and Stanford
Universities (2006)
• Software – Abstracted and virtualized IT infrastructure
resources managed by “Software” via API invocations
• Defined – Applications automatically “defined”
infrastructure requirements, configuration and service
level expectation
• Networking – Infrastructure is fully programmable to
rapidly deploy workloads on optimal resources and to
instantly respond to changing business demands
• Networks becomes abstract resources

13. SDN Principles
• Separate Control Plane and Data Plane Entities
• Execute or run Control Plane software on general
purpose hardware
• Centralized network states and intelligence
• Have programmable Data Plane
– Maintain, control and program Data Plane state from a
central entity
• Data Plane also run on the commodity hardware
(White Box server or Switches)
• An architecture to control not just a networking device
but an entire network.

14. SDN Architecture
The control and data
planes are
decoupled, network
intelligence and state
centralized, and the
underlying network
infrastructure is
abstracted from the
applications
SDN Orchestration
Tools
SDN Controller
OpenFlow
Switches

15. What is OpenFlow
• Myth: SDN is OpenFlow and vice versa
• OpenFlow is a standard communications interface
defined between the control and forwarding layers of
an SDN architecture
• Allows direct access to and manipulation of the
forwarding plane of network devices, both physical and
virtual
• Overlay network protocols without disrupting
underlying fabrics
• Attractive in many environments
– Dynamic infrastructure as a service
– Made networking behave like software

16. Basic OpenFlow Architecture
Controller
OpenFlow Switch
Flow
Table
Secure
Channel
Compute
Device
OpenFlow Switch specification

17. SDN (OpenFlow) Controller
 Manages one or more switch via OpenFlow channels.
 Uses OpenFlow protocol to communicate with a OpenFlow
aware switch.
 Acts similar to control plane of traditional switch.
 Provides a network wide abstraction for the applications on
north bound.
 Responsible for programming various tables in the OpenFlow
Switch.
 Single switch can be managed by more than one controller for
load balancing or redundancy purpose. In this case the
controller can take any one of the following roles.
 Master.
 Slave.
 Equal.
17

18. OpenFlow Channel
 Used to exchange OpenFlow message between switch and
controller.
 Switch can establish single or multiple connections to same or
different controllers (auxiliary connections).
 A controller configures and manages the switch, receives
events from the switch, and send packets out the switch via
this interface
 The OpenFlow channel is a TLS/TCP connection. Switch and
controller mutually authenticate by exchanging certificates
signed by a site-specific private key
18

19. OpenFlow Network Element (Switch)
 Run on Commodity Hardware
 Consists of one or more flow tables, group table and meter
table.
 A single switch can be managed by one or more controllers.
 The flow tables and group table are used during the lookup or
forwarding phase in order to forward the packet to appropriate
port.
 Meter table is used to perform simple QOS operations like
rate-limiting to complex QOS operations like DiffServ etc
19

20. 7/15/2015 Security in SDN 20

21. Pipeline Processing
21
* Figure From OpenFlow Switch Specification

22. Control Program A Control Program B
Network OS
OpenFlow Forwarding Abstraction
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
Flow
Table(s)
“If header = p, send to port 4”
“If header = ?, send to me”
“If header = q, overwrite header with r,
add header s, and send to ports 5,6”
7/15/2015 Security in SDN 22

23. SDN Benefits
• Centralized Control of Multi-vendor environment
• Reduced complexity through automation
• Efficiency with applications, services and infrastructure
optimizations
• Higher Rate of Innovation
– Create and deliver new types of applications and services and
business model
• Scale with rapidly growing of existing applications and
services
• Increase Network reliability and Security
• More Granular Network Control
• Better User experiences

24. SDN THREATS ANALYSIS

25. Security Concerns
• Technology is new and immature
• SDN was not designed with Security in mind
• Required proprietary customization for each
implementation
• Virtual Sprawl” – automated creation of virtual
networks, each has its own security needs
• Network segment is created without security
team knowledge
• Software vulnerabilities

26. Categorization of the Security Issues…
Source: Scott-Hayward, S., O’Callaghan, G. and Sezer, S. “SDN Security: A Survey” IEEE SDN4FNS, November 2013

27. Source: Scott Hogg, “SDN Security Attack Vectors and SDN Hardenings”
http://www.networkworld.com/article/2840273/sdn/sdn-security-attack-vectors-and-sdn-hardening.html

28. Data Plane
Control & Management
7
SDN
device
SDN
device
SDN
device
Admin
Sta on
6
5
4
3
SDN
Controller
SDN control protocol
(e.g., OpenFlow )
Management connec on
(e.g., SSH )
2
Data plane
physical / logical
connec ons
SDN
device
1
Source: Diego Kreutz, Fernando Rammos and Paulo Berissimo, “Towards Secure and Dependable Software-Defined Networks”

29. Data Plane
Control & Management
7
SDN
device
SDN
device
SDN
device
Admin
Sta on
6
5
4
3
SDN
Controller
SDN control protocol
(e.g., OpenFlow )
Management connec on
(e.g., SSH )
2
Data plane
physical / logical
connec ons
SDN
device
1
Threat vector 1
forged or faked traffic
flows
Not specific to SDNs, but can be a door for augmented DoS attacks.
Possible solutions: IDS + rate bounds for control plane requests

30. Data Plane
Control & Management
7
SDN
device
SDN
device
SDN
device
Admin
Sta on
6
5
4
3
SDN
Controller
SDN control protocol
(e.g., OpenFlow )
Management connec on
(e.g., SSH )
2
Data plane
physical / logical
connec ons
SDN
device
1
Threat vector 2
attacks on vulnerabilities
in switches
Not specific to SDNs, but now the impact is potentially augmented.
Possible solutions: sw/hw attestation with autonomic trust management

31. Data Plane
Control & Management
7
SDN
device
SDN
device
SDN
device
Admin
Sta on
6
5
4
3
SDN
Controller
SDN control protocol
(e.g., OpenFlow )
Management connec on
(e.g., SSH )
2
Data plane
physical / logical
connec ons
SDN
device
1
Threat vector 3
attacks on control plane
communication
Specific to SDNs: communication with logically centralized controllers can be
exploited.
Possible solutions: threshold cryptography across controller replicas

32. Data Plane
Control & Management
7
SDN
device
SDN
device
SDN
device
Admin
Sta on
6
5
4
3
SDN
Controller
SDN control protocol
(e.g., OpenFlow )
Management connec on
(e.g., SSH )
2
Data plane
physical / logical
connec ons
SDN
device
1
Threat vector 4
attacks on and
vulnerabilities in
controllers
Specific to SDNs, controlling the controller may compromise the entire network.
Possible solutions: replication + diversity + recovery

33. Data Plane
Control & Management
7
SDN
device
SDN
device
SDN
device
Admin
Sta on
6
5
4
3
SDN
Controller
SDN control protocol
(e.g., OpenFlow )
Management connec on
(e.g., SSH )
2
Data plane
physical / logical
connec ons
SDN
device
1
Threat vector 5
lack of mechanisms to
ensure trust between
the controller and
management apps
Specific to SDNs, malicious applications can now be easily developed and deployed
on controllers.
Possible solutions: sw attestation with autonomic trust management

34. Data Plane
Control & Management
7
SDN
device
SDN
device
SDN
device
Admin
Sta on
6
5
4
3
SDN
Controller
SDN control protocol
(e.g., OpenFlow )
Management connec on
(e.g., SSH )
2
Data plane
physical / logical
connec ons
SDN
device
1
Threat vector 6
attacks on and
vulnerabilities in
admin stations
Not specific to SDNs, but now the impact is potentially augmented.
Possible solutions: double credential verification

35. Data Plane
Control & Management
7
SDN
device
SDN
device
SDN
device
Admin
Sta on
6
5
4
3
SDN
Controller
SDN control protocol
(e.g., OpenFlow )
Management connec on
(e.g., SSH )
2
Data plane
physical / logical
connec ons
SDN
device
1
Threat vector 7
lack of trusted
resources for forensics
and remediation
Not specific to SDNs, but it is still critical to assure fast recovery and diagnosis
when faults happen.
Possible solutions: indelible logging

36. LET’S LOOK AT EACH LAYER ABOUT
THE SECURITY

37. OF Network Devices – Data Plane
• Software Code Vulnerabilities
– Unstable code
– Bad Code
• Malicious code attacks
• DDoS attacks
• Target network devices from within the network
itself
• Rouge OF network devices
• Inject undesired network information to the
controller

38. Communication Channels
• OpenFlow channel defined SSL/TLS, but not
mandatory
• Authentication between the controller and
the OF devices
• DDoS Attacks – keep the link saturated

39. Control Plane
• Needs protection of the control plane and
manage authorization of access and network
applications
• Need to authenticate application access to
control plane
• Network should service business applications
needs, and business logics dictate how
security is applied

40. Controller
• Secure the Controller
• Compromising this controller gives the attackers
command of the entire network
• DDoS attacks to the controller
• Bogus Controller can change the network
topology
• Strong authentication mechanism for SDN
Controller access
• Controller Integrity

41. Northbound API to Applications
• Not define as standard yet, thus
incompatibilities may cause security holes
• Every controller has its own set of APIs
• Authentication to the applications
• Programmable northbound interfaces require
their own security policy framework,
governance, management, … these opens up a
log of very difficult to answer questions
• Communication path is not secure

42. Applications Layer – SDN layer
• No authentication mechanism for Applications
• Need to protect authenticated application from
attacks
• Applications can change how network functions
• May lack of secure coding practices
• Integrity of applications
• If policy is not synchronized, network operations
and functions could be disrupted
• Applications may not have any idea of security
policies

43. HOW SDN CAN HELP TO IMPROVE
SECURITY

44. Security Benefits
• SDN can help provide greater security without
increasing management headache for complex virtual
networks in data center.
• SDN can boost security by routing traffic, as
appropriate, through a central next-generation firewall
and intrusion prevention system
• SDN can also dynamically reprogramming and
restructuring a network that is suffering a distributed
denial-of-service attacks
• SDN can also provide capabilities such as automatically
quarantining an endpoint or network that has been
infected with malware

45. Example

46. SUMMARY

47. Summary
• The Technology is still new and evolving
• A lot of promises with many powerful
capabilities, but…
• Security was not Considered in the Original
Design
• Security Issues remains real in SDN (prevent
organizations to deploy SDN)
• SDN can be an Improvement of Security of
Networks