[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2425: Unreliable (including malicious) storage nodes

Tahoe-LAFS trac at tahoe-lafs.org
Sat May 16 16:39:42 UTC 2015


#2425: Unreliable (including malicious) storage nodes
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  daira
  communitycube          |     Status:  new
         Type:           |  Milestone:  undecided
  enhancement            |    Version:  1.10.0
     Priority:  normal   |   Keywords:  availability reliability anti-
    Component:  code-    |  censorship
  peerselection          |
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Description changed by daira:

Old description:

> An important development to keep a network clean from pseudospoofing
> ("Sybil") and malicious attacks is a way to detect and blacklist
> unreliable or malicious storage nodes
>
> An unreliable storage node is defined as a node that says it's storing
> data, but it isn't.
>
> Those parts of files that it's receiving, are lost.
>
> To prevent use of unreliable storage nodes, each client will check file
> integrity to be sure files are accessible.
>
> Client keeps a relation of parts uploaded to each node. When a storage
> node where file were allocated there, is not giving the file, or answers
> that it doesn't have your file or is not online, after few retries in
> different days this node is marked as unreliable.
>
> Each client will have a list of what he detected as an unreliable storage
> node.
>
> Those list can be done in the introducer, too. In this way, introducer
> would prevent to notice about an unreliable storage node to possible
> clients.

New description:

 An important development to keep a network clean from pseudospoofing
 ("Sybil") and malicious attacks is a way to detect and blacklist
 unreliable or malicious storage nodes

 An unreliable storage node is defined as a node that says it's storing
 data, but it isn't.

 Those parts of files that it's receiving, are lost.

 To prevent use of unreliable storage nodes, each client will check file
 integrity to be sure files are accessible.

 Client keeps a relation of parts uploaded to each node. When a storage
 node where file were allocated there, is not giving the file, or answers
 that it doesn't have your file or is not online, after few retries in
 different days this node is marked as unreliable.

 Each client will have a list of what it detected as an unreliable storage
 node.

 Those list can be done in the introducer, too. In this way, introducer
 would prevent to notice about an unreliable storage node to possible
 clients.

--

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2425#comment:4>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage


More information about the tahoe-lafs-trac-stream mailing list