Security: Stop disconnecting from nodes that send unexpected messages, to prevent disconnection attacks, Credit: Equilibrium

[teor2345]

Motivation

When Zebra receives an unexpected network message from a peer, it disconnects from that peer. This resets a remote zcashd node's internal connection state for Zebra. So Zebra gets the messages it expects once it reconnects.

There are a few issues with this approach:

1. This is a denial of service risk, because Zcash network protocol messages are unauthenticated.

2. Disconnecting due to protocol differences could be stopping Zebra from being listed by block explorers and DNS seeders.

Priority

This is a medium-priority issue, because:

• we want Zebra to be listed in block explorers and DNS seeders
• closing connections won't bring down other nodes
• Security: Limit reconnection rate to each individual peer address #1848 and Security: only apply the outbound connection rate-limit to actual connections #2278 impose connection rate-limits, so any reconnections won't bring down other nodes

Solution

Unrecognised Messages

• Zcash nodes should drop messages they don't recognise.
  • for Zebra, this includes NODE_BLOOM messages.

Protocol Differences

When Zebra can parse a message that a peer has sent, but doesn't expect that message:

• stop immediately disconnecting from peers
• use or drop the message

Be strict with the handshake

• reject port scanners and new connections speaking the wrong protocol

Be permissive after a successful handshake

• ignore malformed messages on established connections - the IP header might be fake
• when is a connection established? After the Version message? After the whole handshake?

Alternatives

Work out how to restore unusable peers without disconnecting:

• only disconnect due to a specific list of errors? Or allow a specific list of errors, and disconnect for any other errors?
• mark peers as "low priority" when they send unexpected messages
  • make these peers timeout and become ready?
  • what should we do if there are too many unusable peers? (randomly disconnect some, with a rate-limit?)
• rate-limit inbound messages from peers that overload the inbound service
  • impose a lower limit for requests containing blocks or transactions, to avoid memory DoS

Context

We might want to follow what zcashd does here pretty closely.

As zcashd's network behaviour becomes better specified, Zebra will have fewer unexpected network messages.

[teor2345]

PR #3120 caused some panics, PR #3124 should fix them.

But we need to implement a permanent fix in this ticket.

[teor2345]

Actually, the errors re-introduced by #3124 don't close the connection, so this ticket is fixed.

We'll deal with NotFound in #2726.