P4 verification works have found numerous bugs in programs of various sizes. While existing tools are efficient in finding bugs such as invalid header accesses, little effort has been put in understanding the potential impact of these bugs against the network. In this paper, we investigate whether these bugs can expose security vulnerabilities similar to those studied extensively for commodity CPUs. This work presents the design and implementation of HackP4 – a tool which makes use of static and dynamic analysis techniques to assess security properties of P4 dataplanes. HackP4 discovers vulnerabilities in P4 programs and automatically generates security exploits if they exist; otherwise, it provides guarantees of their absence. We present the results of running HackP4 against several P4 programs and show the kind of vulnerabilities it is able to capture. Finally, we discuss best practices for mitigating bugs and minimizing the impact of vulnerabilities.

Recent verification work has made advances in finding bugs in P4 programs before deployment, but it requires that the programmer specifies table rules that are possible at runtime[32, 24, 27]. This imposes a specification burden on the programmer, while at the same time failing to guarantee that bugs will not be inserted at runtime by faulty controllers. We present bf4, a novel verification approach for P4 programs that uses a mix of static verification, code changes and runtime checks to ensure that the deployed P4 program is bug free. To achieve this, bf4 uses static analysis to find all possible bugs in the P4 program; for each possible bug, bf4 attempts to find predicates that, when applied to table rules inserted by the controller, make that bug unreachable. If such predicates do not exist, bf4 can change the P4 code and re-run the procedure above. We applied bf4 to a wide range of P4 programs; for all these, bf4 is able to generate controller assertions and propose fixes that guarantee no controller-induced bug is reachable. At runtime, bf4 checks that the controller does not insert faulty rules; when it does, it throws an exception which helps troubleshoot the bug.

We present Vera, a tool that verifies P4 programs using symbolic execution. Vera automatically uncovers a number of common bugs including parsing/deparsing errors, invalid memory accesses, loops and tunneling errors, among others. Vera can also be used to verify user-specified properties in a novel language we call NetCTL. To enable scalable, exhaustive verification of P4 program snapshots, Vera automatically generates all valid header layouts and uses a novel data-structure for match-action processing optimized for verification. These techniques allow Vera to scale very well: it only takes between 5s-15s to track the execution of a purely symbolic packet in the largest P4 program currently available (6KLOC) and can compute SEFL model updates in milliseconds. Vera can also explore multiple concrete dataplanes at once by allowing the programmer to insert symbolic table entries; the resulting verification highlights possible control plane errors. We have used Vera to analyze many P4 programs including the P4 tutorials, P4 programs in the research literature and the switch code from https://p4.org. Vera has found several bugs in each of them in seconds/minutes.

Neutron is the OpenStack component that implements networking and it has been mocked and derided the weakest line in OpenStack [11]. We propose to use network symbolic execution to improve Neutron's ability to correctly implement tenant policies and to provide tenant traffic isolation. We propose to apply symbolic execution on two different OpenStack layers: the tenant view of the network and the actual deployment. Analyzing the tenant view is useful in many ways; first, it helps the tenant better understand its configuration's behavior before deployment. Secondly, its outputs can be compared to the analysis of the deployment to check if they are equivalent. We have built a prototype implementation and conducted preliminary evaluation, finding that we can verify our department's OpenStack deployment in seconds and detect certain common Neutron problems.