• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
LADC 2009 - Student Forum
 

LADC 2009 - Student Forum

on

  • 322 views

Providing security and a consistent failure detection semantic for asynchronous distributed objects

Providing security and a consistent failure detection semantic for asynchronous distributed objects

Statistics

Views

Total Views
322
Views on SlideShare
322
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    LADC 2009 - Student Forum LADC 2009 - Student Forum Presentation Transcript

    • LADC 2009 - Student Forum
      Providing security and a consistent failure detection semantic for asynchronous distributed objects
      Rodrigo Vilar Miranda
      Laboratório de SistemasDistribuídos
      Universidade Federal de Campina Grande
    • Introduction
      • Distributed systems complexity
      • Middleware
      • Security
      • Failure detection
      • The programmer can focus on system logic
      • Use of object oriented languages
    • Introduction
      • Distributed objects model
      • Synchronous
      • Blocked thread
      • CORBA, Java RMI, .NET Remoting
      • Asynchronous model
      • Messages and queues
      • Low level primitives
      • XMPP
    • Introduction
      • Hybrid approach
      • JIC - Java Internet Communication
      • Asynchronous distributed objects
      • Object Oriented API
      • Remote methods without return type and exceptions
      • Internet friendly
      • Simple failure detector
      • It was use in OurGrid 4 alpha
      • Gaps
      • Does not threat security issues
      • The FD can not detect message loss
    • Commune
      • A JIC evolution
      • Flexible security portfolio
      • Connection protocol
      • Enables the FD to detect message loss
      • Some API enhancements
    • Security
      Many security mechanisms for systems over Internet
      Authentication
      Authorization
      Encryption
      Certification, etc.
      Security versus Deployment simplicity
    • Security
      Commune provides a flexible security portfolio
      Asymmetric cryptographic keys
      Sign every message sent through Commune
      Ensure the public key belongs to the message sender
      X.509 certificates
      Certification authorities
      Guarantee the sender identity
    • Security
      Flexibility
      By default, a Commune node automatically generates its own asymmetric key pair and a self-signed certificate
      The default data can be replaced by real data
      According to application security requirements
      OurGrid 4 uses Commune security portfolio
      Asymmetric cryptographic keys
      Validate communication sessions
      Implement a incentive mechanism
      Certification
      Optional use to manage peers relationships
    • JIC Connection Model
      A sender node (A) will send application messages to a receiver node (B)
      A registers interest on B
      The Failure Detector of A starts monitoring B
      Push model
    • JIC Connection Model
      The Failure Detector notifies A when:
      B becomes available (recovery)
      B becomes unavailable (failure)
      Control channels for Failure Detector messages
      Data channel for Application messages
      Can detect only crash failures
      No not detect message loss
    • Commune Connection Protocol
      Consistent failure detection semantic
      Can detect message loss
      Requirement 1
      There are two nodes, A that is interest in B, so:
      If A and B are available,
      eventually a connection from A to B will be established,
      and will continue established while
      A and B were available and
      no messages were lost in the communication layer
    • Commune Connection Protocol
      After the establishment of a connection between A and B, so:
      Requirement 2
      If B fails, eventually A will be notified
      Requirement 3
      If a message was lost,
      3.1 eventually A will be notified of B failure and,
      3.2 if there is also a connection from B to A,
      eventually B will be notified of A failure
    • Commune Connection Protocol
      Connection session number
      Random generated during interest registration
      Sequence number
      Zero in the session creation
      Incremented when a application message is sent
      Requirements 1, 2 and 3.1
    • Commune Connection Protocol
      Reverse connections
      Duplicated and independent data structures
      Exception: Requirement 3.2
    • Connection Protocol Tests
      Spin
      Formal verification tool
      Promela modeling language
      2 Nodes with state machines
      4 Channels
    • Connection Protocol Tests
      Results:
      From the initial model, there are not deadlocks neither unreachable states
      From any possible state, there are not deadlocks neither unreachable states
      It is possible to reestablish the connection
      We performed 456976 verifications using Spin
      13 possible states in A / 13 possible states in B
      13 possible kinds of messages in the outgoing channels
      4 possible kinds of messages in the incoming channels
    • Conclusion
      JIC security gaps were resolved
      Definition and tests of a consistent failure detection mechanism
      Connection Protocol implementation
      Future work
      Unit and system tests
      OurGrid 4.2 – with Connection Protocol
    • Questions?
      Rodrigo Vilar Miranda
      vilar@lsd.ufcg.edu.br