[freehaven-dev] Announcing O'Reilly Chapter, Outline

[Michael J Freedman <mfreed@MIT.EDU>]

Hey all,

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
(http://freehaven.net/archives/freehaven/dev/Aug-2000/msg00006.html)
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
October 15.

This is exciting!
--mike


Accountability
--------------

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

    A. Anonymity

    B. Need for dynamic-ness in decentralized system
       1. Easy to join and leave the system
       2. No centralized / few static server points
          of attack

    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 
       negative attributes.  
       1. If positive attributes are too easy to gain, 
          attackers can more quickly and easily damage 
          system.  
       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
       3. ...
    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

       1. Micropayments:  
         "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."                  mfreed@mit.edu