Although we’ve described it as a separate Web for devices, not people, Andy Piper of IBM’s WebSphere MQ messaging team emphatically describes MQTT protocol in ways that are not at all analogous to the HTTP protocol we’re accustomed to. Endpoint devices with low battery power and extremely limited networking – the kind embedded in sewer pipes whose purpose may be to send a signal meaning, “I’m not broken” – do not need a browser. And besides, they couldn’t handle one if you tried.
It makes MQTT a very limited wire protocol, one whose only purposes are to let a device send a very short message one hop up the chain to an MQ broker, and to receive push-button-like commands from that broker. So what’s to stop someone from building a similar device, planting it in the vicinity of the broker, and making it send the signal instead? Or to have a process impersonate a device through the Web – the one you and I use – that the MQ broker may mistakenly interpret to be from the device… say, from an ATM machine? ReadWriteWeb raised that issue with IBM’s Andy Piper, in a continuation of our interview from last Friday.
“Hello, it’s me.”
“Security’s a really interesting issue when it comes to devices, for lots of reasons,” Piper responds. “The current version of MQTT contains a basic security mechanism.” He didn’t describe it in detail, but the architectural model gives us a clue into IBM’s philosophy that the model itself is the crux of this mechanism.
A session does exist over the “wire” between the device and the broker. That’s different from a Web “connection,” which is often simulated through the use of cookies stored by the server on the client side. Devices push data upstream to the broker, often at regular intervals. It’s not packeted data, or enclosed with sophisticated headers denoting type or quantity. Imagine Sputnik and you’ll get the idea.
“In order for the server to be pushing data down to the devices, those devices must have already connected up and said, ‘Hello, it’s me,” Piper goes on. “You can’t easily peel that or steal that connection from a device.”
The authentication process may actually take place upstream, between the broker and a WebSphere MQ server. Whatever process is utilized – whether it involves LDAP, for instance, or Java Authentication Service – is therefore up to the developer. Authentication at the Web level takes place between the broker and the server, and here the broker vouches for the authenticity, identity, and integrity of the device. But communication at the MQTT level, between the broker and the device, does utilize TCP/IP.
“MQTT doesn’t look inside the data you’re giving it as an application developer,” Piper explains. “So you might want encryption and [the option of] signing your application. The protocol itself doesn’t deal with that. You can use SSL to protect the connection, so you can have a standard similar to HTTPS. You can effectively use SSL certificates to encrypt the connection, and again, the IBM product provides that capability.”
The Web mesh convergence mix-up
IBM’s marketing department positions MQTT as something like the Web and something like Twitter, as in this video above. Here, one of MQTT’s co-creators, Andy Stanford-Clark (don’t think for a moment that IBM doesn’t relish in the fact that his name, too, is hyphenated) describes an application he developed for a British ferry line that tracks the locations of ferries and notifies passengers of potential delays. Twitter is involved in this application, though it is not the backbone of the operation; and despite the way IBM juxtaposes the contexts in its marketing, MQTT does not tweet over the Web. Rather, it enables messaging queue applications to be generated that do tweet, or provide other live notifications.
This is an extremely important distinction, because it goes to security. Imagine for a moment that IBM’s ferry application were entirely Web-based (never mind the unlikelihood that distant ferries would always stream perfect packets in bad weather). Already an amateur can imagine scenarios where elements of this or any other similar telemetry system can be spoofed, using techniques that are publicly known. But MQTT’s distinction, at least for now, is that devices are removed from servers by at least one significant level of abstraction. In other words, there already is a “thing-in-the-middle,” and that’s by design. This division creates something akin to home and small business networking on PCs, where addresses in the 192.168.x.x address range pertain to devices in the “local loop” behind the router.
“We frequently find ourselves with a customer who has a situation where they’ve got a device which has a bunch of sensors attached to it – say, through a serial connection, so not even using TCP/IP. Then they say to me, ‘How do I get these little sensors talking with MQTT?’ The answer is, they actually don’t. [Instead], they should proxy onto a standards-based protocol as soon as they can, to break out of that little local loop attached to that device, and get it onto a messaging backbone as early as they can to make it available to the wider enterprise.”
Smaller worlds may be more convenient
IBM marketing claims “MQTT… makes it possible, potentially, for every device on the network to communicate and share information with every other device.” That’s kind of true. If your device happens to be (borrowing an Andy Piper example from part 1 of our interview) a thermometer, then there really isn’t much reason for it to want to know the readings of every other thermometer – or, for that matter, the status of toasters, refrigerators, and waffle irons. More realistically, as Piper describes it to us, MQTT-enabled devices will be sensors, and much of their communication will be one-way.
But traversing the network of trillions of devices will require many more degrees of separation than just this one. Which is why Piper (validating a suggestion I made) agrees that in the real world, there would inevitably be a multitude of things managing the local loops.
“Look, network topologies generally will need to be thought about in terms of device placement, for example, but you might want local hubs,” he says. “The idea of having all 20 billion devices connected to each other is unlikely. You’re always going to be doing multi-hops between them, because the network connection from me to San Jose to China is going to be multi-hop. That’s just the nature of TCP/IP networking, and the fact that you’re going to have local loops or islands of networks.”
Which brought us to the point of our discussion where we acknowledged that the address space for IPv4 – the older addressing system still used by most of the Internet – has already been exhausted, and doesn’t have room for a billion, let alone a trillion, new little things pinging along. In Part 3 of our discussion, we’ll broach the topics of dividing the network of things, making it easier to navigate, and delegating responsibility for its taxonomy. In other words, will you be Googling your thermometer, or will you resort to the Yellow Pages?