Announce messages can cause instability in neighbouring but distinct networks

[marco85mars20]

Bug description
This might be not an OpenThread bug, but more a limitation in the Thread specs.

When an Announce message is received, in case:

• isFromOrphan = false
• timestampCompare = 1
• channelAndPanIdMatch = 0

the device receiving the Announce message will attempt to attach to the announced partition by using the new channel and PAN-ID (kAnnounceAttachAfterDelay). This is correct when the device was previously part of the same partition and shares the same network-key as the one used by the announcing device.

However, in case the receiving device was part of a Thread network that was intended to remain separated from the other, this causes the device to continuously disconnect from its original partition, and attempt to join the announced one, and most likely this procedure will fail and the device will join back the previous partition. This introduces instability on a mesh network, especially if the affected device is a Router.

How to reproduce

1. latest main
2. not relevant
3. not relevant
4. Two distinct and overlapping Thread network with different Datasets

Expected behavior
A device actively part of a mesh network shall not attempt to connect to a different partition whenever an announce message is received just because it's got a bigger Active TimeStamp.
I am not sure how to prevent this from affecting devices part of distinct but overlapping mesh networks. I can only think of:

• expecting that at least the PAN-ID match
• the receiving device has to be in Detached state (as already done when timestampCompare < 0)
• place the PAN-ID (or the announcing device, eg. Extended MAC) in a (temporary) denylist in case the joining process fails one or more times (in a given time-window) - failing to join the announced partition might be related to poor RSS, or worse, because of different network-key or joiner credentials.

[jwhui]

Reviewing the behavior described, it appears the instability is a result of the two overlapping Thread networks sharing the same Thread Network Key.

In OpenThread (and per the Thread specification), MLE Announce messages are secured using the MLE encryption key, which is derived from the Thread Network Key. When a node receives an Announce message:

1. Security Validation: It first verifies the message's authenticity. If the networks are configured with different Network Keys, the security check will fail, and the message will be dropped without further processing.
2. Network Membership: If the security check passes, the receiving node identifies the sender as part of the same security domain. From the perspective of the Thread MLE layer, these devices are considered part of the same network.
3. Dataset Synchronization: The node then compares the Active Timestamp. If the received timestamp is newer, the node assumes the network has migrated or updated its Dataset and attempts to follow the new configuration (Channel and PAN ID) to maintain connectivity with its network.

To ensure that two overlapping Thread networks remain completely separate and do not process each other's Announce messages, they must be configured with different Thread Network Keys. This ensures that cross-network MLE traffic is filtered at the security layer, preventing the instability you've observed.

[marco85mars20]

Thank you Jonathan for the detailed explanation.

I initially jumped to the wrong conclusion based on the observed behaviour, the expected device configuration, and an assumption (also reinforced externally) that Announce messages are not encrypted.
I later confirmed that the announcing device was actually using the same network key as the receiving devices, which fully aligns with your explanation.

I would appreciate your suggestions on the following scenario:
I have a remote mesh network composed of:

• one Backbone Border Router (BBR)
• ~150 FTD devices (some with router eligibility disabled)
  I have CLI access to the deployed devices.

My goal is to deploy a new BBR and migrate a subset of the mesh to a different dataset (i.e. different channel and network key).
However, I understand that when using dataset CLI commands, Router and REED devices may propagate the new dataset on the existing channel.

Is there a way to perform this migration while preventing the new dataset from leaking to devices that are intended to remain on the original network?

[jwhui]

Unfortunately, Thread does not currently provide a standard way to segment networks like this. You could implement some application logic to implement this.

[marco85mars20]

I have implemented some logic that, when a device is selected to join a different mesh network:

• it disables router-eligibility
• set dataset to contain only the new network-key
• optionally set a preferred channel (if known)
• after finding and joining the new network, it waits to detect the BBR service, and then re-enable router-eligibility

Can you confirm that FTD End Devices, ie. with Router Eligible disabled, after acquiring a new commissioned/full dataset (either via CLI dataset commands, or via their current parent, or at the time of joining a new partition), they would not broadcast the new dataset, especially on previous channel(s) even at a later time when router-eligibility is enabled again?

Thanks

[jwhui]

Yes, I believe that is the case, but I haven't tested it myself.