Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 30 Jan 2020 09:55:25 +0100
From:   Rafal Gajda <rafal.gajda@silvair.com>
To:     "Gix, Brian" <brian.gix@intel.com>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        "Stotland, Inga" <inga.stotland@intel.com>
Subject: Re: [PATCH BlueZ v4 5/5] mesh: Add NVM storage of Replay Protection
Message-ID: <20200130085525.hmlrfexnwm5dehbb@rgajda2364>
References: <20200129023258.10004-1-brian.gix@intel.com>
 <20200129023258.10004-6-brian.gix@intel.com>
 <20200129121744.zv3jnf6uejjpetud@rgajda2364>
 <a49f5f0c9633bacfcbe6f2125aece235ac34e90f.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <a49f5f0c9633bacfcbe6f2125aece235ac34e90f.camel@intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

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