1 Introduction
SoftwareDefined Network (SDN) [1] is gaining more attention due to its advantages in network configuration to improve network performance and network monitoring. So it is essential to ensure the correctness of SDN [17]. In this article, we describe SDN in the Kripke structure along with specifications, then the security properties of an SDN are expressed using temporal formulas. Later, the security properties of the SDN are analysed against a designed Kripke model using model checking.
There are several formal verification techniques [2][3] studied in recent years such as model checking, abstract interpretation and boolean satisfiability [7][8]. Modelchecking is widely used in many fields such as verification of hardware, software and security and safety protocols [15][16]. In model checking, the system is modelled as a state machine and specifications (properties of the system) expresses in linear temporal logic and computation tree logic.
SPIN [4] and SMV [5] are famous model checkers, LTL specifications [6] are allowed to express in SPIN and CTL specifications [6] are in SMV. It is known that automatabased verification can lead to state explosion problem. To address the state explosion problem, symbolic model checking (SMC) [9] and abstract model checking (AMC) [10]
has been developed with successful results. The combination of SMC and Binary Decision Trees (BDDs)
[11] maximise the states in the system, but a bottleneck in manipulating the amount of memory required to store BDDs. Bounded Model Checking (BMC) [12] progresses fastly after SMC, the basic idea of BMC is to find a counterexample in executions whose length k. The BMC problem can quickly reduce to satisfiability problem, which can be verified using SAT solvers [13]. Modern SAT solvers can handle satisfiability problem with thousands of variables.The contribution of the paper is as follows:

Formal representation of softwaredefined networks.

Representation of SDN in a Kripke structure for verification.

Formal analysis of SDN properties against the formal SDN Kripke model.

Formal analysis of faulty transition in the Kripke model of SDN.
The rest of this paper is organised as follows. The necessary background required for the proposed method is defined in Section 2. Section 3 and 4 describes the softwaredefined network and our solution, including a designed formal model for SDN and verification properties of SDN. Finally, we conclude the work in Section 5.
2 Background
2.1 Kripke Structure
A Kripke structure M [14] is a tuple M=(Init, States, Transition, Labelling), where ‘States’ is the set of states which are defined by a set of propositions ‘A’ hold on the states, ‘Init’ ‘States’ is the set of initial states, ‘Transition’ ‘States’ ‘States’ and ‘Labelling’ is a labelling function, ‘Labelling’: ‘States’ 2.
2.2 LinearTime Temporal Logic
Lineartime temporal logic, or LTL for short, is a temporal logic, with connectives that allow us to refer to the future. It models time as a sequence of states, extending infinitely into the future. This sequence of states is sometimes called a computation path, or simply a path. Lineartime temporal logic (LTL) has the following syntax given in Backus Naur form:
::= p () ( ) ( ) ( ) (X) (F) (G) ( U ) ( R )
where p is any propositional atom from some set of Atoms. Thus, the symbols and are LTL formulas, as are all atoms from Atoms; and is an LTL formula if is one, etc. The connectives X, F, G, U and R are called temporal connectives. X means ‘neXt state,’ F means ‘some Future state,’ and G means ‘all future states (Globally).’ The next two, U and R are called ‘Until’ and ‘Release’ respectively.
Definition 1: In a given model M, a path is defined as a sequence of connected edges which connect nodes, lets say , , . . . in S are the nodes such that m0 . The path = , , . . . represents a sequence of nodes in a system M, we define as starting from , for example is , , . . . .
Definition 2: A satisfaction relation is defined for the model M, considering paths to check linear temporal logic (LTL) formula satisfies . The satisfaction relation over and LTL formula is specified as:

, where represents true

q, iff q L(s)

X iff

G iff m m1,

F iff m m1,

U iff m m1 such that and n, n=1, 2, 3…m1 satisfies
2.3 Computation Tree Logic
Definition 3: Computation Tree Logic is a technique to represent time in a treelike structure in which future is not determined; there are many paths in which ‘actual’ path is realised. The Backus Naur form of CTL formulas are defined as:
::= p () ( ) ( ) ( ) (AX) (EX) (AG) (EG) (AF) (EF) (A[ U ]) (E[ U ])
Definition 4: Let M = (S, , L) be a model for CTL, s in S, a CTL formula. The relation M, s is defined by structural induction on :

