# IDSMatch: A Novel Deployment Method for IDS Chains in SDNs +
## 5 Evaluation  
In order to validate our proposed method, we conduct real-world experiments on our test bed network. This network includes gateway nodes, SDN switches, and servers that serve as sources and destinations. The topology of the network is arranged in a perfect tree with four layers. The network is equipped with 32 servers, 15 SDN switches, and some regular L2 switches. The structure of the data center is illustrated in Figure 4(a). The servers, except for the gateway, are equipped with dual-core processors running at 2.4 GHz, 4 GB of RAM, and a 500 GB hard disk drive [46]. The topology is arranged in a three-level complete binary tree. Each server is equipped with at least two-gigabit Ethernet ports. The dotted lines in the star topology in Figure 4(a) indicate the control network. Our setup includes a control network and a data network. The control network connects all management ports of the SDN switches (Pica8 p-3922) and the SDN controller through an L2 switch. The SDN switches are configured as out-of-band controllers, which separate the control and data planes. There are two types of SDN switches: the root switch and the leaf switch, for the gateway. There is a connection between the gateway and the root SDN switch, and there is a connection between the servers and the leaf SDN switch. The controller used in our experiment is a Dell 3248 PowerEdge server running the ONOS software [47]. We installed some default applications over ONOS and one customized application which we named _CustomRouting_. Default applications include LLDP Link Provider, Host Location Provider, OpenFlow Provider Suite, OpenFlow Base Provider, and FWD. In the CustomRouting application, there is an input text file that allows us to set paths between any source and destination using the index of the switch, input port, and output port for each switch. The index of switches is associated with the ID of each switch in the network. Additionally, there are time parameters in the input file for the start of installing customized rules and the time of changing the rule to the new one. By running ONOS, the customized rules will be installed on the switches, and traffic will be directed through the customized path, including the IDS chain. For simulation purposes, we evaluate the performance of our approach over 75-node CORONET and 24-node USNET network topologies as shown in Figure 4(b),\(c\), respectively. Figure 5: Topologies. (**a**) Data center topology. (**b**) 24-node USNET topology. (**c**) 75-node CORONET topology. For the test bed, the performance measurement is the network delay, based on hops and link congestion, whereas in the simulation, the performance measurement is hop counts. In our network, IDSs are installed on servers associated with each switch. The controller is aware of the links, their utilization, and the SDN switches, allowing for a global perspective of the network. After configuring the network and flow settings, we analyze the results from various perspectives to provide insight into the performance of the proposed algorithm. To demonstrate its feasibility and efficiency, we conduct experiments on a real test bed using Snortas the IDS. Legitimate traffic is generated using the Ostinatotraffic generator in normal and burst modes, while malicious traffic is generated using Kali Linux. Deploying IDSs into the network leads to an increase in transmission delay as packets are redirected to the server for detection before being sent back to the network to continue their path. There is also constant background traffic between all servers, with 64-byte packets and randomly selected sources and destinations. In the original paper [4], it is evident that deploying more IDSs enhances detection rates. Multiple IDSs can introduce slightly higher delays due to using alternative paths, but this delay is not significant. Higher attack rates boost detection rates and reduce missed detections, as more samples improve detection probability.