Document

LoRaWAN® Specification v1.0.3

Issue link: https://read.uberflip.com/i/1428383

Contents of this Issue

Navigation

Page 34 of 71

LoRaWAN 1.0.3 Specification ©2018 LoRa™ Alliance Page 35 of 72 The authors reserve the right to change specifications without notice. DevNonce is a random value. 1 For each end-device, the network server keeps track of a 974 certain number of DevNonce values used by the end-device in the past, and ignores join 975 requests with any of these DevNonce values from that end-device. 976 Note: This mechanism prevents replay attacks by sending previously 977 recorded join-request messages with the intention of disconnecting the 978 respective end-device from the network. Any time the network server 979 processes a Join-Request and generates a Join-accept frame, it shall 980 maintain both the old security context (keys and counters, if any) and 981 the new one until it receives the first successful uplink frame using the 982 new context, after which the old context can be safely removed. This 983 provides defense against an adversary replaying an earlier Join-request 984 using a DevNonce that falls outside the finite list of values tracked by 985 the network server. 986 The message integrity code (MIC) value (see Chapter 4 for MAC message description) for a 987 join-request message is calculated as follows: 2 988 989 cmac = aes128_cmac(AppKey, MHDR | AppEUI | DevEUI | DevNonce) 990 MIC = cmac[0..3] 991 The join-request message is not encrypted. 992 The join-request message can be transmitted using any data rate and following a random 993 frequency hopping sequence across the specified join channels. It is recommended to use a 994 plurality of data rates. The intervals between transmissions of Join-Requests SHALL respect 995 the condition described in chapter 7. 996 6.2.5 Join-accept message 997 The network server will respond to the join-request message with a join-accept message if 998 the end-device is permitted to join a network. The join-accept message is sent like a normal 999 downlink but uses delays JOIN_ACCEPT_DELAY1 or JOIN_ACCEPT_DELAY2 (instead of 1000 RECEIVE_DELAY1 and RECEIVE_DELAY2, respectively). The channel frequency and data 1001 rate used for these two receive windows are identical to the one used for the RX1 and RX2 1002 receive windows described in the "receive windows" section of the "LoRaWAN regional 1003 physical layer specification" document 1004 No response is given to the end-device if the join request is not accepted. 1005 The join-accept message contains an application nonce (AppNonce) of 3 octets, a network 1006 identifier (NetID), an end-device address (DevAddr), a delay between TX and RX (RxDelay) 1007 and an optional list of channel frequencies (CFList) for the network the end-device is joining. 1008 The CFList option is region specific and is defined in the "LoRaWAN regional physical layer 1009 specification" document. 1010 1011 Size (bytes) 3 3 4 1 1 (16) Optional Join Accept AppNonce NetID DevAddr DLSettings RxDelay CFList 1 The DevNonce can be extracted by issuing a sequence of RSSI measurements under the assumption that the quality of randomness fulfills the criteria of true randomness 2 [RFC4493]

Articles in this issue

view archives of Document - LoRaWAN® Specification v1.0.3