The Internet of Things Unchecked

$Id: index.html,v 1.7 2016/11/04 10:59:45 plonka Exp plonka $

David Plonka

The Internet of Things (IoT) has been indicted for its involvement in some serious incidents lately. "Smart" TVs, DVRs, and WWW-connected cameras have been named as sources in the largest Distributed Denial of Service (DDoS) attacks. 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 that are (2) rapidly manufactured, homogeneously configured, and deployed across the Internet. These two aspects are important from an engineering and operation perspective. IoT devices are not merely personal electronics equipment. Instead, IoT devices involve Internet resources by design. Also importantly, we are not usually informed about the arrival of new kinds of hosts on the Internet. Due to quick and ongoing arrivals of very many homogeneous devices, the IoT presents performance, reliability, and security challenges that grow larger and faster than those seen before.

The IoT raises 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? 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. As evidence of this, an accidental IoT DDoS occurred in 2003. It involved hundreds of thousands of Netgear devices deployed throughout the Internet. One might ask, "In what way are these IoT devices?" They're IoT devices in two ways: (1) while switches and routers did not previously depend on the Internet, per se, these were built to synchronize their clocks with one NTP server located at the University of Wisconsin-Madison. The IP address of the NTP server is hard-coded in its firmware; (2) in only months' time, hundreds of thousands of these devices were manufactured, sold, and deployed worldwide.

Figure 1 show the Netgear model MR814, manufactured circa 2003. It is one of four Netgear devices that were sources implicated in this accidental flood of traffic.

Figure 1: Netgear MR814: 802.11b Cable/DSL Wireless Router circa 2003

These devices' SNTP client implementation had a design flaw that caused it it 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 this 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 prepared Figure 2 that plots the estimated number of flawed SNTP clients observed utilizing the University of Wisconsin NTP server, 2003-2016. This figure shows the arrivals (c. 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, then, removed around mid-2003.

Figure 2: Flawed Netgear SNTP Client Count, 2003-2016

The takeaways from this measurement studies are 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 an operational recommendations delivered as best current practice in RFC 4085 (BCP 105). For more details on the Netgear incident, visit this site or see this short paper.

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 findings.

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. The aforementioned case study was presented and recorded at the MAPRG meeting during IETF week in Berlin in July, along with some discussion about requirements that might drive IoT measurements.

In developing IoT measurements, there are a number of questions raised. 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? How is IPv6 involved?
With respect to stakeholders, there are many. Manufacturers are presumably wanting to know how devices traverse the supply chain and become active, and then not. Service providers may wish to managed IoT devices and perform risk assessments. Device users, owners, or 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 WWW User-Agent strings and Ethernet MAC address that help identify some IoT devices. These can be spoofed or obscured. Can IoT device identities be authenticated? What features are feasible to measure IoT device uptimes or determine lifetimes?
Lastly, there are privacy and operational implications to IoT measurement. what are the privacy or anonymity requirements can protect IoT users from being victimized? If IoT devices are long-lived and choose not to use IPv6, as many do today, they present a very significant increasing challenge in address exhaustion, in IPv4, and relief, e.g., via IPv6.

The unwanted traffic and vulnerabilities resulting from IoT flaws warrants special attention and concerted efforts in the research, standards, and operator communities. Leaving the Internet of Things, literally and figuratively, unchecked exposes our Internet to an unprecedented scale of performance, reliability, and security problems that were foreseen in incidents a decade ago, but have been unavoided as very recent attacks involving IoT devices have all too clearly shown.

For more information, feel free to contact me via <>.
Related links: