SPIDER: Fuzzing for Stateful Performance Issues in the ONOS Software-Defined Network Controller

TL;DR

The paper addresses stateful performance issues (SPIs) in large SDN controllers by introducing SPIDER, a dependency-aware modular fuzzing framework tailored to ONOS's event-driven architecture. SPIDER builds per-service dependency constraints via static analysis, then generates event sequences that navigate inter-service state changes, enabling scalable fuzzing with performance feedback and semantic mutation. Across 157 ONOS services, SPIDER uncovers 10 true SPI cases (with several requiring multi-event triggers), outperforming monolithic or unconstrained fuzzers and providing concrete case studies. The work demonstrates practical impact by improving SPI detection in complex software, informs safe testability practices, and outlines directions for broader automation and resilience in SDN controllers.

Abstract

Performance issues in software-defined network (SDN) controllers can have serious impacts on the performance and availability of networks. In this paper, we consider a special class of SDN vulnerabilities called stateful performance issues (SPIs), where a sequence of initial input messages drives the controller into a state such that its performance degrades pathologically when processing subsequent messages. Uncovering SPIs in large complex software such as the widely used ONOS SDN controller is challenging because of the large state space of input sequences and the complex software architecture of inter-dependent network services. We present SPIDER, a practical fuzzing framework for identifying SPIs in this setting. The key contribution in our work is to leverage the event-driven modular software architecture of the SDN controller to (a) separately target each network service for SPIs and (b) use static analysis to identify all services whose event handlers can affect the state of the target service directly or indirectly. SPIDER implements this novel dependency-aware modular performance fuzzing approach for 157 network services in ONOS and successfully identifies 10 new performance issues. We present an evaluation of SPIDER against prior work, a sensitivity analysis of design decisions, and case studies of two uncovered SPIs.

Figures (12)

• Figure 1: Simplified view of ARPService in ONOS, illustrating a stateful performance issue. The lookup function triggered by OFPacketIn, performs an $\mathcal{O}(n)$ operation w.r.t. the size of addressMap.
• Figure 2: A high-level overview of Spider.
• Figure 3: Interactions between different services through function calls in ONOS.
• Figure 4: CDF of service dependency set sizes computed by the two algorithms across the 157 services analyzed in ONOS. A smaller size is better: the state-dependency optimization reduces the size of the dependency sets.
• Figure 5: Simplified version of HostEvent.