【Mesh】关于Mesh中Seq+IV与RPL分析

一，Mesh中SEQ,IV,RPL的含义

1，SEQ(Sequence Number)

SEQ是包含在网络 PDU 的 SEQ 字段中的 24 位值，主要用于防止重放攻击。同一节点内的元素可能会或可能不会彼此共享SEQ。在每个消息源（由 SRC 字段中包含的单播地址标识）的每个新网络 PDU 中具有不同的序列号对于网状网络的安全性至关重要。

最大值：0xFFFFFF, 24 位序列号，一个元素可以在重复一个随机数之前传输 16,777,216 条消息。如果一个元素平均每 5 秒发送一次消息（对于已知用例来说是一个相当高频率的消息），则该元素可以在随机数重复之前传输 2.6 年。

这里提到几个关键词：5秒发一次seq累加1，可用2.6年！SEQ累加到最大值后就需要对IV做进位处理了，这里就需要提到下一个关键词IV.

2，IV(Initialization Vector)

IV Index 是一个 32 位的值，它是共享网络资源（即，网状网络中的所有节点共享相同的 IV Index 值并将其用于它们所属的所有子网）。

最大值：0xFFFFFFFF, 每次seq加到最大值后，IV进行累加，网络状态按照mesh spec说明最大可应用5万亿年，足够我们使用了。

这里延申一个关键词：IVI(Initialization Vector Index)，由于有限的广播信道数据传输（即小于31），SIG制定规范时未将3+4字节信息全部包含在Network PDU中，但是包含了最低IV有效位，这个有效位就叫做IVI。

3，RPL(Relay Protection List)

在描述RPL前，我们需要弄清除什么是重放攻击：有合法的元素发起方发送出去的消息可以被攻击者被动接收，然后在不进行任何修改的情况下重新发出。

RPL本质：1，网络设备列表。2，记录了当前网络周边设备的唯一地址和SEQ。

RPL目的：1，防重放攻击。2，Mesh Relay的基础

RPL限制条件：1，单片机存储资源有限，无法对所有在网设备进行存储。2，以200个存储（大部分原厂可提供200，甚至到100的RPL）方式来计算，每个配网设备按照一个element来计算的话，可以存储200个设备列表。如果按照2个element来计算（如mesh开关，每一个开关为一个element），也就只能存储100个设备了。剩下设备我们就无法做到防重放攻击了。

注：关于存储机制与设计方式，各个厂商有些许不同，在下文具体描述。

二，Mesh Seq与IV更新机制分析

1，更新过程分析：

（1）：每发一条信息，seq自加，即seq++；
（2）：Seq到达最大值后，需要更新IV,即iv++；
（3）：由于网络中只存在一个iv，所以我们要通知其它设备更新iv（即便他们的seq没到最大值），这个更新的过程就叫做IV Update。
（4）：通过SNB（Secure Network Beacon）的消息来实现IV Update。

2，IV Update存在如下场景：

（1）：IV Update过程中正常更新
（2）：设备突发断电或进入低功耗模式无法收发数据，触发IV Recovery

3，IV Update如何实现

传输IV Update的数据格式：

（1）：基本描述（参考Mesh Spec 3.10.5 IV Update procedure）
IV 索引为应用层和网络层中用于认证加密 (AES-CCM) 的随机数提供熵。因此，必须经常更改它以避免在nonce中重复使用sequence numbers。 IV 更新过程由作为主子网成员的任何节点启动。当节点认为它有耗尽其序列号的风险时，或者它确定另一个节点即将耗尽其序列号(sequence numbers)时，可以这样做。节点更改其 IV 索引并向网络中的其他节点发送 IV 索引正在更新的指示。然后，网络中的相同或某个其他节点会更改回正常操作。

在密钥索引不同于 0x000 的连接子网上，至少一个安全网络信标状态设置为 1 的节点也必须位于主子网上。
IV 更新程序定义了两种操作状态：

Normal Operation： IV Update Flag = 0
IV Update in Progress：IV Update Flag = 1

在正常操作状态期间，安全网络信标和朋友更新消息中的 IV 更新标志应设置为 0。
当此状态处于活动状态时，节点应使用当前 IV Index进行传输，并应处理来自当前 IV Index 以及当前的 IV Index - 1的消息。
例如， IV Update Flag 设置为 0， current IV Index 等于 0x00101847 时，这个节点发送消息的 IV Index为0x00101847，接收消息的两种情况：

网络层的 IVI 字段设置为 1时，IV Index为0x00101847。
网络层的 IVI 字段设置为 0时，IV Index为 0x00101846 。

（2）：任意一端接收到Secure Network Beacon后存在如下场景：
场景一：
如果正常操作中的节点，接收到一个安全网络信标，其 IV Index大于最后一个已知 IV Index + 1 ，它可以启动 IV 索引恢复过程（IV Index Recovery procedure）。

场景二：
如果正常操作中的节点，接收到一个安全网络信标，其 IV Index等于最后一个已知的 IV Index +1 并且 IV 更新标志设置为 0，则该节点根据
根据自上次 IV Update以来的时间
节点错过 IV update Flag设置为 1 安全网络信标的可能性
做出如下三种可能的选择

可能会直接更新其 IV 而不进入 IV Update正在进行状态，
或者它可能会启动 IV 索引恢复过程，
或者它可能会忽略安全网络信标。

（3）：关于约定熟成的规定
3.1 节点启动 IV Update过程的频率不得超过每 192 小时一次。

3.2 在正常操作中运行 96 小时后，节点可以通过转换到 IV 更新进行中状态来启动 IV 更新过程。当节点从正常操作状态转换到 IV 更新进行中状态时，节点上的 IV 索引应增加 1。