M, s and M, s

M, s q iff q L(s)

M, s iff M, s

M, s iff M, s and M, s

M, s iff M, s or M, s

M, s iff M, s or M, s

M, s AX iff for all such that s we have M, . Thus, AX says: ‘in every next state’.

M, s EX iff for some such that s we have M, . Thus, EX says: ‘in some next state’.

M, s AG iff for all paths …, where equals s, and all along the path, we have M, .

M, s AF iff for some paths …, where equals s, and all along the path, we have M, .

M, s AF iff for all paths …, where equals s, and there is some such that M, .

M, s EF iff for some paths …, where equals s, and for some along the path, we have M, .

M, s A[U] iff for all paths …, where equals s, that path satisfies U .

M, s E[U] iff for some paths …, where equals s, that path satisfies U .
3 Software Defined Network
SDN works on OpenFlow protocol; OpenFlow is a communication interface defined between the controlling plane and data plane. OpenFlow allows direct access to data plane devices, such as switches and routers. OpenFlow separates network control from networking switches and allows centralized control of a network. OpenFlow allows controller software to define how a network flow passes through the network devices based on application and cloud resources. OpenFlow enables the network to be programmed based on a perflow basis. An OpenFlow architecture provides granular control on a network to respond to dynamic changes at an application level; this architecture overcomes disadvantages of IPbased routing, which follows the same path regardless of different requirements. Here we present the OpenFlow specification terms:

Action: an operation on a packet to perform forward and modify a packet.

Connection: a network connection between a switch and a controller.

Flow table: it contains a set of flow entries.

Flow entry: a unit in a flow table to process packets. Flow entry contains match fields for matching packet headers and instructions to apply on a packet.

Packet forwarding: forwarding packet to an output port or a set of output ports.

Packet forwarding: forwarding packet to an output port or a set of output ports.

Header: a control information present in a packet used by a switch to recognise the packet and to inform the switch for forwarding the packet.

Message: a message sent from the OpenFlow protocol for OpenFlow connection.
In this section, we present a formal definition of SDN and security properties which are necessary for SDN. SDN is a tuple SDN:= (P, W, C, FTab, T, ConfiG) where,
3.1 Packet
A packet P is a tuple (h, pLD) consists of a packet header ‘h’ and payload data ‘pLD’ information which is transmitted in a network. The packet header st, dt, (, , . . ) contains source address ‘st’, destination address ‘dt’ and packet pattern (, . . ) which is used to match with ports of the switch during transmission in a network system.
3.2 OpenFlow Switch
An OpenFlow switche ‘w’ contains one or more flow tables, which performs packet lookup and forwarding. A switch communicates with the controller, and the controller manages the switch via OpenFlow protocol. The controller can add, delete and update the flow entries of the flow table belongs to switches. Each entry of flow table contains match fields and instructions to match packets. Matching of the packet header with the first flow table continues to additional flow tables. If a matching entry found, then those instructions are used to forward a packet. If no match of entries in the flow table, then a further configuration of a missed flow entry has to proceed by forwarding a packet to the controller, or packet can be dropped. The instructions belong to each entry of flow table contains actions. The actions are the instructions to forward or modify a packet.
‘W’ is a set of switches W={}, each switch is a tuple w:= (P, W, FR) where ‘P’ is a set of ports in a switch represented as P={}. A port ‘p’ either a input or a output port represented as p(ip, op), where ‘ip’ is a set of input ports and ‘op’ is a set of output ports. Each input and output port consists of port ID, which is used to forward a packet and drop a packet based on forwarding rules which are received from the controller. W is switch controlling software which handles matching functions to route the packets to appropriate network devices. FR is a finite set of information to represents forwarding rules denoted as FR={}. ‘SwitchTrust’ is an assignment function ‘SwitchTrust’: W Label, which assigns each switch with a label, more the number of labels in a switch is considered as a most trusted switch.
3.3 SDN Controller
SDN controller is a tuple C:= {, FC, , , } that manages control flow of the network based on OpenFlow protocol.

is a set of control states.

is a set of initial control states, .

: h is a header modification function that modifies the packet header based on controller policies.

