Blacklisting peers? How to handle protocol quality issues diplomatically

Staking & Delegation Operate a Stake Pool
1

We have one or more incoming topology peers (not in our topology.json & always connecting with high random port numbers) that connect infrequently (in this case either 70 or 75 minutes between connections) flagged like this in our logs:

[relay-ny:cardano.node.ErrorPolicy:Warning:66] [2020-08-26 06:16:35.56 UTC] [String "ErrorPolicySuspendPeer (Just (ApplicationExceptionTrace (MuxError MuxBearerClosed \"<socket: 55> closed when reading data, waiting on next header True\"))) 20s 20s",String "ErrorPolicyTrace",String "<OFFENDING-IP>:46832"]

My instincts are: this is not a hacking or DoS attempt: otherwise it would be more frequent and/or less regular, and this is probably just some old or misconfigured node software listing our relay in its own topology.

We can blacklist IPs easily in our VPC but I first wanted to ask opinions from other SPOs about what’s best for both our relay & the network in this case:

  1. whether it’s sensible to blacklist these nodes by hand (if so, it may be worth filtering the logs for these nodes)
  2. what people have heard about the automatic topology generation handling protocol quality issues like this (i.e.: whether we will automatically drop topology links with non compliant peers)
1 Like
2

It is how it should work, the connecting peer just allocates a high service port for a connection (called ephemeral Ports based on IANA Recommendation set t o49152 to 65k in default).

I would not bother with this peer as you cannot eliminate these and the protocol should handle these kind of behaviours (if not then it is poorly designed and/or implemented, meaning not worth of using this protocol) by dropping them from any list (cold, warm and hot) and closing the TCP connection. Cos, this protocol is like HTTP meaning by that it should and would be constantly attacked from the Internet.

Sorry, typing on the tablet.

2 Likes