Verication of the Alternating-Bit-Protocol using Automated Theorem Provers in ILF - a case study Thomas Baar y Institute of Mathematics Humboldt Unive

Size: px

Start display at page:

Download "Verication of the Alternating-Bit-Protocol using Automated Theorem Provers in ILF - a case study Thomas Baar y Institute of Mathematics Humboldt Unive"

Reynard Arnold
5 years ago
Views:

1 Verication of the Alternating-Bit-Protocol using Automated Theorem Provers in ILF - a case study Thomas Baar y Institute of Mathematics Humboldt University Germany Ingo Dahn z Institute of Mathematics Humboldt University Germany June 5, Motivation For many years the OSI-reference model has been developed into a standard of communication in open systems. The OSI-model knows 7 layers. In each layer communication is described at a specic level of abstraction. Each layer oers services to the next higher layer. Vice versa the layer can use services oered by the underlying layer. In this article we investigate the service 'reliable data-transmission ' oered by DataLink-Layer. Realizing this service the DataLink-Layer can use only the service 'unreliable data-transmission' provided by Physical-Layer. Therefore a communication protocol has to be used. We will formally describe a well-known protocol (Alternating-Bit-Protocol) and prove, that the service oered by DataLink-Layer is really reliable, as soon as the Alternating-Bit-Protocol (ABP) is used. We use the ILF-System [4] for formal verication. ILF combines interactive possibilities for proof development with the power of ATP's. We point out some principles of deduction which are useful in the area of protocol verication. Therefore our verication is only an example how to verify a protocol using ILF. The main proof ideas can be reused to verify much more sophisticated protocols (e.g. Sliding-Windows-Protocol, Kermit-Protocol) or to prove correctness properties of distributed systems. 2 ABP and Z The specication language Z is suitable for specication of distributed systems and protocols. Z is widely used. It is based on set theory and sorted rst order This work is supported by the Deutsche Forschungsgemeinschaft within the Schwerpunktprojekt Deduktion. y baar@mathematik.hu-berlin.de z dahn@mathematik.hu-berlin.de 1

2 predicate logic. Many concepts in Z can be easily translated into other logical languages [3]. A library of well-known mathematical theorems - called Mathematical Toolkit - is an integral part of Z. It is comfortable to use these theorems formally in a proof for our purpose. The separation of the Mathematical Toolkit and the structured character of Z specication turn out to be very useful for formal proof development. The ABP, rst proposed in [2], is a very simple protocol, but its main idea is also used in other much more powerful protocols. Each message to transmit is augmented by an additional bit. Sender and receiver can mark and distinguish actual messages. The ABP is often described in terms of distributed systems. There are 4 agents and several actions to change their state. Sender - SendMsg TimeOut RecAck RejAck - MsgChan LoseMsg LoseAck 6? AckChan? RecMsg RejMsg - Receiver Figure 1: Agents and actions of ABP Starting with an initial state S 1 the decribed system denes a set of possible traces. A trace is a nite or innite sequence S 1 A 1 S 2 A 2 S 3 : : :, where A i denotes an instance of an action, S i the prestate, S i+1 the poststate of A i. We call a projection of a trace to the sequence of states history of states (sthist) and a projection to the sequence of actions history of actions (ophist). From the set of all traces we consider only a subset, called set of regular runs. A trace is a regular run, if it satises some fairness properties. For our ABP-system we want to prove that the nite sequence of messages - which the sender had to transmit in the initial state - is eventually received by the receiver. As a formal basis for our proof we formulate a Z specication to describe the ABP. We omit the specication of some actions which will not be interesting in further sections. At rst we specify some global types and constants. We dene all possible messages as the Z basic type MSG, that means that MSG denotes a nonempty set. Possible synchronization bits (members of Tag) are either 0 or 1, TaggedMsg is the cartesian product of Tag and MSG. The function ip yields the opposite synchronization bit, msgsfortrans is the sequence of messages to transmit by the sender in the initial state. In Z notation this is: [ MSG ] Tag == f0; 1g TaggedMSG == (Tag MSG) 2

