1. Security and software-defined-networks
Markku Antikainen

2. Me Markku Antikainen Got M.Sc. from Aalto and KTH (Sweden) in 2011
Worked as a security consultant in Nixu Ltd
Mostly information security management projects
Doctoral student at Aalto since
Currently visiting the University of Cambridge

3. What I hope you’ll learn
Presentation title: “Security and software-defined-networks”
What is SDN and why it is a big thing
OpenFlow (de facto controller-plane protocol)
What kinds of new threats SDN introduces that did not exist in traditional distributed networks
How to protect against these threats
Another side of the coin: how SDN can be used to improve security

4. Structure of the lecture
Introduction to SDN and OpenFlow
What are the threats against a OpenFlow SDN
How the threats compare to traditional networks
How SDN can be used to improve security

5. Short introduction to SDN and OpenFlow
11/18/2018

6. Traditional networking
Traditionally, routers have two high-level functionalities
Control-plane functionality (routing protocols, QoS protocols)
Forwarding functionality (high speed forwarding based on rules stored in the forwarding tables)
Control plane and data plane are coupled!
Router
Control prot.
(OSPF, RSVP …)
Forwarding table Forwarding HW
11/18/2018

7. Traditional networking - problems
Difficult and expensive to deploy new protocols
What if you want to switch from OSPF to AcmeRoutingProtocol?
Decision making is distributed
may lead to suboptimal decisions as no entity knows the state of the whole network
Routers become more complex and thus too expensive
(Well, the OpenFlow switches are not that cheap either…)
Router
Control prot.
(OSPF, RSVP …)
Forwarding table Forwarding HW
11/18/2018

8. Software defined networking
Idea: Replacing the distributed control-plane with a logically centralized one s
routing
access control
QoS
Control programs
Controller
- logically centralized - global network view - ”programs” switches
OpenFlow
API
Forwarding plane
- stupid switches - forward packets according to controllers instructions
11/18/2018

9. Software defined networking
Idea: Replacing the distributed control-plane with a logically centralized one s
routing
access control
QoS
Control programs
Controller
- logically centralized - global network view - ”programs” switches
OpenFlow
API
Forwarding plane
- stupid switches - forward packets according to controllers instructions
11/18/2018

10. Brief intro to OpenFlow (1)
Controller – switch signaling
Several versions, most recent is 1.5
Uses TCP
TLS optional (authentication, confidentiality etc.)
Outband vs. inband control channel s
ctrlr
11/18/2018

11. Brief intro to OpenFlow (2)
Built around the concept of flow
Flow is "an artificial logical equivalent to a call or connection.“ [RFC 2722]
The controller configures switches flow tables
The controller uses OpenFlow protocol for this
The switch forwards packets based on the rules in the flow-table
Match fields to match against packets
Counters to update for matching packet
Actions to apply to matching packets
Match fields
Counters
Actions
11/18/2018

12. Flow table Match fields Actions Ingress port
Counters
Actions
Match fields
Ingress port
Ethernet src, dst, VLAN id
IP 5-tuple
Actions
Drop packet or forward it to physical or virtual port(s)
Send packet to the controller
Modify the packet
Modify or set VLAN identifier or priority
Modify Ethernet source or destination addresses
Modify IP source or destination addresses
Modify TCP or UDP ports
11/18/2018

13. Example
IP:
11/18/2018

14. Example
IP:
Src IP:
Dst IP:
Payload
11/18/2018

15. Example buffer Dst IP: controller Src IP: switch 1 OF packet-in
Payload
11/18/2018

16. Example buffer IP: 9.8.7.6 Src IP: 1.2.3.4 Dst IP: 9.8.7.6 Payload
OF add flow-table entry
Match fields:
Dst IP: Action:
Forward to int:1
11/18/2018

17. Example buffer Dst IP: switch 1 Src IP: controller OF packet-out
Send buffered msg to interface 1
OF packet-out
Dst IP: switch 1
Src IP: controller
IP:
buffer
Src IP:
Dst IP:
Payload
11/18/2018

