Issue link: https://read.uberflip.com/i/1539840
Developing LoRaWAN Devices Technical Recommendation TR007-1.1 ©2021-2025 LoRa Alliance ® Page 14 of 28 The authors reserve the right to change documents without notice. be used as a last resort. As fully specified in the LoRaWAN Link Layer specification, end- 434 devices SHALL comply with the retransmission back-off behavior during an attempt to re- 435 establish connectivity with the network through the Join Procedure. 436 4.5 Rolling Session Keys 437 4.5.1 Description 438 The end-device, the network, or the application may determine that the session keys for the 439 end-device's current security session need to be refreshed. This may be due to suspected 440 security compromises, the lifetime of the existing session, frame counters are approaching 441 maximum values, or other security considerations. 442 The ability to re-key the end-device is limited to OTAA end-devices. 443 4.5.2 Recommended Practice 444 For end-devices that support LoRaWAN 1.1+, the end-device SHALL initiate a re-keying event 445 through the transmission of a ReJoin Type 2 message. Network-side re-keying SHALL be 446 initiated via the ForceReJoinReq MAC command. Application re-keying MAY be initiated via 447 application-layer messaging or through an interface to the Network Server requesting it to 448 send the ForceReJoinReq MAC command. This enables the graceful re-keying of the-end- 449 device without interrupting the delivery of uplink messages. 450 End-devices that support versions of LoRaWAN prior to 1.1 MAY use Join-Request messages 451 to roll session keys. This technique re-keys the device at the expense of the end-device's 452 ability to continue to transmit uplink messages. Once the end-device issues a Join-Request, 453 uplink messages SHALL NOT be transmitted until a valid Join-Accept is received and 454 processed. In the case of downlink-only connectivity issues, the act of sending the Join- 455 Request will cause the end-device to no longer be able to deliver any uplink messages. As a 456 result, the decision to send a Join-Request while a security session is already established 457 SHOULD only be used as a last resort. There is no network-side facility to initiate a re-keying 458 event. It is RECOMMENDED that application layer re-keying initiation be supported by 459 LoRaWAN 1.0.x end-devices. 460 4.6 DevNonce Values SHALL Not Be Reused 461 4.6.1 Description 462 LoRaWAN requires DevNonce values (for any given DevEUI/JoinEUI pair), never be 463 reused. The simplest and most effective way to accomplish this is for the end-device to 464 increment the DevNonce for each Join-Request transmitted, starting at zero for the first Join- 465 Request. Refer to [TS001] for more information about DevNonce. 466 Join Servers keep a limited history of DevNonce values previously used by an end-device to 467 detect a Join-Request replay and will reject a Join-Request if it contains a DevNonce that has 468 been previously used. Using an incrementing DevNonce enables the Join Server to practically 469