Author: Sven Hager, Stefan Selent , Bjorn Scheuermann

1. Tree in the List : Accelerated List-based Packet Classification Through Controlled Rule Set Expansion Author: Sven Hager, Stefan Selent, Bjorn Scheuermann Conference: CoNEXT’14, Proceedings of the 10th ACM International on Conference on emerging Networking Experiments and Technologies Presenter: YiFang - Huang Date: 2018/10/17 Department of Computer Science and Information Engineering National Cheng Kung University, Taiwan R.O.C.

2. Introduction DDoS attacks are attempts to make a computer resource (i.e. website, e-mail, VoIP, or a whole network) unavailable to its intended users. In the final quarter of 2015, the number of DDoS attacks has hit a new record . Most of DDoS attacks use Internet Protocol (IP) address spoofing technique that allows attackers to modify source IP address of a packet difference from its original address so that their true identities are hidden. Spoofer Project has shown that 13.5% overall address space is spoofable . DDoS flooding attacks are classified into two categories: (i) Network/transport-level DDoS attacks; and (ii) Application-level DDoS attacks. In the literature, several DDoS defense techniques have been proposed to combat DDoS flooding attacks. These techniques are also classified into two categories as DDoS attacks: (i) DDoS mechanisms against Network/transport-level DDoS attacks; and (ii) DDoS mechanisms against Application-level DDoS attacks . However, systems proposed in the literature using these techniques are either implemented as software programs only or against only one DDoS attack type . With high-speed networks, software-based DDoS countermeasure systems cannot fully decode and classify all incoming packets. Meanwhile, defense against only one DDoS attack technique is not efficient enough. National Cheng Kung University CSIE Computer & Internet Architecture Lab

3. Introduction In contrast to these approaches, we propose an FPGAbased multicore architecture (hardware-based) to integrate multiple DDoS defense mechanisms. Our design goals are not only high-performance but also high efficiency DDoS defense system with various mitigation techniques. The use of FPGA allows DDoS mitigation mechanisms to be implemented by both soft general purpose processor (GPP) cores and hardware-based dedicated processing elements. In all cases, the applied mitigation techniques can be modified or updated at both runtime and design time. With the soft GPP-based approach, each DDoS countermeasure technique is executed by each GPP. When the DDoS countermeasure technique needs to be modified or updated, the system just needs to change or update the instruction cache of the processor.While using hardware dedicated processing elements as DDoS countermeasure engines, the updating and modifying process can be done by dynamic partial reconfiguration technique , a specialized technique for FPGA technology only. This is one of the main advantages of FPGA technology.Besides, the use of FPGA also allows the number of DDoS defense techniques integrated into the system to be flexibly changed to adapt DDoS flooding attacks. National Cheng Kung University CSIE Computer & Internet Architecture Lab

4. Introduction The proposed architecture consists of two separated partitions static and dynamic. The static partition includes hardware cores for pre-processing incoming packets and conducting decisions of the DDoS filtering cores (drop or bypass a packet). The dynamic partition accommodates DDoS defense techniques which can be implemented by soft GPPs or dedicated hardware computing cores. Compared to the GPP-based approach, the dedicated hardware computing core approach provides a better system performance but the updating or modifying process using the dynamic partial reconfiguration technique is longer than updating instruction caches in the GPP-based approach. By separating static partition from dynamic partition, one DDoS filtering core can be updated or replaced by an another core implementing a different defense technique to adapt DDoS attacks without interfering other cores. National Cheng Kung University CSIE Computer & Internet Architecture Lab

5. Introduction • We implement our first prototype system with the Hop-count filtering and Ingress/Engress filtering techniques using the Xilinx Virtex 5 xc5vtx240t FPGA device. The synthesis results show that the system can work at up to 116.782MHz while utilizing about 41% LUTs, 47% Registers, and 53% Block Memory of the available hardware resources. Experimental results show that our system achieves a 100% detection rate (true positive) with a 0% false negative rate and the maximum 0.74% false positive rate. • Moreover, the prototype system obtains packet processing throughput by up to 9.869 Gbps in half-duplex mode and 19.738 Gbps in full-duplex mode. National Cheng Kung University CSIE Computer & Internet Architecture Lab

