Surprise! The Internet of Things does not necessarily include the Internet


When the now-familiar Internet of Things (IoT) concept was new, we really meant the mass deployment of “things,” mostly sensors, that connect directly to the Internet and are accessible to as many companies as the Internet. is the basis for new applications. Neither the business model nor the privacy/security issues of this approach were easily validated, so we reverted to something that basically took the internet out of IoT.

But what replaces it?

Answer: Network of Things or Not, and if you have never heard of this concept, you are on the first step in understanding the problem.

Real NoT is divided into two main categories. The first is consumer and is used by small and medium-sized enterprises and even remote offices of the enterprise. In this model, Wi-Fi is used to connect devices to the supplier’s website, giving users access to their technology to monitor and control them. The second mode that enterprises will most likely adopt uses a variety of highly specialized protocols designed just for the IoT. It’s these protocols that make up the real network of things, and most network professionals know little about them.

Real IoT protocols are a mix of proprietary and standard technologies. The vast majority of them are designed to operate at very short ranges in the unlicensed wireless spectrum, a few hundred feet at most. They work on the discovery principle used by router networks, choosing the best route by discovering the network topology, but the implementation is very different. First, there is the short-term problem. Router networks operate at a global distance where IoT networks operate within an object.

The need for monitoring

The big problem is that these wireless IoT networks aren’t equipped with sniffers to detect signals and decode messages, so network experts can’t actually monitor the network to see what’s going on. They have to trust what the IoT hub sees, which means that if a sensor or other item can’t reach the hub, it’s just somewhere in the desert. First, you need to get the hub and IoT devices to at least talk, and if you do, you can see what the route is and how strong the signal is.

What this means is that NoT planners need to understand how far apart they can move devices. They need to be especially careful with battery operated ones as they cannot repeat signals to extend the range. The best strategy is to place your hub in a central location, then add range extender/repeaters that amplify the signals working outwards, starting near the hub, then test as it’s added to make sure it’s actually connected before adding anything else. . Once all the repeaters are in place, you again add the AC-powered elements, starting near the repeaters and working outwards. Battery powered items are added last, and if something doesn’t connect, you’ll need to add a few repeaters until everything works.

Once a network of NoT elements is established, it tends to settle and work, at least as long as everything has power. Each IoT device will have its own power failure behavior. Most switches and sensors will remember their state upon failure and reset to the same state, but if that’s not what you want, you’ll need to program your software to reset state more gracefully. You may also need to pay special attention to the hub’s power supply as it is a simple device that can be damaged by surges or sudden power loss/recovery. Put a UPS in any hub and be safe.

Security of connected devices

The next issue is the security of hubs. Obviously, these little cheap plastic boxes aren’t supercomputers with all the resources to handle the connections. Better IoT protocols will offer encrypted messages, but if your hub is secure, this capability is of limited value because devices must be openly attached to the network so a third party cannot easily access it. 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 challenge comes at the boundary between the NoT network and the rest of your network, i.e. the internet or VPN. The hub often provides the link between these two very different worlds, and the hub is no more powerful than IoT devices. A hub can be as big as a deck of cards, which means its own security features over a VPN, for example, are limited. If someone accesses the hub, they can not only add their devices to the NoT or delete your device, but also access the VPN upstream from the hub.

The moral here is that from a security point of view, it is very important that you protect the node and any connection as much as you can. The physical security of the hub and the connectivity between the hub and the rest of your network are also important. If possible, try to use Ethernet for this connection instead of Wi-Fi, and if you use Wi-Fi, try to set up a separate network for your hub and any Wi-Fi IoT devices to ensure that the IoT hack is not exposed. upgrade your entire enterprise.

IoT-sensor traffic latency

The final issue is the dreaded control loop—the path between the message that must initiate some process step and the application logic that issues the commands. Many IoT applications are highly latency sensitive. Imagine a large truck driving towards a gate where an RFID sensor must read the truck’s ID and send a request to verify that the vehicle is expected and where it needs to go. If the gate opens after the truck is validated, the driver likely continues to roll slowly, waiting for the gate to open. If the control loop is long, that is, there is a lot of delay, then wait for the trucks to pass through several unopened doors. Not a happy outcome.

The problem with NoT management loops is that they involve the NoT, the VPN, and the cloud or data center. All this delay must be added, and due to the limitations already mentioned, it is difficult to measure the part inside the NoT. The only way to get reliable information in the control loop is to conduct tests not only when the program is installed, but when any part of it is changed. Even adding sensors to the NoT can change latency elsewhere in the network.

NoT is not for sissies, and neither is it for traditional networking professionals. The key to NoT success is realizing how different it is, then learning the NoT details before putting on the gears and putting it together. Get it right and all those doors and trucks will thank you.

Copyright © 2022 IDG Communications, Inc.



Source link