Communication assurance with Session Types Rumyana Neykova - PowerPoint PPT Presentation

Communication assurance with Session Types Rumyana Neykova

Communication Safety with Session Types  Promises:  Organising structured communications from a global point of view  Efficient type-checking strategy of processes through projection of global types onto participants

The shortcoming When the endpoints are not typed… the communication assurance is lost 

Runtime Verification to the rescue Transport Monitor Monitor Monitor P Bob P Alice P Carol Attach monitor to each untyped participant. Monitors check that every incoming and outgoing message is correct wrt the protocol specifications.

Content  Session Types Overview  Runtime Verification Overview  Monitoring Demo  Future Directions

Session Types in a Nutshell “… Session Types structure a series of interactions in a simple and concise syntax and ensure type safe communication .”

Session Types Guarantees Communication Safety • No communication mismatch Session Fidelity • Communication follow the described protocol Progress • No deadlock/ stuck in a session

Example Alice Carol Seller Bob  How it works?  Step 1: Write Global Type quote quote  Step 2: Write Local Programs  Step 3: Project and Type Check Locally Delegate T ok ok Address Date

Step 1: Write Global Types

Step 2: Projections

Typing System Typing judgement are of the shape:

Evolution  Binary Session Types [THK98, HVK98]  Myltiparty Session Types [POPL’08]  Progress in Interleaved Multiparty Sessions [Concur’08]  Session Types with Assertions [Concur’11]  Dynamic Multirole session types [POPL’11]

Limitations … Proving communication assurance in the presence of untyped endpoints is a problem for the existing theory since it relies on typing. An alternative mechanisms for validations is needed !!!

Runtime Verification “…Formal method that is used for monitoring of a program being executed by verifying the generated events against a set of properties”

The process  Properties are written in some formal logic - specification language  The properties are transformed into runtime monitor which is instrumented with the system to be monitored  A runtime monitor observes the system while it is running  The monitor triggers an appropriate response if a system property is violated.

Components 1. System to be monitored 2. Set of specifications written in some formal notation 3. Stream of events extracted from the system ( trace ) 4. Monitor ing system which receives the events and verifies

Specification Language “Specification language should be properly chosen to meet the properties that need to be enforced.”  What kind of properties to specify?  Temporal properties  Consequential: authentication happens before data access  real-time: transaction takes no more than 30 sec to execute  Contextual properties: possibility to monitoring objects either globally or locally  Exceptions related: monitoring all exceptional cases in the execution of the program

Various Options for specification Language “Defining a specification language is a problem of choosing the optimal balance between simplicity, efficiency and effectiveness”  The language can be based on:  Algebra  Logic  Regular expressions  Automata  It can be fully featured language  Functional  Imperative  Object-oriented  Extension of an existing language

Monitor “A monitor is a system that observes the behaviour of a system and determines if it is consistent with a given specification”

Example of RV tools Enforce Real-time properties JRMTC Larva Fully functional Design By Contract ASML JASS specification Approach language Self-checking Obser distributed system ver

OOI(Ocean Observation Initiative) Aim: to deploy an infrastructure to expand the scientists’ ability to remotely study the ocean  Builds on large scale infrastructure  Distributed components are managed under diverse administrative domains  Active entities participants and organizations are called agents, agents must conform to norms Need for global safety ensurance by local validation with possibly unsafe endpoints

OOI Use Case : Instrument Command

Use Case

Distributed Monitor (External) monitors : drop violating incoming and ongoing messages  Check:  session initialisation  messages within sessions

Properties  Local/global conformance: a monitored process well- behaves and coherence is preserved in a network  Local/global transparency: monitors do not alter well-behaved interactions  Session fidelity: the interactions of a network are step-by-step conform to the corresponding global types

Demo Time Demo

Demo Notes  Untrusted code runs on end-point machines.  They communicate through a common transport (AMQP).  Monitors check that every incoming and outgoing message is correct wrt the protocol specifications

Future Directions  Runtime enforcements  Exception Handling  Real-Time Properties  Contextual Properties

Q & A

Appendix  OOI  AMQP  Monitor  Properties