6. PROPOSED SYSTEM ARCHITECTURE Static partition The static partition accommodates static modules that are fixed at design time. The modules in this partition are mainly responsible for decoding incoming packets and processing those packets based on decisions of DDoS defense mechanism modules. National Cheng Kung University CSIE Computer & Internet Architecture Lab

7. PROPOSED SYSTEM ARCHITECTURE 2.1.1 Packet Decoder This module decodes and extracts incoming packets into header fields and payload fields. These fields are then sent to Defense Cores that implement DDoS defense mechanisms located in the dynamic partition. While the header field includes source IP address, destination IP address, source port, destination port, and TTL value; the payload field contains information. The raw incoming packets are stored in a Packet FIFO module while waiting for classifying results from DDoS defense mechanisms. National Cheng Kung University CSIE Computer & Internet Architecture Lab

8. PROPOSED SYSTEM ARCHITECTURE 2.1.2 Packet FIFO In high-speed network processing systems, when an incoming package is processing, others are coming continuously or simultaneously at different ports. Moreover, processing a packet takes time, the packet needs to be stored somewhere to wait for decisions from processing cores. In this work, we store incoming packets in a Packet FIFO module. The size of this FIFO depends on system performance (throughput) as well as network speed. The higher performance the system can process, the smaller the size of this FIFO is required. Therefore, the size of this FIFO will vary from system implementation to system implementation. In other words, this FIFO can be implemented by onchip memory or off-chip memory based on its size. Although the module is fixed at design time, we do not consider it as a module of the static partition (as depicted in Figure 1) due to the fact that this module can be implemented by off-chip memory. National Cheng Kung University CSIE Computer & Internet Architecture Lab

9. PROPOSED SYSTEM ARCHITECTURE 2.1.3 Packet Processing The Packet Processing module receives decisions from the Defense Decision module located in the dynamic partition. The decisions are either bypass to allow the corresponding packet to be bypassed to output ports or drop to alert that the corresponding packet belongs to a DDoS attack. Based on these decisions, the Packet Processing module sends the corresponding packet from the Packet FIFO module to the destination output port if the packet is legitimate. Otherwise, the packet is deleted from Packet FIFO. National Cheng Kung University CSIE Computer & Internet Architecture Lab

10. PROPOSED SYSTEM ARCHITECTURE 2.1.4 Dispatch Interface As stated above, one of the primary goals of this proposed architecture is the runtime reconfiguration of DDoS defense processing cores. In order words, Defense Cores implementing DDoS defense mechanisms can be updated or changed at runtime to adapt quickly DDoS attacks. While a Defense Core is being updated or replaced by an another core, others can keep working without any interfering. To support this goal, the Dispatch Interface module is responsible for communication between a central host processor, which monitors and controls the DDoS protection system. When Defense Cores are soft GPPs, the host processor can configure the cores by sending new instruction caches through this interface. Otherwise, dynamic partial reconfiguration bitstream is sent from the host processor to modify Defense Cores if these cores are dedicated hardware processing cores. National Cheng Kung University CSIE Computer & Internet Architecture Lab

11. PROPOSED SYSTEM ARCHITECTURE 2.1.5 Updating Controller The main purpose of this module is to control the process updating or changing Defense Cores. However, the Updating Controller module will vary from implementation to implementation. If the system executes DDoS defense mechanisms by soft GPPs, Updating Controller just needs to select the right instruction cache to update it by a new instruction cache. However, Updating Controller should include different modules that support the dynamic partial reconfiguration technique in the cases of dedicated hardware processing cores are used to execute DDoS defense mechanisms. These supporting modules depend on FPGA families. Therefore, we only describe the Updating Controller module in the proposed architecture. National Cheng Kung University CSIE Computer & Internet Architecture Lab

12. Proposed algorithm 2.2 Dynamic partition Attackers usually deploy DDoS attacks by using different attack methods. Therefore, one of the requirements towards building a comprehensive DDoS defense system is to combine multiple DDoS defense mechanisms. Moreover, these mechanisms should be updated or changed at runtime. Therefore, the dynamic partition includes different DDoS Defense Cores, each of them implements one different DDoS countermeasure technique. When at least one Defense Core recognizes a packet as an attacking packet, the system should remove the packet. National Cheng Kung University CSIE Computer & Internet Architecture Lab

