HIGH-THROUGHPUT AND MEMORY-EFFICIENT TCP REASSEMBLY FOR NETWORK INTRUSION DETECTION SYSTEM

Transcription

1 HIGH-THROUGHPUT AND MEMORY-EFFICIENT TCP REASSEMBLY FOR NETWORK INTRUSION DETECTION SYSTEM Tran Ngoc Thinh 1, Tran Huy Vu 1, Shigenori Tomiyama 2 1 Faculty of Computer Science and Engineering, University of Technology, Ho Chi Minh city, Vietnam, {tnthinh, vutran}@cse.hcmut.edu.vn 2 School of Information Telecommunication Engineering, Tokai University, Kanagawa-ken, Japan, tomiyama@keyaki.cc.u-tokai.ac.jp Abstract Received Date: September 14, 2012 Most of network data are transmitted using TCP protocol, which need to be reassembled before being processed by applications. However, applications proved that TCP reassembly is memoryhungry and it is usually the bottle neck of a system. In this paper, we propose a method for TCP reassembly, called multi-linked-list method, which can offer high throughput and high memory efficiency. The targeted applications of our system are Network Intrusion Detection Systems (NIDS)s which usually use signature-based matching techniques to protect networks from illegal intrusions. Our proposed method combines reassembly technique with edge buffering to help NIDS detect cross packet intrusion patterns. Our system not only supports TCP connections with up to 4 concurrent holes, but also uses memory more efficiently than others. The experimental results show that our system can operate on 10Gbps network link and hold up to 256K connections simultaneously including up to 46K out-of-sequence connections with only 64MB DRAM. Our system can also support connection timestamp and buffer threshold to prevent some kinds of attacks to our system itself. Keywords: Edge, FPGA, Linked List, Segment Array, TCP Reassembly. Introduction Invited Paper Nowadays network is vital to almost every organization. Many protocols have been invented to transfer data over networks. Out of these protocols, the Transmission Control Protocol (TCP) is the most popular. The authors in [12] showed that more than 90% of network traffic is TCP. In TCP protocol, the data is split into packets, and these packets are transmitted consequently. However, they can arrive at the destination in the wrong order due to transmission error or the network routing mechanism. Therefore, the terminal applications have to reassemble these individual packets to reform the original data. Moreover, many Network Intrusion Detection Systems (NIDS)s are now deployed on networks to prevent illegal intrusion on organizations. These NIDSs usually use signaturebased techniques to detect intrusions. In NIDS database, a signature or a rule is a pattern of bytes which identify a virus, malware, and other illegal intrusions and attacks. The NIDSs scan input byte stream and attempt to match as many signatures as possible. If the signatures are included in a single packet, they can be detected by traditional NIDSs; but if the intrusion patterns expand over packets, and these packets do not arrive in the original order (out-of-sequence), they cannot be detected as described in Figure 1. These NIDSs really need integrated TCP reassembly modules to help them robust against attacks. To describe TCP stream with missing packets, we use two terminologies, one or more continuously missing packets are called a hole, and one or more continuous packets are called a segment. The easiest way to reassemble TCP packet is to buffer all out-ofsequence packets before sending them to the applications. Due to the flow control ASEAN Engineering Journal, Vol 1 No 1, ISSN X, e-issn p.13

