A Step in the Right Direction: MQTT and IoT Standards

 

KNOWLEDGE TO POWER THE BUSINESS OF IOT

NEW: IoT PLATFORM RFx TEMPLATE  - CLICK HERE

It’s official, MQTT is now an ISO standard. Confused or wondering why this matters? It’s pretty straightforward - there are multiple “messaging” protocols that are competing to be the defacto standard for the Internet of Things. With billions of dollars at stake in the IoT ecosystem, being the standard for the industry has its advantages. More important, the IoT needs standards to foster more innovation and interoperability. Every ratification, like this one from the ISO, is meaningful. So, if you work in an environment where you only use ISO standards, congratulations on gaining the MQTT standard. if not, here are some reasons why you might care about the ISO ratification.

 

This is certainly great news for everyone who has engaged MQTT to date, as it solidifies what was Google already seemed to know. So now that MQTT will continue it standardization march from Eclipse to OASIS to ISO, the focus shifts to how the IoT ecosystem can engage it.

 

Since ClearBlade first attended the Eclipse.org interop day, we have been deeply involved in the architectural and functional details of MQTT.  We have poured over the byte flags, been baffled over back-level support tactics, and opened a few Paho defects along the way. Despite the struggles, we also have been incredibly impressed by what’s possible with the very lightweight and flexible specification.

 

The ClearBlade MQTT Journey

 

ClearBlade offers customers an IoT platform that runs in the cloud or on-premise called Novi. It is purpose-built for large enterprises, with a sharp focus on security, scalability and performance by default . The platform offers two outward facing protocols for IoT devices to engage - HTTP and MQTT.  When we started building Novi, we didn’t want to recreate the wheel. So, like many others in the community, we looked to the open source world to jump start our MQTT broker. There are some great solutions out there, but we discovered significant gaps in the core specification that didn’t match our enterprise-grade requirements:

 

Authentication - The MQTT specification defines a user name / password authentication model. This is fine and the internet has worked this way for a long time, but there are some real issues in the context of the IoT.  In a world where devices authenticate, having those devices send a username and password is awkward and inefficient. For example, if you’re an IoT developer connecting to a broker with thousands of devices all using your your compiled code, how do you authenticate those?  Does each device get its own username? How do you update the password if it becomes compromised?  What about vulnerabilities to man-in-the-middle attacks? While the oAuth model doesn’t map exactly to our IoT world, a token model makes sense as a default behavior for MQTT. The good news is, while MQTT does not specify a token auth model, it’s very doable with the current specification. The best answer would be for MQTT to engage multiple authentication models. Those models should include tokens via device keys, and it should go a step farther and include certificate based authentication. We’ve accomplished both in the ClearBlade Novi platform.

 

Authorization - The topic-based messaging model is extremely efficient when routing data in dramatically diverse patterns. The flexibility is stunning, but it also exposes massive security challenges. With a REST API, you want to allow some users to call specific services and some not. With MQTT, it’s difficult to define that level of control across infinite potential topics.  For instance, if you were using a standard MQTT broker for implement chat and implementing opening garage doors, there is no inherent way to prevent the garage door credentials from getting access to the chat conversations of every user.  This is a huge problem with security in IoT systems.  Hammers shouldn’t be able to publish or subscribe to everything that’s going on with heart valves. Nor should IoT solution implementers have to run 4 different brokers in isolation just to protect participants in the same system from each other.

 

ClearBlade invested heavily in solving this gap as well, it is achievable with the specification. We provide authority layers of protection between IoT solutions and their co-tenant systems, and with the participants on the system to define access control layers.

 

Scalability - The last challenge of MQTT is one that hasn’t reached critical mass, but it will come and many adopters of MQTT will be unprepared.  Every IoT article starts with the hyperbole of billions and billions of “things” that will be connected. That implies the need for almost limitless scalability, and the nature of an MQTT connection presents a challenge. When HTTP connections are made, data is exchanged and the connections are released.  This process is inherently slow, and MQTT makes up for it by holding open a connection. That’s where the real problem starts.

 

The number of possible connections is a real world physical thing. Machines can only hold a finite number of connections, and network cards can only handle a finite workload.  Whether one network card can handle 50 or 250 thousand connections, there is a limit. MQTT brokers do have the ability to balance their load via bridging, and we can bridge several together to share workload. Using HAProxy, we can push that number up a bit - but even then, we are limited again by the number connections your HAProxy machine is capable of handling.

 

We solved this issue in architecting the Novi platform, but for MQTT to more broadly support real IoT workloads, a standardized model for scale and load balancing needs to be developed and adopted by the community.

 

MQTT moving forward

 

In building the Novi IoT platform, we addressed and filled these gaps and more. For the MQTT specification to continue its path to maturity and IoT adoption, future challenges need to be solved by the community. That means a combination of maturing the specification without making it too heavy, creating frameworks to make critical capabilities repeatable, and adopting common best practices within the developer community.  To flourish, the IoT challenge needs a community focused on building with standards not just end to end solutions.  MQTT is a critical part of solving that equation and an exciting step forward.