1. SDN + NetSec
Vyas Sekar

2. Goals of this lecture Overview of SDN Understand Ethane, early SDN
Understand security concerns with SDN

3. Papers for this class Ethane, one of early SDN pioneers
AvantGuard (will be basis for HW2)

4. SDN: A Major Trend in Networking
Entire backbone
runs on SDN
Bought for $1.2 x 109
(mostly cash)

5. Network Management Traffic Engineering Performance Security Compliance
Resilience
Networks start off providing a basic functionality – send packets from point A to point B. But that’s not the end of the story .. Administrators want to achieve other things with the network – performance

6. Problem: Toolbox is bad!
Traffic Engineering Performance
Security
Compliance
Resilience
Toolbox today

7. Why: Toolbox is implicit in routers!
Traffic Engineering Performance
Security
Compliance
Resilience
Makes the network really brittle, makes it hard to reason whether your policy goals are being met. Toolbox relies on some complex distributed routing algorithms to converge, not clear what happens under failures etc

8. “Ossification”  Innovation
Closed equipment
Software bundled with hardware
Vendor-specific interfaces
Over specified
Slow protocol standardization
Few people can innovate
Equipment vendors write the code
Long delays to introduce new features

9. High-level view of SDN Decouple data from control plane.
Controller
Config
Config
Networks start off providing a basic functionality – send packets from point A to point B. But that’s not the end of the story .. Administrators want to achieve other things with the network – performance
Decouple data from control plane.
Logically centralized management
Configurable hardware with programmable API

10. Historical Perspective of SDN
Active Nets
Separation of control
OpenFlow ++

11. Papers for this class Ethane, one of early SDN pioneers
AvantGuard (will be basis for HW2)

12. Motivation Enterprise configuration Existing solutions
Error prone: 60% of failures
Expensive: 80% of IT budget
Existing solutions
Place middleboxes at chokepoints
Retrofit via Ethernet/IP mechanisms

13. Specific Problem: Access Control

14. Three principles in Ethane
Descriptive/declarative policies
Tie it to names not locations/addresses
Packet paths determined explicitly by policy
Binding between packet and origin
No spoofing
Accountability

15. Three Basic Features in OpenFlow
Controller
Secure
Channel
Open
Protocol
Config
Config
Simple
Flow
Actions
Networks start off providing a basic functionality – send packets from point A to point B. But that’s not the end of the story .. Administrators want to achieve other things with the network – performance
Flow
Table

16. Ethane/OpenFlow Operation
L2 Forwarding application
Controller
(e.g., NOX)
SDN Controller
(2)
(3)
(1)
(4)
(5)
SDN Switch
Host A
Host B
A  B: Forward
Flow Table in SDN Switch

17. FlowTable Actions Forward on specific port/interface
Forward to controller (encapsulated)
Drop
Forward legacy
Future support: counters, modifiers

18. Advantages of Ethane Switches Dumb No complex protocol
Simpler memory architecture
Focus purely on forwarding

19. Comments on Design Common vs worst case design? Latency, scalability
False drops/positives

20. Some optimizations/constraints
Only support exact matches
Controller has to reverse paths
Controller reliability
Cold, warm, hot

21. Drawbacks Support for broadcast is limited
Overlays could still circumvent policy
Using port numbers/matches is unreliable

22. Goals of this lecture Overview of SDN Understand Ethane, early SDN
Understand security concerns with SDN

23. Threat vectors map Threat vector 1 forged or faked traffic flows
Admin
Station
SDN Controller
Control & Management
SDN device
SDN device
SDN device
Data Plane
SDN device 1
Not specific to SDNs, but can be a door for augmented DoS attacks.
Possible solutions: IDS + rate bounds for control plane requests

24. Threat vectors map Threat vector 2
exploiting vulnerabilities in forwarding devices
Admin
Station
SDN Controller
Control & Management
SDN device 2
SDN device
SDN device
Data Plane
SDN device
Not specific to SDNs, but now the impact is potentially augmented.
Possible solutions: software attestation with autonomic trust management

25. Possible solutions: threshold cryptography across controller replicas
Threat vectors map
Threat vector 3
attacking control
communications
Admin
Station
SDN Controller
Control & Management 3
SDN device
SDN device
SDN device
Data Plane
SDN device
Specific to SDNs: communication with logically centralized controllers can be explored.
Possible solutions: threshold cryptography across controller replicas

26. Threat vectors map Threat vector 4
exploiting vulnerabilities in controllers 4
Admin
Station
SDN Controller
Control & Management
SDN device
SDN device
SDN device
Data Plane
SDN device
Specific to SDNs, controlling the controller may compromise the entire network.
Possible solutions: replication + diversity + recovery

27. Threat vectors map Threat vector 5
lack of trust between the controller and apps 5
Admin
Station
SDN Controller
Control & Management
SDN device
SDN device
SDN device
Data Plane
SDN device
Specific to SDNs, malicious applications can now be easily developed and deployed on controllers.
Possible solutions: software attestation, security domains

28. Motivation Two security challenges that SDN poses:
Scalability Challenge: Data plane/Control plane communication bottleneck
Control plane saturation attack
Responsiveness Challenge: Slow detection of, and responses to, the changing flow dynamics within the data plane
Sort of see where they are coming from. But these are not necessarily the case in sdn. Google is doing sdn clearly without facing any scalability issues!

29. AVANT-GUARD (AG) Overview
AG proposes two data plane extensions:
Connection Migration: sift bad traffic at data-plane
Actuating Triggers: data-plane can take pre-specified actions
obv

30. Control Plane Interface Flow Table (TCAM and SRAM)
AG Architecture
Control Plane
Control Plane Interface
Connection Migration
Actuating Triggers
Flow Table Lookup
Packet Processing
AVANT-GUARD
Two modules added to data plane
Flow Table (TCAM and SRAM)
Data Plane

31. Connection Migration
Goal: Add intelligence to the data plane to differentiate those sources that will complete TCP connections from sources that will not.
Main Idea: The data plane does not hand over TCP connections to the control plane until it is verified and fully established.
Builds on the stateless TCP handshake using SYN cookies.
obv

32. Connection Migration: Overview
Takeaway: Reducing data plane/control plane communication overhead
obv

33. Connection Migration Flowchart for handling TCP SYN/RST/FIN packets
obv

34. Connection Migration
Flowchart for handling TCP ACK packets
obv

35. Connection Migration Put Together
obv

36. Actuating Triggers
Goal: Delegating part of getting reports and taking actions to data plane.
Mechanisms:
Enabling the data plane to asynchronously report network status and payload information to the control plane.
Activate a flow rule under some predefined conditions to help the control plane manage network flows without delays.
obv

37. Actuating Triggers
obv
Condition can be based on payload, traffic rate, or rule activation.

38. New OpenFlow Commands
obv

39. Proposed AG SDN Switch

40. Takeaways SDN ideas: Simplifies management New security problems
Decouple data and control
Consolidate management
Open programming APIs for networking
Simplifies management
Centralized, network-wide views
Clean abstraction
New security problems
Single point of failure, scalability, control plane attacks
Lots of excitement (and adoption) from industry!

41. Next class Intrusion detection systems
Other cornerstone of netsec in addition to firewalls
Design of a canonical and popular NIDS
How to evade/attack NIDS!