DHT Request hardening human doc.

[NamsooCho]

DHT Hardening

• Why we use hardening.

DhtRequest hardening is used for avoiding DoS attack.
A Tox node can be enter into Tox Network if the node can respond with valid PingResponse.
So, inserting many fake nodes can attack Tox Network to prevent two valid tox nodes can not connect to each other.
Hardening is used for defeating this attack.

• To implement hardening, we introduce new packet type named CRYPTO_PACKET_HARDENING which of value is 48.
• We should extend existing RequestQueue struct to generic struct which is

From:

pub struct RequestQueue {
    /// Map that stores requests IDs with time when they were generated.
    ping_map: HashMap<(PublicKey, u64), Instant>,
    /// Timeout when requests IDs are considered invalid.
    timeout: Duration,
}

To:

pub struct RequestQueue<T: u64 + HardenPingId> {
    /// Map that stores requests IDs with time when they were generated.
    ping_map: HashMap<(PublicKey, T), Instant>,
    /// Timeout when requests IDs are considered invalid.
    timeout: Duration,
}

Here T may be one of these

u64

Or

struct HardenPingId {
    sendback_node: PackedNode,
    ping_id: u64,
}

• How working
  • send periodically hardening getnodes_req to random node in close_list for all of nodes in close_list.
  • handle incoming harden getnodes_req by responding with harden getnodes_resp, or handle harden getnodes_resp by checking responded node's PK is in my close_List.

[kpp]

Good. But in the first iteration we will receive these packets and drop them.

[kurnevsky]

It seems hardening is going to be removed from c-toxcore.

So, inserting many fake nodes can attack Tox Network to prevent two valid tox nodes can not connect to each other.

Actually hardening can't provide good protection against sybil attack: it assumes that the attacker will send difference responses to different nodes but he doesn't have to do so to achieve the desired result. The attacker can just stop sending specific node to everyone with the same result, as he doesn't know it.

[kpp]

Still we have to parse them to avoid that many error messages in the log.

[ghost]

Bittorrent had the same problem, and they solved it by issuing BEP 42 which basically requires that certain bits of your DHT address exactly match the hash certain bits of your public IP address.

Here's a summary:

• If you launch more than one Sybil from the same public IP they will have DHT addresses very close to each other. In order to launch a large Sybil attack you will need large numbers of public IPv4 addresses.
• The "certain bits" part above is chosen carefully so that an attacker in control of a large contiguous block of IP addresses (say, a /24 or even /16) still can't shut down the entire network. A Sybil attack requires not only lots of IP addresses, but also lots of IP addresses which are far away from each other according to the integer-subtraction distance metric on IPv4 space.

Implementing this defense against Sybil attacks requires DHT nodes to opt-in to the defense. One way of rolling it out in a backwards-compatible manner is for clients to decide with some small probability (say 5%) whether or not to only use DHT nodes that have opted in to the Sybil defense. In other words for each DHT query, with 5% probability, the client would ignore all DHT nodes whose DHT address doesn't match its IPv4 address.

This means that an attacker with lots of machines but few IP addresses could slow down the network by a factor of 20x but could not completely shut it down. The probability can be user-configurable so that users can manually increase it in the event of an attack, and the default setting can be gradually increased over time as more and more DHT nodes opt-in to the defense.