Linux-Bluetooth Archive on
 help / color / Atom feed
From: "Gix, Brian" <>
To: "" <>
Cc: ""
	"Stotland, Inga" <>
Subject: Re: [PATCH BlueZ v4 5/5] mesh: Add NVM storage of Replay Protection
Date: Wed, 29 Jan 2020 15:06:10 +0000
Message-ID: <> (raw)
In-Reply-To: <20200129121744.zv3jnf6uejjpetud@rgajda2364>

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

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.

  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 [this message]
2020-01-30  8:55       ` Rafal Gajda

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 \ \ \ \ \ \

* 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