Project Goal

Anchor 2

Lab 2: Software Defined Networking

SDN architecture allows networks to actively control traffic due to the centralization of network intelligence in the controller and enhances network resource visibility. The widespread use of SDN in recent years has brought a number of new security issues involving the three main layers of SDN: the application layer, the control plane (controller), and the data plane. This lab aims to let students understand the basic SDN by using Floodlight in CloudLab. Based on the topology that students create in the first lab (Lab 1), students can push flow rules through Floodlight, one of open-source SDN controllers

Learning Outcomes: Students will learn how to install flow rules by understanding Openflow.

Anchor 3

Lab 3: Flooding Attacks to the SDN Data Plane

Problem Definition: An attacker can produce a large amount of table-miss flow entries in messages to consume resources in the data plane [1]. The impact of this data-to-control plane saturation attack differs for various target applications. For example, a load balancing application is more vulnerable than a hub application since it requires high programming complexity to handle complicated computations for load balancing. The controller installs flow rules in the switch flow table. The flow rules can be installed proactively or retroactively. Since the switch has a limited number of flow tables, the data plane is vulnerable to saturation attacks. Learning Objectives: Students will learn different attack techniques to saturate data plane resources and understand the different characteristics of SDN applications that can affect flow rules proactively or reactively. Students will be able to understand the internal architecture of the data plane.

Learning Outcomes: Students understand the packet processing policies for different types of SDN applications. They can generate UDP or ICMP based flood attacks to launch saturation attacks in the data plane [49]. They can identify table-miss cases.

Challenging Questions: Students will brainstorm ways to keep the major functionalities of the SDN infrastructure working under a saturation attack in the data plane. See some samples below.

References:

[1] H.Wang, L. Xu, and G. Gu, “Floodguard: A dos attack prevention extension in software-defined networks,” in Proceedings of the 45th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN’15) , June 2015.

Anchor 4

Lab 4: Man-in-the-middle Attacks in the SDN Data Plane

Problem Definition: OpenFlow vulnerability is caused by insecure network management protocols where the adoption of transport layer security has lagged. Even though OpenFlow specifications support the use of Transport Layer Security (TLS), many vendors of both switches and controllers have failed to fully implement the specifications due to the complexity of TLS configuration, such as switch certificates, signing of certificates with a site-wide private key, and installing correct keys and certificates on all devices. The lack of adequate TLS implementation enables adversaries to infiltrate OpenFlow networks through a MIMT [2]. Attackers place a device on a communication path between the switch and the controller, or simply copy the flow to his/her machine. As a result, attackers can fully control any down-stream switches and execute stealthy eavesdropping attacks in-band (i.e., links carry both data and OpenFlow traffic).

Learning Objectives: By using security protocols in the transport layer, student will learn how to establish a secure communication between the controller and switch. Students will understand OpenFlow protocol vulnerability.

Learning Outcomes: Students will be able to launch the MIMT in SDN and understand how attackers can steal information. They will learn security protocols like TLS, IPSec, and SSH and their usage between the controller and the switches. They will learn authentication methods needed for all devices connected to the controller or switches to ensure secure communication.

Challenging Questions: Students will brainstorm efficient authentication methods based on existing SDN features to reduce communication costs.

References:

[2] K. Benton, L. J. Camp, and C. Small, “Openflow vulnerability assessment,” in Proceedings of the Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking , ser. HotSDN ’13. ACM, 2013.

Anchor 5

Lab 5: API Misuse Attacks to the SDN Controller [3, 4]

Problem Definition: Networking functionalities can be implemented in software as applications on top of the control plane in SDN. Each application has its own distinct functional requirements for accessing the controller. Fallacious network applications that misuse APIs in the controller can cause serious security threats to network resources, services, and functions through the control plane due to lack of authentication and authorization for applications and lack of standard open APIs. Students will explore how these unprivileged applications can crash the controller and launch memory leakage attacks [4]. Learning Objectives: Students will learn the internal structure of the controller and understand how applications can misuse APIs to cause attacks.

Learning Outcomes: Students can implement SDN applications and understand the architecture for interaction between applications and controller APIs. Students will be able to identify additional software vulnerabilities by investigating the internal code space.

Challenging Questions: Students will brainstorm security requirements for SDN applications. Different applications must have different privileges to access network information and resources. For example, a load balancing application needs network statistics while Intrusion Detection Systems (IDS) need to scrutinize packet header fields.

References:

[3] Hitesh Padekar, Younghee Park*, Hongxin Hu, Sang-Yoon Chang, “Enabling Dynamic Access Control for Controller Applications in Software-Defined Networks,” the 21st ACM Symposium on Access Control Models and Technologies (SACMAT), June, 2016. (* is the corresponding author.)
[4] S. Shin, Y. Song, T. Lee, S. Lee, J. Chung, P. Porras, V. Yegneswaran, J. Noh, and B. B. Kang, “Rosemary: A robust, secure, and high-performance network operating system,” in Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security . ACM, 2014, pp. 78–89.

Anchor 6

Lab 6: Local Host Hijacking

Problem Definition: The controller has a vast amount of important data, such as topological information, device information, and link information, all of which can be compromised by attackers. To accomplish this, attackers exploit the host tracking service in the controller. They can tamper with host location information to break through the controller and impersonate the target host. In that case, all traffic on the target host will be route to the attacker’s host. TopoGuard [5] was the first to demonstrate network poisoning attacks designed to compromise the network topology information based on the LLDP (Link Layer Discovery Protocol) protocol. It is but one example of many possible network poisoning attacks in SDN.

References:
[5] Sungmin Hong*, Lei Xu*, Haopei Wang, Guofei Gu. "Poisoning Network Visibility in Software-Defined Networks: New Attacks and Countermeasures." In Proc. of 22nd Annual Network & Distributed System Security Symposium (NDSS'15), San Diego, CA, USA. February 2015. (*co-first author)

Anchor 7

Lab 7: Flow Rule Management

Problem Definition: OpenFlow controllers utilize Link Layer Discovery Protocol (LLDP) packets to discover links among OpenFlow switches. However, there exist security flaws during the link discovery procedure. Attackers exploit the link discovery and host tracking services in the controller. They can tamper with host location information to break through the controller and impersonate the target host. In that case, all traffic on the target host will be routed to the attacker’s host. This lab is designed to demonstrate network poisoning attacks designed to compromise the network topology information based on the LLDP.

Anchor 8

Lab 8: NFV Lab using Docker

Problem Definition: Network Function Virtualization (NFV) provides high flexibility to deploy any network functions on the fly. This lab let students understand the concept of NFV by using Docker. This lab aims to let students understand and integrate OVS-Switch with Docker containers in CloudLab. With this understanding, students can create an SDN-based Docker network and control based on SDN and NFV together.

Anchor 9

Lab 9: SDN Application Development

Problem Definition: Users can develop a lot of applications in SDN and NFV, such as Firewall, load balancing, DPI, etc. This lab aims to let students understand the working of IP blacklisting in the Floodlight controller. This lab uses Floodlight, one of the open-source SDN controllers. The Floodlight controller used for this lab has an inbuilt blacklist IP module and the working of the module is explained.

Anchor 10

Lab 10: SlowLoris Attack in CloudLab

Problem Definition: Often a DoS/saturation attack is associated with the occurrence of a burst in the volume of traffic received by an SDN controller or switch. However, there are existing attacks that have low profiles or low rates of traffic. Such attacks maintain a stealthier approach. Even though it takes longer for such attacks to affect SDN planes, the attacks are harder to detect as well. One of these attacks is named SlowLoris.