Verification of the Session Management Protocol A Formal Methods Case Study Karl Palmskog School of Computer Science and Communication Royal Institute of Technology 2006-11-02 Karl Palmskog Verification of the Session Management Protocol
Goals ◮ Examplify formal methods for verification of software ◮ Report on the verification of the Session Management Protocol ◮ Highlight the view of concurrency as interaction Karl Palmskog Verification of the Session Management Protocol
Formal Methods: An Example The mutual exclusion problem for the concurrent processes P 0 and P 1 using shared memory: ◮ Each process wants to access a shared resource, but both processes must not get access simultaneously ◮ A process using the resource is in its “critical section” Karl Palmskog Verification of the Session Management Protocol
Formal Methods: An Example Peterson’s algorithm for mutual exclusion bool b 0 := false ; bool b 1 := false ; int k := 0; P 0 : P 1 : while true do while true do � noncritical section � ; � noncritical section � ; b 0 := true ; b 1 := true ; k := 1; k := 0; await ( ¬ b 1 ∨ k = 1); await ( ¬ b 0 ∨ k = 0); � critical section � ; � critical section � ; b 0 := false ; b 1 := false ; end while end while Karl Palmskog Verification of the Session Management Protocol
Formal Methods: An Example How can we convince ourselves that this algorithm works? ◮ By inspection? ◮ By implementing and testing it? ◮ By proving it correct? Karl Palmskog Verification of the Session Management Protocol
Formal Methods: An Example General formal methods methodology 1. Understand the program 2. Model the program in a suitable formalism 3. Specify the correctness of the program 4. Prove that the model satisfies the specification Karl Palmskog Verification of the Session Management Protocol
Formal Methods: An Example Peterson’s algorithm as a communication protocol ◮ P 0 and P 1 exchange messages with a memory process P m ◮ Variable names are message types ◮ Values are message content ◮ Writing a variable means sending a message to P m ◮ Reading a variable means receiving a message from P m Karl Palmskog Verification of the Session Management Protocol
Formal Methods: An Example Promela model mtype = { b0,b1,k } ; bool proc0InCrit = false ; bool proc1InCrit = false ; chan mem0 = [0] of { mtype , bit } ; chan mem1 = [0] of { mtype , bit } ; run Memory(mem0, mem1, false , false , 0); run Process0(mem0); run Process1(mem1); Karl Palmskog Verification of the Session Management Protocol
Formal Methods: An Example proctype Process0( chan mem) { proctype Process1( chan mem) { BEGIN: BEGIN: mem!b0, true ; mem!k,1; mem!b1, true ; mem!k,0; do do :: mem?b1, false ; break ; :: mem?b0, false ; break ; :: mem?b1, true ; :: mem?b0, true ; :: mem?k,0; break ; :: mem?k,0; :: mem?k,1; :: mem?k,1; break ; od ; od ; proc0InCrit = true ; proc1InCrit = true ; proc0InCrit = false ; proc1InCrit = false ; mem!b0, false ; mem!b1, false ; goto BEGIN; goto BEGIN; } } Karl Palmskog Verification of the Session Management Protocol
Formal Methods: An Example Correctness of Peterson’s algorithm “For all executions, there are no states where both proc0InCrit and proc1InCrit have assumed the value true .” In Linear Temporal Logic: � ( ¬ ( p0c ∧ p1c )) where #define p0c proc0InCrit == true #define p1c proc1InCrit == true Karl Palmskog Verification of the Session Management Protocol
Session Layer Resurgence Problem situation ◮ Demand for new network services ◮ Aging Internet architecture ◮ Need to handle mobility and nomadicity ◮ Lots of extensions of TCP/IP: MIP, HIP, IPSec, . . . Proposed solution ◮ Adopt a more flexible view of the protocol stack ◮ Introduce new functionality at the session layer ◮ Use event-driven reconfiguration and state management Karl Palmskog Verification of the Session Management Protocol
Session Layer Resurgence Karl Palmskog Verification of the Session Management Protocol
Session Layer Resurgence Session layer components ◮ Event collector/dispatcher ◮ Preferences/rules database ◮ Socket rebind extension ◮ Session API ◮ TCP state controller ◮ Session Management Protocol (SMP) Karl Palmskog Verification of the Session Management Protocol
Session Layer Resurgence Session-enabled Session-enabled Legacy application application application Session Management API Session Management Protocol Event collector Rebind-enhanced socket API and dispatcher TCP state Preferences and controller rules database Rebind across Transport layer protocols the stack Network layer protocols Karl Palmskog Verification of the Session Management Protocol
Session Layer Resurgence Session Management Protocol ◮ Data integrity for sessions ◮ Keep track of communication state ◮ Send and and receive context updates Karl Palmskog Verification of the Session Management Protocol
Session Layer Resurgence SMP channels and message types ◮ Data channel ◮ data — application data ◮ checkpoint — communication state data ◮ Control channel ◮ resume — request session resumption ◮ resume ok — confirm session resumption ◮ resume denied — deny session resumption ◮ suspend — sender has suspended Karl Palmskog Verification of the Session Management Protocol
Session Layer Resurgence State machine T19 T1: Network lost T8 T2: User suspends; send suspend T3: Received resume; rebind SUSPENDED T4: Received suspend T5: User suspends T6: Received resume T2 T9 T7: Network changed T5 T4 T8: Received resume; send resume_denied ACTIVE T9: User resumes T7 T1 T10: Sent resume_ok; rollback T3 T11: Failed to send resume_ok T13 T11 READY_RESUME T12: Sent resume T12 T13: Failed to send resume T10 T6 T14: Received resume_ok T15: Received resume_denied T17 T16 T18 T15 T16: Network changed; rebind T17: Received resume; initiator SENT_RESUME T18: Received resume; not initiator T14 T19: Network lost; change interface Karl Palmskog Verification of the Session Management Protocol
Verification of SMP Starting point ◮ Verify the checkpoint mechanism ◮ Lets endpoints know where to resume ◮ Limited scope, well-defined protocol ◮ Important for the correctness of SMP Karl Palmskog Verification of the Session Management Protocol
Verification of SMP Prerequisites A , B : network endpoints S A , S B : sequences of words of data S i A : the i th word of a sequence ◮ Goal for A : transfer all words in S A to B , in order ◮ Goal for B : transfer all words in S B to A , in order Service provisions The purpose is to let A and B continually agree on at least one tuple � i , j � , such that: B , . . . , S j − 1 ◮ A has received S 0 B , S 1 properly B A , . . . , S i − 1 ◮ B has received S 0 A , S 1 properly A Karl Palmskog Verification of the Session Management Protocol
Verification of SMP Environmental assumptions ◮ Executed in the context of an established session ◮ Endpoints use buffered, reliable data channels ◮ Disconnection is not possible Procedure rules ◮ Same for both endpoints ◮ Maintain acknowledged and pending checkpoints/tuples ◮ After filling up the buffer, create a new checkpoint ◮ Send checkpoint message with checkpoint id and number of bytes sent/received ◮ Do not create checkpoints until a reply has been received ◮ Update checkpoint definition using reply data Karl Palmskog Verification of the Session Management Protocol
Verification of SMP Safety specification “The endpoints always have a checkpoint in common”: � (( ak → ( akSn ∧ akRc )) ∧ ( akPn → ( akPnSn ∧ akPnRc )) ∧ ( pnAk → ( pnAkSn ∧ pnAkRc )) ∧ (( ak ∧ ¬ akPn ∧ ¬ pnAk ) ∨ ( ¬ ak ∧ akPn ∧ ¬ pnAk ) ∨ ( ¬ ak ∧ ¬ akPn ∧ pnAk ))) Liveness specification “Endpoints always eventually reach a state from which they can receive and send data”: ( � ♦ inAct ) ∧ ( � ♦ ninAct ) Karl Palmskog Verification of the Session Management Protocol
Verification of SMP Promela model mtype = { data,cp } ; typedef dataMsg { mtype type; byte cpId; byte cpSent; byte cpRecd; } chan point1Recv = [queueSize] of { dataMsg } ; chan point2Recv = [queueSize] of { dataMsg } ; run Endpoint(point1Recv, point2Recv, 0); run Endpoint(point2Recv, point1Recv, 1); Karl Palmskog Verification of the Session Management Protocol
Verification of SMP Correcting the protocol ◮ Only the connection initiator can send checkpoint requests ◮ Needs to know session data buffer size of peer ◮ Only one stream position field in checkpoint message Verification results ◮ Exhaustive verification with partial-order reduction ◮ No counterexamples found ◮ Without compression, would use 10-20 GB of memory Karl Palmskog Verification of the Session Management Protocol
Verification of SMP State machine correctness ◮ Safety: if a session is resumed, it is resumed properly ◮ Liveness: there are no deadlocks State machine model ◮ Add control channels and states to checkpoint protocol model ◮ Use Promela ’s channel over channel feature for mobility ◮ Protocol changes during rollback due to checkpoint error Verification results ◮ Exhaustively verified for some parameters ◮ Many partial state-space searches Karl Palmskog Verification of the Session Management Protocol
Recommend
More recommend
