'Disconnecting, clock drifts too much' can result in hundreds of entries in peerinfo very quickly

[rocket-pig]

Constant re- dis- connects from a handful of IPs leading to hundreds of entries in peerinfo very quickly

cat .navcoin4/debug.log -n5000 | grep -i 'clock drifts too much'

2019-05-17 19:40:11 peer=601 clock drifts too much (69); disconnecting 2019-05-17 19:40:45 peer=602 clock drifts too much (39); disconnecting 2019-05-17 19:42:56 peer=604 clock drifts too much (-54); disconnecting 2019-05-17 19:44:33 peer=605 clock drifts too much (-57); disconnecting 2019-05-17 19:45:57 peer=606 clock drifts too much (34); disconnecting 2019-05-17 19:47:50 peer=607 clock drifts too much (103); disconnecting 2019-05-17 19:49:45 peer=608 clock drifts too much (43); disconnecting 2019-05-17 19:50:45 peer=609 clock drifts too much (39); disconnecting 2019-05-17 19:50:52 peer=610 clock drifts too much (38); disconnecting 2019-05-17 19:53:02 peer=611 clock drifts too much (69); disconnecting 2019-05-17 19:54:59 peer=614 clock drifts too much (9132); disconnecting 2019-05-17 19:56:23 peer=615 clock drifts too much (34); disconnecting 2019-05-17 19:58:15 peer=616 clock drifts too much (103); disconnecting 2019-05-17 19:58:21 peer=617 clock drifts too much (-55); disconnecting 2019-05-17 19:59:59 peer=619 clock drifts too much (42); disconnecting 2019-05-17 20:00:45 peer=620 clock drifts too much (39); disconnecting 2019-05-17 20:01:41 peer=621 clock drifts too much (38); disconnecting 2019-05-17 20:05:29 peer=622 clock drifts too much (69); disconnecting 2019-05-17 20:08:38 peer=623 clock drifts too much (-55); disconnecting 2019-05-17 20:09:01 peer=624 clock drifts too much (34); disconnecting 2019-05-17 20:10:00 peer=626 clock drifts too much (42); disconnecting 2019-05-17 20:10:28 peer=627 clock drifts too much (103); disconnecting 2019-05-17 20:11:04 peer=628 clock drifts too much (39); disconnecting 2019-05-17 20:16:21 peer=631 clock drifts too much (38); disconnecting 2019-05-17 20:19:31 peer=632 clock drifts too much (-57); disconnecting 2019-05-17 20:20:11 peer=633 clock drifts too much (42); disconnecting 2019-05-17 20:21:14 peer=634 clock drifts too much (39); disconnecting 2019-05-17 20:21:19 peer=635 clock drifts too much (103); disconnecting 2019-05-17 20:21:29 peer=636 clock drifts too much (-55); disconnecting 2019-05-17 20:21:47 peer=637 clock drifts too much (34); disconnecting 2019-05-17 20:27:46 peer=640 clock drifts too much (38); disconnecting 2019-05-17 20:30:26 peer=641 clock drifts too much (42); disconnecting 2019-05-17 20:30:54 peer=642 clock drifts too much (-57); disconnecting 2019-05-17 20:31:14 peer=643 clock drifts too much (39); disconnecting 2019-05-17 20:32:00 peer=644 clock drifts too much (34); disconnecting 2019-05-17 20:32:56 peer=645 clock drifts too much (-55); disconnecting

navcoin-cli getpeerinfo | grep "\"addr\": \""

...shows that there's only ~20 ips doing all of this. some are even same IP on different port numbers.

4.6.0 'self compiled'

Ubuntu 19.04 (GNU/Linux 5.0.0-13-generic x86_64) Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz

[mxaddict]

If your system time is correct, then this should be normal behavior for peers with wrong time.

What was the NTP start up log for this node?

[rocket-pig]

Thanks for response. The node doesn't have any ntp issue, all is 'normal' there

...so theoretically, a bad actor with just a couple machines could fill the peerinfo log into the thousands or tens of thousands of entries in short order? It seemed like a potential 'sploit' to knock nodes offline. Don't you think?

[mxaddict]

Not really, they will be added to the banlist after being naughty for X attemps, I forget how many.

[mxaddict]

Also, once they are disconnected, they will be removed from peerinfo list.

[mxaddict]

@aguycalled can you confirm that what I think happens, actually happens with peers who drift out of the allowed time?

[aguycalled]

clock offsets do not ban, only disconnect

[mxaddict]

Ahh, @rocket-pig mentioned the peers were staying in the getpeerinfo list, would that be a vector for a DOS attack?

[mxaddict]

Just creating a bunch of nodes with bad clock settings, then using up node resources by attempting as many connects with proper nodes on the network.

[rocket-pig]

the log shows above that its adding towards what could be a 'resource exhaustion' situation. a couple nodes increased the peer count by hundreds, in not very much time.

edit, im not c++-hip enough to know if that would happen. I just thought i'd bring it up and if it were, you guys would know.

[aguycalled]

When you say it's the same ip on different numbers, that's the local port the other peer is using to connect to your remote port. It's completely normal every socket has a different local port.

I don't see how this could cause a DoS in the node. This is no different from a node disconnecting and connecting again many times.

We could opt for banning nodes with a drifting clock, so successive connection attempts are prevented, but that way we would be stopping that node also from connect to a part of the network for the duration of the ban, even if (s)he manages to finally sync the clock.

[rocket-pig]

the stub above shows that in ~40 mins, ~40 new entries were added. it was not 40 unique IPs when i grepped them out of 'getpeerinfo', (which i only omitted because I thought it would be impolite to post node IPs here.) That's all I'm saying. Maybe its not a big deal to repeatedly make a new entry for a non-new IP. Seemed worth mentioning, but like I said I'm No Pro. Thanks for all your hard work, much appreciated.