doc/book: p2p DoS protection

doc/src/architecture/p2p-network.md

@@ -38,6 +38,25 @@ Then each slot performs this algorithm:
 
 ## Security
 
+### Design Considerations
+
+* Mitigate attacks to a reasonable degree. Ensuring complete coverage against attacks is infeasible and likely
+  introduces significant latency into protocols.
+* Primarily target the p2p network running over anonymity networks like Tor, i2p or Nym.
+  This means we cannot rely on node addresses being reliable. Even on the clearnet, attackers can easily obtain
+  large numbers of proxy addresses.
+
+The main attacks are:
+
+* **Sybil attack**. A malicious actor tries to subvert the network using sockpuppet nodes. For example
+  false signalling using version messages on the p2p network.
+* **Eclipse attack**. Targets a single node, through a p2p MitM attack where the malicious actor controls all
+  the traffic you see. For example they might send you a payment, then want to doublespend without you
+  knowing about it.
+* **Denial of Service**. Usually happens when a node is overloaded by too much data being sent.
+
+### Common Mitigations
+
 * **Backoff/falloff**. This is the strategy implemented in Bitcoin. This can be bad when arbitrary limits are implemented
   since we slow down traffic for no reason.
 * **Choking controller**. BitTorrent no longer uses naive tit-for-tat, instead libtorrent implements an anti-leech seeding algo
@@ -45,6 +64,7 @@ Then each slot performs this algorithm:
   bandwidth to all peers. See also [libtorrent/src/choker.cpp](https://github.com/arvidn/libtorrent/blob/RC_2_0/src/choker.cpp).
     * All p2p messages will have a score which represents workload for the node. There is a hard limit, and in general the choker
       will try to balance the scores between all available channels.
+    * Opening the connection itself has a score with inbound connections assigned more cost than outgoing ones.
 * **Smart ban**. Malicious peers which violate protocols are hard banned. For example sending the wrong data for a chunk.
     * Add a method `channel.ban()` which immediately disconnects and blacklists the address.
 * **uTP congestion control**. BitTorrent implements a UDP protocol with its own congestion control. We could do such a similar strategy
@@ -55,4 +75,35 @@ Then each slot performs this algorithm:
   details of this algorithm. This aids with network connectivity, avoiding netsplits which could make the network more susceptible to
   eclipse/sybil attacks (large scale MiTM).
     * For this we would need a function to connect to a host, send a ping, receive a pong and disconnect to test node connectivity.
+* **Protocol-level reputation system**. You have a keypair, which accrues more trust from the network. Nodes gossip trust metrics.
+    * See [AnonRep: Towards Tracking-Resistant Anonymous Reputation](https://www.usenix.org/system/files/conference/nsdi16/nsdi16-paper-zhai.pdf)
+    * Also the discussion in
+      [Semaphore RLN, rate limiting nullifier for spam prevention in anonymous p2p setting](https://ethresear.ch/t/semaphore-rln-rate-limiting-nullifier-for-spam-prevention-in-anonymous-p2p-setting/5009)
+* **Reduce blast radius**. The p2p subsystem should run on its own dedicated executor, separate from database lookups or other
+  system operations.
+* **fail2ban**
+* **Optimized blockchain database**. Most databases are written for interleaved reads and writes as well as deletion. Blockchains follow
+  a different pattern of infrequent writes being mostly append-only, and requiring weaker guarantees.
+
+### Protocol Suggestions
+
+Core protocols should be modeled and analyzed with DoS protections added. Below are suggestions to start the investigation.
+
+* Do not forward orphan txs or blocks.
+* Drop all double spend txs.
+    * Alternatively require a higher fee if we want to enable replace by fee.
+    * Do not forward double spend txs.
+* Do not forward the same object (block, transaction .etc) to the same peer twice. Violation results in `channel.ban()`.
+* Very low fee txs are rate limited.
+* Limit orphan txs.
+* Drop large or unusual orphan transactions to limit damage.
+* Consider a verification cache to prevent attacks that try to trigger re-verification of stored orphan txs. Also limit the size of the cache.
+  See [Fixed vulnerability explanation: Why the signature cache is a DoS protection.](https://bitcointalk.org/index.php?topic=136422.0)
+* Perform more expensive checks later in tx validation.
+* Nodes will only relay valid transactions with a certain fee amount. More expensive transactions require a higher fee.
+* Complex operations such as requesting data can be mitigated by tracking the number of requests from a peer.
+    * Attackers may attempt flooding invs for invalid data. The peer responds with get data but that object doesn't exist using
+      up precious bandwidth. Limit both the rate of invs to 2/s and size of items to 35.
+    * Also loops can cause an issue if triggered by the network. This should be carefully analyzed and flattened if possible,
+      otherwise they should be guarded against attack.