Using INSPECTOR Device to Stop Packet Injection Attack

Using INSPECTOR Device to Stop Packet Injection Attack in SDN Speaker: Huan-Teng Shen Advisor: Dr. Kai-Wei Ke

Outline 1. Introduction 2. Related Work 3. Proposed Solution 4. Evaluation 5. Conclusion 6. Reference 2

Introduction 3

Abstract ● SDN architecture can easily be attacked by a malicious user in order to prevent an acceptable level of service. ● INSPECTOR is a hardware device added to the SDN architecture to protect a compromised controller from a packet injection attack by verifying the authentication of Packet-In Messages accessing network resources. ● With simulations, INSPECTOR device efficiently stops the attack and enhances the controller performance under malicious attack. 4

Software-Defined Network (SDN) ● SDN separate hardware and software components to build a network that can easily be programmed and is more flexible ● Disassociating the forwarding process of network packets (data plane) from the routing process (control plane) ● SDN enables dynamic and adaptive network management and reduces complexity for the switches in the network 5

Controller ● Control and monitor the entire network ○ data plane components (organized based on the controller instructions) ● Controller gathers information from the network components ○ ○ switch information location of hosts and link status ● Controller has the complete knowledge about the global network topology. ● Controller exchanges data between the controller and the switches by Open. Flow protocol ● The controller makes decisions to define the traffic flows among the network components by installing instructions into the flow tables inside the switches which are stored as entries in Ternary Content-Addressable Memory (TCAM). 6

Packet Injection Attack - Scenario ● The Open. Flow protocol introduces a vulnerable security point ○ ○ a switch has to deal with a new traffic does not have a suitable entry forwarding ● The switch sends a request to the controller as a Packet-In Message over a secure channel. ● The controller responds by installing a new entry into the switch’s flow table with a Packet-Out Message. ● The attacker exploits this process to trigger a huge number of packets in order to increase the workload on the controller or other network resources. 7

Packet Injection Attack - Procedure ● The attacker crafts parts of the packet header fields ○ IP or MAC address ● The attacker sends the forged packets into the network which impose the controller to install a lot of instructions into the switches. ● The controller establishes a wrong topology view for the existing network because the forged Packet-In Messages include false IP or MAC addresses for non-existing devices. ● The controller sends instructions to the switches to store new entries, although the network actually does not need them. 8

Packet Injection Attack - Influences ● It harms the network resources and could destroy the network devices’ functionalities, in particular the controller ○ the applications built on the top of the Rest API would suffer huge performance degradation ● The controller might act as a single failure point for the network when it has to process a huge number of packets which exceed its capabilities. ● Installing a new instruction for each new address is not efficient ○ ○ ○ the SDN switch has limited memory (TCAM stores between 1500 to 3000 entries) Typically, the procedure to exchange the data between the network devices has no mechanism to detect illegal access. the SDN switch cannot prevent the packet injection attack without installing temporary instructions from the controller because the SDN switch has no way of making local decisions. 9

INSPECTOR ● It’s a hardware device can verify if the source address of a new packet has the authentication to send a Packet-In message to the controller. ● an isolated component that receives the new ingress packets from the edge switches. ● It equipped with a database to store the host information and with a CPU to implement a comparison algorithm. ● It uses its database to verify the host and the edge switch information in the header field of the Packet-In Message in order to decide whether the packet has an authentication to access the network or not. 10

Related Work 11

Convert the traffic & remove the unused instructions ● Suppose that the attacker focuses on exhausting a flow table of one switch whilst other switches are not targeted at the same time ● To solve it, converting the traffic from the attacked switch to a neighbor switch and removing the unused instructions in the attacked switch. ● In general, the suggested approach does not take into consideration the impact of the attack on the controller resources. 12

Monitor the average number of packets ● Monitor the average number of packets sent from the controller to the switches ● In case the average exceeded a certain threshold, actions to divert the traffic are executed. ● However, the attacker can bypass this method by distributing or slowing down the attack procedure. 13

