On any sensible IRCd this won't happen. Users sneaking in during netsplits will be booted as netriders when the split closes.

CPU load is not the primary issue. SSL on IRC networks for client connections cannot assert that the communication is secure (for example, that all clients in a channel actually bothered to verify the SSL certificate properly). This issue will remain until client verification techniques such as DANE and DNSSEC are widely adopted on for IRC usage.

It's not true that this is up to the clients authors alone to do this work, and it's not fair for the users to tell them that you are awaiting client adoption of various technology, when the current Quakenet ircd implementation is currently incapable of even accepting SSL connections. Or at least it was, last time I checked.

Also, the DANE support in Irssi was announced in September last year and I have only heard of one network where some of its servers have adopted to this technology. Even though there is only one client that currently supports DANE+DNSSEC verification, we still need the (big) networks to start preparing for the support of it, and help us reaching the point where we can secure our user connections even better :-)

Having SSL on IRC, even without DANE+DNSSEC, is still better than having no SSL at all.

This is why I am disappointed that SILC[1] never got off the ground in the mainstream. It could have been an elegant successor to IRC.

1. http://silcnet.org

I blame the reference (server) implementation leaving so much to be desired. Primarily stability.

I tried running a silc server alongside my ircd for a while, but it never even reached a weeks worth of uptime without crashing (no matter if debian package, self compiled stable or devel, or some minor messing with the source).

Perhaps if a non-C/C++ implementation comes along..

No, it wasn't that. There used to be (maybe still is, I didn't check) a core group of reliable servers. I remember having a client idling on them for weeks without reconnections.

What was missing, I think, was lack of client development and adoption. There was default CLI client which was a weird fork of Irssi, then there was plugin for Irssi, and not much else.

There were of course few small client projects, but few of them got past early alpha stage.

It still helps in the "coffee shop wifi" scenario. I'll take my defense in depth, thank you. =)

Most DDoS attacks directed at IRC networks are not government related. IRC networks have a long and proud history of being one of the most DDoS-prone targets on the internet.

For this reason many hosts disallow IRC in their ToS

To my understanding to take down an IRC server doesn't even need to be a DDOS (Distrubuted Denial of Service) AKA multiple of computers and connections. One good DoS (Denial of Service) AKA one computer one connection, is all it takes to take it down.

Those are easy to block with a firewall policy. DDOS is the only way to sustain an attack.

It's a matter of bandwidth. If a single malicious actor can clog the the IRC server's uplink on the internet facing side of their firewall yes, otherwise no.

It's probably the case that lots of people try that, but unless the IRC server(s) are being hosted on their home network then I doubt one or two computers could bring a whole IRC network down.

According to the leaked documents, denial of the targeted users to communicate with each other.