Monitoring Networks through Multiparty Session Types

Transcription

1 Monitoring Networks through Multiparty Session Types Laura Bocchi 1, Tzu-Chun Chen 2, Romain Demangeon 1, Kohei Honda 2, Nobuko Yoshida 1 2 Queen Mary, University of London, 1 Imperial College, London FORTE/FMOODS 2013, Firenze, 03/06/2013

2 Background Distributed programming Message-passing concurrency. asynchronous networks. examples: services, web applications,... Distant interactions. Interoperability. Distributed verification Desirable properties: fidelity, lock-freedom, governance, security,... Control is local 1 only. Typechecking impossible 2. Communicating programs different languages, compilers, libraries. different hardware. different locations. Solution: 2 Monitoring through 1 Multiparty Session-Types

3 Our collaboration: OOI international oceanography project. vast, connected array of sensors, buoys, intruments. using message-passing communications. applications written in different languages, running on heterogenous hardware in an asynchronous network. web-based user interface for oceanographs. requires correct, safe interactions. perfect framework for session type verification. integration into the CyberInfrastructure sub-project design and maintain Scribble, a protocol language strongly based on MPST.

4 Session types Verification theory originating in typed π-calculi. formal methods, type systems naturally generate typecheckers. Principles: design a specification for network interactions called session session as atomic protocols (global types). participants are abstracted in roles (Instrument, Buyer,... ). specifies only the message layer. project the session into local types local behaviors for each endpoint. ensure each endpoint conforms to its local type. Fidelity: Local conformance implies global correction w.r.t. the specification. Multisession model: one participant can be engaged in several sessions.

5 Session types (II) T A p G p T B p T C G : A B; B C; B A T A :!B.?A v v v P A P B P C P A : s[b]! 8.s[C]?(y)... p: projection from global types to local types. v: verification of processes against local types. type systems: ensure soundness and progress. type-checkers not adapted to heterogenous networks. suggests dynamic verification (monitors). (session type theory includes choices, recursion, predicates,... )

6 Monitors run in parallel (can be embedded or external). act as membranes between the trusted network and applications. ensure interoperability (no access to source code). unmonitored trusted components can be introduced.

7 Session types for monitoring Adapting MPST theory to monitoring. Allowing mixed networks. Principles: developers design protocols for the whole network in a dedicated language, well-formedness is checked, protocols are projected into local types, local types generate monitors, or are statically typechecked.

8 Our Contribution A theory for MPST-monitored networks: Formalise MPST-monitoring and asynchronous networks. Introduce monitors as first-class objects in the theory and make explicit routing information propagation. Compare different networks through equivalences. Justify monitoring by soundness theorems. safety: monitors enforces specification conformance. transparency: monitors does not affect correct behaviors. fidelity: correspondence to global types is maintained. Ensure that theory interacts with implementation.

9 Formalism: MPST syntax G ::= r 1 r 2 : {l i (x i :S i ){A i }.G i } i I G 1 G 2 G 1 ; G 2 µt.g t ɛ end T ::= r!{l i (x i :S i ){A i }.T i } i I r?{l i (x i :S i ){A i }.T i } i I T 1 T 2 T 1 ; T 2 µt.t t ɛ end G: global types: interaction from role r 1 to role r 2 (with choice), parallel and sequential composition, recursion and end. T : local types. A: predicates and expressions used to validate properties over messages inside types.

10 Formalism: Example G ATM = C A : { Login(x i : string){tt}. A S : { LoginOK(){tt}. A C : {LoginOK(){tt}. G Loop}, LoginFail(){tt}. A C : {LoginFail(){tt}. end}}} G Loop = µ LOOP. S C : { Account(x b : int){x b 0}. C S : { Withdraw(x p : int){x p > 0 x b x p 0}. LOOP, Deposit(x d : int){x d > 0}. LOOP, Quit(){tt}.end}} Protocol for interaction with ATM with three commands. Three roles are involved: Client, ATM and bank Server. Contains choices, nested loops and predicate checks.

11 Formalism: Example (projection) T C = A!{Login(x i : string){tt}. A?{LoginOK(){tt}. T Loop LoginFail(){tt}. end}} T Loop = µ LOOP. S?{Account(x b : int){x b 0}. S!{Withdraw(x p : int){x p > 0 x b x p 0}. LOOP, Deposit(x d : int){x d > 0}.LOOP, Quit(){tt}.end}} Projection of ATM example onto role Client. Session seen from the point of view of Client. Type used for monitoring (local enforcement).

