Security in SDN An Introduction

Wen-Pai Lu, Ph.D. Luxoft

July 14, 2015 (ISC)2 Silicon Valley

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

STATUS OF NETWORKS TODAY – HOW THEY EVOLVE

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

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

Network Communication Protocols Today

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

WHY SDN?

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

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

WHAT IS SDN?

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

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.

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

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

Basic OpenFlow Architecture Controller

OpenFlow Switch

Flow Table

Secure Channel

Compute

Device

OpenFlow Switch specification

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

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

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

7/15/2015 Security in SDN 20

Pipeline Processing

21 * Figure From OpenFlow Switch Specification

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

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

SDN THREATS ANALYSIS

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

Categorization of the Security Issues…

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

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

Data Plane

Control &

Management

7

SDNdevice

SDNdevice

SDNdevice

AdminSta on

65

4

3

SDNController

SDNcontrolprotocol(e.g.,OpenFlow)

Managementconnec on(e.g.,SSH)

2

Dataplanephysical/logicalconnec ons

SDNdevice

1

Source: Diego Kreutz, Fernando Rammos and Paulo Berissimo, “Towards Secure and Dependable Software-Defined Networks”

Data Plane

Control &

Management

7

SDNdevice

SDNdevice

SDNdevice

AdminSta on

65

4

3

SDNController

SDNcontrolprotocol(e.g.,OpenFlow)

Managementconnec on(e.g.,SSH)

2

Dataplanephysical/logicalconnec ons

SDNdevice

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

Data Plane

Control &

Management

7

SDNdevice

SDNdevice

SDNdevice

AdminSta on

65

4

3

SDNController

SDNcontrolprotocol(e.g.,OpenFlow)

Managementconnec on(e.g.,SSH)

2

Dataplanephysical/logicalconnec ons

SDNdevice

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

Data Plane

Control &

Management

7

SDNdevice

SDNdevice

SDNdevice

AdminSta on

65

4

3

SDNController

SDNcontrolprotocol(e.g.,OpenFlow)

Managementconnec on(e.g.,SSH)

2

Dataplanephysical/logicalconnec ons

SDNdevice

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

Data Plane

Control &

Management

7

SDNdevice

SDNdevice

SDNdevice

AdminSta on

65

4

3

SDNController

SDNcontrolprotocol(e.g.,OpenFlow)

Managementconnec on(e.g.,SSH)

2

Dataplanephysical/logicalconnec ons

SDNdevice

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

Data Plane

Control &

Management

7

SDNdevice

SDNdevice

SDNdevice

AdminSta on

65

4

3

SDNController

SDNcontrolprotocol(e.g.,OpenFlow)

Managementconnec on(e.g.,SSH)

2

Dataplanephysical/logicalconnec ons

SDNdevice

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

Data Plane

Control &

Management

7

SDNdevice

SDNdevice

SDNdevice

AdminSta on

65

4

3

SDNController

SDNcontrolprotocol(e.g.,OpenFlow)

Managementconnec on(e.g.,SSH)

2

Dataplanephysical/logicalconnec ons

SDNdevice

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

Data Plane

Control &

Management

7

SDNdevice

SDNdevice

SDNdevice

AdminSta on

65

4

3

SDNController

SDNcontrolprotocol(e.g.,OpenFlow)

Managementconnec on(e.g.,SSH)

2

Dataplanephysical/logicalconnec ons

SDNdevice

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

LET’S LOOK AT EACH LAYER ABOUT THE SECURITY

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

Communication Channels

• OpenFlow channel defined SSL/TLS, but not mandatory

• Authentication between the controller and the OF devices

• DDoS Attacks – keep the link saturated

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

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

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

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

HOW SDN CAN HELP TO IMPROVE SECURITY

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

Example

SUMMARY

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