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

PAlice PCarol PBob

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 follow the described protocol
• No communication mismatch

Communication Safety Session Fidelity

• No deadlock/ stuck in a session

Progress

Example

 How it works?

 Step 1: Write Global Type  Step 2: Write Local Programs  Step 3: Project and Type Check

Locally

Alice Seller Bob Carol quote Address Date quote

• k
• k

Delegate T

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 …

An alternative mechanisms for validations is needed !!!

Proving communication assurance in the presence

• f untyped endpoints is a problem for the existing

theory since it relies on typing.

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. Monitoring system which receives the events and verifies

Specification Language

 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 “Specification language should be properly chosen to meet the properties that need to be enforced.”

Various Options for specification Language

“Defining a specification language is a problem of choosing the

• ptimal balance between simplicity, efficiency and effectiveness”

 The language can be based on:

 Algebra  Automata  Logic  Regular expressions

 It can be fully featured language

 Functional  Object-oriented  Imperative  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

Larva JRMTC ASML JASS Obser ver

Enforce Real-time properties Fully functional specification language Design By Contract Approach Self-checking distributed system

OOI(Ocean Observation Initiative)

Aim: to deploy an infrastructure to expand the scientists’ ability to remotely study the ocean Need for global safety ensurance by local validation with possibly unsafe endpoints

 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

OOI Use Case : Instrument Command

Use Case

Distributed Monitor

 Check:

 session initialisation  messages within sessions

(External) monitors : drop violating incoming and ongoing messages

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