1 / 46

Lorenzo Tomasi Marco Casassa Mont

A Distributed Service, Adaptive to Trust Assessment, based on Peer-to-Peer E-Records Replication and Storage. Lorenzo Tomasi Marco Casassa Mont. Table of Contents. Trusted Services and PAST Service Objectives Research Problem Scenario and Use Cases Service Architecture Related work

pshinn
Download Presentation

Lorenzo Tomasi Marco Casassa Mont

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A DistributedService, Adaptive to Trust Assessment, based on Peer-to-Peer E-RecordsReplication and Storage Lorenzo Tomasi Marco Casassa Mont

  2. Table of Contents • Trusted Services and PAST Service • Objectives • Research Problem • Scenario and Use Cases • Service Architecture • Related work • Future steps • Conclusions

  3. Trusted E-Services

  4. A Service for long-term preservation of e-records • Long-term preservation of electronic documents involves • renewal of information • migration of data through technology • survivability • long-term access control • integrity • privacy • confidentiality • authenticity • ………………

  5. Persistent Active STorage Service

  6. PAST Architecture : Layers

  7. Objectives • Develop a service for long-term storage of e-records that can be used by PAST Service as a physical storage layer element • The service should be able to : • store,delete and retrieve a document • preserve a document for a long period • guarantee documents’ survivability, integrity and confidentiality

  8. Objectives Long-term storage of e-records in a medium-large enterprise

  9. Traditional solutions SAN for example … Focus on rapid and frequent access to data Dedicated, expensive solutions

  10. Cheap resources • Cheap and abundant resources within the enterprise : • are geographically distributed (survivability) • their storage capacity and CPU time are not fully in use

  11. Environment description • Environment is dynamic (in the long term period) • PCs change • users change • users’ profiles change • Environment is : • collaborative • unreliable / not trusted • not malicious

  12. Research area Using cheap and abundant resources within a medium-large enterprise is an opportunity and a challenge Opportunity : take advantage of cheap resources Challenge : cope with a dynamic and unreliable environment Objectives : long-term storage, survivability, integrity and confidentiality of e-records

  13. Research Variables none Trust full centralized Control centralized distributed Resources distributed

  14. Related Work Trust Control traditional FarSite Resources OceanStore Frangipani

  15. Related work • OceanStore • global scale • Farsite • long-term storage is not an issue • Frangipani • trusted environment • central administrator

  16. Our research area Resources ---------- distributed Trust : unreliable but not malicious environment

  17. Our research area • Control : • not centralized ( take advantage of distributed resources ) • not fully distributed ( likely anarchic, need for one trusted access point for PAST )

  18. Trusted Not trusted Our model enterprise

  19. Trusted Not trusted Scenario PAST Service PAST requests for storage, deletion and retrieval of e-records are accepted from the trusted, centralized controller

  20. Use cases • join and leave • PAST ( client ) initiative • peers’ initiative • Focus on mechanisms

  21. Use case : join

  22. Use case : store

  23. Use case : retrieve

  24. Use case : delete

  25. Use case : p2p

  26. Basic mechanisms • Communication ( identity ) • Delegation • Integrity management ( signature ) • Confidentiality ( encryption ) • Survivability (documents’ replication )

  27. Is this sufficient ? • Is replication sufficient for the goal of long-term storage ? • Reliability ??? Peers are not reliable !!! • That means peers may : • not be available • lose data (or data may get corrupted) • not be able to complete tasks

  28. Monitoring • Motivation : peers’ unreliability • Objectives : • deal with this unreliability • observe peers’ behaviour • control copies’ status (survivability) • gather information that can trigger actions

  29. Use case : monitoring

  30. Use case : delegation of monitoring tasks

  31. If we could learn … • If we could learn about peers’ behaviour and reliability : • we could have better management of storage and delegation • the whole system could be more efficient

  32. What kind of information we collect ? Information needed can be collected through monitoring activities and other ordinary interactions with peers, and it can be about : • peers’ availability • copies’ correctness • peers’ ability to complete tasks with success • peers’ communication times

  33. What do we learn ? • For example : • about peers’ availability and uptime • which peers are more reliable for completing tasks • which peers are more reliable for long-term storage • …

  34. Rating system • It’s desirable that the controller can use a rating (sub)system that gives information about peers’ behaviour and reliability in order to do better choices • This (sub)system should use a “Trust and Reliability Function” that implements some kind of Trust Metrics

  35. An Adaptive system • With a rating system, the controller can “follow” the environment’s changes, adopting : • dynamic criteria (for example, “delegation of tasks to reliable peers” is dynamic because it means delegating or revoking tasks, according to changes in peers’ reliability) • multiple policies (by knowing peers’ behaviour and according to how much dynamic the environment is, the controller can change its policies)

  36. Architecture principles • Peers should be a cut-down version of the centralized controller • Architecture should be modular

  37. High level architecture

  38. High level architecture • Information base : basic information module and rating information module • Monitoring module • Rating module • Engines for testing, storage, deletion, and retrieval • Registration module • keys and identities manager • Communication manager

  39. Architecture “Intelligent” components Engines (store, delete, retrieve, etc …) Communication Manager

  40. Information base Architecture Policy-based and “planning” components May influence May update Engines Interaction with peers (via communication manager) Monitoring

  41. Monitoring module architecture List of tasks Tasks manager From/to engines requests Generator Delegation manager From/to information base Scheduler

  42. Rating module architecture Rating information db Trust function Information on peers’ behaviour queries “events” generator notifications

  43. Security solutions • Identity certificates (central controller acts as a CA, but there is not a fully deployed PKI) • Secure communications (SSL like) • Delegation based on a SPKI model

  44. Work done • System architecture design • Mid-term HP Labs report, accepted by VIII IEEE Workshop FTDCS ’01 • Skeleton prototype implemented

  45. Trusted Not trusted Trusted Trusted Not trusted Not trusted Future work : inter-enterprise

  46. Conclusions • Trust and Trust Assessment are an important issue for P2P applications, and in general for new trust services • Our approach : • guarantees long-term survivability, confidentiality and integrity of e-records • is modular • is adaptive to trust and reliability assessment

More Related