FC: h PESA FR is a forward rule calculator function, where h is a packet header, : h is a network status, which is used to find a feasible path of a packet in a set of all possible paths . Paths are arranged based on feasibility to reach destination i.e. {}, where ranks high to route a packet, ranks next of .

FC is a transition relation.
3.4 OpenFlow Table
This section describes the components of the flow table ‘FTab’ along with the mechanics of matching and action handling. OpenFlow switch has two types: OpenFlow only and OpenFlow hybrid. OpenFlow switches support OpenFlow pipeline only. OpenFlowhybrid switches support both OpenFlow operation and Ethernet switching operation.
The OpenFlow pipeline of every switch contains one or more flow tables, each flow table contains multiple entries. The OpenFlow pipeline processing unit defines how packets interact with the flow tables. An OpenFlow switch is required to have at least one ingress flow table (flow table to handle packet at an input port of a switch). Pipeline processing happens in two stages: ingress processing and egress processing (egress port that forwards network traffic to analysis tools). The outcome of ingress processing is to forward a packet to an output port, the switch may perform egress processing in the context of an output port. Egress processing is optional, and a switch may not support egress processing.
During the processing of the flow table, a packet header is matched against the flow entries of the flow table. If a flow entry is found, the instruction in that flow entry is executed. If the listing is matched, the instructions in that flow entry are executed. These instructions are used to route the packet to another flow table if the current flow table priory is less than other. If the matching flow entry does not direct to another flow table, then the current flow entries are used to forward the packet to an output port. If a packet does not match with any flow entries in a flow table, then we call it table miss based on flow table configuration. The instructions of a missed flow entry in a flow table can specify how to handle unmatched packets. The unmatched packet may drop, passing to another table or sending to a controller for further configuration.
The OpenFlow expects the mapping between network elements is consistent in following functionalities:

Table consistency, in which the packet must match same as all other OpenFlow Tables. Furthermore, a difference in matching is due to contents of a flow table, and the packet header cannot be altered unless explicitly specified by the OpenFlow processing.

Flow entry consistency, in which the actions of a flow entry apply to a packet is consistent with flow entry match. If a match field of flow entry matches a packet header, then the setfield of a flow table modifies the packet header, unless explicit OpenFlow processing has modified the packet.
A flow table entry of the form, {match fields, priority, counters, instructions, timeouts, cookie, flags}. A match field is to match packets, and it consists of the ingress port and packet header information, and optionally contains metadata of the previous flow table. A priority for matching flow entry of a flow table. Counters are updated once the packet is matched with a flow entry. An instruction is used to modify the action set and pipeline processing. Timeouts are the maximum amount of time or idle time before the switch expires flow. A cookie is opaque data chosen by a controller; this data is used by the controller to filter the flow entries affected by flow statistics, flow modification and deletion requests. A flag alters the flow entries, for example, the flag OFFF_SEND_FLOW_REMOVAL is used to remove messages of that flow entry. All flow tables must support a tablemiss flow entry to handle table misses. A tablemiss entry has a piece of information to handle unmatched packets. An unmatched packet may be: dropped, send to a controller for further configuration or forwarded to subsequent flow tables.
3.5 Topology and Configuration
Topology ‘T’ of an SDN is a binary relation T((W OP)(W IP)) on switches and ports of the network system. The nodes of a network are represented by a relation (W OP) and (W IP). Furthermore, h, p, w denotes the packet state in the network, where ‘h’ is a packet header, and ‘p’ and ‘w’ is a port of a switch ‘w’.
(1) 
(2) 
Once the topology of the network is ready, then the packet transmission relation among the switches is given in recursive relation. Equation 1 presents a packet transmission relation without modifying packet header ‘h’ from input port p to p’. Equation 2 presents a packet transmission relation with modifying packet header ‘h’ from input port p to p’. In both equations 1 and 2, the first condition of the equation presents a packet dropping node, where the number of nodes in a network is not sufficient to send a packet across the network. The second condition of the equations presents a transmission relation across the nodes of a network based on network configuration function ConfiG.
ConfiG is network configuration function, which assigns forwarding rules to switches, ConfiG: W FR. Packets enter into an input port of a switch is configure and forwarded based on forwarding rules. A run of an SDN is a sequence of transmission nodes is present as:
(3) 
Pair is considered as routing configuration by a controller to the switch . A run is a sequence of nodes in a network, which allows packet is passing through in it.
4 Representation of SDN in Kripke and SAT Structure for Model Checking
Verification of SDN security properties is essential, and it enhances the confidence of the system. In this section, we present an SDN’s Kripke structure along with specifications of SDN using LTL and CTL. Kripke structure of an SDN and its specifications are used in the verification process via model checking. Due to the advantages of Bounded model checking, we reduce the model checking problem with a bound, which can be solved by SAT solvers.
The Kripke structure of an SDN is a tuple SDN=(S, S, T, L) as shown in figure 1, where:

