I was surprised that none of the available IoT protocols were able to complete a data exchange, securely, using exactly one UDP packet in each direction. I want a data-efficient protocol for use on LTE-M, which is often provisioned for relatively small amounts of data per billed interval. So, I set out to design one. Here is the first pass, for your comments, please reply to [email protected] .
Simple IoT protocol.
The goal of the Simple IoT protocol is to provide a secure message transport that requires exactly one UDP packet in each direction to complete. During that exchange, data may optionally be sent in each direction. Packets without data (only acknowledgements) need not be acknowledged, if necessary the sender will repeat a data packet until it receives an acknowledgement.
This protocol takes advantage of the 1280 octet minimum packet size guaranteed on IPV6. Use of this protocol on IPV4 is possible, but not recommended, because it depends on all links honoring the same minimum packet size.
Each host is required to have a “secret” which has been shared, out-of-band of this protocol, with all hosts with which it communicates. This secret should be unique per host, and may be unique per peer. The secret is a sequence of octets between 20 and 2048 octets long – the implementation may limit this length.
Overhead:
IPV6 packet: 40 octets.
UDP packet: 8 octets.
Remaining: 1232 octets.
The data-length datum is provided by UDP.
All data are big-endian.
Use some sort of symmetrical encryption. Which one? Provide the option to not encrypt when used on an Amateur Radio link.
Octet Use
0-15 This may only be on the Amateur Radio version, because we can’t encrypt there. The low 16 octets of a cryptographic checksum of the concatenation of the secret and octets 16-end. This is used as both a checksum and a zero-knowledge proof of the identity of the sender. Octets 16-17 of this checksum are saved, and used to match against the acknowledgement from the peer. Which secure checksum algorithm? It needs to be computable in reasonable time on embedded processors.
16 Protocol version (0 for this version)
17 Data version. 0 means “no data”, 255 defined data types.
18-19 Random data (to help defeat attempts to derive the secret). On a dumb device, a sequence is sufficient.
20-32 TAI time in nanoseconds (and I need to shorten this to 64 bits).
33-36 Sequence number. 0 is invalid, the sequence may wrap around to 1 or
start back at 1 when the device or program is restarted.
37 Number of acknowledgement sequence numbers following this datum.
38-n A list of 6-octet acknowledgement sequences. The first 4 octets are the sequence number sent by the peer. The succeeding 2 octets are octets 16 and 17 of the checksum calculated using the shared secret of the peer. These were calculated by the peer, but not sent (on the symetrical encryption non-Amateur-Radio version, I might just use a 16-bit simple checksum here).
Unacknowledged packets may be resent, or dropped and a new packet with new sequence number and timestamp may be sent. Receiving acknowledgement of a packet guarantees that the acknowledgement data in that packet was processed and need not be repeated. Packets without data (only acknowledgements) are not acknowledged, if necessary the sender will repeat a data packet until it receives an acknowledgement. Acknowledgements in data packets may be repeated arbitrarily many times for the previous 1024 packets retrieved (how many times they are actually sent is up to the implementation, but in general only a few repeats should be necessary). The implementation determines the allowable packet delay before resend, and the allowable time difference before sent packets with a timestamp too far in the past are rejected.
n-end Data (a higher-level protocol)
Defined Data types:
0 No data.
1 JSON serialized using Smile [https://en.wikipedia.org/wiki/Smile_(data_interchange_format)]