Re: DHT usage and requirement lists

// Copied from Michael's list of attack scenarios. 

This is an excellent idea. Let's try to come up with a list of attack
scenarios. A couple of suggestions:

1) Dummy files - the attacker wants to make certain files hard to
download by offering dummy files with similar names

2) Keyword spam - the attacker wants to make certain keywords hard to
search for by flooding requesters with bogus results

3) Content spam - the attacker wants users to download certain files
(advertisements, trojans) and responds to many/all searches with those
files

Possible defences:

A) Credence

B) Regularly updated blacklists of IP ranges, file sizes and file hashes

C) Searching our friends and friends-of-friends first

Any others?


--- In [email protected], "pwang708" <wang.peng@...> wrote:
>
> Updated based on Arne and Michael's comments. Some of them will be
> hard to achieve but we still put them here for completeness. Please
> feel free to edit and/or put new sections.
> 
> Usage:
> 1) magnet links
> 2) push-proxies
> 3) alt-locs
> 4) searching for files by hash. 
> 5) Searching for file metadata by its hash. 
> 6) serving as distributed trackers for bittorrent enabled clients. A
> DHT can also be used to search torrent files.
> 7) helping Gnutella for rare keyword searches. 
> 8) serving as a decentralized contact-list so that one can search for
> specific users
> 9) searching for my friends' addresses or their Ultrapeers' addresses.
> Connecting to the same ultrapeers as my friends (and their friends)
> might allow me to find interesting files in fewer hops, which is good
> for two reasons: less bandwidth used, and fewer non-friends (potential
> spammers) reached by the query.
> 10) We can group peers having common interests and tag the groups. A
> group can publish the tags and a subset of current ultrapeers in the
> group into the DHT. A node can search the tags to join the group or to
> find files available under the tags.
> 
> 
> Requirements:
> 1) Good user experience 
> 2) Low overhead.
> 3) Hotspot mitigation.
> 4) Write Quota system. A user can only publish a certain number of
> data items, to each DHT node.
> 5) Data security. E.g., only I can modify my push proxy information. 
> 6) Mitigation of "traditional" spams. I quote a line from Arne's
> previous post: "Spam, in the way it is used today, is a means to make
> it harder for people to reach some popular files for whose
> "protection" the spammers get paid." I think we should use some other
> name (such as targeted file poisoning/pollution attack) to distinguish
> it from "traditional" spams. 
> 7) Index poisoning/pollution attack mitigation.
> 8) Routing security. I.e., always be able to find the replica roots. 
> 9) A richer API. The DHT can be used for several things which may have
> different requirements. E.g., allow users to define their data's life
> time in [MIN, MAX], which are network wide parameters.
> 10) fixable lookup. For example, for lookups we don't care about
> speed, parallelism = 1, else parallelism = 3; exhaustive or not (find
> all replica root or find a node who answers a query); caching replica
> sets so that republishes consume less bandwidth... 
> 11) Identification system.
>