3.3 从正常操作状态到 IV 更新进行中状态的转换必须在序列号用完之前至少 96 小时发生。

3.4 处于正常操作状态的节点接收并接受 IV 更新标志设置为 1 的安全网络信标（指示 IV 更新进行中状态）应尽快转换到 IV 更新进行中状态。

3.5 在 IV 更新进行中状态期间，安全网络信标和好友更新消息中的 IV 更新标志应设置为 1。当此状态处于活动状态时，节点应使用当前 IV Index - 1 进行传输，并处理接收消息从current IV index - 1 以及current IV index。

例如，如果在从 Normal Operation 状态转换到 IV Update in Progress 状态之前 IV Index 为
0x00101847，则转换后，IV Update Flag 将为 1，当前 IV Index 将为 0x00101848。节点应使用
IV 索引 0x00101847 进行发送，并接收如下两种情况的消息：

（1）在网络层中的 IVI 字段设置为 1 时，使用 IV 索引 0x00101847 接收消息；

（2）当网络层中的 IVI 字段设置为 0 时，使用 IV 索引 0x00101848 接收消息。

这允许所有处于正常操作状态的节点使用旧的 IV 索引向该节点发送消息，该节点向那些尚未转换的节点发送消息。

3.6 在 IV Update in Progress 状态下运行 96 小时至 144 小时之间时，节点应转换回 IV Normal Operation 状态并且不更改 IV Index。在转换点，节点应将序列号重置为 0x000000。

例如，当转换回正常操作状态时，IV 更新标志将为 0，当前 IV 索引将为 0x00101848，节点应使用 IV 索引
0x00101848 发送，并接收如下两种情况的消息：

（1）当网络层中的 IVI 字段设置为 1 时，使用 IV 索引 0x00101847 接收的消息

（2）当网络层中的 IVI 字段设置为 0时，使用 IV 索引0x00101848接收的消息。

这允许节点向网络中的所有节点发送消息，无论它们是否也处于正常操作状态或处于 IV 更新进行中状态。它还允许节点从处于正常操作状态或 IV
更新进行状态的所有节点接收消息。

下表提供了 IV 更新程序的摘要：

IV Index	Flag	Procedure State	Accepted	transmitting
n	0	Normal	n-1, n	n
n+1	1	In Progress	n,n+1	n
n+1	0	Normal	n,n+1	n+1

3.7 处于 IV 更新进行中状态的节点，接收并接受了 IV 更新标志设置为 0（指示正常操作状态）的安全网络信标，应尽快转换到正常操作状态。

当节点已发送分段访问消息或分段控制消息而未接收到相应的分段确认消息时，节点应将状态更改从进行中的 IV
更新推迟到正常操作，如本程序所定义。当收到适当的段确认消息或达到此消息传递的超时时间时，应执行延迟的状态更改。

注意：此要求是必要的，因为在完成 IV 更新过程后，序列号将重置为 0x000000，并且 SeqAuth 值将无效。

3.8 当一个节点被添加到网络中时，该节点被赋予一个 IV 索引。如果在网络处于正常运行状态时将节点添加到网络，则它应在正常运行状态下运行至少 96 小时。如果在网络处于 IV Update in Progress 状态时将节点添加到网络，则应赋予该节点新的 IV Index 值并在正常操作中运行至少 96 小时。

三，IV Recovery如何实现

一个节点应该支持IV索引恢复过程，因为一个节点长时间远离网络可能会错过IV更新过程，在这种情况下它不能再与其他节点通信。为了恢复 IV 索引，节点必须侦听安全网络信标，其中包含网络 ID 和当前 IV 索引。在接收并成功验证其 IV 索引比当前已知 IV 索引高 1 或更多的主子网的安全网络信标后，节点应根据此安全网络中的值设置其当前 IV 索引及其当前 IV 更新过程状态信标。
注意：在 IV 指数恢复程序更新 IV 指数后，改变 IV 更新程序状态的 96 小时时间限制（如 IV 更新程序中定义）不适用。
鉴于节点每 10 秒集体传输一次安全网络信标，低占空比节点将必须平均侦听 5 秒以在传输和接收网格消息之前恢复当前的 IV 索引。如果 Low Power 节点没有足够的电量来监听 5 秒，那么它必须通过至少每 96 小时轮询一次它的 Friend 节点来保持与当前 IV 索引的最新状态。
节点在 192 小时内不得执行超过一次的 IV 索引恢复。

四，Mesh中Seq，IV，RPL存储机制分析

1，分析前说明
Flash的读写寿命是有限的，频繁写入Seq+IV与RPL肯定会对flash有一定影响，为应对该问题，每个厂商都有去设计一套如何存储seq，iv，rpl的机制。

2，关于rpl存储机制分析
（1），前面说到Mesh RPL记录了当前网络节点的seq+unicast address，seq一直在更新，频繁的更新seq必定不可以频繁的存储，这里就引入步进的方式，我们以zephyr mesh provisioner为例，存储rpl的时间为接收倒数计时600s，如果连续时间内没有更新，我们将根据最新的rpl信息进行存储。
（2），关于新增的节点信息，如果超出阈值，我们将循环保存。

3，关于seq，iv存储机制分析
我们说到设备节点端的seq变更，这里也涉及当前发送端seq+iv的存储。每发送一次数据seq++，还是以zephyr mesh provisioner为例，这里就需要引入步长来说明了，当每递增的seq到达128时，我们进行存储，如果出现重新上电，我们默认自加128减一以应对掉电场景。即：如果mesh网关向已配网设备节点上电后发送一条消息，此时seq = 127 + 1，突然掉电后，下次上电后mesh网关发送的seq值则为127+ 128 - 1= 254，如此往复。