# Quarantining Malicious IoT Devices in Intelligent Sliced Mobile Networks
## 4 Results
### Dynamic Reassignment
Then, we complete different steps and measure their times: Instruct the Docker engine to deploy a S/P-GW container and wait for the container to be deployed, wait for the S/P-GW container to be properly initialized, instruct the SDN application running on top of the ONOS SDN controller to replicate the context of the UE in the S/P-GW of the IoT NS to the new S/P-GW corresponding to the Quarantine NS and finally instruct the SDN controller to reconfigure the flow rules of the SDN switch to send the traffic of the UE to the S/P-GW in the Quarantine NS. We verified that the UE continued attached to the network during the whole process. For complete clean-up of the experiment before subsequent executions, we disconnected the UE, stopped the eNodeB and removed all Docker containers corresponding both to the Core Network entities of both slices and also the SDN controller. This experiment was run 100 times for statistical significance. Table 3 shows the time required for reassigning a device from the IoT NS to the Quarantine NS and the individual contributions to this time, averaging 100 independent executions. The first fact we can notice is the stability of the results through the different executions. Their variability is very low except for \(\Delta_{4}\). We can see that the total time required for moving one device to the Quarantine NS (\(\Delta\)) is about 1 s. An inspection of this time reveals that the major contribution came from the deployment of the S/P-GW Docker container (\(\Delta_{1}\)) and the initialization of the S/P-GW software (\(\Delta_{2}\)), which took about 600 ms and 400 ms, respectively. On the other hand, S/P-GW state replication (\(\Delta_{3}\)) was an order of magnitude lower requiring less than 40 ms, while data-plane reconfiguration (\(\Delta_{4}\)) took less than 10 ms. Note that the results for \(\Delta_{4}\) are in line with recent measurements of flow setup times in SDN-enabled switches [45]. This reassignment time in the order of one second determines the reaction speed of the first stage of our proposed solution. Since the legitimate devices redirected to the Quarantine NS will be reassigned back to the IoT NS, the time this takes is also relevant for our solution. However, note that this action simply requires a data plane reconfiguration, because the IoT NS is already deployed, the S/P-GW is initialized and it has the required state. As a result, moving a device back to the IoT NS is a lightweight process taking less than 10 ms as measured in \(\Delta_{4}\) in Table 3.  
Furthermore, the process of moving a device to the Quarantine NS as described is fully reactive, comprising the deployment of new data plane resources on demand. As analyzed, this part is indeed the most time consuming in the whole reassignment process. We thus propose as an alternative a proactive approach for reducing reassignment time: Instead of creating the S/P-GW in the Quarantine NS as part of the reassignment process, a S/P-GW can be proactively created and initialized simultaneously to the IoT NS. This way, the reassignment time (\(\Delta\)) will correspond to the contributions of replicating the state of the device in the IoT S/P-GW (\(\Delta_{3}\)) and reconfiguring the data plane (\(\Delta_{4}\)), which adds up to less than 50 ms on the worst case. This time can be further reduced by proactively replicating the state of the devices in the IoT S/P-GW to the Quarantine S/P-GW, maintaining state consistency between both entities. In this latest configuration, \(\Delta\) is fully minimized for the proposed architecture, yielding a value of less than 10 ms for \(\Delta_{4}\). It is important to bear in mind the trade-off introduced by the proactive approach in terms of increased resource usage due to the permanent deployment of the S/P-GW in the Quarantine NS and the control information overhead by maintaining full state consistency between the S/P-GW entities.