It strikes me as being somewhat dangerous to compromise open network/network neutrality rules in order to kick compromised devices off the Internet, never mind the fact that it puts the cost of security vulnerabilities on end users, who can't fix them, instead of vendors, who can.
This feels much like laws that already exist around Attractive/Public Nuisances. A compromised device DDOSing is interfering with others' right to be able to access the internet. The users themselves would in turn have much more impetus to seek remedies, legal or otherwise, to get the devices fixed because they'd then be without the ability to use devices they paid for. In a lot of ways, doing this would put more pressure on the manufacturer, because they would have much less room to wriggle out of their responsibility to ensure their device is actually usable.
It transfers the cost to vendors because their customer has an unusable product. Guess who they call first.
It's tough to defend the rights of citizens to have their internet-of-garbage devices stay online when those devices are turned into weapons of mass outage.
But in front of every compromised IoT device is a compromised router. Whose responsibility is that? I am going to say the majority of users down know how to update the firmware on their routers.
From the experience I have had with customer/technical support reps at cable companies for basic things like a service outage. I can't imagine them dealing with compromised devices and firmware upgrades or locating IoT devices in customer's home. I don't think they have either the staff capacity or sometimes even the technical skill to do so with any efficiency.
Then there's the potential for false positives or bad data where my connection get s null routed and I have to wait on hold for 45 minutes or an hour to talk to someone who may or many not know whats going on. Then I need to prove that there is no IoT device on my local LAN to a support person who might not even know what a mac address is. This just sounds like a mess.
in front of every compromised IoT device is a compromised router.
Why do you say that? AFAIK the devices being infected by Mirai use UPnP to expose themselves so the router probably has no responsibility for the insecurity. It would be great if we could build some sort of immune system into home routers and force IOT companies to pay for it, but that doesn't seem likely.
Short of mass-bricking these devices, any solution is going to be incredibly labor-intensive and expensive.
Sure but UPNP just opens up the outbound connection no?
A command and control connection for a botnet would still need an inbound NAT rule as would the ability to get the IoT device on the LAN in the first place compromise it right? Or am I missing something?
My understanding of UPNP is that it allows the router itself to become a discover-able device on the network. Then the IoT device connects to the router and adds a static port mapping from the router's public IP address on a specific port to the IoT's private IP address. The NAT still works as it normally does where any packets that try to leave the network get remapped by the router seamlessly. The danger in this case is the IoT device has a listening port on your public IP address, allowing attackers to connect directly to it through your router.
Requested responses 8 and 9 scare the crap out of me. I think those pretty much end open source software on the internet. Requested response 6 looks like a call for forced updates. I would of preferred a call for a rule that prevents cell providers from holding up phone updates.
8 and 9 specify manufacturers -- people selling something that connects to the internet. If you're selling, you should have to certify that you've done due diligence. If this is done through NIST standards being created, one of the side effects of this would mean that everyone would get actual guidelines, and almost certainly tools, which could do checking if a device is configured at least semi-properly. If anything, it would mean that vendors would have more impetus to communicate and send patches, because they would have to actually own their problems.
Yes, but even if your standard only states that manufacturers have to provide some sort of resilience to attackers modifying the binaries on the device remotely, I suspect many manufacturers are going to go with the simplest way: preventing any modifications save manufacturer-signed updates, and/or reducing user configurability of the device.
My feeling on this are somewhat mixed; on one hand virtually everyone who owns a modifiable device never makes any significant modifications and doesn't know how to properly secure it to boot. On the other hand, that means that even if manufacturers had no selfish reasons to put in such limitations of their own volition, the natural state for most consumer device markets is going to be to have no modifiable devices available for purchase just because making an unlocked version isn't worth it.
8 and 9 deal with manufactures, but could be used to stop non-manufacture open source. Its been a long time since Bell and I worry security will be used as an excuse to remove some competition.
You can do it (by that I mean NOW) with DHCP-PD (prefix delegation). Router asks for a range of addresses from the ISP which it then assigns to the IoT devices on the inside.
Devices tend to self-assign IPv6 addresses using SLAAC, but the router would still have MAC-to-IP mappings in its neighbor table. Or some cases the router assigns it using DHCPv6.
Just to clear things up for people unfamiliar with IPv6, the ISP does have some input in this process: they give your router a unique prefix (basically a subnet) which the router delegates to the devices in your network.
Parts of this letter sound informed, while other parts sound woefully misguided... I'm not sure I understand the point. What's Mark Warner going for here?
Humbly and without snark, what happened to scribd that has upset people? Is it just the non-standard PDF viewer or have they been up to something underhanded?
"Decentralization of core nameserving and smarter caching downlevel so that single modes of failure on internet name resolution doesn't bring entire swaths of the internet down" is what I was thinking.
Reflection (UDP) and amplification are problems, sure - we could address those as well.
This wasn't an attack against the root servers, so it's unclear what decentralization help. Should Dyn stand up two servers? That sounds like a good idea, but also something they can do themselves.
So a proposal here would look like: redundant resolvers with ISPs and routers failing and load balancing between them along with smarter caching strategies on the entire name resolution stack. Getting more academic and speculative with a “pie-in-the-sky” proposal that would remove both privacy and centralization concerns: quorum strategies over a peer-based, differential privacy protected authenticated database seeded by root servers.
The point here is that “IoT” isn’t the problem. Thousands of traditional servers can do just as much damage (or more) than thousands of IoT devices in a DDoS. You want to stop attacks that bring down DNS? Fix DNS. You aren’t going to be able to legislate away compromise-likely devices and services. That’s an imaginary solution, and likely to exacerbate other issues (IoT privacy).
I'm still not clear on how this is a solution. Attackers don't need to target DNS. With massive botnets, they can generate backbone-melting traffic --- which will look identical to legitimate traffic --- without the use of any amplifiers, and which will knock out any service they choose.
> What problem are we trying to solve?
The problem where DNS providers, such as Dyn, are taken down, leading to outages to large swaths of the internet.
> Why that problem next?
The recommendation to tackle this problem next is the topic of discussion. Namely, the DDoS letter to Chairman Wheeler.
The letter inappropriately confuses fixing this recent outage/attack on DNS with preventing IoT devices from being compromised. My proposal (the high level comment) is to fix the problem being discussed by fixing DNS (making it difficult, as a core internet service, from being DDoSed).
