The document discusses a method for uncovering bugs in P4 programs through assertion-based verification, presenting the Assert-P4 model that allows for modeling P4 program structures in C. It highlights previous models' inability to adequately address P4 specifications and evaluates the proposed method's effectiveness in bug finding through various examples like Dapper and NetPaxos. Performance challenges are noted, with suggestions for future work including exploring the use of the Rust programming language to enhance verification efficiency.

1. Uncovering Bugs in P4 Programs with
Assertion-based Verification
By Lucas Freire et al.
Published in SOSR ’18
Ajay Kharat-(2019H1030011G)
BITS-Pilani

2. Motivation
● P4 programs allows Network Administrators to deploy network functionalities.
● P4 Programming language allows Network Administrators to specify
conditions in few instructions as compared to other programming languages.
● Earlier, some tools were developed to detect bugs in P4 programs.
● But the proposed models are either not able to model P4 programs or cannot
reason about program specifications.

3. Problem Statement

4. Approach and Solution
• Overview of ASSERT-P4

5. ● Specifying Assertions

6. ● Constructing C Models
Headers: P4 headers are modeled Structs in C.
Tables: Each table in P4 is modeled as Functions in C, takes decision based on
match field or symbolic value(basically forcing to take particular action).
Actions: these are also modeled as functions in C, when forwarding rules are
unknown then action parameters are also unknown.
Control Blocks: Contains action and table declarations in P4 these are modeled
as multiple C functions.
Parser: Parsers are translated to multiple functions one for the parser declaration
and another for it’s states.
Assertions: Specified using boolean expressions and if methods in C.

7. ● Symbolically executing program models
➢ The C model of a P4 program is verified by a symbolic engine. The
symbolic execution of a program requires that all its feasible control flows
(i.e. its execution paths) are evaluated through symbolic input variables.
➢ P4 program is converted into DAG representation.

8. Evaluation of Proposed Scheme
● Bug Finding
➢ Dapper: Data plane performance diagnosis tool. Forwards packets without
checking TTL field which can lead to routing loops.
➢ NetPaxos: Network-based implementation of the Paxos consensus protocol.
2 programs:Leaders and Acceptors. Leaders determine round numbers and
acceptors acknowledges it. This process is repeated until k no. of acceptors
acknowledges a round number. Each Acceptor marks every packet that
contain that round number to be dropped before it decides whether to
acknowledge it or not. However, packets are not unmarked even if they are
acknowledged, which means they will be dropped and the vote will not be
counted by Leader.
➢ DC.p4: Contains multiple functionalities of L3/L2 forwarding, ECMP, VLAN,
packet mirroring. But configuring only L3 ACL is not enough for dropping
IPv4 packets as L3 ACL only flags packets to be filtered by another module

9. ● Performance Analysis

10. Related Work
Many tools were proposed for verifying correctness and security properties in
networks over the last few years. They are based on a number of techniques and
address different properties or network architectures. Some of them are:
● Flover and NICE were proposed which use model checking to prove set of rules
installed in switches satisfies network policies or not.
● VMN focuses on verifying reachability and isolation using stateful middleboxes.
● VeriFlow and Deltanet are solutions that allow property verification in real time.
Shortcomings & Future Work
● Shortcomings
➢ Takes time in converting a P4 program into equivalent C program.
➢ Verification time grows exponentially.
● Future Works
➢ RUST programming Language can be used instead of C.
➢ Planning to investigate alternatives to improve its performance on programs