## 6 On Control Messages Protection
### SeFLOOD: The Secure FLOOD
#### 6.3.1 Secure Network Reconfiguration  
SeFLOOD also supports mobile nodes, without adding overhead in terms of number of messages. In fact, it exploits FLOOD messages sent by a mobile node in order to distribute the cluster keys. We assume that nodes have loosely synchronized clocks. This assumption is reasonable because nodes periodically emerge and synchronize their clocks with GPS, for example.  
Assume that \(u_{m}\) is a mobile node wishing to leave the network. Then, it triggers the following protocol:  
(1) \(u_{m}\to GW\): \(\left\langle\mathtt{DEL},u_{m},\tau_{m}\right\rangle_{e_{u_{m}}}\)  
(2) \(GW\to u_{i}\): \(\left\langle\mathtt{BEST},u_{m},\tau_{g},\mathtt{routing}-\mathtt{updates}_{i} \right\rangle_{e_{u_{i}}}\)  
Initially, \(u_{m}\) sends the gateway a DEL message M6.3.1 specifying its identifier and a timestamp \(\tau_{u_{m}}\). The message is protected by means of the node end-to-end key \(e_{u_{m}}\).  
Upon successfully receiving message M6.3.1 (otherwise the message is discarded), the GW deletes \(u_{m}\) from the routing tables, updates the routing tables, and sends a BEST message to every node \(u_{i}\) whose routing table needs to be updated (message M6.3.1). The message specifies the identifier \(u_{m}\) of the leaving node, a fresh quantity \(\tau_{g}\) and the updates to be applied to the routing table. The message is protected by means of the end-to-end key \(e_{i}\). Upon successfully receiving message M6.3.1 (otherwise the message is discarded), node \(u_{i}\) updates its own routing table as specified in the message, by replacing the entries containing \(u_{m}\) with the new ones calculated by the GW.  
Assume now that the mobile node \(u_{m}\) wants to join again the network. The node \(u_{m}\) triggers the following protocol:  
(1) \(u_{m}\rightarrow*\): ADD, \(u_{m}\), \(\
u_{um}\)  
(2) \(u_{i}\to u_{m}\): \(\left\langle\mathtt{ADD}-\mathtt{ACK},\
u_{um},\tau_{i},c_{u_{i}}\right\rangle_{e _{im}}\)  
(3) \(u_{m}\to u_{i}\): \(\left\langle\mathtt{ADD}-\mathtt{ACK},\tau_{i},c_{u_{m}}\right\rangle_{e_{im}}\)  
(4) \(u_{m}\rightarrow\) GW: \(\left\langle\mathtt{ADD}-\mathtt{REPORT},\tau_{u_{m}},\mathcal{C}_{u_{m}} \right\rangle_{e_{m}}\)  
(5) GW \(\to u_{i}\): \(\left\langle\mathtt{ADD}-\mathtt{BEST},\tau_{i},\mathtt{routing}-\mathtt{updates }_{i}\right\rangle_{e_{i}}\)  
Initially, node \(u_{m}\) broadcasts an ADD message (M6.3.1) carrying its identifier and a nonce \(\
u_{u_{m}}\). Upon receiving message M6.3.1 from \(u_{m}\), a node \(u_{i}\) replies by means of an ADD-ACK message (M6.3.1) carrying a timestamp \(\tau_{i}\), the node cluster key \(c_{u_{i}}\), and the received nonce \(\
u_{u_{m}}\), all encrypted with the link key \(\ell_{im}\). Upon successfully receiving message M6.3.1 from \(u_{i}\) (otherwise the message is discarded), node \(u_{m}\) replies by sending a ADD-ACK message (M6.3.1) carrying the node cluster key \(c_{u_{m}}\) and the timestamp \(\tau_{i}\), all encrypted with the link key \(\ell_{im}\). Then \(u_{m}\) sends the gateway GW the members of its cluster \(\mathcal{C}_{u_{m}}\) (message M6.3.1). Finally the GW sends all the nodes \(u_{i}\) (included \(u_{m}\)) whose routing table needs to be updated an ADD-BEST message (message M6.3.1), carrying the updates to the respective routing table. The message contains also the timestamp \(\tau_{i}\) encrypted with \(e_{i}\) in order to guarantee its freshness. Upon successfully receiving this message (otherwise the message is discarded), each node applies the specified updates to its own routing table.