S is a set of initial states where, S S.

‘S’ is a set of states (S, where represents states belong to the controller and represents states belong to switch).

T S S is a transition relation ({(), (), (), () } T), where and is a set of states in a controller and switch.

‘L’ is a labelling function ‘L’: ‘S’ 2
. In our model we used boolean vector
I, W, C , FC, M, O A. ‘I’ and ‘O’ are the bits to represent the input and output port of a switch and a controller. ‘W’ is a bit to represent a packet state in a switch and ‘C’ is a bit to represent the packet state in a controller. FC and M are the bits to represent states, where forward rules calculation and header modification happens.
Given a Kripke structure of SDN, the specifications of a system are expressed using an LTL or CTL formula ‘f’ and a bound ‘d’, and semantics of BMC can describe a process of constructing a propositional formula [SDN, X].
Let (s, s, s, . . s) be a finite sequence of states in a path . The description of a formula [SDN, X] contains two components: SDN is a propositional formula that contains (s, s, s, . . s) and X is also a propositional formula to validate the constraints given in a formula ‘f’. To define specification constraints X, we provide a definition of loop condition ‘L’ which is propositional formula that is true if there is a loop in path . Loop condition is considered as valid if there is a transition from ‘j’ to previous states.
(4) 
For a Kripke structure SDN, and d 0,
(5) 
The complete formula, which includes an SDN model and specification is presented in a boolean formula [SDN, X].
(6) 
Consider a Kripke structure of an SDN in figure 2. Each state of an SDN represented by fivebit variables. We use b[5], b[4], b[3], b[2], b[1] and b[0], where b[5] is a high bit and b[0] be the low bit. The initial state of an SDN is represented as follows,
(7) 
The transition relation of an SDN is represented as follows,
(8) 
4.1 Analyse with a Faulty Transition
We now add a faulty transition from state 101000 to state 001001 denote by T.
(9) 
Consider the primary property of an SDN, forward rules has to calculate for every packet which is pass through the controller for routing. The property is represented as Gp, where p is . Using BMC, we generate a counterexample results witness of Fp. The absence of such property indicates the SDN property is violated.
Consider a case where the bound d = 2 and unrolling the faulty SDN system transition relation in the following formula:
(10) 
The loop condition is represented as:
(11) 
The formula on a path without loops:
(12) 
Finally by substituting all terms and we get:
(13) 
By putting SDN transitions, loop condition and property together, we can get a new formula:
(14) 
Since a missing path is sufficient to prove a violation of SDN property, the loop condition is excluded. This results in the following formula:
(15) 
The assignment 110000, 101000, 001001 satisfies the above formula ; this assignment violates the fundamental property of an SDN.
4.2 Expression of SDN Properties using Temporal Logic
 :

For any state in SDN, it is not possible to send a packet to next switch without having forwarding rules.
 :

For any state in SDN, where a packet enters the controller always calculate forwarding rules for missed flowentry before sending it to the switch.
 :

For any state in SDN, where a packet enters the switch forwards to the controller for calculating/configuring forwarding rules if the switch misses the flow entry.
 :

