4.2.2. Results and Evaluation
In the experiments, two cases were considered, and differences between them were observed. The first case was a network under attack and the second case was a network working without any attack. In particular, in the first case, no defense mechanism was executed on the original Ryu controller, whereas in the second case, the proposed defense mechanism was activated. In both cases, UDP flooding attacks were launched over a period of time. Five minutes were required to simulate an attack. During the experiment, the monitoring software mentioned in
Section 4.1 was used to collect network-performance statistics.
Figure 9 depicts the simulated network topology; only a simple network topology was simulated. Host 1 was responsible for launching UDP flooding, whereas the other hosts remained in normal operating mode [
3].
The experiment began by setting up a network with no defense mechanism. In this case, when there was no attack, the network bandwidth consumption was maintained at a certain level. In addition, the controller central processing unit (CPU) displayed no significant energy consumption. Then, Host 1 started UDP flooding.
Table 1 shows the bandwidth-consumption figures for the two networks. Iperf represents the available bandwidth between the two virtual hosts; therefore, when the attack occurred, the available bandwidth of Iperf was reduced. Iptraf represents the controller bandwidth currently in use. In this case,
Table 1 displays a rapid increase in the controller bandwidth, reaching almost 6000 KB/sec. The top command was used to monitor the CPU consumption. In the experiment, the controller’s CPU consumption began to slowly rise. Under normal circumstances, the bandwidth between virtual hosts is 51 GB/s. However, the bandwidth was reduced to 47 GB/s when the network was under attack. These data confirmed that, when the SDN network experiences a UDP flooding attack, not only is the bandwidth reduced, but the CPU consumption is also significantly increased and becomes a burden for the controller. If the attack keeps flooding the network, then the controller is eventually unable to function normally, resulting in a temporary shutdown of the entire network, which means that packets can no longer be processed, as illustrated in
Table 1. In this experiment, uptime [
33], which is a tool used to measure the controller load, was used.
Table 2 shows the average load on the controller; a number much greater than one indicating an excessive load. The load is a measure of how busy the system’s CPU is and the number of processes that are waiting for the CPU scheduler. A length of one represents the length of the process currently waiting for CPU scheduling.
Table 2 shows that, during the attack, the length reached 2.02. This means that the waiting process queue was at least twice as long as normal and completely full. Under these circumstances, the CPU became too busy, and incoming processes had to wait [
3].
The next step was to carry out a UDP flooding attack. After the flooding attack was launched on the network with the proposed defense mechanism, the bandwidth was still increased, but only by 21.3 KB/sec. Moreover, the bandwidth between virtual hosts was still 50.3 GB/s. Having the defense in front of the network provided highly significant protection and greatly reduced the bandwidth consumption. In addition, the controller’s CPU consumption was also greatly reduced. The results of these two experiments confirmed that the proposed defense mechanism in the SDN network could effectively and significantly reduce the performance burden caused by UDP flooding attacks.
Table 2 shows that the average load on the controller was less than one when the proposed defense mechanism was used.
The next step was to set up the defense mechanism. Measurements were performed under normal circumstances, and the results are shown in
Table 3. The network bandwidth and controller CPU consumption were the same as those in the previous case. These measurements could be used to prove that adding the defense mechanism to the network enhances its security without imposing any additional costs. In addition to the expense of a request packet,
Table 4 shows a comparison of delays before and after defense activation [
3]. The numbers refer to the transmission time for sending the first packet to the host. Clearly, when the defense was not used, the delay time was 9.61 ms. After the defense was activated, the delay time was increased by only 0.40 ms, which is not too much.
The security benefits of the proposed defense mechanism were obtained by manipulating the SDN controller code. With the proposed method, no additional changes to the hardware device were needed. Moreover, the method is implementation-friendly, which means that the controller does not need to undergo significant changes to its core program to accommodate the proposed defense functionality.
Figure 10 shows a comparison of the CPU consumption before and after defense activation. At two seconds, the attack began. In one second, more than a thousand packets were transferred, and the CPU occupancy rate continually increased. However, once the defense had been activated, the CPU consumption quickly decreased again. Even at 10 s, it had returned to normal, with about 50 packets transferred per second. It is apparent that, in the normal state and with the defense running when under attack, the two losses did not differ much. With the defense running (blue line), in about eight or nine seconds, the CPU usage significantly dropped. This delay occurred because it was assumed that the system was determined to have been under attack before the analysis mechanism was activated. It is necessary to wait until after the analysis mechanism is activated to defend against the attack. If the analysis mechanism is activated while under attack, the waiting time does not have to be as long.
Figure 11 shows a comparison of the bandwidth consumption before and after defense activation. Because Iperf was used to test the available bandwidth between virtual hosts, the network bandwidth varied according to its state at the time, possibly resulting in data fluctuations. However, this did not affect the experimental data. Next, the attack was observed. At two seconds after the attack had started, more than a thousand packets were transferred in one second, and the available bandwidth between virtual hosts was decreased. During the attack, the degree of bandwidth loss was very serious, but with the defense, the bandwidth was restored to close to normal, with about 50 packets transferred per second. Once the defense had been active (blue line) for eight or nine seconds, the available bandwidth increased. This delay occurred because it was assumed that the system was determined to have been under attack before the analysis mechanism was activated. It is necessary to wait until after the analysis mechanism is activated to defend against the attack. If the analysis mechanism is activated while under attack, the waiting time does not have to be as long.
The top command was used to estimate the memory usage.
Figure 12 shows that an increase in the number of switches did not cause a large memory increase, as stated in [
34]. When a switch was added, the memory only slightly increased, which did not have much of an impact. When using the defense, the maximal increase in memory consumption was 0.062 GB.
Figure 13 shows the average execution time for the defensive methods. This figure shows the relationship between an increase in the number of switches and the average execution time. With an increase of five switches, the execution time increased by only one second. The proposed system added 15 switches, which involved an increase of only three seconds. This shows that any growth in execution time was not due to an increased number of switches.
Lastly, the results presented in this paper are listed, and the results from
Section 2 are compared with those presented in [
23,
24]. AvantGuard [
23] specifically considered SYN flooding. The authors in [
24] stated that FloodGuard is resistant to all types of flooding attacks, but requires a large programming module, resulting in an overall delay increase. This is the main reason why this study particularly focused on UDP flooding attacks. This eliminated the need for complex packet-analysis modules, resulting in a decreased processing delay for packet transmission.