A serverless antispam network topology

There are a lot of solutions proposed to solve the spam problem. Most of them, however, were nowhere near the goal.With one exception: the group of solutions that empower the spammed user to retaliate against the spammer.

The spammers met with indifference all other measures against them. The reaction against this group, however, was instant and aggressive. Remember the famous Lycos screensaver, or The Blue Frog projects? Spammers spent a well of efforts and money against them – hired lawyers, bribed officials and key personnel, rented botnets to mount DDoS attacks… Thus, they acknowledged that this measure scares them. And it does because, unlike all others invented to the moment, it was going to be effective.

All these projects shared a weak point – they relied on central servers. The spammers immedially identified this to be the weakest link, and attacked exactly there. The attack against the central servers proved to be invariably lethal.

The Okopipi project now attempts to continue this work. Unhappily, it has the same weakness – it is based on central servers. This time, the servers will stay hidden – but until when? To be of any use, they will have to surface in some way, directly or through some gates. And these outlets will quickly meet their fate – the spammers will find them before the ordinary users do, and will take them offline.

The only solution to this problems seems to be a serverless network topology, where every retaliation client is also a server that gives connectivity to the entire network. A good example for an appropriate network topology is the Kademila concept.

This concept is used until now mostly in file sharing networks – Overnet, Kad Network, newer versions of Azureus, etc. It has proven to be flexible and balanced the load extremely well. If nodes are taken down, eg. due to a DoS attack, the others re-knit the network quickly. And if the attack is moved against new nodes, the old ones spring back to life, and restore the network again. For example, when the main server of the server-based eDonkey network – Razorback2 – was taken down, it took several days for the network to reappear again. Its Kademlia-based overlaying protocols – Kad Network and Overnet – were practically unharmed. An analysis shows that one would have to take down more than 95% of a Kademlia-based network to impair its functionality. (This is valid for a network with 1000 nodes – a network with 10 000 nodes will be still knitted even if 99% of the nodes are offline, and will be able to re-involve them in less than an hour.)

For this reason, I would propose to make the client part of the antispam retaliation package able to connect not only to a central server, but also peer-to-peer through a Kademlia-based protocol – or entirely through it. This would make this antispam retaliating network practically indestructible – the worst nightmare of every spammer.

To stay ahead of the DoS atatcks of the spammers, such a network will best start with at least several thousands of nodes, by publishing their list at as many places as possible, at the same time. The spammers will attack quickly, but taking instantly down all these nodes is not realistic. And meanwhile new people will join, and add new nodes. Given the popularity of the subject, I’d expect that the number of the nodes will exceed 200 000 on the first day, and one million at the end of the first week. Destroying so large Kademlia-based network will be beyond the resources of anyone.

Creating such a client will not be a big problem. If it is free software / open source, licensed under GPL, the programmer(s) will be able to use a vast pool of GPLed code. For example, the Kademlia connectivity may be taken from the sources of eMule. A good coder will be able to implement all basic functionality needed within a week; a month of work will yield a stable, cross-platform product.

A good product will require more work. For example, a PKI abilities will be essential for the product updates and the passing of information about spams sent. But, still, a group of developers should be able to deliver such a product in a couple of months. A good security audit will take more time, and is absolutely essential – if there is anything that the spammers would seek to compromise, it will be this product. But, still, it is within the abilities of an antispam group of enthusiasts.

Once the app is ready, it can be distributed among friends, until the desired starting number of nodes is achieved. Also, at this time it will have to be uploaded to as many servers as possible, either without a description, or under a negotiation with the server admins to unveil it at a given moment. When the moment comes, the full list of all the nodes should be published at as many times as possible, in order to keep it accessible, too. Periodically, lists of new nodes may be added, too.

The spammers will quickly realise that fighting the problem electronically is impossible, and will try to do it legally (or, at least, to scare the potential users). So, a good legal preparation will not harm the idea. Another ways of fighting may include sending a lot of fake spam about legitimate sites, so the client app should either require manual approving of spam, or support whitelisting, or both.

Finally, do not think that such a network is a solution to all the problems. One could use it, for example, to mount a DDoS attack against an e-shop that refuses to pay a racket, by sending fake spam about them. Other illegitimate uses are possible, too, and probably will be made, both for a profit and to discredit the idea. But if the main source of funding for the spammers dries up, they will have less and less resources to do mischief.

And the world will be better. 🙂

Leave a Reply