3 ip : Tag! Tag ip(0) = 1 ip(1) = 0 msgsfortrans : seq MSG Sender, receiver and channels are specied as schemas. A schema consists of a declaration and a description part (optional). The declaration part declares components, the description part denes some relations among components. Sender and Receiver contain components for their local synchronization bit (acttag,exptag) and for sended / received messages (msgsin / msgsout). Furthermore Sender needs a buer to retransmit the last message (lasttaggedmsg) when a timeout signal occurs. Channels are modelled as nite sequences. Sender msgsin; yettotrans : seq MSG lasttaggedmsg : P(Tag MSG) acttag : Tag Receiver msgsout : seq MSG exptag : Tag msgsin a yettotrans = msgsfortrans MsgChan msgchan : seq TaggedMSG AckChan ackchan : seq Tag We include these schemas into a System-schema and specify an initial state for System. A schema is included into another schema by copying its declaration and description part. System Sender MsgChan Receiver AckChan Init System msgsin = msgsout = h i msgchan = h i ^ ackchan = h i lasttaggedmsg =? yettotrans = msgsfortrans acttag = ip(exptag) To specify actions Z oers the use of operation schemas. An operation schema for System includes all parts of System in the original and decorated (with ') form, so all components of System are also in original and decorated form components of the operation schema. An original component refers to the component in the prestate, the decorated to that in the poststate. The inclusion part is an abbrevation for inclusion of part and part 0. The inclusion part is an abbrevation for part and the additional equation part = part 0. We explain schema-, - and -inclusion in section 3. The action SendMsg changes Sender and MsgChan (-inclusion) and preserves Receiver and AckChan (-inclusion). 3

4 SendMsg Sender Receiver MsgChan AckChan lasttaggedmsg =? ^ yettotrans 6= h i yettotrans 0 = tail yettotrans ^ acttag 0 = ip(acttag) msgchan 0 = msgchan a h(acttag 0 ; head yettotrans)i lasttaggedmsg 0 = f(acttag 0 ; head yettotrans)g TimeOut Sender Receiver MsgChan AckChan acttag 2 dom lasttaggedmsg msgchan 0 = msgchan a h(acttag; lasttaggedmsg(acttag))i LoseMsg Sender Receiver MsgChan AckChan msgchan 6= h i msgchan 0 = tail msgchan RecMsg : : : : : : RejMsg : : : : : : OP == fsendmsg; TimeOut; RecMsg; RejMsg; RecAck ; RejAck ; LoseMsg; LoseAckg Until now, only ABP-specic statements have been made. In order to describe another protocol or distributed system, this part of specication only has to be changed. In the next part we express formally regular runs. Some preparations: OPSystem System pre == ( OPSystem System) post == ( OPSystem System 0 ) tracelike X == ff : N 1 7! X j 8 i 1 ; i 2 : N 1 i 1 < i 2 ^ i 2 2 dom f ) i 1 2 dom f g 4