Define an entry timeout & install micro-flows ● Two mechanisms to deal with TCAM exhaust ○ define an entry timeout according to the network complexity ○ force the controller to install micro-flows instead of using normal rules. ● Both mechanisms cannot stop the attacker from abusing network resources. ● The attacker might maximize the attack by injecting even more malicious traffic. 14

Detect the attack by examining the flow table state repeatedly ● Suppose that the attacker has complete control of a certain switch, the attacker could alter the instructions on the switch to sniff or steal network information. ● To solve it: the controller detects this kind of attack by examining the flow table state repeatedly, but this abuses CPU and memory usage. 15

Relieve some components in a specific switch ● Take into account the buffer in the switches, CPU and memory usage on the controller ● Relieve some components in a specific switch after noticing the differences. ● Not efficient to prevent or detect slow attack types, in particular with several attackers in parallel ○ sniffing the network information is possible without a high effect on the controller. 16

Check the authentication for every coming packet and install instructions ● Allow the controller to check the authentication for every coming packet install instructions within a short time ● Prevent the attacker from using up the network resources. ● It needs a vast number of instructions stored in the affected switch ● It gives the attacker the opportunity to take over the controller, influencing the controller performance. 17

Proposed Solution 18

INSPECTOR ● Add an isolated component (INSPECTOR) to the network architecture to check all new packets before these reach the controller. ● The INSPECTOR solution considers that the complex network logic should exist only at the edge switches (i. e. , ingress and egress switches), while the core switches should be kept as simple as possible. ● The edge switch is responsible for complex network services, such as network security, while the core switch provides basic packet forwarding. ● Forwarding elements are different in core from edge switches because a core switch is not always required to use end-host addresses (e. g. IPv 4 or IPv 6) forwarding. 19

INSPECTOR - database ● It store all information for the authenticated hosts (Data Path Identifier of the connected edge switch (DPID), In-port number, IP address, MAC address) ● When any host requests a service for the first time, the edge switch sends a Packet-In Message to the INSPECTOR which looks into the header packet field information to ensure that the host’s request has an authentication to use the network resources. ● The other packet types can use the Open. Flow channel directly, thus it distribute the packet load between the controller and the INSPECTOR, especially during packet injection attack. 20

Time Complexity ● Suppose there is a number of switches (S) where each switch either core switch (Sc) or edge switch (Se) ● Take each switch into account to calculate the complexity time T(n) when the packet travels from the source to the destination through n switches. 21

Time Complexity - Worst Case ● ● The INSPECTOR compares the host information to all the authenticated hosts in its database to send the Packet-In Message to the controller using the Open. Flow Channel (of) if the host has the authentication, otherwise the Packet-In Message will be dropped. 22

Time Complexity - Conclusion ● ● The Open. Flow channel uses TCP to transfer the data between the switch and the controller. So the time to use the Open. Flow channel is a constant time. ○ The spent time to switch the packet out of a switch is near to null (in ns). ○ Generally, each new source address passes through the INSPECTOR either for the first time or if the instructions inside the connected edge switch has been deleted because of timeout. Therefore, the complexity of the approach does not influence the network performance as long as the host has an authentication to access the network resources. 23

Evaluation 24

Compare INSPECTOR to the Packet. Checker module ● Packet. Checker was assumed to deal with a flow of packets with the same share of forged addresses (e. g. 1000 packets). ● Every single packet has a different address ● The Ryu controller 1. 3 is used to manage a Fat-Tree topology with a server. ● Each edge switch (from S 1 to S 8) connects up to 10 hosts where one of these hosts acts as the attacker which periodically injects 10 forged packets (in an inter-packet interval of 0. 01 s) with different MAC and IP addresses based on Scapy. ● The network hosts send 76, 000 request packets to the server including 40, 000 forged packets. 25

26

The implementation ● Using Mininet emulator running on a Virtual machine in one process ○ Ubuntu 14. 04 ○ CPU: Intel Core i 5 -8400 2. 80 GHz ○ RAM: 12 GB ● Measurement ○ the number of TCAM entries ○ CPU usage ○ memory usage ○ Open. Flow channel load 27

