Implement MNAUTH and allow unlimited inbound MN connections #2790

codablock · 2019-03-21T13:34:48Z

This implements MNAUTH, which allows us to verify that an incoming connection is indeed from another MN. This in turn allows us to exclude inbound MN connections from limit checks and at the same time protect these connections from eviction.

This is required to ensure that intra-quorum connections stay active as long as they are needed and never get evicted due to MNs being spammed with inbound connections.

The reason we can exclude authenticated MN connections from eviction is because these are naturally limited. MNAUTH will drop any previous connections that were authenticated with the same MN, which means that each MN can cause only one incoming authenticated (non-evictable) connection.

MNAUTH is also sent/verified for outgoing connections, this is however not of interest when it comes to the inbound connection eviction and DoS (or network partition) protection. It is however useful to avoid unnecessarily connecting to a MN that already connected to us when ensuring intra-quorum connections.

UdjinM6

Few things:

let's keep Hash suffix to avoid confusion (I pointed just at few places the issue occurs, not to be committed from suggestions directly);
probably a copy/paste mistake when filling pubKeys set.

src/evo/mnauth.cpp

src/net.h

src/net.cpp

UdjinM6

utACK

We will later need the proRegTxHash

Having serialization and deserialization in the same specialized template results in compilation failures due to the "if(for_read)" branch.

This allows masternodes to authenticate themself.

Give fresh connections some time to do the VERSION/VERACK handshake and an optional MNAUTH when it's a masternode. When an MNAUTH happened, the incoming connection is then forever protected against eviction. If a timeout of 1 second occurs or the first message after VERACK is not MNAUTH, the node is not protected anymore and becomes eligable for eviction.

… same one Now that incoming connections from MNs authenticate them self, we can avoid connecting to the same MNs through intra-quorum connections.

codablock · 2019-03-22T08:26:39Z

Rebased on develop to fix merge conflicts. Needs re-ACK

UdjinM6

re-utACK

PastaPastaPasta · 2019-06-20T05:45:21Z

src/evo/mnauth.cpp

