In this abstract we propose a framework for explaining violations of safety
properties in Software Defined Networks, using counterfactual causal reasoning

Caltais, Georgiana

Olmezoglu, Can

English

arXiv

University of Twente Research Information

Counterfactual Causality in Networks ∗Georgiana Caltais and Can OlmezogluUniversity of Twente, The Netherlandsg.g.c.caltais@utwente.nl , c.olmezoglu@utwente.nl1 Introduction & BackgroundThe main objective of an engineer is to build systems which follow a predefined behaviour.Explaining when a system fails to follow through that behaviour has thereby gained a lot ofattention as engineering rose to prominence. In this abstract, we propose a framework forexplaining violations of safety properties in Software Defined Networks (SDNs), using counter-factual causal reasoning [7].SDN has gained a lot of traction due to its increased network management and pro-grammability, achieved by decoupling the control plane from the data plane [8], in contrastwith traditional networks. SDN technologies can play an important role in solving issuesconcerning big data applications, including data processing in cloud data centers, optimisa-tions and data delivery. In this abstract, we focus on DyNetKAT –a rigorous framework formodelling and analysing (multi-)packet forwarding within an SDN, and communication be-tween data and control planes– introduced in [3] by a subset of the authors. DyNetKAT isbased on NetKAT [1], a minimalist language based on Kleene Algebra with Tests, supportedby a sound and complete axiomatisation. Packets in (Dy)NetKAT are encoded as sets offields and associated values {f1 = v1, . . . fn = vn}. NetKAT can model the forwarding ofa single packet within a network, and includes constructs such as dropping of packets (0),acceptance of packets (1), multicast (+), packet fields modification (f ← n) and repeated ap-plication (∗) of these policies. In addition, NetKAT can be used to build packet histories usingthe dup construct, which was dropped in [3]. DyNetKAT extends NetKAT with channel-based communication (||, x?p, x!p) of flow tables (p) between the data and control planes(with synchronous communication of p on channel x encoded as rcfg(x,p)), no-behaviourpolicies (⊥), non-deterministic choice (⊕), recursive specifications (X) and multi-packet se-mantics in the context of a sequential composition operator (;) that marks the fetching ofa new packet in the packet queue. In contrast with NetKAT, DyNetKAT has an opera-tional semantics that entails LTS models, and a sound and ground complete axiomatisationin the style of the Algebra of Communicating Systems (ACP). The syntax of DyNetKAT is:N ::= NetKAT−dup D ::= ⊥ | N ;D | x?N ;D | x!N ;D | D ||D | D ⊕ D | X with X , D.The complete framework is defined in [3]. Similarly to [3], we consider guarded DyNetKATspecifications that can be reduced to equivalent expressions in head normal form (Lemma 7in [3]). This, in turn, guarantees the existence of finite LTS models for DyNetKAT specifica-tions with finite number of recursive variables, finite sets of channel names and packet fieldsover finite domains.We base our SDN safety failure explanations on the so-called counterfactual causality, oractual causality, introduced in the seminal work [7], and adapted in [2] to the context of finiteautomata (as SDN models) and regular expressions (as a language for defining safety properties).Intuitively, (a sequence of) events c are considered causal with respect to the realisation of ahazard e whenever (i) c is necessary for e to happen, (ii) c not happening entails e not happening∗Abstract accepted at the 33rd Nordic Workshop on Programming Theory, NWPT 2022.1arXiv:2211.00758v1  [cs.FL]  1 Nov 2022(this is known as the counterfactual test), (iii) there is no c′ “simpler” than c that can satisfythe conditions above. In addition, there might be the case that despite c being observed, e doesnot happen due to some other cancelling actions (e.g., the forest does not burn down, despitethe lightning, because the firefighters arrive on time). Such situations are modelled by means ofcontingencies in [7] or events causal by their non-occurrence in [2, 4]. The causal analysis in [2]is performed in the context of FA models, and safety violations, or hazards encoded as regularexpressions defined in the standard fashion: e ::= 0 | 1 | a | e ; e | e + e | e∗. The computedcauses are words, or decorated traces w0 a0 w1 a1 . . . an wn where a0 a1 . . . an is a word which, ifexecuted, leads to the hazard e, and wi ranges over contingencies that disable the hazard. Notethat wi play an important role in describing fixes, or alternative safe scenarios.Our contribution. First, we devise and implement an algorithm that computes the LTSmodels of DyNetKAT programs. Then, we transform the aforementioned LTSs into FA modelsin a straightforward fashion, by handling every state as accepting. The generated FAs can befurther analysed according to the causal inference machinery in [2]. We explain our approachbased on a running example –a faulty virtual circuit that allows illegal packet forwarding–.2 Running ExampleA virtual circuit is created for the delivery of a bit stream between a source host and a destina-tion host [10], denoted by H1 and, respectively, H3 in the example of Figure 2. However, whennecessary, another host such as H2 in Figure 2 should be able to send external packets to H3,provided that H3 is not currently receiving a bit stream. Controller C1 oversees the networkand sends messages to network devices C2, S1 and S2, deciding when packets from H2 areforwarded or whether a virtual circuit between H1 and H3 can be initiated. For example, ifH2 wants to send something to H3, the switch S2 connecting H2 and H3 checks whether thereis a virtual circuit between H1 and H3 by querying C1. When a virtual circuit needs to beinitiated, C2 informs C1 to make sure other packets are not being sent while the virtual circuitis active. After receiving this information, C1 stops allowing external packets from H2 to beforwarded to H3. In equation (1) we provide a DyNetKAT formalism for the running example.A hazardous situation in the running example can happen when a virtual connection betweenH1 and H3 is active and processing a packet σ1 into σ2, indicating switch S1 forwarding thepackage from port 1 to port 2, depicted in red color in Figure 2. As this forwarding operationis happening, a packet σ3 from H2 is processed into σ4 and forwarded to H3 by S2. As thecircuit is already active and using most of the resources of H3, the arrival of σ4 at H3 mightlead to an overflow error.The LTS behavioural model of the DyNetKAT program in Figure 2 can be devised accordingto the DyNetKAT operational semantics. An excerpt of this LTS is provided in Figure 1. Forinstance, the trace rcfg(NoVirtualCircuit,1) rcfg(VirtualCircuitReq,1) originating in n0leads to the state n2 witnessing the hazard h , ((σ1, σ2); (¬V irtualCircuitEnd!1)∗; (σ3, σ4);A∗).The next goal is to exploit the causal machinery in [2] and derive causal explanations for safetyfailures in SDN in an automated fashion.3 Methodology, Results and ExtensionsThe implementation for creating the LTS from DyNetKAT specifications is explained belowand can be found at https://github.com/canolmezoglu/DyNetiKAT.Methodology: To generate the LTS models, the prototype implementation 1 from [3] waschosen as the base implementation for parsing an inputted DyNetKAT specification. This1https://github.com/hcantunc/DyNetiKATn0 : (C2 ||S2 ||C1 ||S1, σ1::σ3::〈〉, 〈〉) . . .n1 : (C2 ||S2′ ||C1 ||S1, σ1::σ3::〈〉, 〈〉)n2 : (C2′ ||S2′ ||C1′ ||S1′, σ1::σ3::〈〉, 〈〉) n3 : (C2′ ||S2′ ||C1′ ||S1′, σ3::〈〉, σ2::〈〉)n4 : (C2′ ||S2 ||C1′ ||S1′, 〈〉, σ4::σ2::〈〉)NoV irtualCircuit?1,rcfg(NoVirtualCircuit,1)V irtualCircuitReq!1,rcfg(VirtualCircuitReq,1)rcfg(VirtualCircuitEnd,1)(σ1, σ2)(σ3, σ4)Figure 1: Virtual Circuit LTS (excerpt)Figure 2: The Virtual CircuitC1 , NoV irtualCircuit!1;C1⊕V irtualCircuitReq?1;C1′C1′ , V irtualCircuitEnd?1;C1C2 , V irtualCircuitReq!1;C2′C2′ , V irtualCircuitEnd!1;C2S1 , V irtualCircuitReq?1;S1′S1′ , ((port = 1).(port← 2));S1′⊕V irtualCircuitEnd?1;S1S2 , NoV irtualCircuit?1;S2′S2′ , ((port = 3).(port← 4));S2Init , C1||S1||S2||C2(1)implementation was modified using Maude [5] to classify different operators of DyNetKAT.Following the parsing, we implemented in Python an algorithm that exploits the operationalsemantics from [3] and extracts the LTS from the parsed specification. To obtain the causesfrom the LTS, we used Algorithm 1 from the work in [2], where the LTS was converted into aFA model by considering all the states of the LTS as accepting states.Results: Upon conducting this methodology on the specification of the running example inSection 2, and using the regular expression h as the hazard, four causal explanations can beidentified as (the minimal) traces leading from n0 to n2. These traces entail a race conditionarising between the controllers when the virtual circuit was first made active. Note that, for thecase study in this paper, there are no contingencies that can be used to steer the aforementionedcausal explanations away from the undesired effect h. Hence, the actual causes coincide withthe traces witnessing h in the LTS model of the virtual circuit in (1).Extensions: Currently, we are working on developing a tool for extracting DyNetKAT specifi-cations from real SDN data, based on the logs in [6] and OpenFlow [9]. The latter is a protocolthat can manipulate the control logic of a network and program the flow table of networkswitches. As OpenFlow networks are working, or when they are simulated, all the modifica-tions are stored in the form of logs, describing what flow table updates have been made bywhich controller and for which network devices. Using these logs, such as ones that could beobtained from the work in [6], the state changes of the network switches can be inferred andconverted into DyNetKAT specifications. These specifications can be used for causal analysison real world data, as well as benchmarking the current prototype implementation.References[1] Carolyn Jane Anderson, Nate Foster, Arjun Guha, Jean-Baptiste Jeannin, Dexter Kozen, ColeSchlesinger, and David Walker. Netkat: semantic foundations for networks. In Suresh Jagannathanand Peter Sewell, editors, The 41st Annual ACM SIGPLAN-SIGACT Symposium on Principles ofProgramming Languages, POPL ’14, San Diego, CA, USA, January 20-21, 2014, pages 113–126.ACM, 2014.[2] Marcello M. Bonsangue, Georgiana Caltais, Hui Feng, and Hünkar Can Tunç. A language-basedcausal model for safety. In Yamine Aı̈t Ameur and Florin Craciun, editors, Theoretical Aspects ofSoftware Engineering - 16th International Symposium, TASE 2022, Cluj-Napoca, Romania, July8-10, 2022, Proceedings, volume 13299 of Lecture Notes in Computer Science, pages 290–307.Springer, 2022.[3] Georgiana Caltais, Hossein Hojjat, Mohammad Reza Mousavi, and Hünkar Can Tunç. Dynetkat:An algebra of dynamic networks. In Patricia Bouyer and Lutz Schröder, editors, Foundations ofSoftware Science and Computation Structures - 25th International Conference, FOSSACS 2022,Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2022,Munich, Germany, April 2-7, 2022, Proceedings, volume 13242 of Lecture Notes in ComputerScience, pages 184–204. Springer, 2022.[4] Georgiana Caltais, Mohammad Reza Mousavi, and Hargurbir Singh. Causal reasoning for safetyin hennessy milner logic. Fundamenta Informaticae, 173(2-3):217–251, 2020.[5] Manuel Clavel, Francisco Durán, Steven Eker, Patrick Lincoln, Narciso Mart́ı-Oliet, José Meseguer,and Jose F. Quesada. The maude system. In Paliath Narendran and Michaël Rusinowitch, editors,Rewriting Techniques and Applications, 10th International Conference, RTA-99, Trento, Italy,July 2-4, 1999, Proceedings, volume 1631 of Lecture Notes in Computer Science, pages 240–243.Springer, 1999.[6] Ahmed El-Hassany, Jeremie Miserez, Pavol Bielik, Laurent Vanbever, and Martin T. Vechev.Sdnracer: concurrency analysis for software-defined networks. In Chandra Krintz and Emery D.Berger, editors, Proceedings of the 37th ACM SIGPLAN Conference on Programming LanguageDesign and Implementation, PLDI 2016, Santa Barbara, CA, USA, June 13-17, 2016, pages 402–415. ACM, 2016.[7] Joseph Y. Halpern and Judea Pearl. Causes and explanations: A structural-model approach —part 1: Causes. CoRR, abs/1301.2275, 2013.[8] Keith Kirkpatrick. Software-defined networking. Commun. ACM, 56(9):16–19, 2013.[9] Nick McKeown, Thomas E. Anderson, Hari Balakrishnan, Guru M. Parulkar, Larry L. Peterson,Jennifer Rexford, Scott Shenker, and Jonathan S. Turner. Openflow: enabling innovation incampus networks. Comput. Commun. Rev., 38(2):69–74, 2008.[10] Larry L. Peterson and Bruce S. Davie. Computer networks - a systems approach (3. ed.). MorganKaufmann, 2003.

Counterfactual Causality in Networks

arXiv.org e-Print Archive

https://research.utwente.nl/en/publications/fabeab8b-8c5e-4af5-8ba3-9b7aa28d12f2

Counterfactual Causality in Networks

Abstract

Similar works

Full text

Available Versions

University of Twente Research Information

arXiv.org e-Print Archive