2 mechanism and the window size scaling scheme [13], the system can have to buffer up to 1GB for each direction of a connection. The problem is even much more difficult for backbone network, whose throughput can reach tens of Gbps and there can be a large amount of connections established on that link. For such networks, a TCP reassembly system has to support not only the high throughput, but also a large number of concurrent connections. In addition, NIDS applications need to scan a whole data stream; however, a TCP stream is usually interleaved by other streams. So a TCP reassembly needs to help NIDSs scanning these types of stream correctly. There are several techniques in NIDSs to detect intrusion patterns. Some use state machine methods such as Aho-Corrasick [8], but the others do not use an explicit state machine such as hashing techniques. For the former case, the TCP reassembly system can store and load the current state of the state machine. But for the latter case, the applications do not have an explicit state machine to be stored and loaded. In general, our targeted system can support ten-gigabit network, manage hundred thousands of concurrent connections, support both types of NIDSs, and use memory efficiently. In this paper, we implement a TCP reassembly system which is developed from our previous research in [14]. In that research, we implemented a TCP reassembly system, which can support 1Gbps network, up to 256K concurrent connections with multi-hole connections and using only 64MB DRAM. The new system is improved to support the data bit-width up to 64-bit and reach a throughput of 10Gbps. Moreover, it supports two operational modes; the mode edge-disable for NIDSs which deploy an explicit state machine and do not need to scan part of the previous packet, and the mode edge-enable for NIDSs which have to re-scan the overlapping edge of the previous packet to detect crosspacket patterns. We calculate the throughput for these two modes independently. We also implement timestamp and buffer threshold to avoid some attacks to our system itself. Conn.1 Conn.2 this http: www Dropped Conn.1 is an attack is an pattern NIDS engine This should be assembled as: this is an attack pattern Related Work Figure 1. Out-of-sequence packets passing an NIDS Several researches have been proceeded to design TCP reassembly systems [1, 2, 3, 4, 5]. In these researches, FPGA is usually used as a development platform because it supports high speed processing and easy to update. Consequently, almost these researches try to avoid the complexity of memory management because maintaining some data structures, which can be done easily in software manner, becomes very difficult in hardware manner. The TCP Processor in [4] uses the retransmission mechanism to reorder the out-ofsequence packets. It drops all out-of-sequence packets so that the source terminal will retransmit all packets that have not come in the right order. The advantages of this approach are simplicity, memory efficiency. It simply updates the sequence number of insequence packets so far, and compares the sequence number of a coming packet to determine if the packet is in-sequence or out-of-sequence. Because all out-of-sequence packets are dropped, reassembly memory is not necessary. However, this method causes the network traffic to be heavier with retransmitted packets, and may prevent the destination terminal from efficient acknowledgement. Moreover, though the percentage of out-of-sequence connection is little, these connections are usually long connections; the ASEAN Engineering Journal, Vol 1 No 1, ISSN X, e-issn p.14