13. Proposed algorithm 2.2.1 Defense Cores Defense Cores are mainly responsible for scanning incoming packets to classify those packets as legitimate packets or DDoS attacking packets. Different DDoS filtering techniques require different data input such as header fields or payload fields. These fields are supplied by the Packer Decoder module. Defense Cores can be implemented by soft GPPs (such as MicroBlaze [18] or NIOS [2] processors) or dedicated custom hardware processing cores or both. However, in all cases, Defense Cores can be updated or changed at both runtime and design time. The update process when Defense Cores are soft GPPs just requires new instruction caches of GPPs changed. Meanwhile, we need to use the dynamic partial reconfiguration technique for FPGA devices if Defense Cores are specialized hardware cores. Compared to the GPP approach, dedicated hardware Defense Cores achieve better performance due to parallelism. National Cheng Kung University CSIE Computer & Internet Architecture Lab

14. Proposed algorithm 2.2.2 Defense Decision DDoS attacking packets can be deployed by different methods. One defense mechanism can only detect one type of DDoS attack. Therefore, if a packet is classified as an attacking packet by one DDoS filtering technique, we do not need to wait for decisions of other techniques in a multiple filtering mechanisms DDoS protection system. The main duty of the Defense Decision module is to monitor classified information from Defense Cores to determine whether a packet is legitimate or belongs to a DDoS attack. If there exists one Defense Core recognizing a packet as an attacking packet, Defense Decision right away sends a drop signal the Packet Processing module accommodated in the static partition. Consequently, Defense Decision resets all Defense Cores to start processing the next packet since we do not need to wait until all Defense Cores finish their scanning process. In contrast, if all Defense Cores vote for a packet as a legitimate packet, Defense Decision sends a bypass signal to the Packet Processing module. National Cheng Kung University CSIE Computer & Internet Architecture Lab

15. SYSTEM IMPLEMENTATION This section presents our first prototype version implementing the proposed FPGA-based multicore architecture to integrate two well-known DDoS defense techniques Hopcount filterting (HCF) and Ingress/Egress filtering (IEF). The NetFPGA-10G board containing a Xilinx xc5vtx240t device is used as an experimental platform. The board consists of four SFP+ ports (NIC Rx and NIC Tx) that are suitable to build a high-speed network processing system. Two Defense Cores implementing HCF and IEF techniques are developed as dedicated hardware processing cores using Verilog-HDL. Therefore, we apply the dynamic partial reconfiguration technique to update and modify Defense Cores as stated above. In this section, we mainly highlight the two DDoS filtering techniques, Updating Controller (DPR) module used to control the dynamic partial reconfiguration process, and Dispatch Interface (ICAP) to receive dynamic partial reconfiguration bitstream from the host processor. Figure 2 depicts our prototype system based on the proposed architecture. National Cheng Kung University CSIE Computer & Internet Architecture Lab

16. SYSTEM IMPLEMENTATION 3.1 Static partition Static partition mainly accommodates Packet Decoder, Packet Processing, Dispatch Interface, and Updating Controller. Depending on system implementation, this partition maybe includes the Packet FIFO if it is implemented by onchip memory. 3.1.1 Packet Decoder & Packet Processing modules These modules are implemented using Verilog-HDL as described above. The Packet Decoder module receives incoming packet from the NIC Rx inputs of the SFP+ ports while the Packet Processing modules forwards legitimate packets to the destination NIC Tx outputs of the SFP+ ports. National Cheng Kung University CSIE Computer & Internet Architecture Lab

17. SYSTEM IMPLEMENTATION 3.1.2 Packet FIFO In this prototype version, we implement the Packet FIFO by FPGA block memory (on-chip memory). We use the FIFO IP core provided by Xilinx [16] to develop the buffer. The size of Packet FIFO is 256-bits in width and 1024 entries in depth. 3.1.3 Dispatch Interface (ICAP) Due to dedicated hardware processing cores used for implementing DDoS filtering mechanisms, runtime update and change should be done by the dynamic partial reconfiguration technique. Therefore, the Dispatch Interface module needs to support this technique. The dynamic partial reconfiguration technique is technology dependency. Hence, we use a Xilinx proposed interface to reconfigure the FPGA device at runtime. Xilinx supports various interface to configure their FPGA devices. Among those interfaces, an ICAP primitive interface [19] is able to read and write efficiently the FPGA internal configuration memory. In this work, we use ICAP as our Dispatch Interface allowing partial reconfiguration bitstream to be transferred from the central host processor to internal configuration memory of the Xilinx FPGA device through a 256-bit Direct Memory Access (DMA) protocol. Figure 3 shows the internal architecture of our implemented Dispatch Interface based on ICAP. National Cheng Kung University CSIE Computer & Internet Architecture Lab

