There’s a tremendous amount of buzz around the Internet of Things, or IoT: How it will revolutionize manufacturing, agriculture, medicine, and our daily lives; the novel capabilities it will support; the new era it will herald. But the Internet of Things relies on networks, and networking technologies are deployed and managed by people—network administrators, in particular. Yet in recent years network administrators have been asked to do more with less: lower budget, smaller staff.
I’ve spent some time thinking about the effect the Internet of Things will have on networks and network administration and I’ve developed some theories. Also, Infoblox recently commissioned a survey of networking professionals and hosted two panel discussions with customers on the Internet of Things to test some of those theories.
For the most part, the survey and these panels confirmed my suspicions. For example, I had spoken with many customers who initially said they had no IoT devices whatsoever. When pressed, though, and given concrete examples (networked badge readers, surveillance systems, HVAC systems, cash registers, vending machines, and so on), most realized they already had at least a nascent IoT infrastructure. Accordingly, 75 percent of respondents to our survey reported that they already had office equipment “Things” on their network, and 70 percent reported security “Things” on their network.
I had also encountered very few IT organizations that had deployed any infrastructure specifically for IoT, from dedicated networks to management systems. Again, our survey supported the anecdotal evidence – only 35 percent of respondents said they have deployed solutions specifically to support IoT.
Since, in most cases, no dedicated network infrastructure exists for IoT devices, most IT organizations relegate IoT devices to existing networks. Only 30 percent of the organizations surveyed planned to create a separate logical or physical network for “Things,” while 46 percent will attach them to the corporate network. In our panel discussions, we found that most organizations simply dump IoT devices on existing guest wireless networks, which usually provide Internet access (which many “Things” require). However, guest wireless networks usually don’t allow access to internal resources (e.g., Domain Controllers, database and file servers), which other IoT devices need, and they provide little or no authentication, unpredictable performance, and no prioritization of traffic, all of which are required by some categories of these devices.
Despite the varied requirements of these IoT devices, many IT organizations I’ve met with described having “Things” that are “thrown over the wall” for deployment, well after another business unit had made the purchasing decision. Our survey bears this out: 60 percent of the organization surveyed reported being brought in to support IoT devices after another organization acquired them, and 63 percent reported that the subsequent deployment was more challenging than the acquirer believed it would be.
This difficulty in implementation isn’t surprising. From our customers, we’ve learned that IoT devices aren’t that smart. Many lack a user interface, making configuration a challenge—and often the responsibility of a network administrator, setting up DHCP options. Many are not easily upgradeable. Many are designed for consumer rather than enterprise deployment, and lack tools and features required for enterprise use. A university network administrator told me about dorm networks with hundreds of Apple TVs—making Apple’s Remote iOS app nearly useless, because it presents you with a list of those hundreds of Apple TVs to choose from. Some “Things” are just designed poorly. A network administrator for a hospital chain described an MRI system that used the same set of hardcoded IP addresses for every machine, meaning that the network administrator had to set up NAT for each MRI machine to ensure it was accessible across the network.
This same lack of capability extends to security features. Most “Things” don’t support strong authentication mechanisms such as 802.1X, leaving network administrators to use their MAC addresses—or nothing—as a weak form of authentication. Consequently, securing IoT devices’ access to the network is difficult. Some organizations I spoke with used VLANs to isolate certain categories of “Things,” but dedicating one VLAN to each type of device certainly doesn’t scale.
Our survey reiterated the concerns of our panel participants: 63 percent of those surveyed are concerned about the security challenges posed by the Internet of Things.
Based on our discussions and the survey results, I’ve come up with a short list of recommendations for network administrators facing an Internet of Things deployment:
1. Work to get yourself a seat at the table early in IoT deployment planning. You should have input into the minimum network requirements of devices that you’ll have to deploy and support.
2. Those requirements should include support for 802.1X, DHCP, SNMP management, remote upgradeability, and IPv6.
3. Consider deployment of IPv6. As you probably know, IPv4 addresses have become much more difficult to get. Some of your “Things” may require access from the Internet or from third parties’ networks. Don’t let your lack of routable IP address space hamper your IoT implementation.
About the author
Cricket Liu is a leading expert on the Domain Name System (DNS) and EVP and Senior Fellow at Infoblox. With more than 25 years of experience with enterprise-scale DNS infrastructure, technical writing, training, and course development experience, Cricket serves as a liaison between Infoblox and the DNS community. Prior to joining Infoblox, Cricket worked for HP for nearly 10 years, where he ran hp.com, one of the largest corporate domains in the world, and helped found HP's Internet consulting business. Cricket later co-founded his own Internet consulting and training company, Acme Byte & Wire. Cricket is the co-author of all of O'Reilly's Nutshell Handbooks on DNS, as well several additional books on the Internet and information systems.
Edited by
Ken Briodagh