3 number of retransmitted packets can be very large. The authors chose this approach because a statistical result in [7] shows that only about 5% of TCP packets are out-ofsequence. But these statistics are quite out of date, newer researches show that the out-ofsequence percentage is even much higher, about 20%. Therefore, dropping out-ofsequence packets by the TCP reassembly system is not efficient because it causes the retransmission of all these packets. To make the TCP reassembly more efficient, Sarang Dharmapurikar and Vern Paxson in [2] use linked-list data structure to store the out-of-sequence packets. Because of the high complexity of management of multi-hole TCP connections, they limited the number of holes in a connection to only one hole. Any packet which creates more than one hole at a time is dropped. In this system, DRAM is utilized to store out-of-sequence packets since its large volume, and the memory is divided into blocks. Each packet can be stored in more than 1 block, 1 block can contain more than 1 packet, so the memory utilization is more efficient. If a segment have to be stored in many blocks, these blocks are linked together to form a linked-list. The reason that they decide to supports only one hole is based on their studies that more than 95% of out-of-sequence connections contain only one hole. However, newer studies in [1] show that the number of 2-hole and 3-hole connections can reach 21% of the out-of-sequence streams. Because the percentage of multi-holes connections is considerable, it is necessary to covers these connections. Palak Agarwal in [5] also uses the approach of linked list for his TCP reassembly module, which is part of his NIDS system. This system actually uses associated linked-list of packets rather than linked-list of memory blocks. Both SRAM and DRAM are utilized to construct the data structure to store out-of-sequence packets. The information of each out-of-sequence packet is stored in SRAM as control blocks, and these blocks are linked together to form a linked list. The real packets are stored in DRAM, each packet is retrieved by a pointer in a corresponding control block in SRAM. Although this method allows multi-hole connections, the data structure is not memory-efficient. This system has to reserve maximum DRAM space, for example 1500 bytes, for each out-of-sequence packet, so it can waste a lot of DRAM memory. Moreover, in almost FPGA platforms, the SRAM volume is quite small; it cannot contain a large number of the control blocks which consist of 16 bytes for each. In another approach [1], the authors use a buffer for each out-of-sequence connection, but the size of the buffer is fixed and every out-of-sequence connection has only one buffer. If an out-of-sequence TCP packet comes, its sequence number is used to compute the offset from the beginning of the buffer to store the packet. This method is not efficient because a large segment cannot be contained in a buffer, but a tiny segment can waste a lot of memory in the buffer. In this paper, the authors use two statistical results; the first is from Cooperative Association for Internet Data Analysis (CAIDA_10G), and the second is statistics of a backbone network of a city which is recorded by the authors themselves. These results show that the mean size of packet is about 500 bytes, and more than 70% out-of-sequence connections are 1-hole connections. According to the authors, the recommended buffer size is 64KB. It means that more than 70% of utilized 64KB-buffer blocks are filled with only 500 bytes. In addition, because of the large size of buffer, this system does not support large number of concurrent out-of-sequence connections. Sugawara et al. introduce a new approach in [3], which does not need to buffer a whole packet. Although this research does not attempt to design a TCP reassembly system, its techniques can be useful to implement a TCP reassembly which is part of an NIDS. In this design, the system has to buffer only data at two ends of a packet, the length of buffered data equals the maximum length of rules, assumed as l. The first l-byte data of packet payload is called the starting edge; the last l-byte data of packet payload is called the ASEAN Engineering Journal, Vol 1 No 1, ISSN X, e-issn p.15

4 ending edge. This technique does not require reordering packets. By rescanning the starting edge and the ending edge of succeeded or preceded packet correspondingly, the system can detect cross-packet intrusion patterns whose lengths are less than or equal to l. However, this technique can only be applied to static scanning engines because the maximum length of a pattern is priory known. In practice, many applications use both static pattern and regular expression (RE). The length of a string, which matches an RE, cannot be priory known. In summary, based on the above analysis, we design our TCP reassembly system with multiple techniques to gain high memory efficiency, high throughput and best support for NIDSs. Multi-linked-list Approach In the above approaches, the design in [2] shows its efficient memory utilization, but it has the disadvantages as stated above. In our design, we also use one linked list to store the payload of packets in the same segment. Because the data in the same segment are consecutive, they are suitable to be stored in a linked-list of memory blocks. A modification of edge buffering scheme [3] is also applied to this system. To support connections with more than 1 hole, each out-of-sequence connection uses an array to manage several holes. Each array element has a pointer to refer to a segment, so the array size is the maximum concurrent holes in a connection. Studies [1] show that 99% out-ofsequence connections have less than 4 concurrent holes. Moreover, if a connection has too many holes, buffering all out-of-sequence packets is not as efficient as dropping the packets so that the source machine will retransmit packets to fill some holes. Therefore, in our design, we limit the number of concurrent holes in a connection to 4, and thus the array size is 4. When an out-of-sequence packet arrives at the system, there are four cases to manipulate the segment array: allocating a new linked list, inserting packet payload to an existing linked list, merging two existing linked lists, and releasing an existing linked list. However, if an out-of-sequence packet makes the number of concurrent holes in the corresponding connection exceed the size of the segment array, the packet is dropped. Structure of a segment array element (Seg.i) Start seq. Next seq. Head Blk.2 Blk.3 Blk.8 Blk.9 Blk.4 Blk.1 Blk.5 Blk.7 Blk.0 Tail segment array Seg.0 Seg.1 Seg.2 Seg.3 Blk.6 Memory block (Blk.i) linked lists Figure 2 Multi-link-list method in combination with edge buffering scheme Figure 2 describes the data structure of the out-of-sequence buffer. Each segment array element contains following information. Start seq.is the sequence number of the first byte of the segment. Next seq. is the next expected sequence number of the segment. Head is address of the first byte of the segment in DRAM. Tail is address of the last byte of the Seg.0 Each linked list stores data of a segment Structure of segment array Start seq.0 Next seq.0 Start seq.1 Next seq.1 Start seq.2 Next seq.2 Start seq.3 Next seq.3 Head 0 Tail 0 Head 1 Tail 1 Head 2 Tail 2 Head 3 Tail 3 Structure of a memory block Data len. Next ptr. Packet0 data Packet0 data Packet0 data Packet1 data Packet1 data ASEAN Engineering Journal, Vol 1 No 1, ISSN X, e-issn p.16

