[flud-devel] Fwd: [p2p-hackers] Question on DHTs fair use

[Alen Peacock]

---------- Forwarded message ----------
From: Alen Peacock <alenlpeacock at gmail.com>
Date: Sep 23, 2006 10:03 AM
Subject: Re: [p2p-hackers] Question on DHTs fair use
To: theory and practice of decentralized computer networks
<p2p-hackers at lists.zooko.com>


On 9/22/06, Victor Grishchenko <gritzko at plotinka.ru> wrote:
> Hi!
>
> I can't find an answer for one question on DHT security. What if some
> attacker starts uploading some unlimited amount of data to a DHT P2P
> network? Are there a way to impose some usage limits on participants?
> Thanks for any hints.


  One effective mechanism for dealing with this problem is to
constrain the type and format of data being stored in the DHT.  For
example, in flŭd backup (http://www.flud.org) the DHT is used only for
file storage metadata, and this metadata follows a prescribed,
transparent format
(http://www.flud.org/wiki/index.php/Architecture#Metadata_Layer).
Nodes which receive PUT commands can perform a very simple check at
store time to ensure that the incoming data conforms to this format,
and then later on can do a more complete audit to ensure that the
metadata corresponds to actual files stored in the system.  When it
does not, the record can be purged.

  A small amount of opaque data is present in the metadata layer in
flŭd, consisting of encrypted local file metadata (filename,
ownership, permissions, etc), and this can be abused.  However, its
size is relatively small in comparison to the transparent metadata, so
the overhead cost to the attacking node to store abusive data is high.
 In addition, there are methods of auditing this opaque data to ferret
out abuse; opaque data in flŭd belongs to the node that initiated the
PUT, and that node must be able to verify its identity through
self-certification.  Signatures over the opaque data could also be
employed.

  In combination, then, these two mechanisms can be used to provide a
facility where nodes can detect malicious behavior and blacklist
misbehaving nodes.

  To prevent Sybil Attacks on the DHT (the obvious counter to
blacklists), several other mechanisms can be used, including
Kademlia's preference for long-lived (old) nodes, hashcash, or
something along the lines of SybilGuard
(http://www.cs.cmu.edu/~yhf/sybilguard-sigcomm06.pdf).  flŭd uses the
former two methods.

  This doesn't mean there aren't other ways to exploit the DHT.  But
it does take away some of the obvious paths of attack.

  Of course, the data constraining method only works for specialized
DHTs, such as the one used in flŭd backup.

Alen