Simultaneous JOIN REQ => ACCEPT to more than one node?

[Thomas Hermansson]

The following seems to happen in my testbed when I have many OTAA nodes and I can’t figure out what would prevent it:

1. multiple nodes in my network issues JOIN REQUEST at the same time (this can happen by chance or if they are powered on simultaneously)

2. gateway receives (at least) one of them successfully and responds with a JOIN ACCEPT assigning a DevAddr, thinking one node did a join req

3. all the nodes that did the JOIN REQUEST will receive the ACCEPT and think the JOIN ACCEPT was directed at them, and gladly sets the same received DevAddr

From here on, we have several nodes that all think they joined successfully and all think they are unique but have the same DevAddr. Needless to say, the system gets severely messed up.

Reading the LoRaWAN specification, the JOIN REQUEST has a node unique DevEUI, a network unique AppEUI, and a random DevNonce (to prevent replay attacks). The MIC is calculated from these and the secret network unique AppKey stored in the node.

The JOIN ACCEPT has, as far as I can see, no data in it which is derived from the JOIN REQUEST, and therefore it can’t be directed to a specific node in the case that many nodes are currently listening to an ACCEPT.

It has: AppNonce NetID DevAddr DLSettings RxDelay CFList, and is encrypted with the AppKey which is network unique and not node unique. The MIC only involves these values and so doesn’t help either.

I would have expected that the JOIN ACCEPT at the minimum includes the DevEUI requesting the join as a part of the MIC, and also that it would include the DevNonce. It seems it includes neither.

So I’m not sure this is a Multitech-specific problem but figured I’d post here as we are using this with a Multitech GW.

[Jason Reiss]

This issue can occur when the same appkey is used for end-devices.

The remedy is to use a unique key for each end-device.

Or add a confirmed uplink that must be responded to following the join accept. Only the intended device will create the correct session keys using its random devnonce.

Of course multiple end-device could randomly select the same devnonce for the join request and create the same keys.

[Thomas Hermansson]

Yes, some sort of higher-level protocol ping after the join would work, it’s just that radio bandwidth is so rare in some of these networks, that it’s a shame to have to do 2 extra packets for something that should have been included in the join handshake to begin with :/

Can the Multitech Conduit use separate appkeys for every node? In the .conf file there seem to be a network-wide AppKey.

[Jason Reiss]

There is limited support in the current release.

Our next release includes unique DevEUI/AppKey configuration as a main feature.

[Author]

Posts