When IoT building management devices DHCP is broken

In our travels consulting to leading property groups and government, we are seeing a trend amongst many manufacturers and vendors of technology so-called the 'Internet of Things', commonly referred to as IoT building management devices. For the purpose of this article, IoT really refers to any network connected device to service plant and equipment within that building - so all prop-tech. At some point, IoT devices need to connect to the internet, typically via a managed corporate network. When integrating a 'smart building', having silos of data is infuriating for all parties other than the individual service contractor.

On many 'smart buildings', even to this day, we see separate networks for different trades. The lift contractor builds their own network, as does the intercom installer, the mechanical control integrator, and so on. This is the 'default' position in many cases. Not only is there a duplication of equipment and cabling, there is no easy path for integration of the various services within the 'smart building'.

When connecting to a corporate or private fibre network, DHCP assigned addresses are the default position as it allows for proper security and ease of maintenance. More below.

DHCP Client Issues

We encountered irregularities in the way the DHCP was implemented in many IoT devices. These irregularities seem to deviate from RFC2131. In a number of projects we are engaged with, many of the devices with a DHCP client in-built have to have this feature disabled and instead a static IP addressed manually assigned to the device. This rendered us unable to implement DHCP for various vendor IoT devices, which, for a corporate IT network becomes problematic in terms of deployment during construction, and for long-term maintenance. For example, when a network switch is replaced, special programming down to each physical switch port is required to allow for statically addressed devices.

Many of the vendor manuals spell out how they send DHCP discover packets. We have seen the following implementations:

• If IoT device doesn't get a DHCP offer from a DHCP server within <90 seconds, revert to a known static IP address
• As above, but revert to a private network address such as 169.168.x.x (APIPA)
• When changing from a DHCP assigned address to a static IP address, the IoT device requires a physical power-cycle
• Some plain don't support DHCP, which while not a good solution, is more honest than an unpredictable and therefore unreliable implementation

The issues with the above are manifest:

• Multiple devices will all have the same static IP address
• Devices will not be discoverable on the network, despite being powered up and connected
• Changing from DHCP to static IP via a remote connection renders the devices offline, necessitating a site visit
• Cannot implement basic physical cyber-security measures such as IEEE 802.1X port-based network access control (PNAC)
• In 2023, IP connected devices should support DHCP for security and maintenance reasons

RFC2131

These method seems to contradict the requirements in RFC2131 which mandates DHCP clients MUST (not should) retransmit DHCPDISCOVER packets according to the following requirements:

Note that it is to retransmit the DHCPDISCOVER packet to a maximum of 64 seconds until it gets a DHCPOFFER. It should not stop this process until it gets a response. It should not revert to a APIPA address or static IP address on fail. Automatic private addressing seems to be a Microsoft policy from the Windows 98 era, which is fine when you can type in to your console ipconfig /release && ipconfig /renew. They were no doubt dealing with broadcast storms in huge monolithic networks back in the day that drove the adoption of this policy. However, to our knowledge it never made it into the RFC.

These various IoT vendor DHCP client implementation is problematic in the real world in this not uncommon scenario:

• Lose electricity on site
• DHCP server is not on UPS (typical in a remote field office) OR UPS times out due to long power outage (flood event, for example)
• DHCP server > 5 min boot time
• IoT devices boot quickly, the DHCPDISCOVER packets time out before the DHCP server is available, reverting all IoT devices to an APIPA private address or everything on the same static IP address

While a private address is somewhat better than everything defaulting to the same static IP address, there is no real reason (from the standpoint of logic) in the case reverting to a private address (thereby not making it available to an installer via a known IP for commissioning) to not keep trying per the RFC. While the counter-argument is, as articulated in many vendor manuals (paraphrasing) 'putting it on a static IP address is best practice' deviates from the expectations of larger and more professionally run networks. Saying that with DHCP you can't be certain that the device will stay on the same IP address underestimates the abilities of the IT professional to create DHCP static mappings. On unmanaged networks, sure, that would be a likely outcome. So, advise static address on small, un-managed networks, and dynamic addresses if you can create DHCP static mappings in the DHCP server?

The Bad, the Good

It's not all bad. While I won't mention the vendors who aren't entirely on board with IT standards, there are the good. Who we will mention.

The good (tested so far):

• Moxa
• Fronius Data Manager (sunspec compliant units)
• SMA (sunspec compliant units)

We'll endeavour to update this list from time-to-time, because at the time of writing, the list is rather short. We have approached the various non-compliant vendors we have encountered and informed them of the issues as outlined above. We hope these vendors will get on board with a more rigorous IT based approach to network security in IoT building management devices.