5 segment in DRAM. For fast retrieving of each segment, we construct the segment array in a special way. All sequence fields are consecutive, all address fields are consecutive, and so the sequence fields and the address fields of a segment are not consecutive. We use this data structure because we want to arrange the sequence fields so that many sequence fields can be read in one DRAM access. Moreover, the system can operate on the sequence fields and the address fields separately. When a packet comes, the first stage of the system accesses sequence fields quickly, determines the action to be issued, and requests the second stage to proceed the action. This operation can be done in one DRAM access. The real operation on the packet payload, which can require much time, is carried out by the second stage independently. Because of this independence, the reassembly operation is pipelined, and does not impact on the throughput of the system. Another issue is to manage the data in a segment efficiently. We divide memory space into blocks; the structure of a block is simple as in Figure 3.a. Data len. is the number of valid data bytes stored in the block. Next ptr. is the address of next block in the same linked list. The Data of each segment is stored in a linked list of blocks. The addresses of the linked lists and the Next ptr are not necessary aligned with the block address; this situation occurs when the payload of a packet is pre-pended to an existing linked list. If the payload of a packet is larger than the block size, it is stored in 2 or more blocks. If the payload of a packet is smaller than the block size, the next packet in the same segment can fill in that block. In pattern matching systems, there are matching engines which do not deploy an explicit Finite State Machine (FSM). For example, some NIDSs use hashing methods, such as Bloom filter [10] or Cuckoo hashing [9], to match static patterns. In such situations, the system cannot reassemble packets by loading and storing FSM of the matching engine. In this paper, we apply the idea of One-edge and Two-edge buffering scheme [3] to store the overlapped data between packets. However, TCP packets are ordered by using multilinked-list method, the edge buffering scheme can be simplified as in Figure 3.A. When the packets are ordered, only the ending edge of each packet is needed to be stored and rescanned. Though the system can store a long ending edge to cover all patterns, the system has to re-scan a lot of data, and thus the throughput of the system is decreased. So the length of edge-data should be carefully chosen. In this paper, based on the rule set of our targeted NIDS, we choose the edge length of 32 bytes. A Edge pkt.1 Edge pkt.0 B Source IP Dest. IP Packet 2 Store edge l byte edge Packet 1 Store edge Packet 0 Store edge Packet data Source Port Dest. Port Buffer address Sequence App. FSM Figure 3. A - Modified Edge-buffering scheme; B- Structure of a connection record(cr) To manage the status of each connection, a Conection Record (CR) is used; the detail of a CR is described in Figure 3.B. Each TCP connection is identified by 4 fields: Source IP, Dest. IP, Source Port, Dest. Port. All packets have the same value of these fields belong to the same connection and the Sequence number indicates the order of the packet in the connection. The Flags include SYN and ACK flags to manage 3-way hand shaking scheme in TCP connection establishment; another flag is EST indicates the record is occupied. Buffer address is a pointer to refer to a segment array of the connection. For matching engines using an algorithm with an explicit FSM, such as Aho-Corasick [8], the FSM is stored to/ loaded from the App. FSM. The field of Timestamp is a relational time value; it indicates how long a CR has been in memory. It is used to determine whether a Flags Timestamp Buffer size Reserved ASEAN Engineering Journal, Vol 1 No 1, ISSN X, e-issn p.17

