Updating the xx network to protect against DDoS attacks (and an urgent xx

Please use this thread to discuss the Updating the xx network to protect against DDoS attacks blog post


I’m sorry for what I will write but you just can’t protect ISP/DC customers with “software” when a “true” DDoS attack occur.

They are only one way for mitigate an attack => having more bandwidth than the attackers

Some attacks now reach hundred of gb even datacenter can be shutting down. It’s what happen to protonmail. You can read that here : Update regarding the DDoS attack - ProtonMail Blog
Way found for mitigate this DDoS : add another physical fibers cable for link this datacenter and redirect a part of the traffic to another physical fibers probably because can manage BGP routing.

You have another big attack on OVH here : https://twitter.com/olesovhcom/status/778830571677978624
You have an explanation here : KrebsOnSecurity Hit With Record DDoS – Krebs on Security

The issue with this network even with 550 nodes it’s than a huge bandwidth attack example ~500gb/s can be shared at ~100gb/s per 100 nodes and use only one small part of the TCP request (attacker side) for just overflow network connections of all of these nodes by using 0.01/1s at 100gb/s bandwidth per gateway with 1gb/s home connection you need 100s for just received these packets and reply/drop them. Gateway not have enough bandwidth and can’t reply/block all packets and just not have enough free bandwidth for process other “legit” traffic. The list of IP:Port is public so a bad guys can just take this list and saturate link whatever what you do from software you can’t increase bandwidth for manage this type of attack.

I just not have enough knowledge in this domain but a DDNS at home isn’t a so bad idea for my point of view. If you have this type of issue you reboot your router for ask a new public IP and change your DDNS name. The attacker should refresh the list for attack this new ddns.
People inside a DC are may be lucky and have an efficient DDoS protection from their provider and mitigate these attacks before reach their gateway but like you can view some years ago was not so much efficient. And look the bandwidth back in 2015/2016 I let you imagine now when some private have 10gb at home on fiber :confused:

So it’s good to improve software but you can’t do so much about some type of DDoS attacks.
May be someone with more knowledge can give you a way for protect the network against that. Enterprise seem all using Akamai/CloudFlare or these types of service for protect their website but not know if we can use this type of protection for the entire network and cause a single point of failure too :frowning: (that’s not good for a decentralized network)

1 Like

You are correct in general that the only way to protect against a DDoS attack is to have more bandwidth than an attacker.

We are not trying to protect against a general case DDoS attack here though.

Our goal is to stop an attack which is submitting cMix messages and filling all batches, which this does not protect against. Without this protection, filling all batches is trivial, far more trivial than a generic DDoS attack.


Good points about DDoS, but that indeed is a separate matter which every gateway needs to solve and as @warnings says, it ideally shouldn’t be shared by too many nodes. So it’d be fine if that was in place separately and if 20% used DIY approach, 20% CF, 20% Akamai, 20% ISP, 20% hyperscaler…

Problem statement describes only gateways and app-level DDoS:

This is a particularly difficult problem, and solutions like mini proofs of work on send seem to work

I think the approach is good for that layer. Below, and before that, node runners could apply other approaches and the less prescriptive about that the project is, the better.

My hosting provider has their own anti-DDoS service. It’s inexpensive and probably crap, but if each is crappy in its own way that should still help because in the case of an attack that exploits one weakness, only a minority of the nodes would be affected while simpler attacks should be survived by all.

1 Like

Nano currency is feeless and because of that faced some attacks like the one we are trying to mitigate… From what I’ve heard, they used a PoW solution as well, but looks like they were evolving it. There is a good read in here about this topic. Great move from the XX team by looking for solutions regarding the free tier messaging exchange!!

1 Like

I had a look at my GW server Provider (Contabo) and they do have some built in DDOS protection for all servers they host. This is the link. Although im sure its not perfect, they do say it will filter nearly 99% of all DDOS attacks. Not sure what the other providers offer but something is better than nothing and when all these protections are paired together I think we are off to a good start. Ill link the Contabo page on DDOS protection Here:

Hetzner info on DDOS protection is here:


As there are multiple layers in the OSI model, so there are multiple levels where you can/should implement a DDoS mitigation solution, you cannot compare apples with pears (layer 2/3 DDoS protections with layer 7 DDoS protection).
Having a DDoS protection at the application level makes absolutely sense (and it’s the only layer where it makes sense for xx network, given that it cannot control our networks), what I don’t like very much is basing it on the IPv4 scarcity. It’s already a shame that it doesn’t support IPv6, and this will make its support even more difficult.
Also I’m not sure if sharing the IPs will have some impact on the metadata privacy.

1 Like

Good idea about leaky buckets. However, I was also wondering about the privacy aspect and what happens if many devices are connected to the same network and share the public ip (eg. Students in university etc…).
Can the IPs be hashed before gossiping?

It will definetly be an issue for students, there will need to be a system to allow increased bucket sizes for certain IPs.

As for hashing, it is of little value. IPv4 addresses are have 32 bits of entropy. A dumb table of all hashes would only take up 128TB of space, trivial for a sufficiently motificated attacker.


Now that the update has been pushed out: about the word “urgent” - what made it urgent?

It’s a given that XX nodes will be DDoS’d, so no doubt the sooner we can better handle those, the better.

the xx messenger is about to launch, with a significant marketing push behind it. With this vulnerability present, someone could have easily and cheaply made the xx network unavailable. We calculated that before it, for ~$100 USD a day someone could saturate the network. It would have been a big blow to the network if someone did that during the launch.