The Internet of Things (IoT) has been indicted for its involvement in some serious incidents lately.1 Smart TVs, DVRs, and World Wide Web-connected cameras have been named as sources in some of the largest distributed denial of service (DDoS) attacks to date.2 But what exactly are the things, or class of devices, that comprise the Internet of Things? These things are devices that are (1) designed to be dependent on the Internet, where such a device would not have depended on the Internet previously, and (2) rapidly manufactured, homogeneously configured, and deployed across the Internet. From an engineering and operation perspective, these two aspects are important. IoT devices are not merely personal electronics equipment. Instead, IoT devices involve Internet resources by design. In addition, we usually are not informed about the arrival of new kinds of hosts on the Internet. Due to the quick and ongoing arrival of so many homogeneous devices, the IoT presents performance, reliability, and security challenges that grow larger and faster than those ever seen before.
The IoT raises a number of questions for our community: How big is the Internet of Things? What is its scope? How can we check?
There are two ways in which IoT is currently unchecked. First, we largely haven’t measured the IoT. How many devices, and of what sorts, are there? At what rate is the IoT growing? What is the lifetime of an IoT device? And second, what standard engineering and operational practices would limit its performance, reliability, and security impacts?
We’ve only begun to answer some of these questions and direct ourselves to address nascent IoT challenges.
A 13-Year IoT Case Study: 2003 to 2016
The challenges presented by IoT devices is not wholly new—in 2003, an accidental IoT DDoS involving hundreds of thousands of Netgear devices was deployed throughout the Internet. These were IoT devices in two ways:
- While switches and routers did not previously depend on the Internet, per se, these were built to synchronize their clocks with a Network Time Protocol (NTP) server located at the University of Wisconsin–Madison. The Internet Protocol (IP) address of the NTP server is hard-coded in firmware.
- In only months, hundreds of thousands of these devices were manufactured, sold, and deployed worldwide.
Figure 1 shows the Netgear model MR814, manufactured circa 2003. It is one of the four Netgear device sources that were implicated in this accidental flood of traffic.
These devices’ SNTP client implementations had design flaws that caused them to query the NTP server once per second until receiving an answer, occasionally resulting in an accidental flood of hundreds of thousands of packets per second. Because the situation was discovered before peak device deployment and the flawed devices continue to operate even today, it represents a unique IoT measurement opportunity. With the help of my colleagues at the University, we plotted the estimated number of flawed SNTP clients observed utilizing the University of Wisconsin NTP server from 2003 to 2016. Figure 2 shows the arrivals (2003–2004) and departures (subsequently) of these devices, over a period of 13 years, ostensibly representing the births and deaths of these IoT devices. About 700,000 total devices were manufactured with the flaw that was ultimately removed in 2003.
These measurement studies indicate that some IoT devices have a very long lifetime and that neither a linear nor a simple exponential decay model quite fits empirical observations. Some IoT devices clearly live longer than a decade, leaving many thousands of users and networks encumbered by flaws.
This incident resulted in a number of engineering and operational recommendations3 delivered as best current practice in RFC 4085 (BCP 105)4. For more details on the Netgear incident, visit http://pages.cs.wisc.edu/~plonka/netgear-sntp/ or see the paper, “The Internet of Things Old and Unmanaged”5.
Checking IoT Today
The Internet Architecture Board (IAB), the IETF, and the Internet Research Task Force (IRTF) each have current initiatives in the IoT space. For example, the Internet of Things Software Update (IoTSU) 2016 Workshop considered how one might best tackle the code and configuration changes to IoT devices and reported its findings6.
As for measurement of the IoT, the IRTF’s Measurement and Analysis for Protocols Research Group (MAPRG) has called for any measurements of the IoT, past or present. And the aforementioned case study was presented and recorded7 at the MAPRG meeting during IETF 96 in Berlin, along with some discussion about requirements that might drive IoT measurements.
Developing IoT measurements raises a number of questions: What real counts or other metrics of IoT devices are available? Who are the stakeholders? What kinds of measurements are possible? What are the privacy considerations? And how is IPv6 involved?
With respect to stakeholders, there are many. Manufacturers will presumably want to know how devices travel the supply chain and become active and then not active. Service providers may wish to manage IoT devices and perform risk assessments. Device users, owners, and customers will likely need to discover or find lost devices and audit premises, perhaps to inform insurers or subsequent buyers about IoT devices that, for instance, run a home.
With respect to kinds of IoT measurements and what’s possible, there are World Wide Web User-Agent strings and Ethernet media access control addresses that help identify some IoT devices, but these can be spoofed or obscured. So questions remain: can IoT device identities be authenticated and what features are feasible to measure IoT device uptimes or determine lifetimes?
Lastly, there are privacy and operational implications to IoT measurement. Can privacy or anonymity requirements protect IoT users from being victimized? If IoT devices are long-lived and, as many do today, choose not to use IPv6, they present a very significant increasing challenge in address exhaustion, in IPv4, and relief, e.g., via IPv6.
The unwanted traffic and vulnerabilities that result from IoT flaws warrant the special attention and concerted efforts of the research, standards, and operator communities. Leaving the Internet of Things literally and figuratively unchecked exposes the Internet to an unprecedented scale of performance, reliability, and security problems foreseen a decade ago, yet still, apparently, unavoided.
Footnotes
- http://thehackernews.com/2016/09/ddos-attack-iot.html.
- http://arstechnica.com/security/2016/09/botnet-of-145k-cameras-reportedly-deliver-internets-biggest-ddos-ever/.
- https://tools.ietf.org/html/rfc4085#page-4.
- https://tools.ietf.org/html/rfc4085.
- http://pages.cs.wisc.edu/%7Eplonka/iotsu/IoTSU_2016_paper_25.pdf.
- https://tools.ietf.org/html/draft-farrell-iotsu-workshop-01.
- https://www.youtube.com/watch?v=DkAS_Ht6J6U#t=38m50s.