Giters

iotaledger / IOTA-2.0-Research-Specifications

This is the repository of the IOTA 2.0 Research Specifications.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

issue peer discovery

NaitsabesMue opened this issue · comments

commented

In ## 2.1.4.2 Verification it is not clear which nodes are on the known_peer_list. Is the the "oldest verified peer" the oldest peer that was recently verified?

Does this enable a Sybil attack where the known peer list is filled with fake identities, making it impossible for the node to verify real nodes?

commented

Mana is not playing a role in the peer discovery. This may be necessary for FPC, since we have to know a good proportion of nodes, but an attack might be to fill the known_peer_list and verified_peer list with many thousands of "0" mana nodes, and then node may not even find anybody to peer with. For FPC it is important that the high mana nodes are verified.

Possible solution:

  1. choose nodes weighted to their mana (scalability at risk, since high mana nodes may receive O(n) requests
  2. order it by mana, plus add a field when last "checked"
  3. high mana nodes are verified atutomatically, if FPC statement are seen on the tangle. If no FPC is going on, they have to send "alive" messages, to avoid high amount of requests
commented

Nodes are added verified_peer_list upon receival of a ping message or after DiscoveryRequest. Reminder on what could happen: an attacker “pingSpam” a targeted node with lots of Sybils, then at some point even DiscoveryRequest are sent to attacker.
Besideabove suggestions to introduce Sybil protection in these lists with mana, some natural “solutions” without mana / or add ons:

  1. connect IP address to nodeId with a 1-to-1 mapping in the list, Then attack becomes harder. For instance, add sender of pong to verified_peer_list only if IP address is not yet on the list. Also only reserve a certain amount. say 100 places in this list to be added from pings.
  2. Another way the verified_peer_list can become corrupt is by requesting with DiscoveryRequest from bad nodes (bootstrap problem). This can be mitigated, already by 1-1 mapping above, or sending the first requests to (hard coded) well known or old nodes. Do this only in the bootstrapping, after that use peerRequests for discovery/udpating verified_peer_list
  3. increased Pow difficulty of hash(nodeId, salt)
    None of these solutions are perfect, but together they give some protection.