[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