Software dataplane verification

Dobrescu, Mihai; Argyraki, Katerina

doi:10.1145/2823400

Cited by 46 publications

(67 citation statements)

References 33 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Most of that work relies on models of NFs that are different from their implementations, hence it cannot reason about the latter (although we should note that NF models can be very effective in reasoning about network configuration [24, 25, 30-32, 38, 39, 46, 52, 55, 59]). One exception is Dobrescu et al [19], which introduced the notion of software data-plane verification, and which proves low-level properties for NF implementations written in Click (i.e., C++) [35]. That work, however, cannot prove semantic correctness of stateful NFs, because it does not reason about state.…”

Section: Introductionmentioning

confidence: 99%

“…The beauty of symbolic execution [9] lies in its ease of use: it enables automatic code analysis, hence can be used by developers without verification expertise. The challenge with symbolic execution is its notorious lack of scalability: applying it to real C code typically leads to path explosion [19,55]. The part of real NF code that typically leads to unmanageable path explosion is the one that manipulates state.…”

Section: Introductionmentioning

confidence: 99%

“…There is a rich body of work on network verification [24, 25, 30-32, 38, 39, 46, 52, 55, 59]. In contrast, there is much less work on NF verification [19].…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

A Formally Verified NAT

Zaostrovnykh

Pirelli

Pedrosa

et al. 2017

Proceedings of the Conference of the ACM Special Interest Group on Data Communication

Self Cite

View full text Add to dashboard Cite

We present a Network Address Translator (NAT) written in C and proven to be semantically correct according to RFC 3022, as well as crash-free and memory-safe. There exists a lot of recent work on network verification, but it mostly assumes models of network functions and proves properties specific to network configuration, such as reachability and absence of loops. Our proof applies directly to the C code of a network function, and it demonstrates the absence of implementation bugs. Prior work argued that this is not feasible (i.e., that verifying a real, stateful network function written in C does not scale) but we demonstrate otherwise: NAT is one of the most popular network functions and maintains per-flow state that needs to be properly updated and expired, which is a typical source of verification challenges. We tackle the scalability challenge with a new combination of symbolic execution and proof checking using separation logic; this combination matches well the typical structure of a network function. We then demonstrate that formally proven correctness in this case does not come at the cost of performance. The NAT code, proof toolchain, and proofs are available at [58].

show abstract

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

A Formally Verified NAT

Zaostrovnykh

Pirelli

Pedrosa

et al. 2017

Proceedings of the Conference of the ACM Special Interest Group on Data Communication

Self Cite

View full text Add to dashboard Cite

show abstract

“…[14] designs and presents the first machine-verified SDN controller based on NetCore [25]. [11] introduces a verification tool that takes the software program of a data plane as input and check target properties. These verification solutions only verify the logic correctness of the control plane and data plane, however fail to locate the network topology exploitations discussed in this paper.…”

Section: Related Workmentioning

confidence: 99%

Poisoning Network Visibility in Software-Defined Networks: New Attacks and Countermeasures

Hong

Wang

et al. 2015

Proceedings 2015 Network and Distributed System Security Symposium

331

256

View full text Add to dashboard Cite

Abstract-Software-Defined Networking (SDN) is a new networking paradigm that grants a controller and its applications an omnipotent power to have holistic network visibility and flexible network programmability, thus enabling new innovations in network protocols and applications. One of the core advantages of SDN is its logically centralized control plane to provide the entire network visibility, on which many SDN applications rely. For the first time in the literature, we propose new attack vectors unique to SDN that seriously challenge this foundation. Our new attacks are somewhat similar in spirit to spoofing attacks in legacy networks (e.g., ARP poisoning attack), however with significant differences in exploiting unique vulnerabilities how current S-DN operates differently from legacy networks. The successful attacks can effectively poison the network topology information, a fundamental building block for core SDN components and topology-aware SDN applications. With the poisoned network visibility, the upper-layer OpenFlow controller services/apps may be totally misled, leading to serious hijacking, denial of service or man-in-the-middle attacks. According to our study, all current major SDN controllers we find in the market (e.g., Floodlight, OpenDaylight, Beacon, and POX) are affected, i.e., they are subject to the Network Topology Poisoning Attacks. We then investigate the mitigation methods against the Network Topology Poisoning Attacks and present TopoGuard, a new security extension to SDN controllers, which provides automatic and real-time detection of Network Topology Poisoning Attacks. Our evaluation on a prototype implementation of TopoGuard in the Floodlight controller shows that the defense solution can effectively secure network topology while introducing only a minor impact on normal operations of OpenFlow controllers.

show abstract

“…It acts by assuring that the program meets the properties stated by its requirements. Several approaches have been developed in order to check if a given data plane satisfies a set of intended properties (SON et al, 2013;DOBRESCU;ARGYRAKI, 2014;LOPES et al, 2015;PANDA et al, 2017). However, the ones that are able to model P4 programs cannot reason about program-specific properties.…”

Section: Introductionmentioning

confidence: 99%