P2P Monitoring

addr Message Flooding (Summer 2021)

• vasild, mzumsande, sipa noticed peers triggering the rate limiter during review
• sipa raised the question if this could be related to the bitcointalk post

• Active monitoring crashed: couldn't keep up connecting to the fake IPs
• Addresses "distributed uniformly over the IPv4 address space" (including reserved blocks)
• addr message last connected timestamp "up to nine minutes into the future"
• An attacker might use this to infer topology of the network:
  • number of peers of a node
  • other interfaces a node is listening on (IPv6, Onion, ...)

addr flooding only detected by coincidence (?)

P2P monitoring

• passive monitoring with honeypot nodes
• goal: detecting and alerting on
  • anomalies
  • issues with master or RCs
  • attacks
• flow: detect → maybe analyze → maybe react
• dashboard with access for Core Devs?
• historical data recording and data sharing
• use anomaly detection methods?

What to monitor?

• P2P messages: inbound and outbound
• Addrman: changes to tried and new tables
• Connections: opened, closed, peer evictions
• Invalid blocks and transactions (e.g., orphan tx)
• DoS metrics: UTXO cache uncaches, ...
• ...

Out of scope:

How to monitor?

• primarly, via USDT tracepoints
• semi-stable interface to Bitcoin Core internals
• P2P message tracepoints exist, others are WIP/missing
• don't disclose IP addresses of honeypot nodes
• nodes in different data-centers / hosted by different orgs
• nodes on different networks (non-IP, e.g., Tor, might see more attacks)
• different features enabled on different nodes, e.g., BIP158 block filters

Dissecting P2P messages

• addr: time, services, IP, port (addrv2 similar)
• reject: message, reason, extra data
• ...

Design