ABSTRACT
Software-defined networking (SDN) has the potential to greatly reduce the cost and increase the manageability of large networks. However, there are multiple security concerns holding back its wide-scale adoption. While previous research has mainly examined securing the data and application planes of SDN, we argue that the controller itself is the most vulnerable component in the SDN architecture because it is both the most central and the most software-reliant component. Therefore, research into better securing the controller is central to any effort at securing the SDN architecture.
This study examines the question of how to better secure the controller by developing a practical framework for finding vulnerabilities in the underlying software of the Open Day light controller. By finding vulnerabilities in its software, we aim to not only improve the security of the controller software, but also build a foundation to allow previous research to implement better solutions to secure other SDN components.
LITERATURE REVIEW
Figure 6: Adding a Flow in the Open Day light Controller
The Flow Programmer Service then receives a notification that a flow has been added as it is registered to receive updates for changes in the Flow Service data tree. Next, the Flow Programmer Service then uses the OpenFlow (OF) Plugin to generate a Remote Procedure Call (RPC), or a procedure that is executed remotely but coded as if it were executed locally, to add the flow in the appropriate switch. This RPC is then routed through the OF Plugin to the correct switch. Figure 6 illustrates this process.
METHODOLOGY
Figure 15: OpenFlow Packet Structure
Each OpenFlow packet consists of a header, which is basically the same for each packet type, and a payload, which varies from packet type to packet type. Figure 15 illustrates this structure.
Figure 26: FireFox Popup Dialog
We included the username and password in the URL to avoid having to instruct the selenium module to enter the credentials through additional actions. We then dismiss ed the popup dialog that resulted. This popup dialog is illustrated by figure 26.
RESULTS
Figure 31: OpenFlow CPU Usage Results
Figure 32: OpenFlow Memory Usage Results
Figures 31 and 32 illustrate CPU and memory usage throughout the fuzzing run for the
OpenFlow plugin of the OpenDaylight controller.
CONCLUSION
Our goal with this project was to provide a practical framework for finding vulnerabilities in SDN controllers. We successfully achieved this objective by developing a fuzzing tool with standard Python modules to fuzz the OpenFlow and RESTCONF plugins of the Open Daylight controller. To develop this framework, we chose to use the Open Daylight controller, because it is well-documented, and fuzzing, because it is an effective method for finding vulnerabilities in large software systems.
We choose two controller features, odl-l2switch-all, a Southbo und plugin and odl-restconf-all, a Northbound plugin, to fuzz with a smart, generation-based, blackbox fuzzing approach. This approach consisted of determining the structure of valid packets or requests to the controller, determining the fields within those packets or requests that could be varied, and varying those fields randomly.
Source: University of Colorado
Author: Walid Sharif