18. Example buffer IP: 9.8.7.6 Src IP: 1.2.3.4 Dst IP: 9.8.7.6 Payload
11/18/2018

19. SDN security threats
11/18/2018

20. SDN security threats
It is difficult to make generalizations about SDN security
There are lot of different kinds of networks
Datacenter networks (network in physically secure premises)
Operator networks (network devices out in the open) …
The capabilities of the attacker are not well defined
Does the attacker have insider access?
Can the attacker install rootkits on the switches? How?
Thus, we are often limited to thinking what-if scenarios
Assume that the attacker has compromised a part of your system and think what are the possible consequences

21. SDN security threats
My approach (roughly) follows a typical risk analysis approach:
Identify assets in the network
Identify risks / threats affecting the assets
Focus on the plausible scenarios
Consider potential consequences of a successful attack
Discuss the most obvious security measures

22. Assets in the network (simplified)
Kreutz, D. et al., Towards secure and dependable software-defined networks, Hot Topics in Software Defined Networking - HotSDN ’13
11/18/2018

23. Some threat vectors
Kreutz, D. et al., Towards secure and dependable software-defined networks, Hot Topics in Software Defined Networking - HotSDN ’13
11/18/2018

24. Threat vectors Obviously, not a complete list!
Attacks on vulnerabilities in controllers
Attacks on vulnerabilities in administrative stations
Attacks on control-plane communication (OpenFlow)
Forged or faked traffic flows
Attacks on vulnerabilities in switches
More interest? Kreutz, D. et al., Towards secure and dependable software-defined networks, Hot Topics in Software Defined Networking - HotSDN ’13
11/18/2018

25. 1. Attacks against the controller(s)
Compromising a controller
Compromise the controller and you’re able to do almost anything
The controller is very obvious target
Mitigation: hardening, regular patching, security monitoring etc.
I.e. academically not very interesting…
Remember, the controller is logically centralized entity
OF-switches in same network may use different controllers
Thus, compromising one controller does not necessarily mean full control over the entire network

26. 1. Attacks against the controller(s) (cont’d)
Compromising one of several controllers
Attacker gets access to a part of a network and to C-to-C channel
I.e. the attacker may also affect the decisions of the other controller
Mitigation:
As on previous slide

27. 2. Attack on vulnerabilities in administrative stations
Admin station(s) as the target
Compromise an admin station and you’re able to do quite a lot
As controllers, the admin stations are also very obvious targets
Not SDN specific threat – similar attack also possible in traditional networks
Mitigation: hardening, regular patching, security monitoring, strong authentication, etc.
Again, not academically very interesting…
Remember, though, that academically uninteresting does not mean irrelevant in real life!

28. 3. Attacks on control-plane communication (i.e. OpenFlow)
The control-plane communication is what truly differentiates SDN from traditional networking
-> More interesting than the previous?
Three possibilities:
MitM’ing the OpenFlow connection
Impersonating switches to the controller
Impersonating controller to a switch
11/18/2018

29. 3. Man-in-the-Middle, OpenFlow
MitM’ing gives the attacker full control over the OF-switch
Quite realistic threat especially with inband control-channel
Mitigation
Secure channel with mutual authentication (i.e. TLS)
Although mitigation sounds easy, distributing keys to hundreds(?) of switches is not trivial
Initial key distribution, renewing keys …
The key distribution problem is a common problem! Not specific to SDN!
Is there a way around the mutual authentication?
E.g. by only authenticating the controller
11/18/2018

30. 3. Attacks on control-plane communication (cont’d)
Do you really need to authenticate the switch?
If only controller is authenticated, an attacker can poison the controller’s networks view by spoofing several OF-switches!
I.e., mutual authentication is needed
Also, the real problem lies in key management
11/18/2018

