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.

Thanks.

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,…

Excerpt (1194 of 2338 characters). Read the whole post on the forum ↗

mattharrop: • 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. 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. mattharrop: • 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,…

Excerpt (1198 of 2219 characters). Read the whole post on the forum ↗

gkrizek: 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. 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. gkrizek: 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… Good question. I’m not sure that…

Excerpt (1194 of 2812 characters). Read the whole post on the forum ↗