18. SYSTEM IMPLEMENTATION 3.1.4 Updating Controller (DPR) As aforementioned, one of the main goals of this work is to update or change one processing core that implement one DDoS defense technique without interfering other cores, and, of course, without interfering the packet classification process. The Updating Controller module is responsible for the dynamic partial reconfiguration process. Updating Controller stops the updated core and sends classified information to Defense Decision on-behalf-of the updated core When the updating process is done by ICAP, the new core is authorized by Updating Controller to scan incoming packets and send its classified results to Defense Decision. National Cheng Kung University CSIE Computer & Internet Architecture Lab

19. SYSTEM IMPLEMENTATION This section presents our first prototype version implementing the proposed FPGA-based multicore architecture to integrate two well-known DDoS defense techniques Hopcount filterting (HCF) and Ingress/Egress filtering (IEF). The NetFPGA-10G board containing a Xilinx xc5vtx240t device is used as an experimental platform. The board consists of four SFP+ ports (NIC Rx and NIC Tx) that are suitable to build a high-speed network processing system. Two Defense Cores implementing HCF and IEF techniques are developed as dedicated hardware processing cores using Verilog-HDL. Therefore, we apply the dynamic partial reconfiguration technique to update and modify Defense Cores as stated above. In this section, we mainly highlight the two DDoS filtering techniques, Updating Controller (DPR) module used to control the dynamic partial reconfiguration process, and Dispatch Interface (ICAP) to receive dynamic partial reconfiguration bitstream from the host processor. Figure 2 depicts our prototype system based on the proposed architecture. National Cheng Kung University CSIE Computer & Internet Architecture Lab

20. 3.2.1 Hop-Count Filtering Although DDoS attackers can forge any data in the header field of a packet, they cannot falsify the number of hops that a packet traverses to reach its destination. The number of traversed hops of a packet, named hop-count, is calculated by subtracting the final Time-to-Live (TTL) from the initial TTL values, so-called calculated Hop-count. TTL is an 8-bit field [11] in the header field that is originally introduced to specify the maximum lifetime of a packet on the Internet. The final TTL is the value when the packet reaches the destination. The initial TTL values are set to 30, 32, 60, 64, 128, or 255 depending on Operating System (OS) where the packet is packed. The HCF module in this work consists of three blocks (described in Figure 4). These are (i) Hop-count calculation to calculate Hop-count value of an incoming packet, (ii) Content Addressable Memory (CAM) to store known Hop-count values of packets coming from specific sources, and (iii) Comparator to compare stored Hop-count values with calculated Hop-count values. Due to the limitation of NetFPGA 10G board hardware resources, we build two versions of CAM, 128 and 256 entries. This module receives a header field of an incoming packet from the Packet Decoder module, located in the static partition, and calculates the actual Hop-count value. The module, then, uses the source IP address of the packet to look up corresponding stored Hop-count value in CAM. If the stored Hop-count value is identical to calculated Hop-count, the packet is legitimate. Otherwise, the packet is spoofed. When this is the first time the packet has come to the system (i.e., whose source IP does not exist in CAM), CAM returns a MISS signal and stores both source IP address of the packet and calculated Hopcount value. This packet is considered as legitimate packet. However, the initial TTL can be forged. It means that the packet is spoofed, but HCF could not recognize that because of the lack of information. That is the main disadvantage and limitation of the HCF mechanism. Load Informing component National Cheng Kung University CSIE Computer & Internet Architecture Lab

21. Balance Decision component National Cheng Kung University CSIE Computer & Internet Architecture Lab

22. Balance Decision component National Cheng Kung University CSIE Computer & Internet Architecture Lab

23. Balance Decision component National Cheng Kung University CSIE Computer & Internet Architecture Lab

24. Balance Decision component National Cheng Kung University CSIE Computer & Internet Architecture Lab

25. Balance Decision component National Cheng Kung University CSIE Computer & Internet Architecture Lab

26. Switch migration component National Cheng Kung University CSIE Computer & Internet Architecture Lab