Replay protection cache entry aging out

[Richard R]

Hello,

I wanted to confirm my understanding of the Replay protection cache. In the code, the limit is set to REPLAY_CACHE_ENTRIES and there is a note that says:

@note The number of entries in the replay protection list directly limits the number of elements
a node can receive messages from on the current IV index. This means if your device has a replay
protection list with 40 entries, a message from a 41st unicast address (element )will be dropped
by the transport layer.

But don't the entries gets aged out? for example when the Sequence number is about to be exhausted and the network have to initiate the IV update procedure and calls 
on_iv_update(); Is the code note there because the IV is typically not expected to change for days (with 96 hours minimum) or is there another protection mechanism I am missing?

Thanks for everyone's time

[tesc]

Hi,

The replay protection list is a table of element addresses and the highest known sequence number being received from that address. As you wrote, the IV Index lasts for at least 96 hours, often longer depending on how long it takes for the first node to run out of sequence numbers. I don't think there are any other protection mechanism that you are missing, no.

In general it would then be wise to keep REPLAY_CACHE_ENTRIES a bit higher than the expected number of elements sending messages to your node, to account for node replacements and network reconfigurations. (It would be a bit annoying to have to wait for the next IV Index rollover before the node can receive messages from new element addresses.)

Regards,
Terje