A Mechanically Proved and an Incremental Development of the Session Initiation Protocol

The Session Initiation Protocol (SIP) is an application layer signaling protocol used to create, manage, and terminate sessions in an IP based network. SIP is considered as a transactional protocol. There are two main SIP transactions, the INVITE transaction and the non-INVITE transaction. The SIP INVITE transaction specification is described in an informal way in Request for Comments (RFC) 3261 and modified in RFC 6026. In this paper we focus on the INVITE transaction of SIP, over reliable and unreliable transport mediums, which is used to initiate a session. In order to ensure the correctness of SIP, the INVITE transaction is modeled and verified using event-B method and its Rodin platform. The Event-B refinement concept allows an incremental development by defining the studied system at different levels of abstraction, and Rodin discharges almost all proof obligations at each level. This interaction between modeling and proving reduces the complexity and helps in assuring that the INVITE transaction SIP specification is correct, unambiguous, and easy to understand.


Introduction
Session Initiation Protocol is a network communications protocol commonly employed for Voice over IP (VoIP) signaling.It is based on request/response transaction model.Each transaction consists of a client request that invokes a particular method on the server and at least one response.The two main SIP transactions are the INVITE transaction for setting up a session, and the non-INVITE transaction for maintaining and closing down a session.Their specifications are defined in Request for Comments (RFC) 3261 [1] and they have been modified in RFC 6026 [2].
A large number of the practical protocols have only informal specifications.Several formal methods have been applied to analyze these protocols, such as model checking [3] and theorem proving [4].However, only a few papers on analyzing SIP using Colored Petri Nets (CPNs) have been published [5][6][7][8].CPNs are based on model checking which verifies the implementation of the system.
Recently a new method Event-B [9] has been developed by Abrial who has developed the B method [10] and the Z language [11].In this paper, we use Event-B to model and prove the SIP INVITE transaction over reliable and unreliable transport medium.The most important benefit of using Event-B is its capability to use abstraction and refinement [12].Indeed, in this approach the modeling process starts with an abstraction of the system which specifies the goals of the system.The abstract level of our Event-B model shows these goals in a very general way, and then during refinement levels features of the protocol are modeled and the goals are achieved in a detailed way.Moreover the Rodin tool [13] permits an automated proof of the different models of the system.
In this paper, we use Event-B to model and prove the SNMP protocol.The most important benefit of using Event-B is its capability to use abstraction and refinement [7].
The remainder of the paper is organized as follows.Section 2 gives a brief overview of Event-B.Section 3 provides the requirements which are informally defined.A refinement strategy is proposed in Section 4. Finally, in Section 5, the formal development is presented.

Overview of Event-B
Before Event-B is a formal method for specifying, modeling, and reasoning about systems, especially complex systems 2 Journal of Computer Networks and Communications such as an electronic circuit, an airline seat booking system, a PC operating system, a network routing program, a nuclear plant control system, and a Smartcard electronic purse.Event-B has evolved from classical B.
Key features of Event-B are the use of set theory as a modeling notation, the use of refinement to represent systems at different abstraction levels and the use of mathematical proof to verify consistency between refinement levels.From a given model M1, a new model M2 can be built as a refinement of M1.In this case, model M1 is called an abstraction of M2, and model M2 is said to be a concrete version of M1.A concrete model is said to refine its abstraction.Each event of a concrete machine refines an abstract event or refines skip.An event that refines skip is referred to as a new event since it has no counterpart in the abstract model.An Event-B model has two parts, context and machine.Each context specifies the static properties of the system, including sets, axioms, and constants.Each machine specifies the dynamic part of the system, including variables, invariants, and events.Variables represent the current state of the system and invariants specify the global specification of the variables and system behaviors.
An event is defined by the syntax: EVENT e WHEN G THEN S END, where G is the guard, expressed as a firstorder logical formula in the state variables and S is any number of generalized substitutions, defined by the syntax  ::=  := (V) |  :=  :| ().The deterministic substitution,  := (V), assigns to variable  the value of expression (V), defined over set of state variables V.In a nondeterministic substitution,  :=  :| (), it is possible to choose nondeterministically local variables, , that will render the predicate () true.If this is the case, then the substitution,  := , can be applied, otherwise nothing happens.
The Rodin is the tool of the Event-B.It allows formal Event-B models to be created with an editor.It generates proof obligations that can be discharged either automatically or interactively.Rodin is modular software and many extensions are available.These include alternative editors, document generators, team support, and extensions (called plugins) some of which include support decomposition and records.