For any state in SDN, where a packet enters the switch’s input port should forward to an output port if there are forwarding rules available to route the packet.
5 Conclusion
In cloud computing, softwaredefined network (SDN) gaining more attention due to its advantages in network configuration to improve network performance and network monitoring. It is essential to ensure the correctness of SDN due to secure data transmitting in it. In this paper, we present a work to apply formal techniques on the softwaredefined network for verification. The softwaredefined network is formally described using the Kripke structure and its properties are formally presented using temporal logic formulas. The SDN LTL or CTL properties are verified against the formal Kripke model to check the specifications meets its model. Furthermore, we also analysed with a faulty transition and verified faulty transition violates the fundamental properties of the SDN.
References
 [1] A. Prajapati, A. Sakadasariya, and J. Patel. Software defined network: Future of networking. In 2018 2nd International Conference on Inventive Systems and Control (ICISC), pages 1351–1354, Jan 2018
 [2] M. C. Gaudel. Formal methods for software testing (invited paper). In2017 International Symposium on Theoretical Aspects of Software Engineering (TASE), pages 1–3, Sept 2017
 [3] Edmund M. Clarke, Thomas A. Henzinger, and Helmut Veith.Introduction to Model Checking, pages 1–26. Springer International Publishing, Cham, 2018
 [4] Gerard J. Holzmann. The model checker spin.IEEE Trans. Softw. Eng.,23(5):279–295, May 1997.
 [5] S. V. A. Campos. Ieee recommended practice for powering and grounding electronic equipment. (color book series  emerald book). In Proceedings. XII Symposium on Integrated Circuits and Systems Design (Cat. No.PR00387),pages 98–101, 1999.
 [6] C. Lutz, F. Wolter, and M. Zakharyaschev. Temporal description logics: Asurvey. In2008 15th International Symposium on Temporal Representation and Reasoning, pages 3–14, June 2008.
 [7] H. K. Jnanamurthy, F. Henskens and D. Paul, "Verification of interactive automated air traffic control system in a model driven approach," 2016 2nd International Conference on Contemporary Computing and Informatics (IC3I), Noida, 2016, pp. 841846.
 [8] H. Jnanamurthy, F. Henskens, D. Paul and M. Wallis, "Clone Detection in ModelBased Development Using Formal Methods to Enhance Performance in Software Development," 2018 3rd International Conference for Convergence in Technology (I2CT), Pune, 2018, pp. 18.
 [9] S. BenDavid, B. Sterin, J. M. Atlee, and S. Beidu. Symbolic model checking of productline requirements using satbased methods. In2015 IEEE/ACM 37thIEEE International Conference on Software Engineering, volume 1, pages189–199, May 2015.
 [10] C. Tian and Z. Duan. Detecting spurious counterexamples efficiently in abstract model checking. In2013 35th International Conference on Software Engineering (ICSE), pages 202–211, May 2013.
 [11] S. Reda, R. Drechsler, and A. Orailoglu. On the relation between sat and bdds for equivalence checking. In Proceedings International Symposium on Quality Electronic Design, pages 394–399, 2002.
 [12] L. Giordano, A. Martelli, and D. T. Dupr e. Achieving completeness in the verification of action theories by bounded model checking in asp.Journal of Logic and Computation, 25(6):1307–1330, Dec 2015.
 [13] P. Arcaini, A. Gargantini, and E. Riccobene. How to optimize the use of satand smt solvers for test generation of boolean expressions.The Computer Journal, 58(11):2900–2920, Nov 2015
 [14] Patricia Bouyer, Patrick Gardy, and Nicolas Markey. Quantitative verification of weighted kripke structures. In Franck Cassez and JeanFran, editors, Automated Technology for Verification and Analysis, pages 6480, Cham, 2014. Springer International Publishing.
 [15] M Hegde, Jnanamurthy H K and S.Singh. Modelling and verification of extensible authentication protocol using spin model checker. In Int. J. Netw. Secur. Appl, volume 4, pages 8198, 2012.
 [16] Manu S. Hegde, Hk Jnanamurthy, and Sanjay Singh. 2012. Formal verification of the Extensible Authentication Protocol using SPIN. In Proceedings of the Second International Conference on Computational Science, Engineering and Information Technology (CCSEIT ’12). Association for Computing Machinery, New York, NY, USA, 365–371.

[17]
H. K. Jnanamurthy, C. Warty and S. Singh, "Threat Analysis and malicious user detection in reputation systems using Mean Bisector Analysis and Cosine Similarity (MBACS)," 2013 Annual IEEE India Conference (INDICON), Mumbai, 2013, pp. 16.
Comments
There are no comments yet.