HANDS-ON LABS FOR SOFTWARE-DEFINED NETWORKING & NETWORK FUNCTIONS VIRTUALIZATION
The advent of new network technologies such as Software-Defined Networking (SDN) and Network Function Virtualization (NFV) has resulted in a high degree of flexibility in network infrastructure, but at the same time brought new security challenges. Although current research efforts have prompted positive progress in addressing security challenges and opportunities in SDN and NFV, the latest results appear in few educational materials targeting SDN and NFV security.
With emerging SDN and NFV technologies, there is a need for education to keep pace. This project aims to develop effective educational materials on SDN and NFV security for preparing students to protect the emerging SDN/NFV-based network infrastructure. This project will advance the knowledge of cybersecurity education by creating hands-on labs and a curriculum on SDN/NFV. The course materials, along with nine hands-on labs, will aim to increase the educational resources for cybersecurity, particularly for security in new networking technologies. Further, this project will advance the usability and effectiveness of using a cloud-based open laboratory to support hands-on labs on SDN/NFV security.
Here are the pedagogical goals in these hands-on labs.
Deep Understanding SDN/NFV: Understanding the concepts and the internal protocols involved in SDN/NFV is fundamental for the delivery of new security solutions to educators and students. A solid background in SDN/NFV will afford them a better understanding of SDN/NFV security.
Understanding new network attacks in SDN/NFV: By exposing multiple attack scenarios to students, we can encourage students to think critically about the differences between traditional network attacks and newer SDN/NFV attacks. Furthermore, we instill in our students various security mindsets to encourage them to detect as many vulnerabilities in SDN as possible.
Click On Any Of Our Below Labs To Learn More About Them
Lab 1: CloudLab
CloudLab is an NSF-sponsored project that enables the academic research community to develop and experiment with novel cloud architectures and to develop new cloud computing applications. Some specific advantages of using CloudLab for building our open laboratory are worthy of mention: It is free of charge for educational purposes It supports OpenFlow It provides a high degree of isolation between simultaneous experiments It uses a profile to encapsulate everything needed to run an experiment. In this lab, students can create a simple network topology in CloudLab. The student will login the CLOUDLAB website, create an experiment profile, and create a topology that includes four instances of XEN VM (Virtual Machine) linked together. The student will then instantiate the topology by selecting a cluster that is available. After the topology is instantiated, the student then sends Ping from one note to every other node to confirm that the topology is created successfully.
Learning Outcomes: Students will learn how to create a network topology in CloudLab, how to instantiate the topology, and confirm that the nodes in the topology are connected correctly. Click on any of the resources below to learn more about the learning outcomes.
Here is the information for CloudLab
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.
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 . 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 . 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.
 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.
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 . 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.
 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.
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 . 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.
 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.)
 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.
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  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.
 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)
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.
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.
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.
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.