P2P Apps (II)

1. P2P Apps (II) CS 598 IG 23rd February, 2006 Mehedi Bakht

2. END-TO-END ARGUMENTS IN SYSTEM DESIGN J. H. Saltzer, D.P. Reed and D. D. Clark M.I.T Laboratory for Computer Science Presented by Mehedi Bakht

3. About the paper • One of the most widely cited/read papers in systems • No number, graphcis,etc ! • The reasoning in this paper is behind many of the design decisions in today’s network

4. The Argument • Define when it is applicable: • “The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system…” • Regardless of what happens in the communication systems, correct operation can only be verified by endpoints.

5. The Argument • Define when it is applicable: • “The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system…” • Is it possible to completely ensure integrity due to probabilistic nature of integrity checks?

6. The Argument • Define the consequence: • “… Therefore, providing that questioned function as a feature of the communication system itself is not possible…” • If you can’t do it properly, don’t do it at all.

7. The Argument • Define the exception: • “… (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)” • Its not a hard and fast rule, there are special cases where the benefit outweighs the cost.

8. 2 4 3 1 5 Careful File Transfer • Copy/Move file from HD on Computer A to HD on Computer B

9. Careful File Transfer • Possible threats to an accurate transfer: • Disk error • Software error (OS, File transfer program, Network driver) • Hardware error • Communication system • System crash

10. Careful File Transfer • Solution 1: Point-to-Point • Reinforce each step of process (timeout, retry, etc.) • Goal: Reduce probability of each threat to an acceptably small value • Could be hard to do, each step must be full-proof • Could be inefficient, extra checking • Solution 2: End-to-End • Store file with a checksum, transfer file, read transferred file back from disk, compute checksum, send checksum to originator to compare the two checksums. • If check fails, redo from beginning

11. Careful File Transfer • Solution 3: Both • Point-to-Point checks in communication system (such as link level, IP, and/or TCP) • End-to-End checks must still be performed, since only one of the threats is handled • Does not reduce the overall burden to the application, but may reduce the frequency of problems • Lesson: • Application must supply the guarantee in the end

12. Performance Aspects • Performing the function at the lower level may cost more! • Job can’t be done as efficiently since information is more limited • May be more efficient if it can be performed with minimal perturbartion • Applications that don’t need the function have to pay for it

13. Performance Aspects • Performing the function at the lower level may cost more! • Applications that don’t need the function have to pay for it • But what if the total cost shared by all applications(when implemented in comm. System) is less than what incurred by individual applications at application layer?

14. Example: Delivery Guarantees • Acknowledgement of Delivery of a message • Knowing that a message got delivered is not important for an application • Knowing that the other host acted on the message is important • This can only be done by the application on the other host, not the comm system

15. Example: Secure Transmission of Data • Encryption in the network requires trust to manage encryption keys • Data is in the clear as it passes into the target node • Authenticity still has to be checked by application • On the other hand, Network encryption ensures that a node cannot deliberately transmit information that should not be exposed • So we need a combination of both?

16. Example: Duplicate Message Transmission • Some network designs allow(ed) a message to be delivered twice • The application might do that, too • Thus, suppression must be accomplished by the application anyway • Function can be omitted from lower levels

17. Example: Transaction Management • Distributed data storage system • Accessing data via identifier, version, type of access: read/write (, value to be written) • Network is simplified and does not suppress duplicate messages • Identifier plus version suffices to detect duplicate writes • Duplicate read only leads to duplicate response • Acknowledgement needed is that data is stored safely • Can only be provided by the higher levels • By eliminating ACKs, the number of messages is halved!

18. Identifying the Ends • Analysis of application requirements is essential • For voice traffic, unusually strong version of the argument applies • Bit-perfect communication leads to delays in packet delivery • It is better to accept slightly damaged but not delayed packets • However, this changes if the conversation is not real-time (voice mail) • Accuracy is more important than performance suddenly • Carefully identify the end points!

19. Does it still hold? • What about middleboxes? • Firewalls • NATs • Transparent Caches

20. Emerging Requirements • Operation in untrustworthy world • Are the end-points in willing cooperation to achieve goals? • attacks on networks, spam, etc • More demanding applications • Simple service model of internet makes no guarantee • Streaming audio and video demand more sophisticated service

21. Emerging Requirements • Rise of 3rd Party Involvement • Third parties impose themselves between communicating end points • ISPs, governments, etc • Less sophisticated users • End tto end arguments may be source of complexity to the user • Software must be installed, configured, upgraded and maintained

22. Preserving Peer Replicas By Rate-Limited Sampled Voting Petros Maniatis Mema Roussopoulos TJ Giuli David S. H. Rosenthal Mary Baker Yanto Muliadi Stanford University Presented by Mehedi Bakht

23. Motivation behind Digital Preservation System • Academic publishing is migrating to web • Websites are becoming the version of record for many scientific journals. • Academic libraries are faced with the urgent problem of creating online collections with the staying power of traditional hardcopy books and journals. • Information stored on paper can survive for millennia; information stored digitally today may not be recoverable next week !!

24. Characteristics of Digital Preservation Systems • Long-term large-scale • Lack of central control • Unusual Requirements • Example : Need to avoid long-term secrets like encryption keys • Unusual Oppurtunities • Example : Some operations can be made very time-consuming without sacrificing usability

25. Design Requirements • Must be very cheap to build and maintain • No high-performance hardware (RAID) • Need not to operate quickly • Should prevent rather than expedite changes • Must properly operate for decades without central control

