mirror of
https://github.com/irungentoo/toxcore.git
synced 2024-03-22 13:30:51 +08:00
49 lines
2.0 KiB
Plaintext
49 lines
2.0 KiB
Plaintext
|
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. ...
|