On Wed, Jan 29, 2020 at 03:06:10PM +0000, Gix, Brian wrote: > Hi Rafał, > > On Wed, 2020-01-29 at 13:17 +0100, Rafal Gajda wrote: > > Hi Brian, > > > > I have a question about the way RPL is stored. > > > > On Tue, Jan 28, 2020 at 06:32:58PM -0800, Brian Gix wrote: > > > Mesh specification requires that Replay Protection be preserved > > > across node restarts. This adds that storage in > > > <node_uuid>/rpl/<iv_index>/<src> > > > > Wouldn't it be more convinient to keep both iv_index and sequence in a file like this: > > <node_uuid>/rpl/<src> > > ? > > > > You could store them in bytes instead of hex string > > and it would eliminate the need for cleaning entries from old IV_index. > > > We considered this and decided against it for ease of processing, as this method requires fewer file > operations. Cleaning old entries is something that will happen regardless of how the RPL tree looks in the > file system, as we delete entries that are older than (net->iv_index - 1) since we don't receive messages on > that iv_index, there is no possiblility of a Replay attack. And deleting a file system tree is pretty simple. > A SRC address does not get to keep it's spot in the RPL indefinitely... only over the current or prior > iv_index. > > Our other considerations included maintaining the integrity of the RPL across power-loss or abort reboots. > > However, we do recognize that some platforms may different NVM storage available that can be optimized in > different ways, so we tried to keep the NVM RPL apis as simple as possible to allow others to optimize the > storage as they see fit. For instance, if someone was to port this to an embedded system without a standard > linux file system. Ok, I understand. Thank you for the explanation. Rafał Gajda Silvair
