# Multi-Mobile Agent Trust Framework for Mitigating Internal Attacks and Augmenting RPL Security
## 3 Proposed Framework
### The Workflow at a Glance  
The architecture and the steps involved in MMTM-RPL are illustrated in Figure 3 and Algorithm 5, and the flow is listed below:  
1. The topology finder module sends a request to the gateway to deploy the RPL topology. 2. The gateway deploys the topology, and details are sent back to the topology finder module, which forwards these details to the cluster builder module. The topology finder looks for changes to the topology (i.e., nodes joining and leaving). It updates the cluster builder module as soon as it identifies a change. 3. The cluster builder module creates logical clusters based on Euclidean distance. If the distance for any node is lower than a threshold, it is dropped from the cluster. This task is repeated every time a node joins or leaves the network dynamically. 4. Once the clusters are created, their details are forwarded to the itinerary planner. 5. The route optimizer module, a sub-module of the itinerary planner, looks for optimized paths in the given RPL based on the logical clusters. Once these are found, the itinerary planner module sets all the details of them for each cluster. Multiple MAsare created by the itinerary planner module for each cluster, and a unique MD5 hash key for a cluster is assigned to each MA by the security provider module. The same unique key is shared with the gateway for (later) MA verification. 6. The MAs are forwarded to the MA distributor module. 7. The MA distributor module sends the MAs to the gateway, which authenticates each MA using the unique key set earlier by the security provider module. If an MA fails authentication, a new MA is initiated dynamically for the itinerary. 8. Once an MA is authenticated, it is allowed by the gateway to visit its specified cluster to fetch trust-related data. 9. After an MA has collected data, the gateway forwards it to the trust scrutineer module. 10. The trust scrutineer module calculates the trust for each node. If a node is deemed to be malicious, it is dropped from the network. Figure 3: Workflow of the proposed MMTM-RPL framework. The numbers in the figure represent the steps taken for malicious node detection and isolation. ```
1:parameters: \(\alpha\), \(\beta\), \(p\), \(n\), \(k\), \(d\)
2:initialize variables:
3:\(\alpha\) = threshold for max. PDR
4:\(\beta\) = threshold for max. changing MAC address
5:\(p_{s}=0\)
6:\(n_{g}=0\)
7:\(k=2\)
8:\(d\) = time slot
9:trust parameters: \(RANK\), \(PDR\), \(\rho\)
10:calculate trust parameters:
11:\(RANK\) = RPL-DODAG \(\triangleright\) initialize rank of each node
12:\(PDR=\left(\frac{\text{dropped packets}}{\text{total no. of packets}}\right)\)
13:\(\rho=\frac{MAC}{d}\)
14:for all nodes do
15: evaluate sinkhole:
16:if\(PDR>\alpha\)then
17:\(n_{g}=n_{g}+1\)
18:else
19:\(p_{s}=p_{s}+1\)
20:endif
21: evaluate Sybil:
22:if\(\rho>\beta\)then
23:\(n_{g}=n_{g}+1\)
24:else
25:\(p_{s}=p_{s}+1\)
26:endif
27: evaluate rank:
28:if\(Rank_{xi}==Rank_{xj}\)then
29:\(n_{g}=n_{g}+1\)
30:else
31:\(p_{s}=p_{s}+1\)
32:endif
33:endfor
34: calculate \(b_{l}\), \(d_{s}\), and \(u_{n}\):
35:\(b_{l}=\left(\frac{p_{s}}{(p_{s}+n_{g}+k)}\right)\)
36:\(d_{s}=\left(\frac{n}{(p_{s}+n_{g}+k)}\right)\)
37:\(u_{n}=\left(\frac{k}{(p_{s}+n_{g}+k)}\right)\)
38: node rating or malicious node detection:
39:if\(b_{l}>0.5\)then
40: node \(\rightarrow\) legitimate node
41:elseif\(d_{s}>0.5\)then
42: node \(\rightarrow\) sinkhole/Sybil/rank/malicious
43:else
44: node \(\leftarrow\) uncertain
45:endif
46: node mitigation:
47:if node == attacker then
48: remove from topology
49:else
50: select for routing
51:endif
```  
**Algorithm 4** Malicious node detection and isolation.