6 CR should be replaced by a new one or not. If hash collision occurs during the arrival of a new packet, the Timestamp is check. If the Timestamp exceeds a threshold, the CR will be replaced by the new one; otherwise, the new packet is dropped. Whenever a CR is successfully retrieved, its Timestamp field is updated to the present. This technique is to cope with SYN flooding and connections which are not properly closed. Buffer size is the current size of the buffer to store out-of-sequence packet. If an out-of-sequence packet causes the Buffer size to exceed a threshold, it is dropped. This policy is to avoid the buffer over flow attacks to the TCP-reassembly system itself. Implementation Figure 4 is the block diagram of our system. Input Controller receives each packet from network, extracts information in packet header includes IP addresses, TCP ports, sequence number and flags, and then send them to the Flow Controller. It also calculates the TCP checksum and signals Flow Controller with checksum error. Besides, Input Controller sends packets to Packet Buffer. The main function of Packet Manager is to temporarily store packets, which are received from Input Controller, in a FIFO. This FIFO is able to remove a whole packet, or continuously read out the data byte by byte. Output Controller controls the dropping, forwarding, etc. of packets. If a packet needs to be dropped, it requests Packet Manager to remove the packet from FIFO, or else it requests Packet Manager to read a packet out. In case a packet is forwarded, it will send the packet to network only. But if a packet has to be buffered in memory or passed to NIDS engine, the Output Controller sends the packet to Reassembler module as well. Flow Controller manages connection records. When a packet arrives, it accesses the connection record, compares the sequences to decide an appropriate action on the packet. Flow identification consists of 96 bits, including source IP, destination IP, source port and destination port. It is impossible to use the 96-bit identification directly as the address to access memory. In our system, we use hashing technique to solve this problem; an 18-bit hash value, which is calculated from 96-bit identification, is used as the address to retrieve connection record in memory. The sequence number of the coming packet is then compared to the number in connection record. Based on the comparison result, there may be 4 types of actions: dropping, forwarding, buffering and sending a packet to application. The Flow Controller also accesses the sequence fields in the segment array of the connection to determine extra parameter for the action. The parameters can be insertion a packet to a segment, reading out a packet from a segment, or merging 2 segments. If a packet is the first out-of-sequence packet, Flow Controller requests Memory Controller to allocate a new segment array. The segment array address and record address are also sent to reassemble as extra parameters. Packets Input Controller Packet Manager Output Controller To network Connection information Flow Controller Conn. Record mng. O.S. buffer check Command Ext. param rsm FIFO Reassembler Pkt FIFO dsm FIFO To App. App.FSM Conn. records Memory Controller DRAM payload Figure 4. Architecture of TCP Reassembler ASEAN Engineering Journal, Vol 1 No 1, ISSN X, e-issn p.18

