Connected devices need a safe, reliable network of things (NoT) that ties them together, but that glue is likely IoT-specific protocols, not the internet.
When the now-familiar concept of the Internet of Things (IoT) was new, we were envisioning a massive deployment of “things”, mostly sensors, connected directly to the internet and, like the internet, available to many companies to form the basis for new applications. Neither the business model nor the privacy/security issues of that approach were easily validated, so we’ve fallen back to something that largely takes the internet out of IoT.
But what replaces it?
Answer: The Network of Things or NoT, and if you’ve never heard of that concept, you’re at the first step of understanding the problem.
The real NoT falls into two main categories. The first is consumeristic and is also used by small to mid-sized businesses and even enterprise remote offices. In this model, Wi-Fi is used to connect devices to a vendor website, which then provides users with access to their technology to monitor and control them. The second mode, the one enterprises are most likely to adopt, uses a variety of highly specialized protocols designed for IoT alone. It’s these protocols that build the real network of things, and most network professionals know little about them.
Real IoT protocols are a mixture of proprietary and standard technologies. The great majority of them are designed to operate on unlicensed wireless spectrum at a very short range, maxing out at a couple hundred feet. They work on the same principle of discovery that router networks use, picking the best route by discovering network topology, but the implementation is very different. First, there’s that short-range problem. Router networks work over global distance where IoT networks work within a facility.
The need for monitoring
The big problem is that those wireless IoT networks don’t come with a sniffer to detect the signals and decode the messages, so network professionals can’t actually monitor the network to see what’s happening. They have to rely on what the IoT hub sees, which means that if a sensor or other element isn’t able to reach the hub it’s just off in the wilderness somewhere. First, you need to get the hub and the IoT devices at least talking, and if you do, you can see what the route is and how strong the signal is.
What this means is that NoT planners have to figure out just how far apart they can put the devices. They need to be especially careful with the ones that are battery-powered, because they can’t repeat the signals to extend range. The best strategy is to place your hub somewhere central, then add range-extender/repeaters that just boost the signals, starting close to the hub and working outward, then checking one as it’s added to be sure it’s really connected before adding anything else new. When all the repeaters are in place, you then add the AC-powered elements, again starting close to repeaters and working outward. The battery-powered stuff gets added last, and if something doesn’t connect, you have to add some more repeaters until everything works.
Once the mesh of NoT elements is established, it tends to settle down and work, at least as long as everything has power. Every IoT device will have its own power-fail behavior. Most switches and sensors will remember their state at the time of a failure and recover in the same state, but if that’s not what you want, you’ll need to program your application to restore state more gracefully. You may also have to pay special attention to the power supply to the hub because it’s a simple device that might be damaged by surges or sudden loss/recovery of power. Put a UPS on any hubs and be safe.
Security of connected devices
The next issue is the security of the hubs. Obviously these little cheap plastic boxes aren’t supercomputers with all kinds of resources available to secure connections. The better IoT protocols will offer encrypted messages, but that capability is of limited value if your hub is secure, because devices have to be added explicitly to the network, so a third party can’t break in easily. IoT protocols are also very limited in what they can do, so it’s hard for an attacker to gain much by compromising a device.
The real security problem comes at the boundary between your NoT network and the rest of your network, meaning the internet or your VPN. The hub often provides the linkage between these two very different worlds, and the hub isn’t much more powerful than the IoT devices. A hub might be as large as a deck of cards, which means its own security features upstream to the VPN, for example, are limited. If somebody breaks into the hub, they can not only add their own devices to your NoT or remove yours, they may also be able to sneak upstream from the hub into your VPN.
The moral here is that from a security perspective, it’s critical that you protect the hub-to-whatever connection as well as you can. Physical security of the hub is important, and so is the connection between the hub and the rest of your network. Try to use Ethernet for that connection where possible rather than Wi-Fi, and if you do use Wi-Fi try to set up a separate network for your hub and any Wi-Fi IoT devices to ensure that an IoT hack doesn’t open up your whole enterprise.
Latency of IoT-sensor traffic
The final issue is the dreaded control loop—the pathway between a message that’s supposed to initiate some process step and the software application logic that has issued the commands. Many IoT applications are highly delay sensitive. Envision a big truck wheeling along to a gate, where an RFID sensor is supposed to read the truck’s ID and send a request to check whether the vehicle is expected, and where it’s supposed to go. If the gate is opened when the truck is validated, the driver likely keeps rolling slowly, expecting the gate to open. If the control loop is long, meaning it has a lot of latency, then expect the trucks to roll through a couple of unopened gates. Not a happy outcome.
The problem with NoT control loops is that they span the NoT, the VPN, and the cloud or data center. All that latency has to be added up, and the part within the NoT is hard to measure because of the limitations already noted. The only way to get reliable information on the control loop is to run tests, not only when the application is installed but when any part of it is changed. Even adding sensors to your NoT can change latency in another part of the network.
NoT isn’t for sissies, and it’s not really for traditional network professionals either. The path to NoT success lies in realizing just how different it is, then learning NoT details before you start sticking gear in and connecting it. Do it right, and all those gates and trucks will thank you.