26. LOCKSS • Lots Of Copies Keep Stuff Safe • What is it? • software for digital preservation • provides librarians with an easy and inexpensive way to collect, store, preserve, and provide access to their own, local copy of authorized content they purchase

27. How does LOCKSS work? • Have many copies to ensure the long-term survival of the documents • Same as for hard copies • Use Peer-to-peer opinion polls to guarantee the authenticity of the documents

28. Design Principles • Cheap storage is unreliable: • Write-once media are a least as unreliable as disks • No long-term secrets: • Too hard to preserve; too hard to recover from leak • Use inertia: • Prevent change, do not make it too easy

29. Design Principles (Continued) • Avoid third party reputation: • Too vulnerable to slander or subversion • Intrusion detection is intrinsic: • System with bimodal behavior can provide intrinsic intrusion detection • Assume a strong adversary: • Attackers will be able to use very large numbers of hosts over a long time

30. The New Opinion Poll Protocol • Large Archival Units (AUs) • Different types of peers • Malign peer: one tries to subvert the system • Loyal peer: one that follows the LOCKSS protocol at all times • Damaged peer: a loyal peer with a damage AU • Healthy peer: a loyal peer with the correct AU • Goal • high probability of healthy peers despite failures and attacks • Low probability that a powerful adversary can inflict sufficient damage without detection

31. The Idea of Polling • The basic idea is to ensure authenticity of AUs by taking advantage of bimodality of the replicas

32. Bimodal System Behavior • For any given article, it is the case that • with high probability either most of the replicas are good • or with high probability most of the replicas are bad. • That is, the probability of half of the replicas being good and half of the replicas being bad is almost zero Probability

33. The Idea of Polling • If the votes overwhelmingly agree, the poll initiator’s copy is ok, do nothing • If the caller of the pool receives votes that overwhelmingly disagree • Ask for a copy to repair its own • Vote again • If the result of the poll is neither a landslide win nor a landslide loss (i.e. it violates the bimodal property), then the caller raises an alarm to attract human attention to the situation

34. Voting Membership • Inner circle • Decide the poll outcome • Outer circle • Nominated by inner circle • May become members of the inner circle in the future

35. Details • Each peer maintains two lists • Reference list • Recently encountered peers • Friends list • Peers with out-of-band relationship

36. Protocol Description - Bootstrappiing • For each document (or Archival Unit - AU) a library maintains a Friend List. Friend List

37. Protocol Description - Bootstrappiing • For each document (or Archival Unit - AU) a library maintains a Friend List. • How this friend list is created in the first place by libraries which do not have much collaboration with other libraries? Friend List

38. Bootstrapping (Continued) • Copy all entries from its current friends list into its reference list • Each reference has a random expiration time Friend Reference Copy

39. Poll Initiation Poll ? Poll ? Poll ? Reference Inner random # of copies Poll : [Poll ID, Public Key] • Choose N random peers from the reference list (inner circle)

40. Send encrypted poll messages Remove peers that cannot answer the challenge-response questions within a specified time frame from the inner circle If too few inner circle members, invites additional peers from the reference list Abort when the reference list is exhausted INITIATOR VOTER Poll ? Poll Initiation

41. In response, the peer sends back a PollChallenge message of the form [Poll ID, Diffie-Hellman Public Key, challenge, YES] YES/NO denotes whether the peer is willing to vote or note Challenge is a random value used for “effort proof” INITIATOR VOTER Poll ? Challenge (Yes/No) Poll Solicitation

42. For every received affirmative message the initiator produces some computational effort that is provable via poll effort proof The effort and its proof are cryptographically derived from The poll identifier Potential voter’s challenge INITIATOR VOTER Poll ? Challenge (Yes/No) Proof Poll Effort

43. Computational Effort • Originated from the idea to fight spam • Basic idea: • the sender must make some sort of computational effort specific to the message or the receiver • It should take much less time to verify the effort than to compute it • LOCKSS uses memory-bound computations to account for CPU power disparity

44. A voter verifies the poll effort proof it receives in a PollProof message using the poll identifier and challenge it sent to the initiator Chooses I other peers at random from its own reference list and nominates them for inclusion into the poll INITIATOR VOTER Poll ? Challenge (Yes/No) Proof Nominate Poll Effort Verification & Nomitaion

45. Consists of a hash of AU and interleaved with provable computational effort Vote computation is divided in rounds, each with computational effort and the hashed portion double in size A subsequent challenge is dependent on the previous challenge INITIATOR VOTER Poll ? Challenge (Yes/No) Proof Nominate Vote Vote Construction

46. Vote Verification • If the proof of effort is incorrect, the vote is invalid, and the peer if black listed • If the proof is correct, and the hash matches, it is valid and agreeing • If the proof is correct, and the hash mismatches, it is valid and disagreeing

47. Vote Tabulation • Agreeing votes are smaller than a threshold (landslide loss), the initiator needs to repair its copy • Agreeing votes are greater than a threshold (landslide win), the initiator updates its reference list and schedules the next poll • Otherwise, raise an alarm

48. Repair • Need to detect inconsistencies between the voting information and the repaired AU • If initiator cannot complete the repair process, raise the corresponding alarm

49. Protocol Analysis • Need to achieve the following • Prevent one from gaining a foothold • Make it expensive for the adversary to waste another peer’s resources • Make it likely for attacks to be detected

50. Timeliness of Effort • Only proofs of recent effort can affect the system • Need to expend resources to maintain foothold