5 regular runs : sthist : tracelike System ophist : tracelike OP dom ophist = dom sthist 1 2 dom sthist 8 op : OP [no action is triggered in the last state] 8 opinst : op dom sthist 6= N 1 ) sthist(#sthist) 6= pre(opinst) sthist(1) 2 Init 8 i : (dom sthist n f1g) 9 opinst : ophist(i? 1) sthist(i? 1) = pre(opinst) ^ sthist(i) = post(opinst) 8 i 1 : N 1 8 op : OP [Fairness] (9 i 2 : N 1 i 1 i 2 ^ i 2 2 dom ophist ^ ophist(i 2 ) = op) _ (9 i 3 : N 1 j i 1 i 3 8 i 4 : N 1 j i 3 i 4 8 opinst : op i 4 2 dom sthist ) sthist(i 4 ) 6= pre(opinst)) To prove the desired property of the protocol we prove several subgoals which can be seperated in so called safety and liveness properties. As one of the possible safety properties we want to prove that in every state of a regular run the sequence of received messages is a prex of the sequence of already sent messages. 8 i : N 1 i 2 dom(sthist) ) sthist(i):msgsout sthist(i):msgsin As one of the possible liveness properties we want to show that the sender will send a new message until he has sent all messages: 8 i : N 1 i 2 dom(sthist) ^ sthist(i):yettotrans 6= h i ) 9 j : N 1 j i ^ j 2 dom(sthist) ^ #(sthist(j ):msgsin) = #(sthist(i):msgsin) ILF and Z We have to translate Z specications into ILF theories, because ILF is unable to handle original Z specications. The syntax of ILF-theories is very similar to ordinary predicate logic. Moreover a powerful type system can be used to formulate short and readable ILF theories. Currently the translation from Z to ILF notation has to be done by the user. The translation must respect some translation rules and it is straightforward. We demonstrate a small translation into typed logic. Basic types, predicates and functions are translated as usual. 5

6 Z Typed Logic [ t 1 ] r : P t 1 c : t 1 f : t 1! t 1 TYPE = ft 1 g PRED = f(r : [t 1 ])g FUN = f(c : []! t 1 ); (f : [t 1 ]! t 1 )g Schemas can be represent as predicates, their components as functions. A a 1 : t 1 r(a 1 ) TYPE = fschg sch represents schematype hj a 1 : t 1 ji VAR = f(x : sch)g FUN = f(a 1 : [sch]! t 1 )g PRED = f(r A : [sch])g Theory = f8 x r A (x), r(a 1 (x))g We do not directly translate more sophisticate Z structures like schema-, - and -inclusion into typed logic. We only unfold this abbreviations into ordinary schemas, which are then translated as above. Z plain Z A a 1 : t 1 r(a 1 ) no simplication B b 1 : t 1 r(b 1 ) no simplication Sys A B Sys a 1 : t 1 [all declarations of A and B] b 1 : t 1 r(a 1 ) [all denitions of A and B] r(b 1 ) 6

7 Init Sys a 1 = c Init a 1 : t 1 b 1 : t 1 r(a 1 ) r(b 1 ) a 1 = c [like Sys] [additional denition of Init] Op1 A B b 0 1 = f (b 1 ) Op1 a 1 : t 1 [original and decorated components] a 0 1 : t 1 b 1 : t 1 b 0 1 : t 1 r(a 1 ) ^ r(a1) 0 r(b 1 ) ^ r(b1) 0 a 0 1 = a 1 b 0 1 = f (b 1 ) [consequence of A] With the expansion of inclusions the structure and clarity of the specication are lost. However, this expansion leads to formulas with less complex terms. This facilitates the work for the ATP's considerably. Moreover, many proof problems require the use of information which refers to several components of the distributed system. Hence the structuring of the knowledge base suggested by the Z specication is not helpful for our verication task. 4 Proof of safety properties Usually an invariant is shown to hold by induction. This means to prove the subgoals (1) 1 2 dom sthist ) (1) (2) (n 2 dom sthist ) (n))?! ((n + 1) 2 dom sthist ) (n + 1)) It is seldom that an invariant can be shown separately. Normally we need auxiliary invariants (simultaneous induction). In our case 12 other invariants were necessary to prove the safety property formally. The whole proof consists of 13 proofs for initial step of the induction and 13 * 8 (number of actions) = 104 proofs for the other induction steps. The proofs of these numerous little tasks are stupid for humans and require a lot of concentration and time. It is only really interesting task during developing this proof to nd useful lemmas. Using ILF it is much easier to prove the desired properties. The user has only to formulate the auxiliary invariants. Based on specication theory and 7

8 invariants a user dened ILF tactic generates 117 subgoals, comparable with a natural proof. When the subgoals are proved the whole problem is proved. ILF ensures the formal correctness for this proof reduction. The user dened ILF tactic is a domain specic combination of many basic ILF tactics and make some assumptions about the structure of the underlying theory. The assumptions are only related to parts of the theory which dene formally regular runs and therefore the tactic is not specic for the Alternating-Bit- Protocol. We can reuse the tactic to show safety properties of other protocols or distributed systems. The generated subgoals can be solved automatically by the provers integrated into ILF or interactivly. The proofs of the subgoals for initial steps of induction are often trivial. It is more interesting to prove induction steps. As a simple but typical task we present the proof that action SendMsg respects the safety property 8 i : N 1 i 2 dom(sthist) ) sthist(i):msgsout sthist(i):msgsin For the induction step from n-th to (n+1)-th state a theory like in gure 2 is used. 1 The parts except part V) are automatically extracted by ILF. Typically the theory consists of simply structured formulas like facts and implications to specify pre- and postconditions. In part III) we can nd many equations because using equations is an intuitiv style of specication for dening actions like SendMsg. ILF can use these equations to simplify the theory and reduce the signature. Many functional symbols representing schema components in the post state can be substituted by their denition (e.g. yettotrans 0 = tail yettotrans), but there are also some other cases (compare msgsin 0 ). To solve an induction step other theorems (part V)) are often necessary. To prove properties of a Z specication we can use all theorems collected in the Z library (Mathematical Toolkit). It is a problem to choose the right axioms from this library. Generally the user has to do this work. ILF provides a facility to choose whole classes of axioms, e.g. all axioms dening a property for sequences. But the automatically selected theories contain in most cases more axioms than really needed. If no further simplication of the theory can be done, ATP's are invoked to prove the subgoals. The user can specify a timelimit (often 1-2 minutes) for each prover, after lapse of timelimit ILF kills the prover. To prove the subgoals we used the provers Setheo [7] and Discount [1]. In 102 of 104 cases Setheo or Discount can nd a proof before timelimit has exceeded. In the other 2 cases the user has to simplify the goal by a further tactic and after that, Setheo and Discount can also nd a proof. Therefore ATP's gave an eective support to the user while proving safety properties. The boring task to check every action for every invariant have been done by Setheo and Discount. It is possible that an ATP nds subproofs because there is an error in the specication. This is most easily detected when the user inspects a well readable 1 We abbreviate sthist(n):msgsout with msgsout and sthist(n+1):msgsout with msgsout 0, analogous for all other components. 8

