Add support for the FOpts, FCntDwn erratum to LoRaWAN 1.1.0

[janakj]

Summary

I have been trying to connect a LoRaWAN 1.1.0 device to TTN. The device is based on LoRaMac-node v4.6.0 which implements LoRaWAN 1.1.0 together with the FOpts,FCntDwn erratum. The erratum fixes a security vulnerability in LoRaWAN 1.1.0. In order to do so, it changes the encryption algorithm for the FOpts header.

Since TTN v3.18.2 and earlier does not seem to implement the erratum, MAC commands transmitted via FOpts do not work. The device can join successfully and application layer communication works, but MAC commands transmitted via FOpts (ADR, LinkCheck, DeviceStatus, etc..) are ignored on both the device and the TTN network server. This is due to the mutually incompatible FOpts encryption scheme. When either end-point tries to decrypt FOpts, it gets bogus MAC commands and ignores the entire header.

I have been debating whether to submit this as a bug or an improvement request. Since the erratum is four years old at this point and critical for secure LoRaWAN 1.1.0 operation, I consider this a bug. In my opinion, TTN network server should implement the erratum when LoRaWAN 1.1.0 is selected for a device.

The erratum will be probably rolled into LoRaWAN 1.1.1 when it is published. However, I would encourage the TTN team to consider implementing the fix proposed in the erratum even before LoRaWAN 1.1.1 is published.

CC'ing @johanstokking based on an earlier discussion in a different thread.

Steps to Reproduce

1. Provision a new LoRaWAN 1.1.0 device in TTN
2. Use LoRaMac-node v4.6.0 on the device
3. Join TTN in OTAA mode (this will work)
4. Send a LinkCheckReq to TTN (this will fail)

Not very easy to reproduce I admit, unless you already use LoRaMac-node, but please feel free to reach out to me if you need help reproducing it.

What do you see now?

1. The device sends a LinkCheckReq encoded in FRMPayload. TTN NS correctly processes this.
2. TTN NS generates LinkCheckAns and transmits the answer encrypted via FOpts
3. The device decrypts FOpts, but gets bogus MAC commands because it uses a different encryption scheme
4. The entire FOpts header is ignored by the device

The same thing happens in the opposite direction as well, i.e., TTN NS ignores encrypted FOps headers from the device. MAC commands transmitted via FRMPayload work.

What do you want to see instead?

I would like the TTN network server to use the FOpts, FCntDown erratum when operating in LoRaWAN 1.1.0 mode.

Environment

• LoRaMac-node v4.6.0
• TTN network server v3.18.2
• nam1 cluster

How do you propose to implement this?

If you wish to retain compatibility with existing LoRaWAN 1.1.0 devices that do not implement the erratum, it might be best to introduce a new MAC version, e.g., MAC_V1_1_0_FOPTS. In the console, you could present this as "LoRaWAN Specification 1.1.0 + FOpts, FCntDown erratum". The end-user would then be able to select the appropriate MAC version, depending on whether their devices implement the changes proposed in the erratum.

When MAC_V1_1_1_0_FOPTS is selected, the network server would encrypt the FOpts header field differently, according to the erratum.

See this ChirpStack function for an implementation in Go. Or see this function in LoRaMac-node for an implementation in C.

How do you propose to test this?

(see above)

Can you do this yourself and submit a Pull Request?

No. I am not familiar with the TTN code base.

[johanstokking]

This seems legit, looks like we've overlooked the errata and nobody really tried LoRaWAN 1.1 end devices before or at least not with a proper LoRaWAN end device stack.

If we can do this in 3.19.0 then great, but otherwise let's get this in 3.19.1.

[janakj]

Thanks a lot, @adriansmares ! I will give it a try once it is deployed.

[janakj]

I can confirm that LoRaMac-node (v4.6.0) now works with TTN in LoRaWAN 1.1 mode.