The choice of protocol for IoT and M2M will dictate the emergence and success of the market

For those that have not engaged in the conversations of the estimated 14.4 trillion dollar market called the Internet of Things, there is a discussion over what the world will use to create the bond allowing man and machine to work seamlessly together.  Before anything can be realized from all the marketing hype of what you can/will do, the devices, systems and applications have to communicate with each other over a common protocol which facilitates secure, efficient, real-time interaction for events and commands.

There is a discussion currently in progress focusing on this subject and comparing XMPP, REST, MQTT and CoAP at http://www.linkedin.com/groupItem?view=&gid=108418&item=239593910&type=member&commentID=138229614&trk=hb_ntf_COMMENTED_ON_GROUP_DISCUSSION_YOU_COMMENTED_ON

I have extracted a comment that takes a very good approach to summarizing each protocols functions by updating a post from Paul Duffy http://blogs.cisco.com/author/paulduffy/, Technical Leader with the Cisco Connected Energy Advanced Research and Standards team http://blogs.cisco.com/ioe/beyond-mqtt-a-cisco-view-on-iot-protocols/ which gives a peak at Cisco views on the protocols (not necessarily accurate).

Comment from Peter Waher, CEO / Gerente General at Clayster Laboratorios Chile Limitada  to Joe Speed, M2M leader at IBM.

“Hello Joe

In response to your comments:

Regarding supposed security level of MQTT: The link you provide does not give 5 stars to MQTT in any category. It gives it to Facebook Messenger. However, Facebook is an example where a single actor controls the entire communication environment. They can use unsafe protocols, and still make it safe, since they do not invite others into their networks.

Regarding your comment: “MQTT is engineered for constrained environments & wireless, not “made for LAN deployments””: This is exactly the point. You need to know the protocol and know what it is good at, and what it is not good at. It is an efficient publish/subscribe protocol that can be used for resource constrained devices.

But it is not the only such solution. XMPP & EXI is another, infinitely much safer, option. It supports exactly the same use cases you mention in your post. I assume you are not familiar with this protocol and its extension. I encourage you to check it up: XEP-0322 [1].

As you mention, MQTT is “not made for LAN deployments”. I could not have said this better myself, and I’m happy than an IBM M2M leader agrees with me on this point. However, Internet of Things includes this: It is about publishing Things on the Internet, everywhere, including LAN (which is more safe than Internet), but it also includes the Internet, which is even less safe than LAN. It’s horribly and irrevocably unsafe.

Creating a standard for Internet of Things, without taking security into account, is like sending guns to small children, telling them how to store it safely, and then hoping them to follow your recomendations. A standard simply MUST enforce security, especially for the Internet of Things, or security vulnerabilities so huge (and corresponding hacks) the world has never known before will be created. (IoT will expand the number of connected devices by a factor of 50-100 in just a decade.) Even worse: Normal PC’s are easy to update. But devices in IoT, might not even be updatable, leaving the holes wide open until the devices are physically replaced (who will pay for that?). Somebody promoting an IoT protocol without having this in mind, simply does not know about IoT, or has an extremely limited view on what IoT is and will be in a short future.

Regarding Pauls blog, it’s interesting to note Cisco has started to evaluate the recent extensions made to XMPP, making it “suited for Iot”. However, there are many areas missing in his comparison. I would like to add the following sections also:
Security (securing against attacks and exploits):

CoAP: MEDIUM. It has security mechanism, but they are optional. [2]

XMPP: HIGH. Encryption + Client Authentication + Client Authorization mandatory. It is the only solution that has a Client Authorization mechanism. The others cannot implement this, even if they do it as an application specific extension. The protocols simply do not allow it.

REST/HTTP: MEDIUM. It has security mechanism, but they are optional.

MQTT: Low. Sends passwords in clear text. The SSL/TLS solution does not remote the man-in-the-middle attack threat, making it possible to extract passwords in clear text even if communication is encrypted. Since it is done for constrained devices, the probability that safeguards against this is implemented is low.
Provisioning (Configuring IoT networks):

CoAP: Low. No privisioning support is defined for CoAP.

XMPP: HIGH: Ability for operators to provision who can talk to who, what they can see or do, what services are accessible to whom, etc, is available through XEP.0324 [3].

REST/HTTP: Low. Non-existant.

MQTT: Low. Non-existant.
Interoperability (Making things from different vendors understand each other):

CoAP: Low. Content is binary, and proprietary. To make things interoperate, further work has to be done. Limited such work is available in the SENML initiative, but it covers only a very small fraction of use cases for IoT.

XMPP: HIGH. Through XEP-0323 (Sensor Data) [4], XEP-0325 (Control) [5] and XEP-0326 (Concentrators) [6] important use cases for interoperability has already been defined. More extensions in this field is being worked on, and will be published shortly.

REST/HTTP: Low. Non-existant.

MQTT: Low. Non-existant.
So, as a base for Internet of Things, I would say MQTT is a very poor choice. That doesn’t mean it’s a bad protocol or bad technology. It has its obvious advantages, when it comes to transporting and routing messages using a publish/subscribe architecture in secure and controlled environments. I understand why large corporations want to use it, in settings where they control everything, from sensor, gateways, networks, servers, etc. But, it is simply not suited to be a standard for IoT.

Sincerely,
Peter Waher”

[1]: http://xmpp.org/extensions/xep-0322.html
[2]: http://datatracker.ietf.org/doc/draft-ietf-core-coap/
[3]: http://xmpp.org/extensions/xep-0324.html
[4]: http://xmpp.org/extensions/xep-0323.html
[5]: http://xmpp.org/extensions/xep-0325.html
[6]: http://xmpp.org/extensions/xep-0326.html

Advertisement