31. 3. Attacks on control-plane communication (cont’d)
Another concern about mutually authenticated TLS
It is not supported by all OpenFlow devices
TLS is not even mandatory feature in OpenFlow specifications
It was in OF 1.0 but was later removed
11/18/2018

32. 4. Forged or faked traffic flows
Attacker floods the network with carefully crafted packets causing e.g. DoS
At least two ways how DoS can be achieved:
If you can flood the controller
If you get switches’ TCAM memories filled
In both cases, the attacker needs to know details how the network behaves
11/18/2018

33. 4. Forged or faked traffic flows (cont’d) Flooding the controller
The attacker crafts packets that a switch always sends to the controller for processing
The attacker may try to flood the network with these hoping that this would congest the controller
11/18/2018

34. 4. Forged or faked traffic flows (cont’d) Filling TCAMs
Filling switches TCAMs
The attacker crafts packets for which the controller always creates a new flow entry
A full TCAM causes problems because
New potentially high-hitting flow-entries cannot be installed thus leading to…
… more packets being sent to controller for processing
… dropping packets when the buffers become full
This attack only works with hardware switches
Typical hardware switches can store ~1k-10k flow entries due to the limited TCAM size
Software switches do not have this problem!
11/18/2018

35. 4. Forged or faked traffic flows (cont’d) Finding suitable packet formats
Previous DoS attacks require that the attacker knows what kinds of packets are handled by the controller
The attacker may deduce this by measuring the round-trip times
Works when trying to flood the controller
and when trying to fill switches’ TCAMs
11/18/2018

36. 4. Forged or faked traffic flows (cont’d)
Mitigation
Rate-limiting packets sent to the controller
Introduced in OpenFlow version 1.3
Design the controller logic flooding attacks in mind
Use as much aggregated flow-entries as possible
Use software switches in places where you must have a lot of flow entries
General principle for creating networks: intelligence to the network edges and muscle to the core
11/18/2018

37. 5. Attacks on vulnerabilities in switches
Attacker compromised an OpenFlow switch
Kind of unusual idea since usually you assume that network equipment is trusted
Nevertheless, a scenario worth thinking since
APT-attackers are becoming more and more common
Device base becomes increasingly homogeneous
OF-switches (virtual switches in particular) are often regular Linux boxes
Cannot rely on the protection given by proprietary software
Questions
What operations can an attacker do with a OpenFlow switch?
What kinds of attacks are possible assuming an attacker who controls one OF switch?
11/18/2018

38. 5. Attacks on vulnerabilities in switches
Let’s consider a scenario where the attacker has compromised a hardware switch
It would seem that the attacker is limited to the OpenFlow packet processing primitives when altering the traffic flows
Packet forwarding
Simple packet header modification
However,
By rerouting some packets to an external computer, the attacker can effectively perform arbitrary computations on the packets
11/18/2018

39. 5. Attacks on vulnerabilities in switches (cont’d) Control-channel hijacking
Idea:
Reconfigure the switch to use another attacker’s computer as its controller
Route OF packets from the original controller to the attacker’s new controller
What the attacker gains:
Ability to spoof the state of the compromised switch
Capability for arbitrary computation
11/18/2018

40. 5. Attacks on vulnerabilities in switches (cont’d) Control-channel hijacking
Idea:
Reconfigure the switch to use another attacker’s computer as its controller
Route OF packets from the original controller to the attacker’s new controller
What the attacker gains:
Ability to spoof the state of the compromised switch
Capability for arbitrary computation
Configurations
Controller IP:
Use TLS: True
Flow table, entry 1
Src IP:
Action: send to ctrlr
11/18/2018

41. 5. Attacks on vulnerabilities in switches (cont’d) Control-channel hijacking
Idea:
Reconfigure the switch to use another attacker’s computer as its controller
Route OF packets from the original controller to the attacker’s new controller
What the attacker gains:
Ability to spoof the state of the compromised switch
Capability for arbitrary computation
Configurations
Controller IP:
Use TLS: True
Flow table, entry 1
Src IP:
Action: send to ctrlr
11/18/2018