9 I) Precondition msgsout msgsin II) Preconditions omitted here (not needed) of other invariants III) Denition lasttaggedmsg =? of SendMsg yettotrans 6= h i yettotrans 0 = tail yettotrans acttag 0 = ip(acttag) msgchan 0 = msgchan a h(acttag 0 ; head yettotrans)i lasttaggedmsg 0 = f(acttag 0 ; head yettotrans)g exptag 0 = exptag msgsout 0 = msgsout ackchan 0 = ackchan IV) Invariants msgsin a yettotrans = msgsfortrans of sender msgsin 0 a yettotrans 0 = msgsfortrans V) Mathematics 8 SQ 1 8 SQ 2 8 SQ 3 SQ 1 SQ 2 ) SQ 1 SQ 2 a SQ3 8 SQ 1 8 SQ 2 8 SQ 3 8 SQ 4 SQ 2 6= h i ^ SQ 1 a SQ2 = SQ 3 a SQ4 ^ SQ 4 = tail SQ 2 ) SQ 3 = SQ 1 a hhead SQ2 i VI) Goal msgsout 0 msgsin 0 Figure 2: Theory used by an induction step proof presentation. ILF supports this with it's automatic generation of human readable proof presentation [5]. Some subproofs found by ATP's are really interesting and quite dierent from natural ones. Such proofs give the user new insights into the mechanism of the protocol. Natural language proof presentation makes them intelligible for users without special knowledge in deduction. 5 Proof of liveness properties The proof of liveness properties requires to show that each message sent by sender is eventually received by receiver and vice versa each acknowledge message sent by receiver is eventually received by sender. We call this the information ow of the protocol. In principle we have to show that after every state an action will occur which can be viewed as a step forward in the infomation ow. Normally the argumentation for the occurrence of such an action is based on the fairness of regular runs. Since all nite runs are fair by denition, fairness is a useful property only for innite runs. 9

