# Mitigating Timing Side-Channel Attacks in Software-Defined Networks: Detection and Response +
## 4 Experiments and Results  
The base simulator for the experimental stages was Mininet [54], which was deployed on a Linux-based virtual machine (VM1). As an SDN controller, we used RYU [55], which was deployed as a remote controller. Considering both the processing resources required by Mininet and how to create a realistic SDN scenario, we installed an RYU controller on a separate virtual machine (VM2). In the application layer, we utilised RYU apps integrated with custom Python-based applications. Detection and response solutions have been developed using dedicated Linux-based virtual machines. This ensures that solution processing and predictions do not influence SDN resources. The solutions were connected to the RYU controller using separate APIs in the application layer of the SDN environment. In the network topology for the detection section, the network architecture comprised four OpenFlow switches. Each switch is linked to a remote RYU controller on the northern side. Each switch in southbound traffic was connected to two hosts. To contemplate traffic congestion on the links, each link between the host and switch in the topology was programmed to have a delay of 2 milliseconds (ms). RYU applications enable the controller to install flows on all the switches. Using the RYU controller, we ran an application to handle spanning trees and Address Resolution Protocol (ARP) requests in the network topology. The APIs forward selective 'Packet Ins' to MongoDB for both the solutions. MongoDB was installed on the same machine as the solution and acted as a database for each model. Within each solution, separate Python applications are developed for each module. Figure 5 shows the experimental setup used for the detection and response solutions. We evaluate the effectiveness of our proposed detection approach in terms of precision, recall, and F1 score. Each of these evaluation parameters, which collectively provide a comprehensive assessment of the model's performance, is described briefly in the following section. **Precision Score:** Precision is the proportion of correctly predicted positive classes relative to the total number of predicted positive classes. The calculation for the Precision Score is articulated in the following equation:  
\[\text{Precision}=\frac{\text{True Positives (TP)}}{\text{True Positives (TP) + False Positives (FP)}} \tag{1}\]  
**Recall Score:** The recall is defined as the proportion of predicted classes that exist. It indicates how many positive instances have been correctly detected via the model. The following formula represents the recall score expression. \[\text{Recall}=\frac{\text{True Positives (TP)}}{\text{True Positives (TP) + False Negatives (FN)}} \tag{2}\]  
**F1 Score:** The F1 score is the average of the scores for precision and recall. It combines the precision and recall metrics into a single metric. The following expression represents the formula for the calculation of the F1 score. \[\text{F1 Score}=2\times\frac{\text{Precision }\times\text{Recall}}{\text{Precision }+\text{Recall}} \tag{3}\]  
Following the custom topology setup, the initial phase of dataset construction was initiated. Using a script, legitimate and probe traffic is transmitted from multiple nodes within the topology. To construct the dataset, a variety of networking utilities were utilised [56]. Specifically, TCP Netcat plays a role in establishing and maintaining resilient data streams, thereby simulating traffic patterns that closely resemble real-world scenarios. On the other hand, UDP Netcat was utilised for lighter connectionless data transfers. The reachability  
Figure 5: Implementation of Detection and Response Solution. of the host was tested using the ICMP protocol via the execution of the 'ping' command. Nmap was utilised to generate network traffic by scanning target IPs and subnets and employing various types of scans to generate distinct packets, such as TCP SYN and UDP packets. This simulation successfully replicated the diverse network conditions for testing.