Hardening the Tox network, document writing in progress.

1 files changed, 48 insertions, 0 deletions

diff --git a/docs/Hardening.txt b/docs/Hardening.txt
new file mode 100644
index 00000000..838b3566
--- /dev/null
+++ b/docs/Hardening.txt
@@ -0,0 +1,48 @@
+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. ...