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.

翻译：暂无翻译