summaryrefslogtreecommitdiff
path: root/protocols/Tox/toxcore/docs/Hardening.txt
diff options
context:
space:
mode:
Diffstat (limited to 'protocols/Tox/toxcore/docs/Hardening.txt')
-rw-r--r--protocols/Tox/toxcore/docs/Hardening.txt60
1 files changed, 60 insertions, 0 deletions
diff --git a/protocols/Tox/toxcore/docs/Hardening.txt b/protocols/Tox/toxcore/docs/Hardening.txt
new file mode 100644
index 0000000000..50ccfd53e0
--- /dev/null
+++ b/protocols/Tox/toxcore/docs/Hardening.txt
@@ -0,0 +1,60 @@
+Currently an attacker with sufficient resources could launch a large scale
+denial of service type attack by flooding the Tox network with a bunch of nodes
+that do not act like real nodes to prevent people from finding each other.
+
+Due to the design of Tox, this is the worst thing an attacker can do to disrupt
+the network.
+
+This solution's goal is to make these denial of service attack very very hard
+to accomplish.
+
+For the network to work every Tox node must:
+1. Respond to ping requests.
+2. Respond to get node requests with the ids of nodes closest to a queried id
+(It is assumed each nodes know at least the 32 nodes closest to them.)
+3. Properly send crypto request packets to their intended destination.
+
+Currently the only thing a node needs to do to be part of the network is
+respond correctly to ping requests.
+
+The only people we really trust on the network are the nodes in our friends
+list.
+
+
+The behavior of each Tox node is easily predictable. This means that it possible
+for Tox nodes to test the nodes that they are connected to to see if they
+behave like normal Tox nodes and only send nodes that are confirmed to behave
+like real Tox nodes as part of send node replies when other nodes query them.
+
+If correctly done, this means that to poison the network an attacker can only
+infiltrate the network if his "fake" nodes behave exactly like real nodes
+completely defeating the purpose of the attack. Of course nodes must be
+rechecked regularly to defeat an attack where someone floods the network with
+many good nodes then suddenly turns them all bad.
+
+This also prevents someone from accidentally killing the tox network with a bad
+implementation of the protocol.
+
+Implementation ideas (In Progress):
+
+1. Use our friends to check if the nodes in our close list are good.
+
+EX: If our friend queries a node close to us and it correctly returns our
+ip/port and then sends a crypto request packet to it and it routes it correctly
+to us then it is good.
+
+Problems with this: People don't always have at least one online friend.
+
+2. Pick random nodes (add ourselves some random (fake) friends to increase the
+pool of available nodes) and make then send requests to other nodes, the
+response is then relayed back to us and compared to how the node should have
+behaved. If the node is found to be behaving correctly, it is set as trusted.
+Only trusted nodes are sent in send node packets, that is unless the exact node
+being queried for in the getnode packet is present, it will be sent in the
+sendnode packet even if it is not trusted.
+
+The hypothesis is that if to be part of the network nodes have to behave
+correctly it should prevent disruption from nodes that behave incorrectly.
+
+(This idea is currently being implemented in the harden branch.)
+...