42. 5. Attacks on vulnerabilities in switches (cont’d) Control-channel hijacking
What kind of damage can an attacker cause with a single switch?
Sniff and MitM unencrypted traffic
Also non-protected control-plane traffic in case of inband control channel!
This we already have discussed about
Get intel about the network (topology, routing etc.)
Poison the controller’s network view
May be used to DoS by causing non-optimal routing and congestion
Attract traffic to the compromised switch (can be used in sniffing or launching a MitM on some data-plane traffic) …
11/18/2018

43. 5. Attacks on vulnerabilities in switches Poisoning controller’s network view
Several reasons why an attacker wants to spoof topology
Attract more traffic to a compromised switch
Creating congestion to certain links …
A compromised switch can lie about its neighbors
But only about its neighbors
Topology spoofing is also possible in traditional networks!
Actually, the attack is more severe in a traditional network
In SDN, a compromised switch can only lie about its immediate neighborhood
In routed network, a compromised router can spoof e.g. distances to any other node (in distance vector routing)
11/18/2018

44. 5. Attacks on vulnerabilities in switches Poisoning controller’s network view
A single compromised switch is very limited in how well it can modify the topology
Regardless, it is possible to cause major changes in routing
Connect two neighbors directly to each other
I.e. the compromised switch would simply relay packets between the two neighbors without appearing on the path A B
11/18/2018

45. 5. Attacks on vulnerabilities in switches Poisoning controller’s network view
Already this may cause major changes in routing
1-hop shorter path is a major difference as network diameters are often quite small
Of course, true effect still depends on the topology
The distance distributions appear like binomial distributions with relatively small variance
11/18/2018

46. Building security with SDN
11/18/2018

47. Building security with SDN
So far I’ve discussed:
What is SDN (and OpenFlow)
Some ways how software defined networks can be attacked
The other side to the topic ”SDN security” is to discuss what kinds of security services can be build with SDN technologies
I’ll briefly go through some ideas from the literature
11/18/2018

48. Security functions as SDN applications
The idea of SDN is that you’d be able to deploy new network functionalities simply by creating new code
In theory, many security functions can be built as applications on the SDN controller
E.g. firewall, DDoS detection, scan detection …
The problem with this approach:
OpenFlow provides very limited access to packet-level information
OpenFlow forwarding plane is almost stateless
Switches are unable to actively monitor flow status without the involvement of the controller
Thus, stateful packet inspection with OpenFlow is difficult
11/18/2018

49. DDoS Mitigation
OpenFlow is suitable for DDoS mitigation since coarse filtering rules can be used to mitigate most DDoS attacks
Usually traffic comes from relatively well defined IP ranges
DDoS attacks change the traffic patterns drastically
Idea:
Study the normal traffic patterns
When under an a DDoS, block IP-address ranges from which the server is not accessed much normally
Performs surprisingly well!
For more information: Kalliola et al.; Denial-of-Service Mitigation for Internet Services, 2014, LNCS 8788
11/18/2018

50. (Security) service chaining
Idea
Instead of spreading middleboxes all over the network, centralize the services
If traffic needs some service (e.g. firewalling), route the flow via a centralized FW
Useful e.g. in datacenter nets and operator nets
Reduces operation cost
Increases operational flexibility
11/18/2018

51. Conclusion
11/18/2018

52. Conclusion There are (at least) two angles to the ”SDN security”
The security challenges created by the paradigm
The security solutions that SDN paradigm/technologies enable
Making SDN deployment secure is not witchcraft
Consider what risks are relevant in your setup (i.e. risk analysis)
Use mutually authenticated TLS
Pay attention to key management practices
Ensure the security of the controller
SDNs are not inherently less secure that traditional networks
11/18/2018

53. Conclusion What I did not explain
routing
access control
QoS
OpenFlow
Controller
API
11/18/2018

54. That’s it!
Questions, comments? Feedback about the lecture is much obliged!
11/18/2018