10 We argue, that in the last state of a nite, regular run all data and acknowledge messages are sent and received. Let us assume the opposite for the last state. This means that there are still some messages for the sender to send (yettotrans 6= h i) or the acknowledge for the last message is not received yet (lasttaggedmsg 6=?). In the second case the action TimeOut, in the rst case TimeOut or SendMsg are triggered and therefore it cannot be the last state of a regular run. Assuming innite runs we sketch a tiny step in the information ow : 2 8 i 1 : N 1 msgchan(i 1 ) 6= h i ) 9 j : N 1 j i 1 ^ last msgchan(i 1 ) = head msgchan(j ) Informally speaking: The last element in the channel will be eventually the rst one. For this we need the following lemma: 8 i 1 : N 1 msgchan(i 1 ) 6= h i ) 9 j : N 1 j i ^ msgchan(j + 1) = tail(msgchan(j )) To show this lemma we can distinguish 2 cases using fairness for action LoseMsg: 1. 9 j 1 : N 1 j 1 i 1 ^ ophist(j 1 ) = LoseMsg In this case we can prove the lemma observing the fact 8 l : N 1 ophist(l) = LoseMsg ) msgchan(l + 1) = tail msgchan(l) 2. 9 j 2 : N 1 8 j 3 : N 1 j 2 i 1 ^ (j 3 j 2 ) 8 opinst : LoseMsg sthist(j 3 ) 6= pre(opinst)) Hence 8 opinst : LoseMsg pre(opinst):msgchan 6= h i we can conclude: msgchan(i 1 ) 6= h i ^ j 2 i 1 ^ msgchan(j 2 ) = h i Now the proof can be completed using the following lemma. 8 i : N 1 (9 j : N 1 i < j ^ msgchan(i) 6= h i ^ msgchan(j ) = h i) ) (9 j 0 : N 1 i j 0 ^ msgchan(j 0 + 1) = tail msgchan(j 0 )) This little example shows, that we must prove numerous lemmas before proving a single step in the information ow. The user can nd and formulate these lemmas and therefore he has to know the main proof ideas. Some of the lemmas are independent from the protocol (like this example) other depend on protocol denition. Nevertheless the detailed proof for the liveness properties can be obtained by combining the interactively generated proofs with the subproofs found by the ATP's. 2 We abbreviate sthist(i):msgchan with msgchan(i), analogous for all other components. 10

11 6 Tactics The use of interactive provers is a consequence of the limited power of ATP's. Two general problems may cause the unability of nding a proof: The goal requires a long (complicated) proof or the supplied theory is too large and contains many axioms not needed to show the goal. Therefore ILF-tactics have to solve two tasks: 1) Simplication of goals 2) Choice of suitable axioms to prove the goal Especially - in ILF - it is not the major task of tactics to generate partial proofs. ad1) Finding a proof becomes more easy, if the required proof becomes shorter. The ILF system oers several possibilities to realize such a simplication using tactics. The user can insert helpful lemmas, generate an equivalent set of subgoals (e.g. to show A ^ B it is sucient to show A and B), apply some theorems (e.g. to show C it is sucient to show A ^ B if we have A ^ B ) C as an axioms in the theory). ad2) Often the choice of a theory for a subgoal is based on heuristics. Nevertheless we can connect theory choice with tactics. For instance the use of a lemma is in many cases only necessary for the goal, for which this lemma was inserted. For some goals, like the induction step to show safety properties, tactics can extract a quite exact theory choice if they respect the structure of the whole proof (compare section 4). From this point of view we can realize some properties of tactics which are especially important. Tactics should consists of some basic elements and control structures giving the user the possibility to dene his own domain specic tactics. The basic elements should include: inserting of new, user dened subgoals application of an inference rule analysis of goal, in general matching a given structure with the goal analysis of axioms in the theory, in general matching a given structure with an axiom ILF provides the user with such basic tactics. The language PROLOG is used to recombine existing tactics to new ones. PROLOG oers sucient complex control structures and is suitable for matching tasks in an outstanding way. It supports backtracking in case of failed attemps and storage of intermediate results for further use. 11

