Linux-Bluetooth Archive on
 help / color / Atom feed
From: Rafal Gajda <>
To: "Gix, Brian" <>
Cc: ""
	"Stotland, Inga" <>
Subject: Re: [PATCH BlueZ v4 5/5] mesh: Add NVM storage of Replay Protection
Date: Thu, 30 Jan 2020 09:55:25 +0100
Message-ID: <20200130085525.hmlrfexnwm5dehbb@rgajda2364> (raw)
In-Reply-To: <>

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

      reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-29  2:32 [PATCH BlueZ v4 0/5] mesh: Add NVM storage of Replay Protection List Brian Gix
2020-01-29  2:32 ` [PATCH BlueZ v4 1/5] mesh: Relocate tree deletion to util.c/h Brian Gix
2020-01-29  2:32 ` [PATCH BlueZ v4 2/5] mesh: Move Replay Protection to mesh/net.c Brian Gix
2020-01-29  2:32 ` [PATCH BlueZ v4 3/5] mesh: Clean-up unneeded Sequence Number increments Brian Gix
2020-01-29  2:32 ` [PATCH BlueZ v4 4/5] mesh: Apply Replay Protection to all incoming packets Brian Gix
2020-01-29  2:32 ` [PATCH BlueZ v4 5/5] mesh: Add NVM storage of Replay Protection Brian Gix
2020-01-29 12:17   ` Rafal Gajda
2020-01-29 15:06     ` Gix, Brian
2020-01-30  8:55       ` Rafal Gajda [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200130085525.hmlrfexnwm5dehbb@rgajda2364 \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Bluetooth Archive on

Archives are clonable:
	git clone --mirror linux-bluetooth/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-bluetooth linux-bluetooth/ \
	public-inbox-index linux-bluetooth

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone