# Packet Injection Exploiting Attack and Mitigation in Software-Defined Networks
## 3 Packet Injection Exploiting Attack
### Threat Experiment  
We conduct experiments in a software environment to verify the feasibility and effectiveness of the packet injection exploiting attack. The experiment topology is simulated by Mininet, as shown in Figure 3. We select Floodlight v1.2 as the controller, and the southbound interface is Openflow1.3. We select \(h1\) and \(h6\) as attacking hosts and others as normal network users to simulate the attack. The host \(h1\) uses Scapy [32], a powerful interactive packet manipulation program to inject fake hosts into the SDN network, and the host \(h2\) implements a DoS attack based on these fake hosts. Next, we carry out verification from the injection of fake hosts and the implementation of DoS attacks. **(1) Packet Injection Attack**: The host \(h1\) forges data packets and injects them into the experimental network at a fixed rate. The source MAC address of the forged data packet is generated using the built-in _RandMAC()_ function of Scapy, and the destination MAC and IP address point to the host h6. We modify the source code to output the device MAC since Floodlight does not display additional device information intuitively. The experimental results are shown in Figure 4. As we can see, the injected host is successfully learned by the  
Figure 2: Attack scenario. device management service and added to the SDN network topology. In this way, we inject 50 non-existent devices. **(2) DoS Attack**: Since the attacker knows the fake hosts, they can use them to implement a denial-of-service attack by constructing specific packets on the host \(h6\). These packets have two characteristics: (1) The destination MAC points to the MAC address of any injected host and (2) the randomly generated IP address and port number. It should be emphasized that there are two main reasons why we call it DoS instead of DDoS. On the one hand, these injected hosts are non-existent. Their topological location is related to the host that launched the injection attack, and they share the same bandwidth resources. On the other hand, neither the attack's power, scale, or destructiveness is the same as DDoS. When the switch receives the attack packets from the host \(h6\), there is no corresponding processing rule in the flow table, and it will forward them to the controller by _Packet-In_ messages. Since the injected fake host has been added to the SDN network topology, the controller will calculate and install the forwarding strategy without discarding the packets associated with them. This is the main difference with the forging destination MAC address attack. We evaluated the attack's impact from the two aspects of controller CPU utilization and switch flow table occupancy. At the same time, we compared the forging destination MAC address attack to illustrate the difference between the two. **Attack impact on the SDN controller:** We measured the controller CPU usage using the Psutil library [33] under different conditions. Figure 5a-c respectively represent the  
Figure 4: Floodlight with injection attack. Figure 3: Environment setup. impact on the controller CPU under the normal network status, the forging destination MAC address attack, and the packet injection exploiting attack. As shown in Figure 5a,b, the controller CPU consumption under the forging destination MAC address attack is the same as the normal network state. This is because the manipulated MAC address does not exist in the SDN network topology, and the controller discards the packets without making a decision. As we can see from Figure 5c, the CPU utilization rate rises significantly under the packet injection exploiting attack. The main reason is that all manipulated hosts have been injected into the SDN topology, and the controller will compute routes for unmatched packets about them. Thus the controller load increases sharply due to frequent decision-making.