12 7 Conclusions / experiences We have formally veried ABP using the proof system ILF starting from a specication in Z. For this purpose some domain specic tactics were developed. These tactics only assume some structure about the general specication part (denition of regular runs) and can be reused for similar problems, too. ILF tactics have to simplify a problem, not to solve it. That's the serious advantage compared with pure interactive provers. ILF benets from powerful automatical provers during it's work. For practical reasons it's very important that a prover can handle redundant theories. In most cases the user is not able to specify exactly the theory which is needed to prove a specic subgoal. The ability to prove really dicult problems and nd long proofs is less important. Often the user knows the key ideas of a proof and can help ILF (and ATP's) by giving additional lemmas. The use of ILF is very helpful for problems which can be divided automatically into many subgoals by a tactic. If it is not possible to benet from such a comfortable proof structure the user has to use the interactive ILF facilities. But he does not need to prove the whole problem in an interactive way and can also use ATP's for generated subgoals. Compared with other systems, e.g. [6], [8] the use of ATP's reduces the amount of user input considerably. For the verication of the safety and liveness properties of the ABP only 1 respectivly 5 ILF tactics were used. Nevertheless, a fully detailed verication can be obtained by combining the proofs generated by the ATP's with the partial proof edited by the user. In the future we intend to verify other protocols, especially the Sliding-Windows- Protocol. Another aim is to prove correctness properties for other distributed systems. References [1] J. Avenhaus, J. Denzinger, and M. Fuchs. Discount: A system for distributed equational deduction. In Proceedings 6. RTA, Lecture Notes in Computer Science, pages 397{402. Springer Verlag, [2] K. A. Bartlett, R. A. Scantlebury, and P. T. Wilkinson. A note on reliable full-duplex transmission over half-duplex links. Communication of the ACM, 12(5):260{261,265, [3] J. Bowen and M. J. C. Gordon. Z and hol. [4] B. I. Dahn, J. Gehne, T. Honigmann, and A. Wolf. Integration of automated and interactive theorem proving in ILF. In Proceedings CADE-14. Springer, [5] B. I. Dahn and A. Wolf. Natural language presentation and combination of automatically generated proofs. In F. Baader and K. Schulz, editors, Frontiers of Combining Systems, pages 175{192. Kluwer, [6] M. J. C. Gordon and T. F. Melham, editors. Introduction to HOL A theorem proving environment for higher order logic. Cambridge University Press,

13 [7] R. Letz, J. Schumann, S. Bayerl, and W. Bibel. Setheo: A high-performance theorem prover. Journal of Automated Reasoning, 8:183{212, [8] L. C. Paulson. Isabelle - A Generic Theorem Prover. LNCS 828. Springer,

Diagram-based Formalisms for the Verication of. Reactive Systems. Anca Browne, Luca de Alfaro, Zohar Manna, Henny B. Sipma and Tomas E.

In CADE-1 Workshop on Visual Reasoning, New Brunswick, NJ, July 1996. Diagram-based Formalisms for the Verication of Reactive Systems Anca Browne, Luca de Alfaro, Zohar Manna, Henny B. Sipma and Tomas