TCAM ● The controller installs instructions by sending Packet-Out Messages to a certain switch in order to respond to the switch’s Packet-In Message. ● The implementation measures the number of the flow table entries created in the TCAM during the experiment. ● To count the whole number of entries that our topology needs, Ping. All packets were sent before the attack started. ● Figure 2 shows the number of created flow table entries compared to that of the Packet. Checker module in all the edge switches of our topology. ● The improvement rate is between 200% and 400% and increases according to the increase of the attack attempts number because the INSPECTOR approach is able to keep the usage of TCAM at the same level without attack. 28

29

Open. Flow Channel Workload ● The Open. Flow channel is a secure channel to exchange messages that are transmitted between an Open. Flow controller and an Open. Flow device. ● The Open. Flow channel workload parameter is measured as the number of different packets per 10 seconds interval that use the secure channel during the attack. ● The INSPECTOR can handle all the sent packets within 50% of the time of the Packet. Checker module. ● The INSPECTOR just spends 340 s whilst the Packet. Ckecker needs 670 s, because the Packet. Checker module launches a procedure to deal with the incoming malicious packets in contrary to the INSPECTOR which just drops them before they reach the controller. 30

Open. Flow Channel Workload (Cont’d) ● By comparing the number of dropped spoofing packets, we find that almost all spoofing packets could be dealt with by our INSPECTOR. ● We send 76, 000 packets including 40, 000 spoofing packet, and the Ryu controller received 36, 000 packets (the legal packets only). ● Figure 3 presents the difference in presence of the attack which reaches to around 85%. Efficiently, the INSPECTOR neutralizes the Packet-In Messages and hence mitigates the load on the Open. Flow channel. 31

32

CPU Usage ● Using the Psutil library to measured the usage of CPU and memory ● The implementation starts with a Ping. All to install the necessary instructions on the switches. Thereafter, the attack is launched. ● Figure 4 presents a comparison of CPU usage between the INSPECTOR and the Packet. Checker module during the attack duration only. ● The INSPECTOR minimizes the CPU usage to approximately null or to 2% at the worst case because the INSPECTOR denies the forged packets to enter the controller while the Packet. Checker needs to deal with all the forged packets. 33

34

Memory Usage ● Figure 5 depicts the memory usage during the attack duration only. ● In general, the Packet. Checker module processes the topology management information from the attacker for the first time and denies other attempts with the same information. ● In contrary, the INSPECTOR does not allow any forged packet to enter the topology management service, hence the memory usage stays constant. ● The INSPECTOR decreases the memory usage between 22% and 38% compared to the Packet. Checker. 35

36

Delay Time ● According to Carrier-Grade Recovery Requirements, the time to send a packet from a source to a destination has to be less than 50 ms meaning the network performs in normal conditions, to make sure that the INSPECTOR does not influence the network performance. ● In figure 6, the experiment did Ping. All. Therefore, the network hosts sent 76, 000 request packet to the server without attack. ● As a result, the average of Round Trip Time (RTT) for all sent packets has been around 13 ms. 37

38

Conclusion ● The introduced comparison of the INSPECTOR to the Packet. Checker module presents 200% and 400% TCAM improvement rate, decreases the Open. Flow Channel Workload about 85%, minimizes the CPU usage to approximately null or to 2% at the worst case and decreases the memory usage between and 22% and 38%. ● Using an additional hardware device to deal with the forged packet is an efficient approach and significantly enhances the controller performance during the attack. ● The next step is to add a trusted third party ensuring the INSPECTOR would not be compromised. ● Furthermore, the search method could be reduced to a constant time by using a smarter data structure. 39

Reference ● A. S. Alshra’a and J. Seitz, "Using INSPECTOR Device to Stop Packet Injection Attack in SDN, " in IEEE Communications Letters, vol. 23, no. 7, pp. 1174 -1177, July 2019. doi: 10. 1109/LCOMM. 2019. 2896928 https: //ieeexplore. ieee. org/document/8633936 40