LoRaWAN 1.1 devNonce must be stored in a non-volatile memory on end device

[descartes (Nick McCloud)]

@robertlie

If the DevNonce and JoinNonce are not persistent stored it will be difficult to make these devices work correctly again.

Or just take a few join tries before they succeed.

But if a device is solar powered or could be sent for repair or is attached to a beehive, then this isn’t the use case I’m looking at so I’d put some NVM on the board.

And I’d put NVM on most boards anyway.

But I won’t be putting NVM on a low-cost device that is sealed because it’s not a requirement.

[robertlie]

@descartes, according the LoRaWAN 1.1 specification, the Network Server checks the DevNonce and the end device checks the JoinNonce.

In the specification this is what it says about the DevNonce (in verbatim):

DevNonce is a counter starting at 0 when the device is initially powered up and incremented
with every Join-request. A DevNonce value SHALL NEVER be reused for a given JoinEUI
value. If the end-device can be power-cycled then DevNonce SHALL be persistent (stored
in a non-volatile memory). Resetting DevNonce without changing JoinEUI will cause the
Network Server to discard the Join-requests of the device. For each end-device, the
Network Server keeps track of the last DevNonce value used by the end-device, and
ignores Join-requests if DevNonce is not incremented.

So, if a Network Server developer implements it according to text above than your low-cost device, with no NVM, will not work.
Multiple join tries will also not work.

Unless I completely misunderstand the text about the DevNonce.

Please note I don’t have a specific position on this matter.
I only want to check if I understand the LoRaWAN 1.1 specification correctly.

[descartes (Nick McCloud)]

@robertlie

Multiple join tries will also not work.

See previous post:

@descartes

But, and here’s the kicker, you can tell why a device has restarted from it’s power manager - as seen in the Microchip offerings so we have the option of incrementing the DevNonce by a chunk & a bit, say from 1 to 11 (I like prime numbers). So it can have two goes at joining without disrupting the specification’s karma.

[bwooce]

@bluejedi

That also includes v1.0.4.

Ah. yes. Good point.

@robertlie

If the DevNonce and JoinNonce are not persistent stored it will be difficult to make these devices work correctly again.

Agreed. The device can’t trust the JoinNonce supplied if it doesn’t have the old one to do the comparison that it’s greater. Protecting against replay attacks towards the device.

@descartes

Or just take a few join tries before they succeed.

This bit makes that interesting:

Network Server keeps track of the last DevNonce value used by the end-device, and ignores Join-requests if DevNonce is not incremented.

So incrementing the DevNonce every time the join response isn’t heard could make it decay into a bad place, but not so different from using up all the DevNonces today. TTS also errors once you get to MaxUint32. Wait…that’s a bug? Should be MaxUint16. That’s the end of the line for that JoinEUI at that point. No wrapping.

I wonder if we’re going to end up with an “ignore” option on the Network Server. Ha! There is one in TTS and exposed on the UI as “resets join nonces”. So not so different from the ignore frame counters setting we know and…well it’s not loved but it’s sometimes useful.

Okay yes NV storage of this is a good idea. We’re going to see some non-compliant devices not do it and they’ll be vulnerable to replay but they can still work if configured Network side to do so.

[descartes (Nick McCloud)]

@bwooce

We’re going to see some non-compliant devices not do it

You may never see the non-compliant devices not doing it because they join and er, that’s it.

@bwooce

they’ll be vulnerable to replay

For various values of “who wants to hack in to my temp & humidity monitor” and hang around just at the point they are deployed to pick up the join request. For any serious monitoring, then I’d have a device with, wait for it, NVM.

It’s not a black & white issue, it’s about the situation. Worrying about a simple device that picks up information you can gather by holding a wet finger in the air isn’t justifiable.

I fully support the back-off / jitter so that a device, regardless of type/cost, doesn’t hammer the join and quickly devolves to trying just once every 24 hours on the reasonable presumption that there isn’t a gateway to hear it but an engineer may turn up to sort stuff out.