Policy of "Outgoing Only Node" vs "Full Duplex Node"

The “OON / Outgoing Only Node”, is a node with a private address (behind NAT) or with a public address but uses a firewall and more generally refuses incoming connexion.

The “FDN / Full Duplex Node” is a node that allows both incoming and outgoing connexions.

If the Cosmos Hub has too many “OON” attached to a small number of “FDN”, then it’s easy to break the network by focusing on the “FDN”.

The problem is that it is easier to deploy OON for AntiDDOS solution, which reports the risk on other FDN. There is currently no incentive for Validators to deploy FDN, and that’s a problem for a public network.

I think validators should publish a minimal number of FDN.

I am not sure what is the best way to incentivise Validators to run FDN. It could be a social thing in the front-end (e.g. computing uptime % taking only FDN into account) or maybe we could try to incentivise FDN directly in protocol. Opening this subject to discuss the best way forward.


A few thoughts without conclusions:

  • Infrastructure is a frequent target of DDoS attacks. Outgoing only sentries expose their public IP address to the network when they make outgoing connections. Once any outbound connections have been made, firewalls, routers and other infrastructure become vulnerable, even if the sentry can’t be directly targeted.
  • A malicious node could accept inbound connections from outbound only sentries, and once that TCP connection is open, gaiad is in two way communication with the attacker. gaiad is vulnerable to exploit even on outbound only nodes.
  • A distributed network of sentries on multiple platforms, with sentries being added and removed frequently, which do not identify themselves as belonging to a specific validator, and with diverse routes back to the validator will be difficult to successfully DDoS.
  • Private peering arrangements between validators using private sentries, using either VPC peering or direct private links (SDN most likely) reduce the incentive to DDoS attack a validator, even if their public sentries can be identified. If the validator’s private links will keep it online even through a highly successful DDoS attack, what’s the point of expending the resources to marshal the attack in the first place?
  • Validators are vulnerable to compromise in the same way that other infrastructures are. The relative ease with with a validator can be fairly well secured against direct attack from the public internet points to other attack vectors. Social engineering, spearfishing, access via backdoors or out-of-band management interfaces, desktop or mobile exploits, etc… are just as likely if not more likely that a “frontal” attack on sentry infrastructure.
  • Compromise of loss of a validator’s private key is potential fatal to the validator.
  • One concern is that large and well funded validator operations can afford the infrastructure and professional staff to harden themselves, which may redirect attacks to smaller validators who are less able to defend themselves.
  • Validators likely have incentives to attack other validators. It is well worth considering the game theory here, and that incentives for validators to co-operate do not all go one way.

No conclusions, just some thoughts to chew on. Looking forward to other’s thought on this topic.


From the research I’ve done, this seems like the best approach to Sentrys I’ve come up with. Along with this, each Sentry would have a public IP so they are all communicating on different IPs. If you did this on an internal network where they all leave a NAT or Firewall, then you still have a single IP to attack, like you mention in a previous bullet point. If you have a large fleet of Sentry Nodes that have their own IPs across a geographically diverse area, then DDoSing one is basically pointless. It wouldn’t really affect a Validator.

By this comment, are you referring to having a fleet of Public Sentrys, fleet of Private Sentrys (Relay Nodes), and a Validator? In this scenario, do your Private Sentrys peer only to your Public Sentrys? If that’s the case, if all your Public Sentrys got DDoSed, then you Validator would go offline, right? Does this just add more complication and reduce performance? I’m trying to understand the need for Relay Nodes at all…

Why is this? Are you meaning a Validator could attack another to simply discredit that other Validator (and therefore getting users to Delegate to them instead of that other Validator)? Or do you mean to attack another Validator to steal their Steak and delegate it to yourself?

Each public sentry should have it’s own public IP. This is easy to accomplish on AWS/GCP and I assume on other complex cloud platforms as well.

Good question. I’m not sure that there is a need for two layers of sentry. I’m experimenting with this architecture. You could also have a single layer of sentry all of which peer with your validator, with some of them dedicated to private peering relationships. In this case, a private sentry / relay node is identical to a regular sentry, other than who it peers with.

I think that having private links to other validators that are not vulnerable to DDoS from the public internet will improve resiliency. However, I think these private links present a centralization risk, if establishing such links results in private clubs or cartels, and a risk of cascading comprise if the links aren’t carefully managed. In a best case, I think there would be many private links, and but few in common. The network topology gets complicated very quickly, I haven’t thought about it enough yet.

A validator might be motivated to discredit another validator for financial, strategic, or social reasons. There could be validators with financial reasons to want Cosmos to fail, and operate on Cosmos for the express purpose of causing chaos. An honest validator could also be compromised, and if you have trusted links to that validator, this would present a weak point. I think it’s a good policy to consider everyone to be potentially hostile in crypto. :slight_smile: