How does a cardano node protect itself against flooding tx/DDOS?

Hello Developers of cardano nodes,

I asked this question on reddit, but didnt get a true answer.
If malicious actors flood the cardano nodes with small transactions (valid tx /invalid tx) how does a cardano node protect itself against the flood?

-Memory Limits? Dropping small TX in mem pool? / Dropping repeated transmitted TX?
-Hard blocking of connection, if too many wrong tx are incoming?
-Other countermeasures?

Thanks

2 Likes

The tx fees ought to minimize DDoS attacks. At a certain point an attack would just be too expensive.

I think tx fess only protecting the blockchain itself not the network components - any open port can be attacked with fake packets - so I think implicit protection not available - that is why relay nodes exists in front of the block producing node to protect it from DDOS. So even the relay would go off your producer is still alive - the question is - can block producer spread the block only on outgoing connections…

What if you are spammed with wrong tx? It costs nothing to create wrong tx and send it.
Or if you are spammed repeatly with 1 tx over 1.000000 times?

I hope there is a mechnism that protects nodes. Bitcoin was attacked a few times over the years, Cardano should learn from this.And i always read cardano is so well thought through. You can bring several nodes down, if there is no protection logic.

Lots of good documentation to read here: GitHub - input-output-hk/ouroboros-network: Specifications of network protocols and implementations of components running these protocols which support a family of Ouroboros Consesus protocols; the diffusion layer of the Cardano Node.

They have thought of the things you describe. There is way too much to post here but this is one of the many sections in the Network Design document: https://hydra.iohk.io/job/Cardano/ouroboros-network/native.network-docs.x86_64-linux/latest/download/1

9.2.2 Demand-driven protocols
Protocols are designed in a demand-driven style, so that for each node and each peer connected
to that node, the node controls the rate of data arriving, the maximum concurrency, and the
amount of outstanding data. This prevents an adversarial peer from mounting a resource
consumption attack: if it obeys the protocols, its ability to consume resources at the node is
bounded, and if it violates them it will be disconnected. Of course, initial connection requests
cannot be bounded by the protocol, but the rate at which they are accepted can be limited.

3 Likes

Ok, i read the paper and the chapters “9.2.2 Demand-driven” and “9.2.1 Validated forwarding” explain the design, that prevents DDOS. In short, if a node sends rubbish TX, the connection to the node will be closed. Before a node relays transactions, the header/content is checked against rules.

Whats interesting is the choice to multiplex mini protocols over 1 tcp connection. This saves ressources and is an efficient networking technique.

9.2.1 Validated forwarding
Nodes are responsible for the validity of forwarded messages. In particular, messages must be:
• well-formed syntactically, and
• semantically valid in the context of previously forwarded information from that peer
–Blocks in order on their chain Transactions
*in submission order
*compatible with UTxO and other recent transactions
If a peer fails to meet these requirements it is considered adversarial and the connection to it
is dropped.

Multiplexing mini protocols over 1 tcp connection
…at one end we multiplex by chopping up the data streams from the individual protocols intobounded sized chunks and interleave them on the single TCP data stream

2 Likes