12 Formalism: Networks P ::= a s[r] : T a(y[r]:t ).P k[r 1, r 2 ]!l e k[r 1, r 2 ]?{l i (x i ).P i } i I if e then P else Q P Q 0 µx.p X P; Q (νa) P (νs)p N ::= [P] α N 1 N 2 0 (νa)n (νs)n r ; h r ::= a α s[r] α h ::= m h m ::= a s[r] : T s r 1, r 2, l v π-based calculus. Asynchronous networks composed of: processes P located at principals α, abstracts local applications. router r, abstracts network routing information, updated on-the-fly. global queue h. abstracts messages in transit.

13 Formalism: Semantics [a s[r] : T ] α r ; h [0] α r ; h a s[r] : T [a(y[r] : T ).P] α r ; a s[r] : T h [P[s/y]] α r s[r] α ; h [s[r 1, r 2 ]!l j v ] α r ; h [0] α r ; h s r 1, r 2, l j v [s[r 1, r 2 ]?{l i (x i ).P i } i ] α r ; s r 1, r 2, l j v h [P j [v/x j ]] α r ; h : r(a) = α : r(s[r 2 ]) α : r(s[r 2 ]) = α (reductions can happen inside contexts) Two rules for session invitations. Two rules for session interactions. Asynchrony is handled through global queue. Routing information is used and updated at runtime.

14 Specifications Σ ::= Σ, α: Γ;, Γ ::= Γ, a :?(T [r]) Γ, a :!(T [r]) ::=, s[r]:t, Σ: spec., : session env, Γ: shared env. Specifications have a semantics (used for satisfaction). Monitored Networks Monitors M = α: Γ; are introduced as component of monitored networks. Reduction rules for monitored networks (send rules): M r(s[r 2 ]) α [s[r 1, r 2 ]!l v ] α M r ; h [0] α M r ; h s r 1, r 2, l v M s[r 1,r 2 ]!l v s[r 1,r 2 ]!l v M [s[r 1, r 2 ]!l v ] α M r ; h [0] α M r ; h

15 Equivalences To compare networks, we use: weak bisimulation over partial networks (i.e. without transport) reduction-closed barbed congruence = over networks. barbed congruence allows us to model interfaces: 2 structurally different networks implementing the same services are equated, structure is hidden through routing. Interface: example G 2 Loop = µ LOOP. S T : { Query(){true}. T S : { Answer(x t : int){true}. S C : { Account(x b : int){x b 0}. C S : { Withdraw(x p : int){x p 0 x b x p 0}. LOOP, Deposit(x d : int){x d > 0}. LOOP, Quit(){true}.end }}}} same protocol, except makes use of a transaction agent. P S: original server program, PS 2 : new server program, PT: agent program. ([P S] α ; s[s] α, s[c] β, s[a] γ ) = ([P 2 S ]α [PT] δ ; s[s] α, s[c] β, s[a] γ, s[t] δ )

16 Satisfaction The satisfaction relation = N : Σ relates networks and specification: if Σ expects an input, N should be able to process it. if N performs an output, Σ should be expecting it. still holds after reduction (coinductive definition). Tailored for monitoring. monitors do not enforce liveness. Satisfaction equivalence If N 1 = N2 and = N 1 : Σ then = N 2 : Σ.

17 Results (Safety) Local Safety = [P] α M : α : Γ; with M = α: Γ;. A monitored process satisfies its specification. Global Safety If N is fully monitored w.r.t. Σ, then = N : Σ. monitored networks behave as expected. does not ensure liveness.

18 Results (Transparency) Local Transparency If = [P] α : α : Γ;, then [P] α ([P] α M) with M = α : Γ;. unmonitored correct processes are undistinguishable from their monitored counterparts. allows one to mix monitored and typechecked processes. Global Transparency Assume N and N have the same global transport r ; h. Assume: 1. N is fully monitored w.r.t. Σ and 2. N = M r ; h is unmonitored but = M : Σ. We have N = N. monitors does not alterate behaviors of correct networks. monitor actions are not observable on correct components.

19 Results (Fidelity) a configuration is consistent: when it corresponds to a well-formed array of global types (G 1,..., G n ) through projection. conformance is satisfaction + receivability (queue can be emptied). Session Fidelity Assume: 1. configuration Σ; r ; h is consistent, 2. network N M r ; h conforms to configuration Σ; r ; h. For any l, whenever we have N l g N s.t. Σ; r ; h l g Σ ; r ; h, it holds that Σ ; r ; h is consistent and N conforms to Σ ; r ; h. consistence is preserved by reduction, at any time, the network correspond to a well-formed specification.

20 Conclusion A theory for monitoring through MPST inside asynchronous networks: models monitor behaviors, models dynamic routers, monitoring ensures correction, equate networks with the same interface. Implementation is done. Future works: Ongoing partnership with OOI. Express governance properties. Handle interruptions and exceptional behaviors.