Informal Description of SIP INVITE Transaction
The INVITE client and server transactions are defined in RFC 3261 and its modifications are presented in RFC 6026 using two state machines.(ii) Initially, the INVITE server transaction enters the proceeding state when it is created.
(iii) The server transaction must generate a 100 (Trying) response unless it knows that the TU will generate a provisional or final response within 200 ms, in which case it may generate a 100 (Trying) response.
(iv) While in the proceeding state, if the TU passes a response with status code from 300 to 699 to the server transaction, the response must be passed to the transport layer for transmission, and the state machine must enter the completed state.
(v) When the TU on the server side forwards a final success response (2xx) to the server transaction, the transaction delivers this response to the transport layer for transmission and enters the accepted state.Retransmissions of the 2xx response are handled by TU, not by the server transaction.
(vi) The purpose of the accepted state, which presents the modification of INVITE server transaction according to RFC 6026, is to absorb retransmissions of an accepted INVITE request.Any such retransmissions are absorbed entirely within the server transaction.
(vii) Timer L is started when the accepted state is entered.This timer reflects the wait time for retransmissions of 2xx responses.When timer L fires, transaction enters the terminated state.
(viii) For unreliable transports, the server transaction must start timer G to control the time for each retransmission.
(ix) If timer G fires, the response is passed to the transport layer once more for retransmission, and timer G is set to fire in min (2 * T1, T2) seconds.From then on, when timer G fires, the response is passed to the transport again for transmission, and timer G is reset with a value that doubles, unless that value exceeds T2, in which case it is reset with the value of T2. (

Refinement Strategy
The development is made of an initial model followed by some refinements.The initial model is high level abstraction showing that the transaction has a client side and a server side; the client and the server can both send and receive a message.
The first refinement: in this model we specify the requests and the responses sent by the client and the server, respectively; we introduce also their different states.
The second refinement contains the introduction of the timer constraints for reliable transport.
The third refinement contains the introduction of the timer constraints for unreliable transport.

Initial Model. In this initial model, we just formalize a communication between client and server by means of messages (Algorithm 1).
First, we define two carrier sets REQUESTS and RESPONSES: they describe, respectively, the set of messages which can be sent by the client and the set of messages which can be sent by the server (see Box 1).
Then the variables cl sent, sr got, sr sent, and cl got are introduced to define, respectively, the set of requests sent by the client, the requests received successfully by the server, the set of responses sent by the server, and successfully received responses by the client (see Box 2).
We now define the invariants.In invariants (inv1 and inv2), the set cl sent and sr got are simply typed as subset of REQUESTS.As expected in invariants (inv3 and inv4), the set sr sent and cl got are defined as a subset of RESPONSES.The invariant (inv5) denotes that if any message is not in the set cl sent, it must not be in the set sr got.The same for (inv6) (see Box 3).
Finally, we define four events in our abstract model.An event client send represents the sending request from the client to the server.An event server receive represents the request received successful by the server, guards of this event state that a message should be in the set cl sent.An event server send represents the response sent from the server to the client, the guard of this event state that the set sr got should not be empty.The last event client got represents the response received successful by the client.
Proofs.In this initial model, there are 6 invariant preservation proofs, with 2 of them proved interactively.

First Refinement.
In this first refinement, we introduce specific requests (INVITE, ACK) and responses (1xx, 2xx, 3xx-699).We introduce also the different states of the client and the server.First we define the context which contains the carrier set STATES.It represents the different states of client and server.We define also the constants in the context and their associated axioms by the agent (see Box 4).
In order to manipulate states we introduce two new variables (See Box 5): c st denotes the current state of client, s st denotes the current state of server.
We are now ready to define our events (Algorithm 2).(iii) Server send 1xx refining the abstract event server send: after receiving the request INVITE, the server sends a provisional response (1xx) to a client and it remains in proceeding state (iv) Client receive 1xx refining the abstract event client receive: the client receives the response 1xx and the state proceeding must be entered.
(v) Server send 2xx refining the abstract event server send: while the server is in proceeding it can send the final success response to a client and it enters in accepted state.(vii) Server send 3xx-699 refining the abstract event server receive: when the server sends the final nonsuccess response, it enters in completed state.
(viii) Client receive 3xx-699 refining the abstract event server receive: while the client is in calling or proceeding state and it receives the nonsuccess response 3xx-6xx, the state completed must be entered.
(ix) Client send ACK refining the abstract event client send: the client sends an acknowledgment (ACK) to the server after receiving the nonsuccess response.
(x) Server receive ACK refining the abstract event server receive: the server receives the ACK and it enters in confirmed state.
(xi) We add two new events client final state and server final state as anticipated events.
Proofs.The proof obligation generator of the Rodin Platform produces 49 proof obligations, with 7 of them proved interactively.

Second Refinement.
In this refinement, we introduce the time constraints for reliable transport.We add six timers B, H, D, I, L, and M: timer B controls transaction timeouts, timer H determines when the server transaction abandons retransmitting the response, timer D reflects the amount of time that the server transaction can remain in the "completed" state, timer I determines the server state from confirmed to terminated, timer M reflects the amount of time that the TU will wait for retransmissions of the 2xx responses, and timer L reflects the wait time for retransmissions of 2xx responses.For modeling these timers, we define six variables that represent each of them, and others six Boolean variables for whether the timer is held or not (see Box 6).
Concerning events, we add six new events Expire B, Expire D, Expire H, Expire I, Expire M, and Expire L; they represent when each timer will expire.We add also six time progression events: Tick Tock B, Tick Tock D, Tick Tock H, Tick Tock I, Tick Tock L, and Tick Tock M (Algorithm 3).
When the client transaction sends an invite, the client transaction must start timer B (we refine the abstract event client send INVITE by adding the action temp B := TRUE).If the client transaction is still in the calling state when timer B fires, the client transaction should pass to the final state terminated.If the client transaction receives a provisional response while in the calling state, it transitions to the proceeding state; then the timer B must turn off (we refine the abstract event client receive 1xx by adding the action temp B := FALSE).The client transaction should start timer D when it enters the completed state, so we add temp D := TRUE as action in the event client receive 3xx-699.If timer D fires while the client transaction is in the completed state, the client transaction must move to the terminated state.
When the completed state is entered, timer H must be set to fire (we refine the abstract event server send 3xx 699 by  adding the action temp H := TRUE).If timer H fires while in the completed state, it implies that the ACK was never received.In this case, the server transaction must transition to the terminated state and must indicate to the TU that a transaction failure has occurred.
When confirmed state is entered, timer I is set to fire in zero seconds for reliable transports.We add temp (I := TRUE) as action in the refined event server receive ACK. Once timer I fires, the server MUST transition to the terminated state.Timer L is started when the accepted state is entered.When timer L fires, transaction enters the terminated state.
When accepted state is entered, timer M must be started.When timer M fires, transaction enters the terminated state.
Proofs.There are 10 invariant preservation proofs.They are all straightforward and easily proved automatically by the Rodin platform prover.

Third Refinement.
In this last refinement, we introduce the time constraints for unreliable transport.New variables are declared, "A" as the timer that controls request retransmissions, "G" controls the time for each retransmission, and two Boolean variables temp A and temp G for whether the timer is held or not.We add also two new events.

Resend INVITE.
When timer A fires, the client transaction must retransmit the request INVITE and must reset the timer with a value of 2 * T1.When timer A fires 2 * T1 seconds later, the request must be retransmitted again.
Resend 3xx-699.If timer G fires, the response 3xx-699 is passed to the transport layer once more for retransmission, and timer G is set to fire in min (2 * T1, T2) seconds.From then on, when timer G fires, the response is passed to the transport again for transmission, and timer G is reset with a value that doubles, unless that value exceeds T2, in which case it is reset with the value of T2 (Algorithm 4).We refine the events expire I, expire M, expire L, and expire D by adding, respectively, the actions d = 32, I = 10 * cst, M = 64 * cst, and L = 64 * cst, where cst = 500 ms.
Proofs.This refinement requires 14 proofs, all proved automatically except one.

Proof Statistics. Table 1 describes the proof statistics of the formal development of SIP INVITE transaction in the
Rodin tool.These statistics measure the size of the model, the proof obligations generated and discharged by the Rodin platform, and those that are interactively proved.

Conclusion
In this paper, we have modeled and proved SIP INVITE transaction over reliable and unreliable transport medium using Event-B We have explained our approach using refinement, which allows us to achieve a very high degree of automatic proof.The powerful support is provided by the Rodin tool.Rodin proof is used to generate the proof obligations and to discharge those obligations automatically and interactively.Modeling and analyzing SIP specification using formal methods can help in assuring correctness, unambiguity, and clarity of the SIP protocol.Since a well-defined and verified protocol specification can reduce the cost for its implementation and maintenance, modeling and analysis are important steps of the protocol development life-cycle from the point view of protocol engineering.
In the future work, we would model and prove the non-INVITE transaction over reliable and unreliable mediums.

( i )
Client send INVITE refining the abstract event client send: the client sends an INVITE and the state calling must be entered.(ii) Server receive INVITE refining the abstract event Server receive: the server receives the INVITE and it enters in proceeding state.