1.
LADC 2009 - Student Forum<br />Providing security and a consistent failure detection semantic for asynchronous distributed objects<br />Rodrigo Vilar Miranda<br />Laboratório de SistemasDistribuídos<br />Universidade Federal de Campina Grande<br />

2.
Introduction<br /><ul><li>Distributed systems complexity

3.
Middleware

4.
Security

5.
Failure detection

6.
The programmer can focus on system logic

7.
Use of object oriented languages</li></li></ul><li>Introduction<br /><ul><li>Distributed objects model

8.
Synchronous

9.
Blocked thread

10.
CORBA, Java RMI, .NET Remoting

11.
Asynchronous model

12.
Messages and queues

13.
Low level primitives

14.
XMPP</li></li></ul><li>Introduction<br /><ul><li>Hybrid approach

15.
JIC - Java Internet Communication

16.
Asynchronous distributed objects

17.
Object Oriented API

18.
Remote methods without return type and exceptions

19.
Internet friendly

20.
Simple failure detector

21.
It was use in OurGrid 4 alpha

22.
Gaps

23.
Does not threat security issues

24.
The FD can not detect message loss</li></li></ul><li>Commune<br /><ul><li>A JIC evolution

25.
Flexible security portfolio

26.
Connection protocol

27.
Enables the FD to detect message loss

28.
Some API enhancements</li></li></ul><li>Security<br />Many security mechanisms for systems over Internet<br />Authentication<br />Authorization<br />Encryption<br />Certification, etc.<br />Security versus Deployment simplicity <br />

29.
Security<br />Commune provides a flexible security portfolio<br />Asymmetric cryptographic keys <br />Sign every message sent through Commune<br />Ensure the public key belongs to the message sender<br />X.509 certificates<br />Certification authorities <br />Guarantee the sender identity<br />

30.
Security<br />Flexibility<br />By default, a Commune node automatically generates its own asymmetric key pair and a self-signed certificate<br />The default data can be replaced by real data<br />According to application security requirements <br />OurGrid 4 uses Commune security portfolio<br />Asymmetric cryptographic keys <br />Validate communication sessions<br />Implement a incentive mechanism<br />Certification <br />Optional use to manage peers relationships<br />

31.
JIC Connection Model<br />A sender node (A) will send application messages to a receiver node (B)<br />A registers interest on B<br />The Failure Detector of A starts monitoring B<br />Push model<br />

32.
JIC Connection Model<br />The Failure Detector notifies A when:<br />B becomes available (recovery)<br />B becomes unavailable (failure)<br />Control channels for Failure Detector messages<br />Data channel for Application messages<br />Can detect only crash failures<br />No not detect message loss<br />

33.
Commune Connection Protocol<br />Consistent failure detection semantic<br />Can detect message loss<br />Requirement 1<br />There are two nodes, A that is interest in B, so: <br />If A and B are available, <br />eventually a connection from A to B will be established, <br />and will continue established while <br />A and B were available and <br />no messages were lost in the communication layer<br />

34.
Commune Connection Protocol<br />After the establishment of a connection between A and B, so:<br />Requirement 2<br />If B fails, eventually A will be notified<br />Requirement 3<br />If a message was lost, <br />3.1 eventually A will be notified of B failure and, <br />3.2 if there is also a connection from B to A, <br />eventually B will be notified of A failure<br />

35.
Commune Connection Protocol<br />Connection session number<br />Random generated during interest registration<br />Sequence number<br />Zero in the session creation<br />Incremented when a application message is sent<br />Requirements 1, 2 and 3.1<br />

36.
Commune Connection Protocol<br />Reverse connections<br />Duplicated and independent data structures<br />Exception: Requirement 3.2<br />

37.
Connection Protocol Tests<br />Spin <br />Formal verification tool<br />Promela modeling language<br />2 Nodes with state machines<br />4 Channels<br />

38.
Connection Protocol Tests<br />Results:<br />From the initial model, there are not deadlocks neither unreachable states<br />From any possible state, there are not deadlocks neither unreachable states<br />It is possible to reestablish the connection<br />We performed 456976 verifications using Spin<br />13 possible states in A / 13 possible states in B<br />13 possible kinds of messages in the outgoing channels<br />4 possible kinds of messages in the incoming channels<br />

39.
Conclusion<br />JIC security gaps were resolved<br />Definition and tests of a consistent failure detection mechanism<br />Connection Protocol implementation<br />Future work<br />Unit and system tests<br />OurGrid 4.2 – with Connection Protocol<br />

40.
Questions?<br />Rodrigo Vilar Miranda<br />vilar@lsd.ufcg.edu.br<br />