Denial Of Service Prevention.

Community Bar Sport
1

For a while now I've been (just from thinking about it every now and then) working out a system that could make Denial Of Service attacks a thing of the past...

Remember Limewire? (I think it was called that) the system relies on 1 working IP address and a P2P system...

Now the easiest way to explain how this concept works is kinda simple, we stop using Dedicated servers and move to a P2P system for websites, 10 - 15 years ago, the end user (us) the vast majority of us were limited to upload speeds as slow as dialup, and now pretty much everyone has a min 512k - 1mbit upload speeds, with a lot of users 50x faster than that..

You run this application (no name for it yet) and it simply tries to connect to all the known/working IP addresses, if the IP address has gone offline, after say a week, it will retire the IP address and put it down as dead server, and every other week see if it's back online... if you have no IP addresses, hop onto google.com look for (name of app) working IP addresses, people could put them on static IP servers, or just a little box of the most active IP's using this p2p network..

still with me?

Once the Entry Point has been found (just 1 of potentially millions of IP addresses or googled for a working one) if the connection is valid, the server they link to will automatically send all of it's known working IP addresses to you, and then you'll pass on those working to others and they repopulate working IP's with others and so on..., and even though everyone does not directly connect, data will be daisy changed between user hosted servers.

Dead or gone Servers IP's all get sent via P2P (this could be your IP or my IP or someone down the street) to notifiy other clients connected to this network... now if you're still not confused by the way Servers are found and populated (hell place your IP address on A4 paper and pin them up it would work , as all the other user does is add you, and your working IP's will be shared with them)

Now the fun begins...

Once you have a Valid working IP address, your client (imagine, utorrent, bittorrent, atorrentofsomekind) will then populate it's database with websites, for example Arduino.cc could be hosted as a compressed/archived file or the equivalent 'torrent' file is created with the contents stored in folders, even maybe encrypted.

This client runs, and it will list all of the known Servers, "Add website" point it to the folder, create the what needs to be done and everyone on this P2P network will now begin to populate 1 website to everyone, now for example when the program runs a list of websites may appear.

[arduino.cc]
[joeswebsite.com]
[FoolMe.foo]
[etc.]
[etc]

Bigger the system the more websites can be held, to access these sites all one does is double click on the link it opens in a browser, if you make a modification the modification is sent out to everyone else connected.

Pros.

No more DOS attacks, it's simply not possible unless you attack every IP on the P2P network.
No more Spying (as the data could be encrpyted) by the NSA
No more "down time"
No more "fees"
No more "DNS"
Free for all to use
Secret Websites, Password Driven.

Allows countries in war torn zones and places under communism to freely access any site they want and share data.

Essentially everyone becomes a webserver, it also allows anyone to create a website for free to use by everyone else for free.
If it got successful, categories can be made, sub categories, etc etc..

Cons.

You would need the p2p application (or Portal) to access these sites.
1 IP required to find to connect to the network (Which would still rely on DNS servers, search engines)
Potential for abuse... eg running an underground website to sell illegal things on... (Silkroad springs to mind)

It would be one hell of a project to take on, but I could see a lot of potential, and so far P2P has been mainly used for illegal downloads but because this system is 100% legal, there really should be nothing, absolutely nothing to stop You and I from hosting one of these servers...

Apart from the Logistics, how it works (how's it populate data between P2P) ... how's the general Idea sound? :~

2

it simply tries to connect to all the known/working IP addresses

If everyone does this you do not need a DDOS to break the net

@cjdelphi,
please make a calculation of the increase of traffic e.g. based on the statistics of this forum.
and do not forget to calculate the synchronization between the servers

If this was a solution, all companies would have worked with it already ...

3

I did not just explain precisely how it works.

And no.. it would not cause a dos attack any more than any other p2p network already in existance...

And again, just because you've not alrady seen it done, does not mean it won't work....

Enough ignorance and closed mindedness please, unless it's been done it's not worth doing because with that narrow minded attitude you'd still be living in a cave.

4

I did not say your idea will not work, in fact it will work, 100% sure.

My worries are the price, to start with the additional bandwidth that is used. And no, bandwidth is not free (even if it may appear so).

All I asked was to make the math involved, and you can simply calculate (within certain precision) how much extra bandwidth is needed. Things that can be calculated to see what impact they have should be calculated. That has nothing to do with narrow mindedness, but with an professional attitude. It is very easy to throw up ideas, it is much harder to proof they will work and under what conditions.

If you want your ideas to be taken serious you must provide good, verifiable arguments. No capital venturist (or how they are called) will invest money in "a good idea", it is all about the quality of the arguments. And they are among the most open minded people I know as they know you must go beyond believe to make money beyond believe.

I will make a simplified calculation so you can improve on that.

Suppose you have 1 server with 1.000.000 users that visit the server 10x per day to read something and 3x per day to write something.

That means

  • 10.000.000 read requests per day. => 20 M packets (assuming it can all be in only one forth back session)
  • 3.000.000 write requests per day => 6 M packets (idem)
    total 26 M packets.

the server gets split over 10 servers to reduce the load.
Assuming every client knows the IP address of its nearest host (in fact a DNS-round robin algorithms takes care of that)

same load

  • 10.000.000 read requests per day. => 20 M packets (assuming it can all be in one forth back session)
  • 3.000.000 write requests per day => 6 M packets (idem)

but because we now have 10 servers, these need to synchonize
scenario 100% replication

  • 10M reads => no need to synchronize
  • 3M writes => every write needs to be send to 9 other machines. => 27M writes

total 26M + 27M ==> 53M packets needed, effectively doubling the load on the network.

scenario 10% replication

  • 10M reads => no need to synchronize
  • 3M writes => every write needs to be send to 1 other machines. => 3M writes

total 26M + 3M ==> 29M packets needed, => increase of 12% network

scenario 30% replication

  • 10M reads => no need to synchronize
  • 3M writes => every write needs to be send to 3 other machines. => 9M writes

total 26M + 9M ==> 35M packets needed, => increase of 34% network

In short, the total amount of network traffic increases and depending on the replication percentage it may increase fast.
Of course if you change the numbers different percentages will appear (spreadsheets are very good at this).

The math above is simplified, (assumption) a more realistic model will be more than twice as worse. (not taken into account Hofstadter's law)
2) it does not take into account the extra costs for maintaining multiple servers, etc.

5

PS,
let your ideas coming, See also - The Eight Irresistible Principles of Fun - YouTube -

Edison needed hundreds (thousands?) of tests before he had the first acceptable wire for his light bulb.

6

I figured the torrent model is a good model...

Not every packet needs to be fowarded on, just the virtual websites being hosted, you could connect to 20ips who all host the virtual domain, I understand your concern with the traffic I'm sure there is a solution for example when loading the website you download what you need from multiple sources... you would never need to connect to an ip that does not host that virtual website so you'd never request it unless you wanted it...

Take the black box, an Australian approached an airline with his blackbox and nobody wanted it...

If the packets which were fowarded were short or maybe compressed and sent, there are a lot of clever programmers out there, I'd like to see what can be done... no more down time, if a website was infected for example, under p2p this could be prevented (I think)

7

You're definitely not the first to propose a p2p web server/hosting/browsing solution; in fact, if you google "p2p web" (along with "server"/"hosting"/"browsing" for further narrowing of results), you'll find more than a few announcements and implementations. While I didn't read your entire post in depth, I am almost certain that most of your ideas have been explored or implemented in one form or another. I am not dismissing these ideas, btw - just expressing that while they certainly have merit to them, they are (and have been) explored in the past and present.

8

There are a lot of reasons why this isn't done.

As Rob alluded to, if the website is anything but static (meaning its content can by distributed once, and it remains current indefinitely), there's a lot of resulting synchronization traffic. Worse is what happens when the sites are not perfectly synchronized. (Ask any database administrator how much they like dealing with replication. Or systems administrator, regarding Windows DFS.)

More to the point, websites often maintain statefulness. That is, logins/passwords, content databases, that sort of thing. Cookies maintain some of the state on the client side, but often as not it's just a pointer to data stored server-side. If connections move from server to server randomly, maintaining statefulness becomes incredibly complicated. For one of many reasons why, consider the primary key of a database table. (Many, many websites rely on a database. Like this one, for instance.) The primary key will often be an integer "id" field that must have unique values. It's common to ask the database server to automatically increment this field every time there's an insert. This lends to the concept of a "master" database server. In a P2P environment, which is the master? Who maintains the definitive id column? How do you handle inserts that happen in parallel at different sites, which end up using the same id? There are solutions to this problem, but the easiest is to not have this problem in the first place.

Then there's HTTPS, which requires certificates that rely on the IP as part of the site's identity. Change IPs and the certificate is no longer valid. Remove this requirement, or allow "member sites" to join arbitrarily, and how do maintain security, privacy, accountability, and trustworthiness?

Furthermore, your proposal might relieve the effects of a DDOS on a target website, but it doesn't relieve the burden of malicious traffic on the providers. Your proposed solution actually makes that worse. Think about all your neighbors with broadband access. Then scale out to the rest of your city. And the rest of your state. Country. Continent. Planet. That's a lot of aggregate bandwidth. At some point, you end up limited by how fast you can make transceivers (10Gb Ethernet modules exist and are widely deployed, but they're not cheap!), or how many you can parallel (which requires sophisticated controllers to divide the traffic among participating interfaces.)

By far the best way to resolve this is, with sites of any significant popularity, to offload the static content to regional content servers, thus localizing the bandwidth demands, and keeping that stuff off the really big, and really busy, data trunks between geographical areas. And, as it turns out, this is already being done. By (e.g.) Google, Amazon, Akamai...

Ultimately, there's only one way to prevent DDOS attacks. (See attached image.)

internet-hole.jpg