7 Reassembler is the main module of our system and is used to manage reassembly memory. The detail management of reassembly memory is described in section 3. Reassembler receives commands from Flow Controller and requests Output Controller to read out or remove a packet. If it receives a command to send a packet to application circuit, the extra parameters indicate whether to read out a segment or not. If it receives a command to buffer a packet, the extra parameters indicate the position to insert the packet. Rsm FIFO is used to keep packets to be buffered, and Dsm FIFO is used to keep packets read out from memory. Another FIFO, named Pkt FIFO, is used to keep packets from the Output Controller. When a packet is completely read out from Pkt FIFO and sent to application, the Dsm FIFO is read if it has any data. Reassembler can request Output Controller to drop a packet if that packet creates more than 4 holes in the corresponding connection. Output Controller requests Packet Buffer to remove a packet or read out a packet. A packet can be sent to both network and Reassemler, or sent to network only. Memory controller arbitrates read and write requests from Flow Controller and Reassembler; it also controls the allocating or releases of a memory blocks. The real packet payload is stored in memory blocks; the size of memory block is 1KB. The segment array size is 32 bytes. Memory Controller maintains 2 FIFOs to store addresses of buffer blocks and segment arrays correspondingly. One FIFO is used for allocating and releasing of memory blocks, another is used for allocating and releasing of segment arrays. When it allocates a memory block or a segment array, it reads the corresponding FIFO, and return the address which has been read out. When a memory block or segment array is released, the address of the block or segment array is written to the corresponding FIFO. Evaluation To evaluate our approach, we synthesize our design as described in section 4 on Virtex2- Pro FPGA chip. We use Xilinx ISE 10.1i for synthesis and timing simulation. The synthesis results show that our design can operate at clock rate of 157MHz. One of the typical clock rate is MHz, our system can process 64-bit data in each clock pulse, so the raw maximum throughput is MHz*64b or 10Gbps. However, since the TCP characteristics and overhead of the system, the real throughput is a little bit lower. The number of occupied slices is about 18% of total slices of Virtex2-Pro. So our TCP reassembly system can be fully integrated into Virtex2-Pro along with an application circuit such as NIDS. Our system uses 16MB DRAM to store connection records. In edging-enable mode, a 32-byte edge buffer is placed next to each connection record, so the maximum number of connection records is 16MB/(32B+32B) or 256K; however, in the edging-disable mode, the number is 16MB/32B or 512K. Our system uses 46MB DRAM to store out-of-sequence packets with the block size is 1KB, so it can hold maximum 46K out-of-sequence connections. It also uses 2MB DRAM to store up to 64K segment arrays. The total used memory is 64MB. Throughput The throughputs depend on the packet lengths, the percentage of out-of-sequence packets, as well as the edge length to be stored. Therefore, we evaluate our system in two operational modes, the edge-disable and the edge-enable mode, which are shown in Figure 5 and Figure 6. The packet payload lengths are chosen from 1 to 1450 bytes. The curve named Max shows the maximum throughput that can be reached on wire. Although the speed of Ethernet link is 10Gbps, the overhead of each packet slows down the maximum throughput. Ethernet protocol requires an inter-frame-gap, preamble, start-of-frame delimiter and CRC code between two frames; for 10Gbps link, these values are 5, 7, 1, 4 ASEAN Engineering Journal, Vol 1 No 1, ISSN X, e-issn p.19

8 bytes correspondingly. Therefore, the throughput achieves almost 10Gbps with large packets but it is sharply decreased with small packets. The other curves show the throughput of the system with out-of-sequence percentage is 0%, 5% and 10% correspondingly. These numbers are typical out-of-sequence percentage numbers. At first, the system is tested in edge-disable mode as illustrated in Figure 5. In this mode, the system does not store and load the edge data, so the throughput of our system can reach the maximum throughput when the percentage of out-of-sequence packets is 0%. When this number changes to 5% and 10%, the throughput is slightly decreased. The evaluation of the edge-enable mode is shown in Figure 6. In this mode, the system loads and stores 32- byte edge data for each TCP packet. These numbers are measured with the edge length of 32 bytes. With a very small packet, for instance 1 byte of payload, the ratio between payload length and edge length is very small, and the system has to wait for DRAM read operation to be completed. So the throughput decreases sharply. With large packets, though the ratio is high, the out-of-sequence packets can also decrease the throughput of the system. However, these packets can be transmitted during the inter-frame gap of the incoming packets so that the throughput is slightly decreased Throughput (Gbps) Packet payload length (Bytes) 0% 5% 10% Max Figure 5. Throughput of TCP Reassembly system in edge-disable mode ASEAN Engineering Journal, Vol 1 No 1, ISSN X, e-issn p.20

