This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Distributed Network - Frame counter reset



Dear TI-community,

as defined in the R21 specification there is no network key update mechanism for distributed networks. Therefore, the frame counter of devices in the network can't be reset during a network key switch.

As a result the device should stop sending frames when in reaches the maximum frame counter (probably in normal operation the frame counter will reach the maximum after years).

How is an end user supposed to handle this situation? Form a new network in order to reset the frame counter or reset the device?

Or is it believed that the frame counter won't reach the maximum before the end of the product lifetime?

Thanks in advance!

  • That is a great analysis of the situation, this is covered in SWRA615 and the Zigbee User's Guide:

    www.ti.com/.../swra615.pdf
    dev.ti.com/.../z-stack-overview.html

    Keep in mind that this is over 2 billion frames, or 12,275 packets per hour (204 per minute) over a 20 year lifetime. If this were somehow exceeded then I suppose a device or network reset would be required.

    Edit: Correct values are 4 billion frames, or 14,550 packets per hour (408 per minute).

    Regards,
    Ryan

  • Thanks for your quick answer!

    I'm not sure if you have a miscalculation, probably you have counted with 2^31. Why not 2^32, as this is the size of the frame counter?

    One more thing regarding the nwkAllFresh=False attribute, especially the following line.

    If storing this frame count and address information will cause the memory allocation for this type of information to be exceeded, and the nwkAllFresh attribute in the NIB is TRUE, then security processing shall fail and no further security processing shall be done on this frame

    If I understand correctly this means if there are already too many address-frame counter pairs on the receiving node, therefore there is no free allocated persistent/RAM space on the device to store a new address-frame counter pair, the frame check shouldn't be enforced. Am I right that this has nothing to do with checking the Frame Counter for freshness (Replay-Protection) as long as there is enough space for storing the address-frame counter pair?

    However, what I have encountered during cross-checking with books is that nwkAllFresh=False is described as deactivating the freshness check when the Frame Counter of a device overflows. However, if this is the case and all devices in the network behave as per standard, there won't ever be a frame with Frame counter 0xFFFF FFFF as the standard states:

    If the outgoing frame counter is equal to 2^32-1, or if the key cannot be obtained, security processing shall fail and no further security processing shall be done on this frame.

    I hope you can point me in the right direction.

  • You are correct about the size of the frame counter, the values from my initial reply can be doubled and this only greater proves the point. The Zigbee 2017 Specification even provides Network Frame Counter Usage Calculations in Section 4.3.4.1

    I believe you are correct that the passage selected does not have to do with checking the frame counter for replay protection (already covered in step 1 & 3 of 4.4.1.2). Outgoing frames may fail but nwkAllFresh concerns incoming frames (Section 4.3.3/Table 4-2), which is not controlled by the local device.

    Regards,
    Ryan
  • So do I assume rightly that setting nwkAllFresh to False has in practice no notable impact on the security of the network?

    Generally speaking centralized networks have a higher security, so what is the reason nwkAllFresh=False in centralized networks but not in decentralized ones? Especially because nwkAllFresh was set to False in the ZLL standard.

  • nwkAllFresh indicates whether incoming NWK frames must be all checked for freshness when the memory for incoming frame counts is exceeded. Regardless of security implications it is recommended that this NIB value remain at its default setting, as this is what the stack has been tested against. Otherwise you will need to generate a test to observe the behavior of your own accord.

    Regards,
    Ryan