Uncovering Bugs in P4 Programs with Assertion-based Verification

Freire, Lucas G.; Neves, Miguel; Leal, Lucas dos Santos; Levchenko, Kirill; Schaeffer-Filho, Alberto; Barcellos, Marinho P.

doi:10.1145/3185467.3185499

Cited by 57 publications

(42 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Target device-independent or -dependent bugs are present in many real-world P4 applications. Currently, the aforementioned runtime bugs cannot be detected by the existing static analysis approaches [2][3][4][5].…”

Section: Motivating Examplesmentioning

confidence: 99%

“…Majorly, the existing tools are based on static analysis [2][3][4][5] of the P4 program and thus, fail to detect the runtime bugs or faults. Considering the example of a target device-independent or -dependent bugs illustrated in §2, the current solutions [2][3][4][5] are not able to detect such bugs, as they rely on static analysis and thus, executing runtime verification to observe the device behavior on various inputs is not feasible. In particular, if the parser in a P4 switch fails to check the IPv4 ihl field, the checksum is updated incorrectly leading to anomaly in the network behavior.…”

Section: Related Workmentioning

confidence: 99%

“…In particular, if the parser in a P4 switch fails to check the IPv4 ihl field, the checksum is updated incorrectly leading to anomaly in the network behavior. For instance, the runtime verification of hash computations cannot be supported by the symbolic execution solutions [2,4,5]. Similarly, if the parser in a P4 switch fails to check the IPv4 ihl field, the checksum is updated incorrectly leading to anomaly in the network behavior.…”

Section: Related Workmentioning

confidence: 99%

“…Runtime bugs or faults may cause serious network outages or security threats, which is why the network verification is critical. Current approaches focus mainly on the static analysis [2][3][4][5] of P4 programs. We, however, realize that static program analysis is insufficient when it comes to extensively and automatically verifying the runtime behavior of a P4 switch as P4 programs alone do not determine the forwarding behavior.…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Runtime Verification of P4 Switches with Reinforcement Learning

Shukla

Hudemann

Hecker

et al. 2019

Proceedings of the 2019 Workshop on Network Meets AI &Amp; ML - NetAI'19

View full text Add to dashboard Cite

We present the design and early implementation of p4rl, a system that uses reinforcement learning-guided fuzz testing to execute the verification of P4 switches automatically at runtime. p4rl system uses our novel user-friendly query language, p4q to conveniently specify the intended properties in simple conditional statements (if-else) and check the actual runtime behavior of the P4 switch against such properties. In p4rl, user-specified p4q queries with the control plane configuration, Agent, and the Reward System guide the fuzzing process to trigger runtime bugs automatically during Agent training. To illustrate the strength of p4rl, we developed and evaluated an early prototype of p4rl system that executes runtime verification of a P4 network device, e.g., L3 (Layer-3) switch. Our initial results are promising and show that p4rl automatically detects diverse bugs while outperforming the baseline approach.

show abstract

Section: Motivating Examplesmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Runtime Verification of P4 Switches with Reinforcement Learning

Shukla

Hudemann

Hecker

et al. 2019

Proceedings of the 2019 Workshop on Network Meets AI &Amp; ML - NetAI'19

View full text Add to dashboard Cite

show abstract

“…Languages for network function specification exist within industry, including TOSCA [28], a templating metamodel for network function virtualization. Also related is Assert-P4 [13], which is a proposed approach for checking P4 programs that is also based on assertion checking. Combining assertions with symbolic execution, it finds bugs motivated by controller misconfiguration and code circumvention and gives developers that ability to specify properties about their programs.…”

Section: Related Workmentioning

confidence: 99%

Checking-in on network functions

Lakhani

Miller

2019

Proceedings of the Applied Networking Research Workshop

View full text Add to dashboard Cite

When programming network functions, changes within a packet tend to have consequences-side effects which must be accounted for by network programmers or administrators via arbitrary logic and an innate understanding of dependencies. Examples of this include updating checksums when a packet's contents has been modified or adjusting a payload length field of a IPv6 header if another header is added or updated within a packet. While static-typing captures interface specifications and how packet contents should behave, it does not enforce precise invariants around runtime dependencies like the examples above. Instead, during the design phase of network functions, programmers should be given an easier way to specify checks up front, all without having to account for and keep track of these consequences at each and every step during the development cycle. In keeping with this view, we present a unique approach for adding and generating both static checks and dynamic contracts for specifying and checking packet processing operations. We develop our technique within an existing framework called NetBricks and demonstrate how our approach simplifies and checks common dependent packet and header processing logic that other systems take for granted, all without adding much overhead during development.

show abstract

Packet processing and data plane program verification: A survey with tools, techniques, and challenges

Akarte

Yadav

2023

Int J Communication

View full text Add to dashboard Cite

SummaryIn today's era of fast‐growing network‐enabled devices combined, it increases the complexity of the network. This leads to the massive data packet transfer on the network via the data plane in a software‐defined networking environment. The programmable packet processing in a data plane may introduce indirect bugs that are hard to catch manually. To avoid catastrophic after‐effects, such programs need to be formally verified. Researchers have proposed various tools and techniques to verify the data plane program using the P4 language. Most of the researchers have used the concept of assertion and symbolic execution to provide P4 verification approaches. As symbolic execution does not scale up well, researchers have proposed different techniques, which include the use of constraints, slicing of the program, parallelization, data plane verification, program verification, and so on. The tools have experimented with different choices for compiler optimization. In this article, we perform a pervasive survey on various verification tools and techniques based on data plane programming using domain‐specific language like P4 from the inception of the concept. We have compared the packet processing tools developed as per the requirement of time with their ideology and the impact of change.

show abstract

Uncovering Bugs in P4 Programs with Assertion-based Verification

Cited by 57 publications

References 23 publications

Runtime Verification of P4 Switches with Reinforcement Learning

Runtime Verification of P4 Switches with Reinforcement Learning

Checking-in on network functions

Packet processing and data plane program verification: A survey with tools, techniques, and challenges

Contact Info

Product

Resources

About