2013-10-11 08:47:06 +08:00
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
2014-03-04 20:48:38 +08:00
|
|
|
The behavior of each Tox node is easily predictable. This means that it possible
|
2013-10-11 08:47:06 +08:00
|
|
|
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.
|
|
|
|
|
|
2013-10-31 08:25:02 +08:00
|
|
|
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.)
|
|
|
|
|
...
|