9 Throughput (Gbps) Packet payload length (Bytes) 0% 5% 10% Max Memory Utilization Figure 6. Throughput of TCP reassembly system in edge-enable mode In Figure 7, the memory utilizations of three cases, 0%, 5% and 10% out-of-sequence packets are shown. The packet payload lengths are also chosen in a range from 1 to In case of 5% and 10% out-of-sequence packets, the number of out-of-sequence packets in a single connection is from 1 to 4. We choose this range because our design support maximum 4 concurrent holes in a connection; moreover, we analyzed a network data set which is recorded by Lincoln Laboratory and found that the number of concurrent holes in a connection is also less than Memory usage (MB) Number of concurrent flows (x1000) 0% 5% 10% Figure 7. Memory footprint ASEAN Engineering Journal, Vol 1 No 1, ISSN X, e-issn p.21

10 Packet drop rate 20.00% 18.00% 16.00% 14.00% 12.00% 10.00% 8.00% 6.00% 4.00% 2.00% 0.00% Number of concurrent flows (x1000) Concurrent Flows Figure 8 measures the drop rate as increasing the number of concurrent flows. The drop rate dramatically increases when the number of concurrent flows exceeds 150K because of the hash collision. Actually, many of these cases are caused by connections in idle state for a long time. To cope with this issue, we use timestamp to replace these connections by new coming connections when collision occurs. As stated previously, our design stores connection records in a hash table. A full hash table can contain 256K elements. However, a hash table is typically limited to a half-full table. Although our system can support 256K concurrent connections in ideal case, we recommend applying our system to networks which have less than 128K concurrent connections. Comparison Figure 8. Drop rate of the system at different number of concurrent flows We also compare our system to other systems. We do not compare our system with the system in [3] because that system uses the method of out-of-order matching, and thus does not need to reorder out-of-sequence packets. We assume the network traffic conforms to the CAIDA_10G in [1]. Table I shows that our system can support out-of-sequence connections more than 98.8% compared to 89.6% in the system in [2]. Theoretically, the fixed length buffer method [1] and simple linked list method [5] can support more than 4 concurrent holes in a single connection. However, the number of connections with more than 4 holes is very small, so dropping packets which create more than 4 holes in a connection are more practical. In Table II, we compare the memory utilizations of our system with other systems. Because the design in [2] supports only single-hole connections, we compare the memory utilizations for single-hole connections only. In addition, we use simulation results to compare with other designs because our hardware system has only 64MB of memory. The first column is the number of out-of-sequence packets in a single-hole connection. In fixed length buffer method [1], the authors recommend each out-of-sequence connection have a minimum buffer of 16KB. Based on the statistical data in [1], the mean packet size is 441 ASEAN Engineering Journal, Vol 1 No 1, ISSN X, e-issn p.22

