Formal Verification of Ad hoc On-demand Distance Vector (AODV) Protocol using Cadence SMV

Transcription

1 Formal Verification of Ad hoc On-demand Distance Vector (AODV) Protocol using Cadence SMV Xin Liu and Jun Wang Department of Computer Science, University of British Columbia 2366 Main Mall, Vancouver, BC, Canada, V6T 1Z4 {liu, ABSTRACT Routing protocols usually consist a huge state space (exponentially increase with the number of entities involved in the protocol) because of the concurrency and data-centric properties. The naïve approaches which directly use traditional verification techniques like explicit state exploration (e.g. Murphy [9]) or symbolic model checking (e.g. SMV [3]) often cannot make much progress due to the state explosion problem. Wireless routing protocol poses additional challenges, that is, the nature of the unstable environment requires wireless communication protocol to maintain extra information to keep a certain level of availability and fault tolerance. Also, the network topology changes require a more complex model. This makes the originally serious state explosion problem even worse. This paper studies a well-known routing protocol AODV (ad-hoc on demand distance vector routing). We propose an approach to decompose the whole problem into relatively small problems and describe techniques to handle specific properties of communication protocols. KEYWORDS: model checking, node, network topology, state explosion 1. INTRODUCTION With the mature of various wireless communication technologies, people put lots of attention to develop efficient and reliable wireless routing protocols. It is a great opportunity for verification community to get involved in a new, important and promising application domain. However, it also poses a big challenge to traditional verification techniques because unlike combinational logic and other simple interacting finite state machine, wireless routing protocol does not only involve concurrency, but also need to keep large amount of local data which depend on each other s state and network topology. Moreover, the network topology in wireless computing environment is not fixed and therefore the way those concurrent finite state machines (or nodes in terms of application domain) interact should also vary. Some previous works have been done on the verification of wired routing protocols and even wireless routing protocols. [4] verifies RIP using SPIN [13] and HOL. [7] uses SPIN [13] and PROMELA to verify ATM Routing Protocol PNNI(Private Network-Network Interface). At the wireless side, [4] also uses SPIN to verify AODV. [8] also verifies AODV, but through a timed automata approach. However, these approaches only handle very small number of nodes (typically two or three nodes) and extremely simple and fixed network topology (even for wireless protocol). We argue that although their models can provide a relatively accurate representation of a single node s behaviour, they do not provide satisfactory solution to state explosion problem and therefore cannot be extended to handle even slightly more complicated network topology. Also, 1

2 fixed network topology is definitely an unreasonable assumption for wireless protocol since in real environment nodes tend to be very dynamic and can move around without any restriction. This property therefore suggests a dynamic network topology. However, we are not claiming that there must exist a way to use existing tools to verify arbitrarily large networks. Since each entity in the network must keep some minimum local information which depends on the current network state, these mutually dependent local data suggest that the state space has to be huge no matter how we build the model. Moreover, the dynamic property of wireless networking environment implies that more state variables must be used to keep track of the network topology from the global point of view. In this paper we propose a method to decompose the dynamic networks into representative categories and use a step by step approach to verify big networks. We also provide a simple yet general approach to handle the modeling of timeout, sequence number and message channels. We argue that due to some special properties of routing protocols, the modeling of timeout, sequence number, and message channels can be greatly simplified and abstracted without losing generality. The remainder of this paper is organized as follows. Section 2 gives an introduction to Symbol Model Checking. Section 3 gives a brief introduction of AODV algorithm and describes some terminology which we will use later. In section 4, we give details about our approach to break the problem set and how to model them. The bug we found during the verification, along with some thoughts about the protocol specification is described in section 5. Section 6 generalizes the way we deal with each specific challenge to the verification of wireless routing protocol. Section 7 concludes the paper. 2. SYMBOLIC MODEL CHECKING In this section we briefly describe the concept of symbolic model checking and the Cadence SMV tool. Symbolic Model Checking [3] is a formal verification technique. Instead of explicitly representing state space using tables or lists, symbolic model checking makes use of Binary Decision Diagram (BDD) [5] to give a symbolic representation of state space. Therefore, in terms of verification, instead of explicitly exploring the whole state space by using some graph searching algorithms (such as depth first search and breadth first search), symbolic model checking uses image computation to derive the state space represented in BDD form. People claim that in many cases the complexity of state space is much less than the number of states [3]. The most well-known tool that makes use of symbolic model checking is SMV series. In this paper we use Cadence SMV [6], which is designed in Cadence Berkeley Lab. The properties to be verified are specified in LTL (Linear Temporal Logic). Although originally it is designed mainly as a verification system for hardware design, many people started to apply it to more general and software-based verification tasks. As powerful as Cadence SMV is, users still need to do compositional verification [6]. Cadence SMV provides various approaches, such as Refinement Mapping, to classify and decompose complex problem domain. Cadence SMV has a very efficient way of verifying properties of combinational logic and interacting finite state machines, but it does not have an efficient way of handling real numbers or integers. 2

3 3. AODV AODV, also known as Ad hoc On-demand Distance Vector protocol, is an IETF standardizing protocol for MANET (Mobile Ad-hoc Network). It is designed by Charles E. Perkins and Elizabeth M. Royer and was first published in The version we are working with is its latest RFC version, also known as RFC3561 [2]. There is a newer draft version of AODV protocol, but since it is incomplete and most discussions about this protocol are based on RFC3561, we decided not to use the new draft. Therefore, we are not responsible for the incompatibility issues raised by the newer version. Like other Ad-hoc networking protocol, it does not rely on the coordination of a Access-Point or Base Station, instead, neighbouring nodes can recognize each other and then build or join small groups. The way AODV works is based on On-Demand approach which uses distance vector to build a path to a destination node whenever it is necessary. The advantage of this approach is that it can adapt to the network topology change quickly and therefore is suitable to be deployed on highly mobile network environment. Also, the on-demand property results in low-processing requirement and low-network utilization. However, like other distance vector based routing protocols, the biggest challenge is to avoid loop condition. Because whenever it is trapped into some loop conditions, it might stay in the loop infinitely without noticing it. The RFC3561 claims that AODV protocol is now loop-free, and our work shows that this is not the case. The protocol itself is relatively simple. There are 3 types of control messages, RREQ stands for route discovery message, RREP stands for reply message and RERR stands for error message. As the name suggested already, RREQ is used to discover a route when current node wants to send a data packet to another node but it does not have a valid path to that node. On the other hand, RREP message is generated to reply the initiator of the RREQ message when a node itself is the destination node or it knows a valid route to the destination node. RERR message is used when a node notices a link-break or in the case some other error conditions appear. More details about this protocol can be found in [1]. 4. MODEL As we stated in the introduction, wireless routing protocol, such as AODV, does not only involve concurrency, but also need lots of local data to store the routing information. It also needs to keep some data to track the network topology. So, simply employing the naïve approaches which directly model the protocol according to its specification will often encounter the state explosion problem, which makes the verification impossible. This is proved by the experience on our first version model, in which we try to give a general and complete model according to the RFC3561 (in this model, every node can initiate a route discovery and can be the destination, and every node maintains the routing table). On our desktop PC with Pentium4 CPU 2.4GHz, 1GB RAM, two nodes model consumes 400 MB memory and runs for 10 minutes, but three nodes model encounters the state explosion and can not run further. To avoid the state explosion, we use an approach which decomposes the whole problem into relatively small problems, in more detail, we enumerate all the possible network topologies, and model each meaningful topology separately. The beauty of this method is that in each model, the 3

4 network topology is known, so we can give specific role (originator, intermediator, or destination) to each node, thus the state space can be reduced significantly. Furthermore, by using this approach, we can minimize the nodes local variables further, for example, the routing table of destination node can be removed. Figure 1 gives the meaningful network topologies for three nodes, which are named linear topology and triangle topology. Figure 2 gives the meaningful network topologies for four nodes, called star topology, umbrella topology, linear topology, diamond topology, camel topology, and complete topology, respectively. (The link between two nodes means that they can communicate with each other) Figure 1. Meaningful network topologies for three nodes Figure 2. Meaningful network topologies for four nodes We should mention that this approach also deals with dynamic network topology changes. Starting from the simplest topology, we can go step by step to verify more complex topologies. The idea is if we know that certain properties held in some simpler topologies and if we can prove that a more complex topology can be scaled-down to those simpler versions with certain changes and these changes will not affect the properties, then we know that these properties will hold in the more complex topology no matter how its topology changes, providing that without changes those 4

5 properties held in that topology. For example, in order to verify that with dynamic network changes, the 3-nodes triangle type is always loop-free, we can first verify that this property held in the 3-nodes linear type. Note that when network topology changes in this triangle type, for example, the destination node moves around, the only interesting case is that it cannot talk to originator anymore, which is exactly the same as what 3-nodes linear type looks like. Therefore, if we can verify that loop-free is true in the period after the link originator-destination breaks and before the network becomes a stable linear type again, then we know that the dynamic topology change will not affect the loop-free property in this case. Although this approach is sound but not complete, it does cover lots of interesting cases which cannot be covered by other approaches. In our current work, we have modeled the 3-nodes linear topology and triangle topology. For four nodes, star topology and umbrella topology are modeled. Table 1 gives the running results of these models except for the four nodes umbrella topology. We should mention here that when we run 4-nodes umbrella topology model, the Cadence SMV crash when the model consumes 600 MB memory. We think that there must be some bugs in the current implementation of Cadence SMV to cause this crash. Since the time limit, we cannot find why this is case, but we believe with a more concise and specific model, our approach is able to handle at least this topology. State variables Consumed Memory Running time 3-nodes linear topology MB 4 minutes 3-nodes triangle topology MB 4.5 minutes 4-nodes star topology MB 2 minutes Table 1. Running results of models 5. LOOP CONDITION The models we described above do not consider the data packet. With these models, Cadence SMV does not find counterexamples. However, this does not mean that the specification of AODV (RFC3561) which we work on is loop free. It is very likely that SMV does not find bugs because the models have done too much abstraction, and some of the abstractions hide the bugs. After carefully reviewing RFC3561, we believe that not considering data packet is kind of over abstraction, so we decide to add data packet into the models. As a result, the three nodes triangle model does find a bug which can result in loop. Following section describes this bug in detail Loop Condition Appendix demonstrates the bug we found. Suppose we have 3 nodes: A, B, and C. A is originator, B is intermediator, and C is the destination. Initially, A has a route to C via B, and the destination sequence number is 0. Suddenly the link between B and C break, B find this link break and start repair. It broadcasts a RREQ message with destination sequence number 1, but this message is lost (this is showed in Figure 3(a)). Then the repair at node B timeout, it increase the route entry s destination sequence number to 1 and set the route entry invalid, it also send a RERR message with destination sequence number 0 to A, however this message is lost too (showed as in Figure 3(b)). Later B want to send data to destination C, but it find it does not have a valid route to C, so it initiate a route discovery. It broadcast a RREQ message with destination sequence number 1. Node A receive this message and forward it to C, since destination sequence number in RREQ 5

6 message is greater than the destination sequence number in node A s route entry (this is showed in Figure 3(c)). When C receives the RREQ message, it increases its sequence number to 1 and sends a RREP message back to A. At the same time, node A sends a data packet destining C to node B. This is reasonable because A has valid route to destination C via B (showed as Figure 3(d)). As the RREP message arrives at node A, A update its route table and send a RREP message to node B. For node B, when it receive the data packet sent by A, it find that it does not have a valid route to destination C, so it send a RERR message with destination sequence number 1 back to A (this is showed in Figure 3(e)). When node B receives the RREP message, it updates its routing table. From now, node B has a valid route to destination C via A. When node A receives the RERR message, it set its route entry invalid, so now it doesn t know how to get destination C (showed as Figure 3(f)). Later link AC break. Following this link break, node A want to send data to C, but it doesn t have a valid route, so it initiate a route discovery. It sends RREQ to node B. Node B receives this RREQ message, sends back a RREP message to A, thus we get loop between A and B, which is showed as Figure 3(g) and Figure 3(h) Other Problems in the Specification Virtually all standard specifications contain ambiguities and omissions, RFC3561 is no exception. After carefully review the standard, we find that the specification doesn t say how to set the destination sequence number of RERR message when generate it (we set the destination sequence number copied from route entry, which we think is reasonable). The specification is also not clear about what to do after receiving RERR message. 6. VERIFICATION CHALLENGES AND SOLUTIONS In this section we list several common challenges that must be dealt with when verifying routing protocols. For each challenge, we also describe the approach we used to solve it and why we believe this is the proper approach.. Lots of these challenges can be handled by nondeterminism. However, we need to distinguish Global order (total order) and Partial order (local order) before we apply nondeterminism technique. Generally speaking, nondeterminism is more suitable to handle partial order rather than total order. Detailed discussion is provided later Timeout Many verification tools (e.g. Murphy, SMV) do not provide direct support for time-related operations, and even if time is built into the tool (e.g. SPIN), the support is still very rudimentary. Therefore, timeout is usually modeled either by nondeterminism or a counter. As long as the property we need to verify is not directly related to real-time, the above two approaches are usually good enough. However, unlike some real time protocols, correctness of routing protocol should not depend completely on some tight and concrete time constraints. The nature of the network, especially wireless network, makes any tight and concrete time constraint unreasonable. Here, by saying tight we mean any bound that is tighter than the possible maximum live time of a message that can stay in network without being discarded. Therefore, the value of timeout should be considered as a suggestion, which can be used to improve the performance of routing protocols. In our work we use nondeterminism approach, which is not only reasonable but also effective in terms of verifying loop-free property. 6

7 However, pure nondeterminism is also not a good solution because certain events should happen in some determined order. This is the concept of global order and partial order. Partial order is a perfect match to nondeterminism, but global order (total order) is not. For example, if event A happens before event B, and both of them start a timer (with same value), then the timeout event of event A should occur before the timeout event of event B. This is a subtle point which is very likely to be missed during the initial modelling. On the other hand, without considering these points, we might get many unrealistic solutions. We use two methods to solve this problem. The first is to add fairness constraint to prune unrealistic paths. However, this will lead to very complicated Temporal Logic statement and may affect the performance. The other approach, which we believe is better, is to plug the order into model. In terms of the example stated above, instead of making two independent processes describing the timeout event, one can pass a common boolean variable as argument to them, which states that if A happens before B, then A should timeout before B Lifetime and TTL These two time-related parameters are widely used in AODV and other routing protocols as well. If it is necessary, then we can use the same approach as described in last section to model them. However, in order to avoid the state explosion, usually they are excluded from the final model unless their values will affect the correctness of the property to be verified Periodical Message This is a common operation in most of the routing protocols. The liveness of a route usually depends on these messages, for example, the HELLO message in AODV is used to determine the liveness of neighbouring nodes. Again, for tools without a built-in concept as TIME, periodical message cannot be model in a straightforward fashion. Some other tools, such as SPIN, Verus might be more suitable in terms of modeling these messages. We think it is not possible to model the exact behaviour in Cadence SMV directly, therefore, we use the reverse approach, which is to model the consequence of receiving or not receiving these messages instead of modeling the message itself. The consequence of receiving or not receiving these periodic messages is modeled to happen nondeterministically. For example, instead of modeling sending HELLO messages, we use a process link_break to represent what happens if no HELLO message is received in a given period. This approach gives an additional abstraction of the actual behaviour, therefore, it is not a perfect solution and may generate more unreasonable counter examples. But with a careful design of the model itself and some fairness constraints, we can get rid of most uninteresting and unrealistic behaviour Sequence Number Sequence number modeling is also a big challenge to verification. Like many other verification tools, Cadence SMV does not have a specific representation of real number or integer. Integer is treated as Enumeration type and therefore is kept in its binary form. However, this enumeration type of representation causes a single variable to have the same number of values as the bits that are used to represent all the integers. For example, if the sequence number is from 0 to 1023, then each state variable will have 1024 choices and each asks for 10 bits to represent. Since SMV checks models by exploring all the possibilities of these values, the state explosion problem is 7

8 very seriously. Without the tool support, there is no perfect way of solving this problem. The approach we use is just to set a very small upper bound on sequence number. In addition, we use an INVALID value indicating the end of the verification task. Whenever any sequence number based variable is assigned a value as INVALID, then it will not change again and thereby the model will converge very fast. Although it is true that by doing this, the verification will not be complete any more, the improvement of performance usually beats the disadvantage. Just like the tradeoff happening here, we would rather use more abstracted model to verify as much as we can instead of using a complete model and thereby cannot verify anything at all. Moreover, the incompleteness can often be minimized or even eliminated by a carefully overall design (e.g. decomposition of problem domain) Channel and Message Buffer This is a challenge because in real protocol, message buffers tend to be huge and a single channel can contain multiple messages at the same time. However, in terms of verification, we cannot afford so many individual states. We argue that setting an arbitrary upper bound on buffer size will not help because no matter which value you choose, it will not be general enough to represent the actual behaviour of channel or message buffer. The good news is, since we model the protocol in terms of nondeterministic finite state machine, as long as it is not necessary to model the case like certain number of k (k > 1) messages must be sent by node A and C before node B can handle one of the messages, then setting buffer size to be 1 should probably be general enough to satisfy the verification requirements (here we are not considering the reordering of messages, which will be discussed next). In terms of verifying Loop-free property, AODV does fall into this category Message Reorder This is not a big problem for routing protocol because it is reasonable to assume that on a single link, message should arrive in order. This property is guaranteed by the underlying network. For details about this property, interested readers can refer to ETHERNET specification for wired network and IEEE802.11b for wireless network. Therefore, when we talk about message reordering in these areas, we actually mean the reordering due to the network congestion, which involves several nodes and channels. Since different node and channel is modelled separately, using size 1 as message buffer or channel capacity is reasonable Message Loss This is common to wireless networking because the unreliable communication environment. It is easy to think of modelling it by using nondeterministic message_loss process. However, there is still one problem. If the property we want to verify is related to reachability, then the verification process will probably return false because from SMV s point of view, it is reasonable that a message can never reach its destination. In order to avoid this, certain fairness constraints should be used to prune corresponding scenarios. However, these constraints can turn out to be very hard to write and even if you can write them, they often tend to be too expensive to compute. 7. CONCLUSION AND FUTURE WORK Routing protocols, especially wireless routing protocols, have some special properties that challenge traditional verification techniques. There is no straightforward approach to verify a 8

9 routing protocol automatically by using existing tools alone. Even with the help from some tools targeting at communication protocols, such as SPIN, the verification can only handle a fairly small network. Cadence SMV is a powerful tool, but based on our experience, we think it is not suitable for verifying routing protocols, although we use it and finally find a bug in current RFC specification of AODV protocol. In this paper, we propose a general approach to decompose a big network into handful pieces and we show how this approach can be used to handle the challenge coming from the dynamic network topology change. However, even with help from this approach, it is still very difficult to solve the state explosion problem. Here is a tradeoff. We can do more abstraction and thereby shrink the state space. Proving the abstract model is correct will automatically imply the correctness of the properties that are included in the abstract model. However, properties that are excluded from the abstract model are still left unproved. Therefore, too much abstraction makes the verification more unrealistic and it is hard to discover bugs. On the other hand, we can do less abstraction and model more details, but by doing this we might not be able to verify anything at all. Therefore, a certain level of abstraction has to be used. The limitation of our current work is that we can not find a proper level of abstraction, which can be used to verify certain properties without losing generality, and can be easily configured to handle more complex network and verify more complicated properties. We leave this as our future work. REFERENCES [1] AODV Homepage. [2] AODV RFC [3] J. R. Burch, E.M. Clarke, K.L. McMillan, D.L. Dill, L.J. Hwang. Symbolic Model Checking: States and Beyond. Information and Computation, Vol. 98, No. 2, June [4] K. Bhargavan, D. Obradovic, C. Gunter. Formal Verification of Standards for Distance Vector Routing Protocol. J. ACM 49(4): (2002) [5] R. Bryant. Symbolic Boolean Manipulation with Ordered Binary Decision Diagrams. CMU CS Tech Report CMU-CS [6] Cadence SMV Documentation [7] D. Cypher, D. Lee, M. Villalba, C. Prins, D. Su. Formal Specification, Verification, and Automatic Test Generation of ATM Routing Protocol: PNNI. In Proceedings of FORTE/PSTV'98, Case Studies in Protocols,1998 [8] S. Chiyangwa, M. Kwiatkowska. Modeling Ad hoc On-demand Distance Vector (AODV) Protocol with Time Automata, in proceedings of Third Workshop on Automated verification of Critical Systems (AVoCS'03), Southampton April 2003 [9] D.L. Dill, A.J. Drexler, A.J. Hu, C.H. Yang. Protocol Verification as a Hardware Design Aid. International Converence on Computer Design, [11] K. Havelund, N. Shankar. Experiments in Theorem Proving and Model Checking for Protocol Verification. In Proceedings of FME 96, LNCS 1051 [12] Davor Obradovic, Formal Analysis of Convergence of Routing Protocols, Ph.D. Thesis Proposal, Department of Computer and Information Science, University of Pennsylvania, November 28, 2000 [13] SPIN Homepage. 9

10 APPENDIX LOOP CONDITION Figure 3. shows the bug we find which can result in loop. Message format: RREQ: dest_seq RREP: dest_seq, hop_count RERR: dest_seq Figure 3(a) Figure 3(b) Figure 3(c) Figure 3(d) 10

11 Figure 3(e) Figure 3(f) Figure 3(g) Figure 3(h) 11