The DDoS attack against DNS provider Dyn on October 21st (though relatively brief) gained a lot of public attention because it took down some of the Internet’s most popular websites weekday. The forensic details of the attack were available almost immediately: the Mirai botnet leveraging tens of thousands of IoT devices (e.g., CCTV cameras, DVRs, etc) generated an IP death-ray that may have exceeded 1.2Tb/s at times and that was pointed at Dyn’s managed DNS platform.
That DNS can be the achilles heel of any network service isn’t news to anyone who’s spent more than an hour troubleshooting said services. And the DNS-based mitigations, if not total solutions, to such attacks are as arguably prosaic as the attacks themselves are dramatic. As stated by our own DNS boffin Cricket Liu: “Build in redundancy. Many companies rely on a single DNS provider like Dyn, leaving them vulnerable to attacks. Instead, businesses need to either deploy some on-premises appliances that can serve as external authoritative name servers – the servers that advertise their DNS data to the Internet – or bring in a second DNS provider. This is no different from ensuring that your company has redundant connections to the Internet.”
But even with these reasonable measures taken to protect DNS, the IoT devices themselves remain largely unsecured. In the case of the Mirai malware, basic password dictionary attacks against IoT devices using telnet suggest that even the most basic security measures applied by device vendors or consumers could reduce the number of vulnerable devices and thus, overall volume of such attacks. This of course is easier said than done. Network security analyst Bruce Schneier compellingly argues that the results of poor IoT device security is an externality for both device users and vendors and that some form of regulation will be required to fix the problem.
But where does IPv6 fit in to all this? This is, after all, an IPv6 blog and we can all be excused for a Pavlov’s-canine-like response to any mention of IoT with the query “Whither IPv6?”
As repeated ad infinitum (ad nauseam), IoT and IPv6 are inextricably bound by necessity: the predicted 20 billion-by-2020 IoT devices will require IPv6 to connect to the Internet. The economics of IoT for vendors suggest that security will continue to be an afterthought for IoT devices unless regulation happens. The introduction of IPv6 to this equation complicates this picture, implying an ongoing crisis with neither IPv4 nor IPv6 properly secured. But it also underlines an opportunity: It is, as Homer Simpson once trenchantly put it: a “crisitunity”!
First, the complication. The same lack of economic incentives that discourage IoT vendors from building robust security features into their IPv4 devices, discourage them equally in IPv6. In fact, it may prove cheaper to exclusively build IPv6-only devices. Given that IPv6 traffic levels exceeded 50% among US mobile carriers last year and that predictions are for a majority IPv6 Internet by 2018, vendors and service-providers will be under tremendous pressure to save money by limiting the amount of money they spend supporting IPv4 features and services.
An IPv6 Internet means of course that DDoS volume won’t vary much based on the address family being used to launch the attack. It also remains to be seen whether many of the IoT devices coming online to support an Internet of Everything will be a) directly connected to the Internet (as opposed to behind a gateway — and implying an entirely different if not more sanguine, security story), and b) sufficiently resourced (e.g., power, bandwidth, processing) to help sustain future DDoS attacks.
But regardless, in the interval before and during the impending manifestation of an Internet of Everything (with all the risk that implies for a Hobbesian world of endless DDoS attacks directly impacting life-or-death services that are now more-or-less safely isolated in meatspace), IoT vendors and users have an opportunity (not to mention responsibility) to assess how the security posture of their IoT devices can be improved and/or purpose-built. This obviously includes basic stuff like password security and closing commonly exploited TCP ports. But it also includes leveraging elements unique to IPv6.
For instance, the enormous address space of IPv6 prevents the smallest legal unit of subnetting, the /64 (with 1.8E19 addresses!), from being casually scanned in the same way IPv4 can easily be. In fact, as Geoff Huston pointed out in a blog post about IoT last year, using a publicly available, open-source tool like Zmap it would take less than 5 minutes to scan the entire IPv4 address space. At a million addresses per second, scanning a single IPv6 /64 would still take more time than the age of the universe.
To be fair, deriving security from this or any other facet of IPv6 goes beyond any single vendor or user but now is the time to begin to collaboratively and collectively addressing this looming technical and security debt. While it’s not entirely clear what combination of purpose-built features and deployment practices will best secure tomorrow’s Internet of Everything, attacks like the recent one on Dyn are proof that such collaboration is already overdue.
