[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[freehaven-dev] Announcing O'Reilly Chapter, Outline
So David alluded to a "chapter" in a previous email, without giving more
specifics (or context) what we were actually discussing. For about a
week or two, we've been in contact with an editor at O'Reilly publishing
(Andy Oram). He initially contacted us because O'Reilly plans to
publish a book on peer-to-peer systems within the next few months, in
order to capture the Napster/Gnutella/Freenet hype.
Basically, we are going to contribute one chapter (20-30 pages or so) to
the book. There should be about 8-10 individuals/groups contributing.
The topic we are focusing on is:
Accountability, Flooding control and resource management
This topic can be largely summarized in Roger's reply to Ian Clarke
about accountability measures in current peer-to-peer systems. We'll
also include within that a 5-page or so description of Free Haven.
One of the big goals is to point out the wrong assumptions people often
make about micropayments schemes and the like: it's not to get rich,
it's to provide accountability.
Anyway, I'm attaching a very rough outline I drew up. Comments, input,
suggestions, etc. are all welcome...the due date for first draft is
This is exciting!
I. Overview: why we need it
A. Problem: flood control and resource management
1. Tragedy of the Commons
2. Difficulties in paying for public goods (Mancur Olson)
B. Types of attacks
1. Flooding storage space
2. DoS on communication link (bandwidth)
C. Preventions/protections from attacks
II. Difficulties: why it's not easy
B. Need for dynamic-ness in decentralized system
1. Easy to join and leave the system
2. No centralized / few static server points
C. Comparison to real world identification
1. Non-static/permanent IDs (nyms)
2. Difficulty in binding negative attributes
(users can just take on a new nym?), unlike
rl where SSN are bound to "permanent files"
in centralized databases (credit history,
law enforcement, etc.)
3. Comparison to "spot" checking in rl: make
penalty prohibitively large to prevent people
from taking "risk." This model does not extend
as easily to non-static ids.
D. Judging behavior v. intent
1. The importance of differentiating these
two aspects: do we only care if data is
present / protocol has been followed
properly, or is it important to differentiate
those who maliciously break protocol?
2. The need for automated decision-making,
and the difficulties that entails (hard
to judge "intent")
E. The balance between gaining positive and
1. If positive attributes are too easy to gain,
attackers can more quickly and easily damage
2. If negative attributes are too easy to gain,
"good" nodes can too quickly lose "reputation"
do to behavioral problems (not intent).
F. Methods to minimize damage that adversaries
(intentional or not) can inflict on the system
III.Historical examples of accountability requirements
A. Non peer-to-peer / centralized servers
1. TTP models
2. PGP Keyservers
B. System successes/failures
C. What we've learned
IV. Peer-to-Peer models
A. Projects and accountability systems used
Freenet, Gnutella, Publius, FreeHaven, MojoNation,
Blocks, Eternity USENET, Intermemory, Eternity, ...
B. Accountability methods
"Pricing via Processing", Moni Naor et al, 1991
a. ecash (Chaum, Brands)
b. hashcash (Adam Back), Payword (Rivest and Shamir)
c. client puzzles (Brainard and Juels)
d. b-money (Wei Dai)
e. bread pudding (Jakobsson and Juels)
2. Reputation and Trust networks
3. Caching (only storage)
Akamai and Freenet style
4. SYN cookies (only bandwidth)
V. Social considerations
(??? This entire section might not fit well with
out theme, and might fit better with the concept
of "Trust" Andy talked with Publius about)
A. Requirements for targetted audience
B. How computational "accountability" leads to
real-life trust in a system
C. Cultural assumptions
VI. Open problems, Future Directions, ...
"Not all those who wander are lost." firstname.lastname@example.org