Proving the Business Case for the Internet of Things

Microsoft PaaS provides foundation for secure IoT connectivity

Steve Rogerson
January 31, 2019



Microsoft has introduced Azure IoT Hub device streams, a platform-as-a-service (PaaS) that provides a foundation for secure end-to-end connectivity to IoT devices.
 
“In today's security-first digital age, ensuring secure connectivity to IoT devices is of paramount importance,” said Reza Sherafat, senior programme manager for Azure IoT, in a blog post. “A wide range of operational and maintenance scenarios in the IoT space rely on end-to-end device connectivity to enable users and services to interact with, login, troubleshoot, send or receive data from devices. Security and compliance with the organisation's policies are therefore an essential ingredient across all these scenarios.”
 
Users, partners, application developers and third-party platform providers can leverage device streams to communicate securely with IoT devices that reside behind firewalls or are deployed inside private networks. Furthermore, built-in compatibility with the TCP/IP stack makes device streams applicable to a wide range of applications involving custom proprietary protocols as well as standards-based protocols such as remote shell, web, file transfer and video streaming.
 
At its core, an IoT hub device stream is a data transfer tunnel that provides connectivity between two TCP/IP-enabled endpoints: one side of the tunnel is an IoT device and the other side is a customer endpoint that intends to communicate with the device, also known as a service endpoint.
 
“We have seen many setups where direct connectivity to a device is prohibited based on the organisation's security policies and connectivity restrictions placed on its networks,” said Sherafat. “These restrictions, while justified, frequently impact various legitimate scenarios that require connectivity to an IoT device.”
 
Examples of these scenarios include:

  • An operator wishes to login to a device for inspection or maintenance. This scenario commonly involves logging to the device using SSH secure shell for Linux and RDP remote desktop protocol for Windows. The device or network firewall configurations often block the operator's workstation from reaching the device.
  • An operator needs to access a device's diagnostics portal remotely for troubleshooting. Diagnostic portals are typically in the form of a web server hosted on the device. A device's private IP or its firewall configuration may similarly block the user from interacting with the device's web server.
  • An application developer needs to retrieve logs and other runtime diagnostic information remotely from a device's file system. Protocols commonly used for this purpose may include FTP file transfer protocol or SCP secure copy. Again, the firewall configurations typically restrict these types of traffic.
IoT hub device streams address the end-to-end connectivity needs of the above by leveraging an IoT hub cloud endpoint that acts as a proxy for application traffic exchanged between the device and service. This setup is depicted in the diagram at the top of the page and works as follows:
  • Device and service endpoints each create separate outbound connections to an IoT hub endpoint that acts as a proxy for the traffic being transmitted between them.
  • The IoT hub endpoint will relay traffic packets sent from device to service and vice-versa. This establishes an end-to-end bidirectional tunnel through which device and service applications can communicate.
  • The established tunnel through the IoT hub provides reliable and ordered packet delivery guarantees. Furthermore, the transfer of traffic through the IoT hub as an intermediary is masked from the applications, giving them the seamless experience of direct bi-direction communications that are on par with TCP.
IoT devices can be reached from service endpoints without opening an inbound firewall port at the device or network perimeters. All that is needed is the ability to create outbound connections to IoT hub cloud endpoints over port 443; devices that use IoT hub SDK already maintain such a connection.
 
To establish a stream, both device and service endpoints need to authenticate with the IoT hub using their corresponding credentials. This enhances security of the device communications layer, by ensuring that the identity of each side of the tunnel is verified prior to any communications taking place between them.
 
By default, IoT hub device streams use TLS-enabled connections. This ensures that the application traffic is encrypted regardless of whether the application uses encryption or not.
 
The use of device streams eliminates the need for complex setup of virtual private networks (VPNs) to enable connectivity to IoT devices. Furthermore, unlike a VPN, which give broad access to the entire network, device streams are point-to-point involving a single device and a single service at each side of the tunnel.
 
IoT hub device streams can accommodate TCP/IP application traffic. This means a wide range of proprietary as well as standards-based protocols can leverage this feature. These include well-established protocols such as RDP, SSH, FTP and HTTP/Rest.
 
Devices that are deployed inside private networks can be reached without assigning publicly routable IP addresses to each device. Another similar case involves devices with dynamic IP assignment, which might not be known by the service at all times. In both cases, device streams enable connectivity to a target device using its device ID rather than IP address as identifier.
 
“IoT hub device streams are particularly helpful when devices are placed behind a firewall or inside a private network with no publicly reachable IP address,” said Sherafat.
 
To illustrate the applicability of device streams in real-world IoT scenarios, consider a setup involving equipment and machinery – IoT devices – on a factory floor that are connected to the factory's local area network. The LAN typically is connected to the internet through a network gateway or an HTTP proxy and is protected by a firewall at the network boundary. In this setup, the firewall is configured based on the organisation’s security policies, which may prohibit opening of certain firewall ports. For example, port 3389 used by RDP is often blocked. Therefore, users from outside of the network cannot access devices over this port.
 
“While such a network setup is in widespread use, it introduces challenges to many common IoT scenarios,” said Sherafat. “For example, if operators need to access equipment from outside of the LAN, the firewall may need to allow inbound connectivity on arbitrary ports used by the application. In the case of a Windows machine that uses RDP, this comes at odds with the security policies that block port 3389.”
 
Using device streams, the RDP traffic to target devices is tunnelled through the IoT hub. Specifically, this tunnel is established over port 443 using outbound connections originating from the device and service.
 
“As a result, there is no need to relax firewall policies in the factory network,” said Sherafat. “In our quick-start guides available in C, C# and NodeJS languages, we have included instructions on how to leverage IoT hub device streams to enable the RDP scenario. Other protocols can use a similar approach by simply configuring their corresponding communication port.”