# Packet Injection Exploiting Attack and Mitigation in Software-Defined Networks
## 4 Countermeasures
### Injection Detection
```
1:\(S\): set of switches, \(MT\): mapping table
2:For\(\forall s_{j}\in S\):
3: Listening Packet-In message from \(s_{j}\)
4: Extract mac, dpid, port from Packet-In message
5: Get \(mac_{i}\) from \(MT\) by dpid and port
6:If\(mac_{i}\) not exist in \(MT\):
7: Set \(mac_{i}\)=mac and add to \(MT\)
8: Forwarding and Continue
9: Else If\(mac_{i}\) == mac:
10: Forwarding and Continue
11: Else: Report entry to flow rule management
12: End For
```  
**Algorithm 1**_Packet-In_ Message Verification  
**(2) _Port-Status_ Message Verification:** Inspired by the DoSDefender [16], the injection detection module monitors the \(\mathit{OFPT\_PORT\_STATUS}\) message to realize the dynamic management of the mapping information between the switch and connected hosts. This is because when a host location migrates or the status of a switch port changes, the controller receives an \(\mathit{OFPT\_PORT\_STATUS}\) message. The entry containing the corresponding switch and host will be deleted simultaneously based on this message. However, since the \(\mathit{OFPT\_PORT\_STATUS}\) message can be actively triggered (such as restarting the network service), only through this message to manage \(MT\) has the risk of being bypassed. For example, we assume a compromised host \(h_{1}\), whose MAC address is \(m_{1}\). The attacker can bypass the defense in two steps. **Step 1:** The attacker actively triggers the \(\mathit{OFPT\_PORT\_STATUS}\) message, causing the defense mechanism to delete the mapping entries related to \(h_{1}\). **Step 2:** The attacker sends crafted packets with spoofing mac address \(m_{2}\) to trigger _Packet-In_ messages. When receiving a _Packet-In_ messages, the defense mechanism will create a new entry related to \(h_{1}\), whose mac is \(m_{2}\). In the whole process, we can see that the mac address of \(h_{1}\) has not changed, but a fake host with mac address \(m_{2}\) has been successfully injected into the network. For the above reason, the injection detection module implements the legality verification, as shown in Algorithm 2. The primary idea is that if a host's mapping is updated, the address information should be consistent with the latest mapping in its subsequent packets. After receiving the _OFPT_PORT_STATUS_ message, it creates a temporary mapping table \(MT^{\prime}\) to store the switch and host information in the subsequent related _Packet-In_ messages. If \(MT^{\prime}\) contains only one mapping entry when the _Packet-In_ messages reach the set threshold, it indicates that the message is legal and updates the \(MT\). Before reaching the threshold, the original mapping entry in the \(MT\) will not be deleted. Otherwise, it is considered that the _OFPT_PORT_STATUS_ message is illegal and forwards host information to the flow rule management module. ```
0: S: set of switches, \(MT\): mapping table, counter: packet-in message verify threshold
1:For\(\forall s_{j}\in S\):
2: Listening _oftp_port_status_ message from \(s_{j}\)
3: Construct temporary mapping table \(MT^{\prime}\)
4:Fori = 1 to counter:
5: Listening packet-in message from \(s_{j}\)
6: Extract mac, dpid, port from packet-in message
7: Encapsulate mapping entry which key is mac and value is dpid and port and insert to \(MT^{\prime}\)
8:End For
9:If\(MT^{\prime}\) only contains one mapping entry:
10: Update \(MT\) by the mac, dpid, and port
11:Else: Report entry to flow rule management
12:End For
```  
**Algorithm 2**_Port-Status_ Message Verification