This patchset fixes handling of IV Index during IV Update procedure:
- use incoming IV Index in both network and application/device nonce,
according to incoming IVI field
- use current IV Index when relaying packets, according to IV Update
state
See Mesh Profile v1.0.1, section 3.10.5.
Michał Lowas-Rzechonek (2):
mesh: Fixed handling of IVI flag in app layer
mesh: Use current IV Index when relaying
mesh/net-keys.c | 6 ------
mesh/net.c | 17 ++++++++---------
2 files changed, 8 insertions(+), 15 deletions(-)
--
2.19.1
If we are in IV Update state, packets shall be transmitted using IV
Index - 1, including relayed packets.
---
mesh/net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mesh/net.c b/mesh/net.c
index a5693f154..0a6ff8eac 100644
--- a/mesh/net.c
+++ b/mesh/net.c
@@ -2512,7 +2512,7 @@ static void net_rx(void *net_ptr, void *user_data)
relay_advice = packet_received(net, key_id, iv_index,
out, out_size, rssi);
if (relay_advice > data->relay_advice) {
- data->iv_index = iv_index;
+ data->iv_index = mesh_net_get_iv_index(net);
data->relay_advice = relay_advice;
data->key_id = key_id;
data->net = net;
--
2.19.1
On 06/27, Michał Lowas-Rzechonek wrote:
> If we are in IV Update state, packets shall be transmitted using IV
> Index - 1, including relayed packets.
> ---
> mesh/net.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mesh/net.c b/mesh/net.c
> index a5693f154..0a6ff8eac 100644
> --- a/mesh/net.c
> +++ b/mesh/net.c
> @@ -2512,7 +2512,7 @@ static void net_rx(void *net_ptr, void *user_data)
> relay_advice = packet_received(net, key_id, iv_index,
> out, out_size, rssi);
> if (relay_advice > data->relay_advice) {
> - data->iv_index = iv_index;
> + data->iv_index = mesh_net_get_iv_index(net);
Ew, I misread the spec.
3.4.6.3 explicitly says:
"When a message is retransmitted, as defined below, the IV Index used
when retransmitting the message shall be the same as the IV Index when
it was received"
Please disregard this patch.
cheers
--
Michał Lowas-Rzechonek <[email protected]>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND
Hi Michal,
> -----Original Message-----
> From: [email protected] [mailto:linux-bluetooth-
> [email protected]] On Behalf Of Michal Lowas-Rzechonek
> Sent: Thursday, June 27, 2019 12:41 AM
> To: [email protected]
> Cc: Gix, Brian <[email protected]>
> Subject: [PATCH BlueZ v3 2/2] mesh: Use current IV Index when relaying
>
> If we are in IV Update state, packets shall be transmitted using IV Index - 1,
> including relayed packets.
> ---
> mesh/net.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mesh/net.c b/mesh/net.c
> index a5693f154..0a6ff8eac 100644
> --- a/mesh/net.c
> +++ b/mesh/net.c
> @@ -2512,7 +2512,7 @@ static void net_rx(void *net_ptr, void *user_data)
> relay_advice = packet_received(net, key_id, iv_index,
> out, out_size, rssi);
> if (relay_advice > data->relay_advice) {
> - data->iv_index = iv_index;
> + data->iv_index = mesh_net_get_iv_index(net);
I don't think this is correct. *relayed* packets must preserve the originators IV_Index...
At most, two different IV_Index values are considered valid at any time in the mesh. Each node has it's own sense as to what the *Network* IV_Index is, and it shall accept that IV_Index, and 1 less... With this difference reflected in the IVI bit of the first octet.
When acting as a relay, incoming messages must be one of these two settings to be recognized, but after decrementing TTL and re-encrypting, the IV_Index of the original sender must be preserved. The iv_index is part of both the Network nonce and the Access layer nonce. If a relay uses a different nonce than the originator (SRC), then the receiving DST device will be unable to decrypt the Access layer using the same nonce as the repackaged Network layer.
> data->relay_advice = relay_advice;
> data->key_id = key_id;
> data->net = net;
> --
> 2.19.1
Brian,
On 06/27, Gix, Brian wrote:
> I don't think this is correct. *relayed* packets must preserve the
> originators IV_Index...
Correct. I realized my mistake and quoted the appropriate section of the
spec - there is a message about it on the list.
The other patch stands, though - as it happens, our network is in the
middle of IV Update at the moment and I've been getting failures about
decrypting application payloads.
cheers
--
Michał Lowas-Rzechonek <[email protected]>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND