mirror of
https://github.com/irungentoo/toxcore.git
synced 2024-03-22 13:30:51 +08:00
1cb38abf99
This commit fixes some typos and grammar mistakes. It also fixes some of the long text lines and generally makes the documentation more readable.
61 lines
2.7 KiB
Plaintext
61 lines
2.7 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. 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.)
|
|
...
|