Re: [PATCH BlueZ v4 5/5] mesh: Add NVM storage of Replay Protection

[Rafal Gajda <rafal.gajda@silvair.com>]

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