SDN controller choice impacts defense speed and resource use
Resource versus Responsiveness: Benchmarking SDN Controller Runtimes for a Moving-Target-Defense Control Plane at Scale
Networking and Internet Architecture
Summary
Networks can hide from attackers by frequently changing their device addresses, but this can cause sudden bursts of changes controllers must manage. The researchers tested the same defense method on three different network controllers to see how well they handled these bursts. They found that some controllers react quickly but use more resources, while others save memory but react more slowly, sometimes causing connection delays. This means picking the right controller is important for balancing speed and resource use in network defenses.
What this means in practice
- •For network operators: Choose SDN controllers that balance latency and resource use for effective moving target defense in large campus networks.
- •For cloud infrastructure teams: Optimize SDN controller deployment to maintain quick response times while managing resource consumption during network address rotations.
Authors
Souhail Chakkour, Umesh Biswas, Charan Gudla
Abstract
Network Moving Target Defense (MTD) built on Software-Defined Networking (SDN) continuously rotates host-facing addresses to invalidate an attacker's reconnaissance. Each rotation creates a burst of control-plane mutations, while new connections may simultaneously require reactive flow installation. Yet SDN controller runtime is usually treated as an implementation detail in the MTD literature. We show that it materially affects performance. We port the same Continuity-Preserving Address Mutation (CPAM) logic to three widely used controllers: Ryu (single-threaded cooperative Python), OpenDaylight, and ONOS (both multi-threaded JVM), and evaluate them on an identical 500-host campus fabric using an RFC 8456-aligned methodology with ten runs per controller. All three provide near-zero loss, sub-millisecond jitter, and preserve established sessions, but their control-plane behavior differs sharply. OpenDaylight and ONOS keep reactive latency low and stable, whereas Ryu serializes reactive flow installation behind periodic rotation work, increasing reactive RTT by about 100x and causing a small number of setup-time failures. Ryu uses far less memory, while ONOS achieves OpenDaylight-class reactive latency with the lowest CPU utilization of the three and a smaller live heap than OpenDaylight. These results expose distinct resource-versus-responsiveness operating points and show that controller selection should be treated as a first-class design decision in SDN-based MTD.