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.

We present SymNet, a network static analysis tool based on symbolic execution. SymNet injects symbolic packets and tracks their evolution through the network. Our key novelty is SEFL, a language we designed for expressing data plane processing in a symbolic-execution friendly manner. SymNet statically analyzes an abstract data plane model that consists of the SEFL code for every node and the links between nodes. SymNet can check networks containing routers with hundreds of thousands of prefixes and NATs in seconds, while verifying packet header memory-safety and covering network functionality such as dynamic tunneling, stateful processing and encryption. We used SymNet to debug mid- dlebox interactions from the literature, to check properties of our department’s network and the Stanford backbone. Modeling network functionality is not easy. To aid users we have developed parsers that automatically generate SEFL models from router and switch tables, firewall configura- tions and arbitrary Click modular router configurations. The parsers rely on prebuilt models that are exact and fast to an- alyze. Finally, we have built an automated testing tool that combines symbolic execution and testing to check whether the model is an accurate representation of the real code.

In order to improve users ability to interact with devices in an intelligent house, we propose a platform for intelligent device composition, based on Service Oriented Architecture. In such an environment, devices can be controlled and monitored using Service invocations, or they can interoperate in order to fulfil complex tasks, using Service composition. As part of our platform, we define a language for dynamic service composition, called MetaBPEL. It extends the WS-BPEL 2.0 language with semantic information, and acts as an abstract workflow definition mechanism. Unlike BPEL and other conventional composition languages, MetaBPEL does not bind to actual service implementations, but merely describes capabilities that services must have, in order to participate in a workflow. This feature allows both workflow migration between different environments as well as service replacement without modifying the composition scheme. In the article, we describe the MetaBPEL structure and the associated creation, generalization and instantiation mechanisms.