MORPH: An Adaptive Framework for Efficient and Byzantine Fault-Tolerant SDN Control Plane

Abstract

Current approaches to tackling the single point of failure in SDN entail a distributed operation of SDN controller instances. Their state synchronization process is reliant on the assumption of a correct decision-making in the controllers. Successful introduction of SDN in the critical infrastructure networks also requires catering to the issue of unavailable, unreliable (e.g. buggy) and malicious controller failures. We propose MORPH, a framework tolerant to unavailability and Byzantine failures, that distinguishes and localizes faulty controller instances and appropriately reconfigures the control plane. Our controller-switch connection assignment leverages the awareness of the source of failure to optimize the number of active controllers and minimize the controller and switch reconfiguration delays. The proposed re-assignment executes dynamically after each successful failure identification. We require 2FM +FA+1 controllers to tolerate FM malicious and FA availability-induced failures. After a successful detection of FM malicious controllers, MORPH reconfigures the control plane to require a single controller message to forward the system state. Next, we outline and present a solution to the practical correctness issues related to the statefulness of the distributed SDN controller applications, previously ignored in the literature. We base our performance analysis on a resource-aware routing application, deployed in an emulated testbed comprising up to 16 controllers and up to 34 switches, so to tolerate up to 5 unique Byzantine and additional 5 availability-induced controller failures (a total of 10 unique controller failures). We quantify and highlight the dynamic decrease in the packet and CPU load and the response time after each successful failure detection.1) If the PRIMARY controller receives the client request, the task (e.g., path finding) is executed locally. 2) If a SECONDARY controller receives the client request, the request is proxied by the SECONDARY to the PRI-MARY controller, which then proceeds with request handling. If the PRIMARY controller fails, a new PRIMARY that handles the client request, is re-elected [9], [10].However, an occurrence of a Byzantine failure of the PRI-MARY controller (i.e. because of a corrupted [1], manipulated [11], or buggy [12] internal state), may lead to incorrect computation decisions in the controller logic. With Byzantine failures, there is incomplete information on whether the controller has truly failed. Thus, the controller may appear as both failed and correct to the failure-detection systems, presenting different symptoms to different observers (i.e. switches). Additionally, a malicious adversary may interfere with or modify the controller logic for the purpose of taking control of the network or re-routing the network traffic [11].On the other hand, availability-related controller failures lead to the controllers becoming inactive. In contrast to Byzantine failures, such controllers do not actively perform malicious actions nor do they try to hide their...

P4BFT: Hardware-Accelerated Byzantine-Resilient Network Control Plane

“…BFT has recently been investigated in the context of distributed SDN control plane [5]- [7], [10]. In [5], [6], 3F M + 1 controller replicas are required to tolerate up to F M Byzantine failures.…”

“…We introduce and experimentally validate the P4BFT design, which builds upon [5]- [7] and adds further optimizations:…”

“…It furthermore ensures that a minimum number of required controllers, necessary to tolerate a number of availability failures F A and malicious failures F M , are loaded and associated with each switch. This task is also discussed in [6], [7].…”

“…The green dashed block highlights the processing node responsible for comparing the controller messages destined for S4. Figure (a) presents the unoptimized case as per [5]- [7], where S4 collects and processes control messages destined for itself, thus resulting in a control plane load of F C = 13 and a delay on critical path (marked with blue labels) of F D = 3 hops (assuming edge weights of 1). By optimizing for the total communication overhead, the total F C can be decreased to 11, as portrayed in Figure (b).…”

“…RAFT is, however, unable to distinguish malicious / incorrect from correct controller decisions, and can easily be manipulated by an adversary in possession of the leader replica [4]. Recently, Byzantine Fault Tolerance (BFT)enabled controllers were proposed for the purpose of enabling correct consensus in scenarios where a subset of controllers is faulty due to a malicious adversary or internal bugs [5]- [7]. In BFT-enabled SDN, multiple controllers act as replicated state machines and hence process incoming client requests individually.…”