LoRaWAN 1.0.4 support

[maxgerhardt]

Is your feature request related to a problem? Please describe.

Currently, LMIC supports, per README, LoRaWAN versions 1.0.2 and 1.0.3. Per https://www.thethingsnetwork.org/article/whats-new-in-lorawan-104-1 and https://lora-alliance.org/resource_hub/lorawan-104-specification-package/, LoRaWAN version 1.0.4 has been released in 2020, with multiple security improvements (and functionality improvements):

• enforcing up/downlink counters to be 32-bit wide and saved persistently in non-volatile memory
• changes to how the DevNonce is chosen for OTAA (monotonic increase instead of random choice)
• AppEUI & AppNonce replaced with JoinEUI & JoinNonce
• etc.

Describe the solution you'd like It would be nice for (Arduino-) LMIC to officially support LoRaWAN v1.0.4.

Describe alternatives you've considered Stay at 1.0.3 with these security improvements not taken advantage of.

Additional context None

[descartes]

Yeah, it would, as a nice to have if your devices are doing top secret work but it's not vital to security and it's definitely non-trivial - how will you be assisting with this?

[mrx23dot]

I would definitely use a session struct inside LMIC, containing everything needed for activation and ABP, including counters. Then it can be easily saved/restored to/from NV, even swapping network operators.

Using random nonce is better if NV fails. Websites still use old naming conventions first those have to change.

[HeadBoffin]

Using random nonce is better if NV fails.

Excepting that v1.0.4 requires an incrementing JoinNonce ...

Websites still use old naming conventions first those have to change.

Why? v1.0.2 & v1.0.3 devices are very prevalent so the nomenclature is correct for them.