Security Hands-on Labs in SDN/NFV

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:

  1. It is free of charge for educational purposes
  2. It supports OpenFlow
  3. It provides a high degree of isolation between simultaneous experiments
  4. 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.

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 [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.

[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.

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

[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.

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.

[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.

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.

[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)

Copyright © Dr. Park, San Jose State University