11 bytes, so buffering 64K connections requires 1024MB of memory. In 1-hole linked list method [2], the recommended page size is 2KB, so the memory requirements in the first two rows are 128MB instead. If this system uses the page size of 1KB, the memory requirement is a 4MB smaller than the memory requirement of our system as illustrated in the table. However, this system cannot handle connections with more than 1 hole. In simple linked list method [5], the system uses linked list of packets, so the system has to reserve a large space enough to store a biggest packet. The recommended buffer size is 1500 bytes, so the memory requirement is calculated in the table. However the mean packet size is 441 bytes, so this method is inefficient either. In general, the results show that our system uses memory more efficient than the others. Table 1. Number of Concurrent Holes in a Connections Number of holes in 1 connection Percentage Fixed buffer [1] 1-hole linked list [2] Simple linked-list [5] Our system % support support support support 2 7.3% support support support 3 1.9% support support support 4 1.2% support support support-4 Total 100% 100% 89.6% 100% >98.8% Table 2. Memory Utilization of Our System and Other Systems for Buffering 64k Single-hole Connections Number of Fixed buffer 1-hole linked Simple linkedlist Our system packets in 1 segment [1] list [2] [5] MB 64MB 93.75MB 68MB MB 64MB 187.5MB 68MB MB 128MB MB 132MB MB 128MB 375MB 132MB Conclusion In this paper, we present a technique of TCP reassembly. We focus on multi-linked list method to manage the memory of out-of-sequence packets, which is efficient and easy to scale up in the future. Besides, the edge buffering scheme is also deployed to detect crosspacket intrusion patterns in signature scanning engine. Our architecture supports connections with multiple concurrent holes, and it can support up to 99% of out-ofsequence connections. Moreover, our system supports a throughput at approximately 10Gbps. Experimental results show that our system can hold up to 256K concurrent connections and 46K out-of-sequence connections with only 64MB DRAM. In the future, we plan to implement an enhanced function, which will resolve the hash collision problem. References [1] R. Yuan, W. Yang, M. Chen, X. Zhao, and J. Fan, Robust TCP Reassembly with a hardware-based solution for backbone traffic, The Fifth IEEE International Conference on Networking, Architecture and Storage, pp , ASEAN Engineering Journal, Vol 1 No 1, ISSN X, e-issn p.23

12 [2] S. Dharmapurikar, and V. Paxson, Robust TCP Reassembly in the presence of adversaries, The 14th conference on USENIX Security Symposium, Vol. 14, pp , [3] Y. Sugawara, M. Inaba, and K Hiraki,., High-speed and memory efficient TCP stream scanning using FPGA, Field Programmable Logic and Applications International Conference, pp , [4] D.V. Schuehler, Techniques for Processing TCP/IP Flow Content in Network Switches at Gigabit Line Rates, Thesis (PhD),Washington University, United States, [5] P. Agarwal, TCP Stream Reassembly and Web Base guide for Sachet IDS, Thesis (Master), Indian Institute of Technology, India, [6] H. Chen, Y. Chen, and D. H. Summerville, A Survey on the Application of FPGAs for Network Infrastructure Security, the IEEE Communications Surveys and Tutorials, pp. 1-21, [7] S. Jaiswal, G. Iannaccone, C. Diot, J. Kurose, and D. Towsley, Measurement and Classification of Out-of-sequence Packets in a Tier-1 IP Backbone, Technical Report CS Dept. Tech. Report 02-17, UMass, pp , [8] D. Pao, W. Lin, and B. Liu, A memory-efficient pipelined implementation of the Aho- Corasick string matching algorithm, ACM Transactions on Architecture and Code Optimization, Vol. 7, No. 2, pp.1-27, [9] T. N. Thinh, S. Kittitornkun, and S. Tomiyama, Applying cuckoo hashing for FPGAbased pattern matching in NIDS/NIPS, International Conference on Field Programmable Technology, 2007, pp [10] B.T. Hieu, N. D. A. Tuan, and T. N. Thinh, BBFex: An efficient FPGA-based design for long patterns in Pattern matching system. International Conference on Intelligent Network and Computing, pp , [11] Net FPGA Technical Specifications, Available: [Accessed: August, 2012] [12] B. Shihada and P.H. Ho, Transport control protocol in optical burst switched networks: Issues, solutions and challenges. The IEEE Communications Surveys and Tutorials, Vol. 10, No.2, pp , [13] TCP Extension for High Performance, Available: [Accessed: August, 2012] [14] T.N. Thinh, S. Kittitornkun, S. Tomiyama and T.H. Vu, TCP Reassembly for Signature-based Network Intrusion Detection Systems, IEEE International Conference Electrical Engineering/Electronics, Computer, Telecommunications and Information Technology, pp. 1-4, ASEAN Engineering Journal, Vol 1 No 1, ISSN X, e-issn p.24