+        return;
+    }
+
+    if (strCommand == NetMsgType::MNAUTH) {


why isn't it assumed this is the case? I would think this method is only called when that check is true

Nope, it's called for every incoming message. This follows the convention that we use for all Dash specific message handling. For example, everything related to DKGs is handled in CDKGSessionManager::ProcessMessage and it by itself checks which message it actually is. This might look a bit strange in the cases where it's only one message that we're interested in, but I prefer to use the same style/convention for all cases.

…ocessMessage We could be reading multiple messages from a socket buffer at once _without actually processing them yet_ which means that `fSuccessfullyConnected` might not be switched to `true` at the time we already parsed `VERACK` message and started to parse the next one. This is basically a false positive and we drop a legit node as a result, even though the order of messages sent by this node was completely fine. To fix this the logic for tracking the first message after `VERACK` was moved into ProcessMessage. This partially reverts dashpay#2790

…ocessMessage We could be reading multiple messages from a socket buffer at once _without actually processing them yet_ which means that `fSuccessfullyConnected` might not be switched to `true` at the time we already parsed `VERACK` message and started to parse the next one. This is basically a false positive and we drop a legit node as a result even though the order of messages sent by this node was completely fine. To fix this I partially reverted dashpay#2790 (where the issue was initially introduced) and moved the logic for tracking the first message into ProcessMessage instead.

We could be reading multiple messages from a socket buffer at once _without actually processing them yet_ which means that `fSuccessfullyConnected` might not be switched to `true` at the time we already parsed `VERACK` message and started to parse the next one. This is basically a false positive and we drop a legit node as a result even though the order of messages sent by this node was completely fine. To fix this I partially reverted dashpay#2790 (where the issue was initially introduced) and moved the logic for tracking the first message into ProcessMessage instead.

We could be reading multiple messages from a socket buffer at once _without actually processing them yet_ which means that `fSuccessfullyConnected` might not be switched to `true` at the time we already parsed `VERACK` message and started to parse the next one. This is basically a false positive and we drop a legit node as a result even though the order of messages sent by this node was completely fine. To fix this I partially reverted #2790 (where the issue was initially introduced) and moved the logic for tracking the first message into ProcessMessage instead.

We could be reading multiple messages from a socket buffer at once _without actually processing them yet_ which means that `fSuccessfullyConnected` might not be switched to `true` at the time we already parsed `VERACK` message and started to parse the next one. This is basically a false positive and we drop a legit node as a result even though the order of messages sent by this node was completely fine. To fix this I partially reverted dashpay#2790 (where the issue was initially introduced) and moved the logic for tracking the first message into ProcessMessage instead.

We could be reading multiple messages from a socket buffer at once _without actually processing them yet_ which means that `fSuccessfullyConnected` might not be switched to `true` at the time we already parsed `VERACK` message and started to parse the next one. This is basically a false positive and we drop a legit node as a result even though the order of messages sent by this node was completely fine. To fix this I partially reverted dashpay#2790 (where the issue was initially introduced) and moved the logic for tracking the first message into ProcessMessage instead. Signed-off-by: cevap <[email protected]>

codablock added this to the 14.0 milestone Mar 21, 2019

codablock force-pushed the pr_mnauth branch from af01e90 to 96bbb2e Compare March 21, 2019 13:44

UdjinM6 added the P2P Some notable changes on p2p level label Mar 21, 2019

UdjinM6 reviewed Mar 21, 2019

View reviewed changes

src/evo/mnauth.cpp Outdated Show resolved Hide resolved

src/net.h Outdated Show resolved Hide resolved

src/net.h Outdated Show resolved Hide resolved

src/net.cpp Outdated Show resolved Hide resolved

src/net.cpp Outdated Show resolved Hide resolved

codablock force-pushed the pr_mnauth branch from fe21ce4 to 65e4f3d Compare March 21, 2019 16:47

UdjinM6 previously approved these changes Mar 21, 2019

View reviewed changes

codablock added 7 commits March 22, 2019 09:25

Sort evo/* source files in Makefile.am

38eb76d

Keep track of proRegTxHash in CConnman::masternodeQuorumNodes map

b8af5ff

We will later need the proRegTxHash

Fix serialization of std::tuple with const rvalue elements

60225d1

Having serialization and deserialization in the same specialized template results in compilation failures due to the "if(for_read)" branch.

Implement MNAUTH message

5ead24e

This allows masternodes to authenticate themself.

Avoid connecting to masternodes if an incoming connection is from the…

fe811b9

… same one Now that incoming connections from MNs authenticate them self, we can avoid connecting to the same MNs through intra-quorum connections.

Apply review suggestions

d58789f

codablock dismissed UdjinM6’s stale review via d58789f March 22, 2019 08:26

codablock force-pushed the pr_mnauth branch from 65e4f3d to d58789f Compare March 22, 2019 08:26

UdjinM6 approved these changes Mar 22, 2019

View reviewed changes

codablock merged commit b18f8cb into dashpay:develop Mar 22, 2019

codablock deleted the pr_mnauth branch March 22, 2019 10:52

PastaPastaPasta reviewed Jun 20, 2019

View reviewed changes

UdjinM6 mentioned this pull request Jan 31, 2020

Fix node protection logic false positives #3314

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement MNAUTH and allow unlimited inbound MN connections #2790

Implement MNAUTH and allow unlimited inbound MN connections #2790

codablock commented Mar 21, 2019

UdjinM6 left a comment

UdjinM6 left a comment

codablock commented Mar 22, 2019

UdjinM6 left a comment

PastaPastaPasta Jun 20, 2019 •

edited

Loading

codablock Jun 20, 2019

PastaPastaPasta Jun 20, 2019

Implement MNAUTH and allow unlimited inbound MN connections #2790

Implement MNAUTH and allow unlimited inbound MN connections #2790

Conversation

codablock commented Mar 21, 2019

UdjinM6 left a comment

Choose a reason for hiding this comment

UdjinM6 left a comment

Choose a reason for hiding this comment

codablock commented Mar 22, 2019

UdjinM6 left a comment

Choose a reason for hiding this comment

PastaPastaPasta Jun 20, 2019 • edited Loading

Choose a reason for hiding this comment

codablock Jun 20, 2019

Choose a reason for hiding this comment

PastaPastaPasta Jun 20, 2019

Choose a reason for hiding this comment

PastaPastaPasta Jun 20, 2019 •

edited

Loading