Rosemary

Abstract

Within the hierarchy of the Software Defined Network (SDN) network stack, the control layer operates as the critical middleware facilitator of interactions between the data plane and the network applications, which govern flow routing decisions. In the OpenFlow implementation of the SDN model, the control layer, commonly referred to as a network operating system (NOS), has been realized by a range of competing implementations that offer various performance and functionality advantages: NOX [14], and ONIX [18]. In this paper we focus on the question of control layer resilience, when rapidly developed prototype network applications go awry, or third-party network applications incorporate unexpected vulnerabilities, fatal instabilities, or even malicious logic. We demonstrate how simple and common failures in a network application may lead to loss of the control layer, and in effect, loss of network control.To address these concerns we present the ROSEMARY controller, which implements a network application containment and resilience strategy based around the notion of spawning applications independently within a micro-NOS. ROSEMARY distinguishes itself by its blend of process containment, resource utilization monitoring, and an application permission structure, all designed to prevent common failures of network applications from halting operation of the SDN Stack. We present our design and implementation of ROSE-MARY, along with an extensive evaluation of its performance relative to several of the mostly well-known and widely used controllers. Rather than imposing significant performance costs, we find that with the integration of two optimization features, ROSE-MARY offers a competitive performance advantage over the majority of other controllers.

Cross-App Poisoning in Software-Defined Networking

“…Several controller frameworks exist, such as Floodlight [20], Ryu [71], Open Network Operating System (ONOS) [61], and OpenDaylight (ODL) [64]. Special-purpose controllers for secure environments include SE-Floodlight [68], Rosemary [75], and Security-Mode ONOS [89]. The controller maintains data stores that collectively serve as a "network information base" for abstractions of the network's topology, flow entries, and end hosts, among others.…”

“…3.3.1 Lack of well-defined application isolation and enforcement as applied to shared control plane state. Some controllers, such as Rosemary [75], sandbox each app's resources (e.g., memory and CPU usage) and use RBAC to allow apps or prevent them from accessing parts of the SDN control plane state, in a manner analogous to resource sharing and file permissions in operating systems, respectively. However, RBAC is limiting in practice because it does not enforce certain usage of data after authorization [72].…”

“…Security-Mode ONOS [89] extends the ONOS controller to include API method-level RBAC enforcement. Rosemary [75] isolates applications by running each application as an individual process. SE-Floodlight [68] hardens the control plane by enforcing hierarchical RBAC policies and logging events through an auditing subsystem.…”

“…To date, defenses that limit the SDN attack surface have included app sandboxing [75], TLS-enabled APIs [61,64,68], API abuse prevention [65,78], and role-based access control (RBAC) for apps [68,89], among others. Although these mechanisms improve control plane security, we posit that they are not sufficient for mitigating information flow attacks within the control plane.…”

MinDoS: A Priority-Based SDN Safe-Guard Architecture for DoS Attacks

“…Additionally, a software extension to NOX was proposed in FortNoX [9], which offers rolebased authorization and security constraint enforcement for the NOX controller. Both SE-Floodlight [10] and Rosemary [11] proposed a security enforcement kernel to improve the robustness of SDN controller. In addition, some recent works [12]- [14] have noted that the SDN controller is vulnerable to DoS attacks.…”