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;
From:   "=?utf-8?Q?Micha=C5=82?= Lowas-Rzechonek" 
        <michal.lowas-rzechonek@silvair.com>
Date:   Mon, 30 Mar 2020 17:27:26 +0200
To:     linux-bluetooth@vger.kernel.org
Cc:     Brian Gix <brian.gix@intel.com>,
        =?utf-8?Q?Przemys=C5=82aw?= Fierek 
        <przemyslaw.fierek@silvair.com>
Subject: Application vs Network nonce in segmented messages
Message-ID: <20200330152130.gf5jkgalya34mj2e@kynes>
Mail-Followup-To: linux-bluetooth@vger.kernel.org,
        Brian Gix <brian.gix@intel.com>,
        =?utf-8?Q?Przemys=C5=82aw?= Fierek <przemyslaw.fierek@silvair.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Brian,

A question: when poking around the code looking for places where I
should fix the net key index, I've noticed a peculiar thing in
mesh/net.c:

	if (msg->segmented) {
		/* Send each segment on unique seq_num */
		seq_num = mesh_net_next_seq_num(net);
		...

This means that for segmented messages, if sequence number used on the
transport layer is, say, N, then the first segment is encrypted with
sequence number N + 1 on *network* layer.

While I think it's legal from the spec point of view, I can't think of a
reason to do so. Can you please shed some light on that line?

regards
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND