HN2new | past | comments | ask | show | jobs | submitlogin

It's actually proof that internet architecture in general is broken. Well, not broken; it was broken, and then healed in a weird way so there's extra cartilage sticking out causing annoyances and won't move as easily anymore.

The security industry has absolutely nothing to do with the existence of a botnet that can take down massive internet infrastructure. The security industry just puts bandaids on shitty products. It's the internet architects/designers that are responsible for botnets.

In order to make the internet very simple, very compatible, and decentralized and distributed, the design allows a baby monitor to send arbitrary traffic to any device on the global network. There is no good reason for this. The reason is, anything else would be complicated, and complicated things become expensive and troublesome. But that's not a good reason to allow baby monitors to take down internet services.

The solution would be to segregate critical equipment address and protocol by function, and to put in strict controls in all routers to prevent illegitimate traffic from reaching the wrong equipment. This would not only improve security, it would make allocation of address space and application ports make some kind of practical sense, and allow for improvements in the way applications communicate over the internet, to say nothing of improved management of traffic.

But nobody's going to change the design, so whatever.



The thing is, that's the opposite of the net neutrality world; it's the telco world, where the monopolist gets to segregate your traffic and charge arbitary prices for it.

I'm old enough to remember when UK modems had to be "BABT approved", adding considerably to the price. See (1993) https://groups.google.com/forum/#!topic/uk.telecom/6j1bVHcq1...


We already know what customers are sending what traffic to what providers; net neutrality is purely a political thing, there is nothing technical stopping it. Baking the differences in traffic into the address space and protocols would just more clearly define what we already define very loosely with things like port numbers and loose firewall rules.


What "differences in traffic" do you mean exactly? Who gets to decide them - that's a political thing, no?


Traffic in general can be (roughly) summarized as application, infrastructure, and signaling. On top of this, it's clear that different address space is used by different organizations for different purposes. Classify the traffic based on these differences and carve up address space to suit the differences, and perhaps differences in the transport protocols that match the practical differences in how the traffic is used.

For example, bgp traffic shouldn't work on non-routers. Certain signaling (icmp and udp traffic flags for non-peer traffic) isn't needed by most customer equipment. And it's stupid that IP spoofing works at all, much less on robust servers on internet backbones. It's clear there is traffic allowed on parts of the internet it shouldn't be allowed on. Changes could be made to correct this, and no, they are not political.


None of those examples are relevant to the Mirai case, though? I don't think it even relied on IP spoofing. It was just an enormous HTTP flood.


.....source? They hit a DNS provider, and the bot has a dozen different capabilities. In any case it doesn't matter, DoS often relies on spoofing and the attack still stands


How do you tell illegitimate and legitimate traffic apart?

In many cases the only difference between a DDoS and normal operation is the volume of traffic at the victim host.


I'm not sure, but like I said, separate first by address and function. This could work a hundred different ways. I could give examples but they'd be off the top of my head and not properly designed.


I'm sure you could come up with a hundred different improperly designed ways off the top of your head. And it wouldn't work.

And trying to design it properly, you'd probably come to the conclusion that it won't work (without causing massive disruption and breaking everything we've built so far).


Causing massive disruption is what I'm proposing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: