Category: MQTT-SN

MQTT-SN Standardization Progress

Good News! The MQTT-SN standardization is progressing nicely. That isn’t to say at warp speed, but at a steady pace in the right direction with no significant obstacles so far. Of course, someone might decide to discover one in response to this article, but it’s better to know about any now if they exist.

Looking back, I think we had two major objectives, apart from the benefit of standardization itself:

  • To take into account experiences of implementation and improve them. MQTT-SN was devised in a different era of MQTT and networks: things have moved on.
  • To align more closely with MQTT 5.0 which had been developed in the meantime. Ironically, in the odd case such as cleanstart/cleansession, this means moving back in time to pre-MQTT 3.1.1.

Simon Johnson brought the experience of ThingStream’s use of MQTT-SN in a production environment into the fray. We started with that, along with some alignment with MQTT 5.0. I thought at the beginning that I would prefer the fewest changes we could get away with, but as our discussions proceeded I realized there were more changes I would like to see adopted.

So we’ve ended up with a list of about 40 issues. Through the end of 2020 and the first few months of 2021 we proposed solutions to those and had them agreed. In the meantime, Andy Banks had updated the original source specification to the format used at OASIS and started making basic corrections.

Since then, Simon and I have updated the draft specification with the issue proposals to result in the latest working draft. At this stage, or with a few minor extra changes, we will have completed the technical updates needed to implement the new version of MQTT-SN.

Next Steps

There is still a lot of work before the specification is complete: the non-normative sections, introduction, conformance statements and formalization (RFC-izing) of the language for example. I estimate all this will take six months at least.

The immediate steps are:

  • Take the current working draft to the MQTT Technical Committee to hear any objections to our direction of travel. I don’t expect any, but I want to find out.
  • Assuming no objections, we can then embark on the process of completing the non-normative sections and rest of the updates.

In the meantime, Simon and I are planning implementations, Simon in Java, mine in Python. If anyone else wants to start implementing then that would be welcome. Having some implementation experiences is necessary for the specification to become an OASIS standard, as well as double checking our work.

I hope that later in the year, we will have a specification ready for release as a first Committee Specification Draft (CSD), along with a couple of implementations. Reaching a final standard should then be possible in 4Q this year or 1Q the next.

One Thing! – Security

I heard, through Simon, that CoAP has added functionality to deter security issues. I didn’t know what that was, but a quick search resulted in hits about DDoS attacks. From a quick read, I think that MQTT-SN isn’t vulnerable to the same type of attacks, but perhaps QoS -1 publishes (without a connection) could be used and should be thought about carefully before use. If anyone has any thoughts or more information on this topic, do speak up.

MQTT-SN Authentication

This discussion is part of the standardization of MQTT-SN at OASIS. Here is a summary of the current issues we are working on. The issue for authentication is 568.

In the current MQTT-SN specification (1.2), there is no authentication capability included apart from the client id. This applied to the early versions of MQTT as well, so it’s not that surprising as MQTT-SN was derived from MQTT.

Later, userid and password fields were added to the MQTT connect packet, with optional external TLS encryption applied to the TCP/IP connection. In MQTT 5.0 an enhanced authentication capability was added by means of the new AUTH packet.

It’s generally agreed that we should add authentication to MQTT-SN. There are a few considerations which are different to MQTT however. MQTT is aimed at low powered devices, but MQTT-SN is notionally aimed even lower at connectionless network communications such as UDP where packet sizes are limited and TCP capabilities such as fragmentation do not exist.

So we need to be even more aware of data overhead, bloat and efficiency than we do with MQTT. In the base version of MQTT-SN, 1.2, there is a maximum of only one variable length field in each packet. This means that there is no length field apart from that for the whole packet, unlike in MQTT where there are many variable length fields each with its own length. So MQTT-SN is more efficient in terms of the size of each packet, at the expense sometimes of multiplying the number of packets needed. The MQTT-SN will message operations are an example of that.

The MQTT-SN 1.2 connect packet is structured like this:

Length n
(byte 0)		MsgType
(1)		Flags
(2)		ProtocolId
(3)		Duration
(4,5)		ClientId
(6:n-1)
MQTT-SN 1.2 CONNECT packet

The flags byte is an identical format for all the packets that use it, and is fully used – I’ll come back to that in a moment.

To add authentication to MQTT-SN I propose that an additional AUTH flag is added to the connect packet, which tells the server that an AUTH packet is going to be sent following the CONNECT packet. The AUTH packet consists of the following fields:

Length n
(byte 0)		MsgType
(1)		Length m
(2)		Auth Method
(3:m+2)		Auth Data
(m+3:n-1)
Proposed MQTT-SN AUTH packet with two variable length fields

This is designed to allow the operation of SASL framework authentication mechanisms and follows MQTT 5.0 closely. The current list of registered mechanisms includes PLAIN, a single message including the following fields:

  • authorization identity
  • authentication identity
  • password

each separated by a NUL (U+0000) character. Using this mechanism allows the CONNECT packet to be followed by an AUTH packet which includes a userid (authentication identity) and password, and so caters for the simple MQTT like case.

More sophisticated methods can also be used – this should allow any of the registered SASL mechanisms to be used. The server can also send an AUTH packet, either before a CONNACK, or during a session for re-authentication of the client.

It would be neater from a packet structure point of view if the authentication method were a fixed rather than variable length field. However, SASL mechanism names have a maximum length of 20 characters, so including a one-byte length field is going to be more efficient just about all the time.

Another alternative could be to have a one byte code for authentication method. But someone would have to maintain the table of translations from codes to meaning, or leave it to be implementation independent, hindering application portability.

Finally, to fit in the AUTH flag to the connect packet, some space will have to be made. As the CONNECT flags are a completely different set to those used in the other packets I propose that they are separated. The CONNECT flags:

x
(7)		x
(6)		x
(5)		x
(4)		Will
(3)		CleanStart
(2)		x
(1)		Auth
(0)
Proposed CONNECT flags; x means reserved

DUP
(bit 7)		QoS
(6,5)		Retain
(4)		x
(3)		x
(2)		TopicIdType
(1,0)
Proposed flags for other packets

I have left the positions of the existing fields unchanged for continuity, but they could be changed for neatness.

So this is my current first draft proposal. I’d like to get any thoughts that any of you might have. I haven’t used the SASL mechanisms myself so hearing from anyone who has could be particularly useful.