Highly Memory-Efficient LogLog Hash for Deep Packet Inspection

Transcription

1 Highly Memory-Efficient LogLog Hash for Deep Packet Inspection Masanori Bando, N. Sertac Artan, and H. Jonathan Chao Department of Electrical and Computer Engineering Polytechnic Institute of NYU Abstract Today s network line rates reach speeds of 40 Gbps and are anticipated to reach 100 Gbps in the near future. These high speeds make Deep Packet Inspection (DPI) in Network Intrusion Detection and Prevention Systems (NIDPSs) very challenging. The DPI examines each incoming packet byte-bybyte and matches them against a set of predefined malicious signatures. One way to achieve high-speed DPI is to store all the signatures on high-speed on-chip memory. However, on-chip memory is limited and space-efficient data structures are needed to leverage precious on-chip memory efficiently. A hash table addressed by a Minimal Perfect Hash Function (MPHF) is such a high-speed, space efficient data structure. In this paper, we describe a highly memory-efficient MPHF, which requires 3.5 bits per key to facilitate access to the key in on-chip memory while allowing us to perform the expensive exact match operation only once. The proposed MPHF also has a low construction time. I. INTRODUCTION To ensure reliable and secure services, network security has grown increasingly important in the Internet. Deep Packet Inspection (DPI) has been widely used in Network Intrusion Detection and Prevention Systems (NIDPSs) to detect malicious code such as viruses and worms [1] [2]. DPI examines each incoming packet byte-by-byte and matches them against a set of predefined malicious signatures. To implement DPI at 40 Gbps, or even 100 Gbps, cost effectively and scalable to a few tens of thousands keys is very challenging. Achieving the above objective requires including all the signatures on the chip to take advantage of parallelism/pipelining operations. Minimal Perfect Hash Functions (MPHFs) have been used, during the query, to access a key 1 in the hash table to compare with the incoming packet. The MPHF [3] guarantees that there will be only one key stored at each hashed location so that it needs to perform just one exact match operation (in other words, there is no hash collision). In addition, it achieves the minimum hash table size by equating the table size to the number of keys. In [4], we have proposed an on-chip trie-based framework called TriBiCa (Trie Bitmap Content Analyzer) to implement the MPHF on a Field-Programmable Gate Array (FPGA) chip at a speed of 10 Gbit/s [5]. Figure 1 shows TriBiCa with three different partitioning schemes. A simplified trie structure is illustrated in the left- 1 A key can be a whole or partial signature or some other information regarding a signature. Fig. 1: An example of trie based MPH data structure, and three partitioning schemes. hand side of the figure. TriBiCa starts with n keys at the root node of a trie and it partitions the keys into two sets (each set with n/2 keys). In the example, the root node contains eight keys (n = 8) [ABCDEFGH]. The eight keys are partitioned into two equal-sized sets in child nodes. Each child node has four keys [BDEH] and [ACFG]. We repeat this operation until we reach leaf nodes that are located in the bottom of the trie and that have only one key. As a result, an MPHF trie is constructed. 2 To query for a key, the algorithm traverses the trie until a single candidate key is located at a leaf node. When the single key is found, only one comparison between the queried key and the candidate key is needed to decide whether the queried key is actually the same as the candidate key. Although each query needs to traverse log 2 (n) levels, since the architecture is fully pipelinable the throughput is one query response per clock cycle. The right-hand side of Fig. 1 illustrates three different approaches for node partitioning; the partitioning of the root node is used as an example. In the first approach, bitmaps are used to represent the destination of keys [4] [5]. The figure shows an L as a destination to the left child node, and an R as a right child node. To allocate those input keys into the bins, a universal hash function [6] is used to distribute keys evenly. 2 If the number of keys is not a power of two (e.g., 5), the keys are pushed into the left nodes (i.e., some right nodes will be empty.). There is no need to store the empty nodes on the right, so the trie still provides an MPHF.

2 Let m be the number of bins. Then, this approach requires m bits for m bins, since bitmaps are used. The second approach, proposed in [7], uses a memory-efficient partitioning method, called a Boundary Hash, to replace the bitmaps. The Boundary Hash only keeps information of the boundary bin to partition a node (the third bin is the boundary bin in the figure). Hence, the memory requirement drops from m to log 2 (m). In this paper, we propose an even more memory-efficient approach named LogLog Hash (the third approach). In the figure, the left-most virtual bin has address 0 ( 000 in binary notation), and the right-most virtual bin has address m 1 = 7 ( 111 in binary notation). In this example, the most-significant bit is selected as a representative bit (circled by a dotted line - bit location 0 in the figure.). (log 2 (m)) = 3 bits are required to distinguish eight bins (m), and one bit is chosen out of the three bits as the representative bit. To distinguish between these three bits, ( log 2 (log 2 (m)) ) = 2 bits are required to store the representative bit. Section III discusses LogLog Hash in greater detail. The rest of the paper is organized as follows: Section II summarizes related work. Section III presents the proposed scheme. Section IV provides theoretical analysis of the memory usage and success probability of the proposed scheme. Section V summarizes the experiments executed to show the performance of the proposed scheme. Section VI concludes the paper. II. RELATED WORK Both software and hardware methods exist to implement DPI in NIDPSs. Snort [8] and Bro [9] are two software NIDPSs that support detection of sophisticated intrusions. Software NIDPSs run on general-purpose processors, which have difficulty catching up with today s line rates. To satisfy requirement of high-speed networks, we focus our discussion on hardware-based approaches. Hardware-based approaches can be classified, into off-chip memory [10] [11] and on-chip memory [12] [20] architectures. Considering speed as the first priority, off-chip memory architectures are not as tempting as on-chip approaches. The most critical drawback of the off-chip architecture is the requirement to physically connect to the matching engine(s) located on a chip. Physical pins are very expensive. Even if the external memory speed increases significantly, this physical pin problem still remains and obstructs the parallelism of engines. Thus, the off-chip approach is not suitable for very high-speed line-rate operations. For the partitioning operation, BARTS [21], a memoryefficient route lookup scheme, and our LogLog Hash choose a particular bit as a representative bit. However, BARTS selects the representative bit from the input keys, so uniformity of the input is critical for BARTS to succeed. Our approach uses the output of a universal hash function to avoid the uniformity requirement. The Perfect Hash Function proposed by Sourdis et al. [16] [20] also uses inputs as hash keys, and the hash function is hard-coded in the logic. Lu et al. [19] achieved MPHF using Bloom Filters with 8.6n bits. However, complex computations are required to locate entries in the hash table for queries. (a) A hash function h u1 results with a representative bit having equal number of zeros and ones circled by the dotted rectangle. (b) None of the bit positions has equal number of zeros and ones. Thus, no representative bit is found. Fig. 2: An example of LogLog Hash for (a) success and (b) non-success case. III. LOGLOG HASH Figure 2 shows an example of how the LogLog Hash scheme achieves equal partitioning of a set of n = 4 (K n : K 1... K 4 ) keys into two equal-sized subsets of two keys each, using the representative bit. All four keys are hashed, using universal hash function h u1 in (a) and h u2 in (b), into virtual bins (m). In this example, the hash result (location of the virtual bin (m)) can be between 0 and 7 ( in binary representation). Out of these log 2 (m) = 3 bits, the algorithm successfully finds a representative bit for this partitioning using h u1 in Fig. 2(a). b 1 is a representative bit in the example, since for half of the keys (K 1 and K 3 ) b 1 is 0, and for the remaining half (K 2 and K 4 ) b 1 is 1. In contrast, Fig. 2 (b) is a non-success case as none of bit location (b 2, b 1, b 0 ) contains an equal number of zeros and ones. We show in Section IV that the failure case is less likely to happen. The success probability of LogLog Hash is analyzed in Section IV. The simulation result is discussed in Section V. Figure 3 gives pseudo-code to implement LogLog Hash to construct a node. The algorithm first calculates a hash function for each key and stores the results. The function updatebit- Counts counts the number of ones for all bit locations and returns the value. The algorithm then searches for each bit location based on updatebitcounts results to determine whether a representa-

3 tive bit exists for the particular hash result in this set of keys. If so, the algorithm returns the location of the representative bit; otherwise, it returns null. The algorithm has a worstcase run time of O(n log 2 (log 2 (m))) to determine whether a representative bit exists for a node using one hash function. If no representative bit is found (null as the return value), the operation is repeated with another hash function. 1: LogLogHash (S, h u, A ) 2: // S is a set of n keys (K 1...K n ) 3: // h is a universal hash function with range [0, m 1] 4: // A is an array of m bins 5: // l = log 2 (log 2 (m)) 6: // L is an array of l counters 7: 8: // Programming 9: for i = 1 to n do 10: insert K i to A[h(K i )] 11: updatebitcounts(l, l, A[h(K i )]) 12: end for 13: // Determine the representative bit 14: for j = 0 to l 1 do 15: if L[j] = n/2 then 16: return (j) 17: end if 18: end for 19: return (null) // No representative bit, return null 20: 21: updatebitcounts (L, l, location) 22: for j = 0 to l 1 do 23: if location[j] = 1 then 24: L[j]++ 25: end if 26: end for 27: return (L[ ]) Fig. 3: Pseudo-code for partitioning a node using LogLog Hash. IV. ANALYSIS A. Space Complexity of LogLog Hash This section discusses the space complexity of LogLog Hash and compares it with Boundary Hash. For Boundary Hash, the space complexity derived in [7] is shown in (2). In each level (l), there are 2 l nodes and each node requires log 2 (M R /2 l ) bits; root node is at level l = 0. The sizes of the nodes are determined by the size of the root node M R. M Bl = 2 l log 2 (M R /2 l ) (1) From (1), the total memory for the Boundary Hash trie with log 2 (n) levels is M B = log 2 (M R /n) n + 2 n log 2 (M R ) 2 (2) To analyze the memory requirement of LogLog Hash, let us start with the space complexity of each level. Each node reserves log 2 (log 2 (m V )) bits of memory where m V is the number of virtual bins at each node. It is called virtual, since the nodes do not keep information of individual bins. In Boundary Hash, the size of the virtual bin is adjusted by the size of the keys in a node to maintain success probability. LogLog Hash eliminates this restriction by a higher success probability. M Ll = 2 l log 2 (log 2 (m V )) (3) From (3), the total memory for the LogLog Hash trie with log 2 (n) levels is M L = log 2 (n) 1 l=0 2 l log 2 (log 2 (m V )) (4) = log 2 (log 2 (m V )) (n 1) From (4), the space complexity to store the representative bit for the entire trie is O(n). LogLog Hash also requires space for storing hash functions, since our scheme uses a pool of hash functions. Let H w be the size of each hash function and H be the total number of universal hash functions used in the system. Then, the complexity of storing hash functions is given as O(n (log 2 ( H )+H w )). In the worst case, H = (n 1) different hash functions are required. (In the worst case, all nodes use different hash functions.) Thus, worst-case complexity is O(n (log 2 (n)+h w )). However, the simulation results in Section V show that the requirement is much lower in practice. B. Success Probability of LogLog Hash Success probability of a node is the probability of finding a representative bit to partition the keys in the node into two equal-sized sets. A higher success probability implies fewer hash functions required by the system, leading to less memory consumption. For a partitioning to be successful, the LogLog Hash algorithm needs to find at least one representative bit. The probability s for a particular bit to be a representative bit is derived as follows. From a set of n keys, if we pick a particular bit location to form an n-bit sequence, the number of possible bit sequences is 2 n (any n has a choice of two values: either 0 or 1). Out of these possible sequences, only a particular bit location with exactly n/2 ones (or zeros) is qualified as a representative bit. There are ( n n/2) such combinations. Therefore, s is given as: ( n ) n/2 s = 2 n (5) Then, for a set of n keys using m bins, the probability that none of the bits is a representative bit is given as: q = (1 s) log 2 (mv ) (6) Finally, from (6) the probability of successfully partitioning this set using LogLog Hash, p = 1 q (equally, the probability of finding at least one representative bit) is derived as:

4 P L = 1 ( 1 ( n n/2 2 n ) ) log2 (m V ) } {{ } No representative bit The success probability of LogLog Hash for different key size (n) corresponding to partitioning bits is shown in Table I (a). Those values are computed using (7). For comparison, success probability of the Boundary Hash, P B, is shown in (8) [7]. ) ǫ ( ) n b 1 m m 2 n/2 ( )( ) ( n ǫ n 1 2 ǫ ( m b P B = n b=0 ǫ=1 2 ǫ ǫ m m (8) where n is the key set size, m is the bin size, and ǫ is the number of key(s) in the boundary bin. Table I (b) shows the numerical values corresponding to the equation. Comparing Table I (a) and (b), it is clear that the success probability of LogLog Hash is always better than Boundary Hash using the same amount of memory for partitioning. TABLE I: Success probability comparison between Boundary Hash and LogLog Hash based on partitioning bits and key sizes. n=2 n=4 n=8 n=16 n=32 n=64 n=128 1-bit bits bits bits bits bits bits (a) LogLog Hash (Theoretical Result) n=2 n=4 n=8 n=16 n=32 n=64 n=128 1-bit bits bits bits bits bits bits (b) Boundary Hash (Theoretical Result) If we only consider success probability, it seems better to use the LogLog Hash scheme in every level of the trie instead of Boundary Hash. Yet, in practice there is a tradeoff. The 7-bit LogLog Hash function requires 128 bits as a hash coefficient, which increases memory consumption and hardware complexity. However, we would like to emphasize that those large hash coefficients are only required if the node has a larger number of keys (greater than n = 1024) and those nodes are much more limited in number, compared to the majority of the smaller key size nodes. (e.g., half of the nodes in the entire trie are n = 2, a quarter of the nodes are n = 4, etc.). Thus, in this paper, we focus on those smaller (7) ) n 2 nodes, and use up to five partitioning bits (i.e., 32 bits as a hash coefficient). Table II shows simulation results for the success probability of partitioning a node using LogLog Hash. Each value is based on 8192 nodes with 100 different hash functions (i.e., nodes are examined to find the success probability for each setting). Compared to our theoretical result (Table I), values are accurately matched. The error rate of those values is, at most, 0.7%. TABLE II: Success probability of partitioning a node using LogLog Hash for different numbers of keys. (Simulation Result) n=2 n=4 n=8 n=16 n=32 n=64 n=128 1-bit bits bits bits bits V. PERFORMANCE Performance of LogLog Hash is verified using a simulation program developed in C#, which runs on AMD Athlon64 (2.8 GHz) with 2 Gbytes of main memory. In this section, we focus on two parameters: (1) Memory usage, and (2) construction time. In the first experiment, the LogLog Hash and Boundary Hash are compared for various key set sizes (n = 1K... 1M) where each key is a 32-bit random number. For each key set size, 100 different key sets are examined. Then, the LogLog Hash and Boundary Hash are constructed for each of these key sets. For the Boundary Hash, configuration of M R = 2n is used, which gives the best results [7]. To be fair, we use the same or less number of virtual bins for LogLog Hash (i.e., the last level uses two bits, and the level above it uses three bits). All nodes with n = use five bits, and nodes at higher levels use Boundary Hash. Figure 4 shows the average and maximum number of hash functions required for each trie in this experiment for different n. The LogLog Hash results are shown as solid lines. The Boundary Hash results are shown as dotted lines. Following the theoretical results discussed in Section IV, LogLog Hash uses fewer hash functions in both average and maximum cases (i.e., less memory required in any key set size.). The next experiment focuses on optimizing the memory requirement of LogLog Hash. LogLog Hash is used in the last ten levels and Boundary Hash is used for higher levels. The lower levels have more significance in the total memory usage, so this assumption is realistic to show the performance of LogLog Hash. An example representation for the configuration of LogLog Hash is [ ] where the leftmost digit shows the number of bits in a node at the highest level that uses LogLog Hash (i.e., level 10) and the rightmost digit shows number of bits in a node at the last level. In other words, this configuration shows that the 10 th level uses five bits (2 32 virtual bins) and the last level uses one bit (four virtual bins).

5 a stateful detector with 3531 keys) 3 ; details are described in [5]. The experiment is repeated for 100 different hash sets. The results show that the first and second detector require a maximum of 5.50n bits and 5.42n bits using LogLog A configuration, respectively. Compared to existing schemes, our proposed LogLog Hash requires less memory to operate. For instance, our previously proposed TriBiCa [4] and Boundary Hash [7] require 11n bits and 7n bits, respectively. Moreover, [22] reported that they have a memory requirement of 8.6n-bits for Snort signatures, and [23] shows that their MPHF requires 6.86n bits. Fig. 4: Number of hash functions required for various key set sizes for LogLog Hash and Boundary Hash. Each data point shows a maximum or an average value over the 100 key sets. Memory requirements of LogLog Hash for different settings are shown in Fig. 5. The Boundary Hash results are also plotted as a comparison. LogLog A, B, and C has configurations [ ], [ ], and [ ], respectively. For smaller key set sizes, there are some fluctuations because of hash coefficient storage. However, the number of hash functions will very slowly increase proportional to the key set. Thus, the hash coefficient storage will be negligible for larger key set sizes. The number converge at 5.6n around n = 1M. Fig. 5: Memory required for various key set sizes for LogLog Hash and Boundary Hash. Each data point shows a maximum value over the 100 key sets. To show the memory usage for DPI, Snort signatures [8] are programmed in the LogLog Hash trie. The TriBiCa framework uses two detectors (a 4-byte detector with 2723 keys and TABLE III: Average LogLog Hash construction times for key sets with different sizes. Time is given in milliseconds. The table shows trie construction time and total time (including time to hash keys using universal hash functions) separately. LogLogTrie Total 1K K K K K K K K K K M Table III shows the average construction times of the LogLog Hash in milliseconds for 100 key sets. Both trie construction time and total time increase linearly proportional to input key size n. A. Hash Grouping We would like to mention one memory reduction optimization called hash grouping. Until now, we assumed all nodes could use different hash functions (i.e., memory for the hash ID needed to be reserved in each node). According to the previous simulation results, more than half of the space requirement is for hash storage. Thus, if multiple nodes (a group) can share the same hash function as in TriBiCa [4], the memory requirement can be reduced significantly. For example, if the number of keys is 1024, then there are 512 nodes in the last level. Using hash grouping with a group size of 32, only 16(= 512/32) hash IDs need to be stored instead of 512 hash IDs. Figure 6 shows the simulation results for different group sizes of G = Total memory consumption drops as group sizes become larger. For G=32, memory is reduced to nearly 3n for large key sizes. LogLog Hash is used in the last six levels [555432] and higher levels 3 When input key set size is not a power of two, at most, one of the nodes in each level is partially populated by keys. This means partitioning the node exactly in half is the right operation (e.g., if the root node contains six keys, the left child node must contain four keys and the right child nodes must have two keys.). Boundary Hash is more suitable for partitioning nodes that are partially occupied. Thus, Boundary Hash is used for those nodes. Those nodes appear, at most, in one node in each level (log 2 (n)), which is negligible. However, to be more precise, those nodes are considered in our Snort simulation results.

6 use Boundary Hash with m=8n. Due to limited space, only the simulation results are shown for the hash grouping and a detailed discussion is left as a future work. Fig. 6: Memory requirement for various key set sizes for LogLog Hash with grouping. Each data point shows a maximum value over the 100 key sets. VI. CONCLUSION This paper presents a highly memory-efficient trie-based Minimal Perfect Hash Function, called the LogLog Hash. The proposed compact and simple design allows very highspeed Deep Packet Inspection for Network Intrusion Detection and Prevention Systems. The LogLog Hash requires 5.6n bits without hash grouping for n 2K, and 3.5n bits with hash grouping for n 8K. VII. ACKNOWLEDGMENTS The authors would like to thank Yanming Shen, Najla Alfaraj, and HoYu Lam for their insightful comments. [10] F. Yu, T. Lakshman, and R. Katz, Gigabit Rate Pattern-Matching using TCAM, in Int. Conf. on Network Protocols (ICNP), Berlin, Germany, Oct [11] H. Song and J. Lockwood, Multi-pattern Signature Matching for Hardware Network Intrusion Detection Systems, in 48th Annual IEEE Global Communications Conference, GLOBECOM 2005, St Louis, MO, Nov-Dec [12] C. Clark and D. Schimmel, Scalable Pattern Matching for High- Speed Networks, in IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM), Napa, California, 2004, pp [13] Y. H. Cho and W. H. Mangione-Smith, Fast Reconfiguring Deep Packet Filter for 1+ Gigabit Network, in FCCM, 2005, pp [14] Z. K. Baker and V. K. Prasanna, High-Throughput Linked-Pattern Matching for Intrusion Detection Systems, in Proc. of the First Annual ACM Symposium on Architectures for Networking and Communications Systems, Princeton, NJ, 2005, pp [15] J. Moscola, J. Lockwood, R. P. Loui, and M. Pachos, Implementation of a Content-Scanning Module for an Internet Firewall, in FCCM, 2003, pp [16] I. Sourdis, D. Pnevmatikatos, S. Wong, and S. Vassiliadis, A Reconfigurable Perfect-Hashing Scheme for Packet Inspection, in Proc. 15th International Conference on Field Programmable Logic and Applications (FPL 2005), August 2005, pp [17] L. Tan and T. Sherwood, Architectures for Bit-Split String Scanning in Intrusion Detection, IEEE Micro, vol. 26, no. 1, pp , Jan-Feb [18] G. Papadopoulos and D. N. Pnevmatikatos, Hashing + Memory = Low Cost, Exact Pattern Matching, in Proc.15th International Conference on Field Programmable Logic and Applications (FPL), August 2005, pp [19] Y. Lu, B. Prabhakar, and F. Bonomi, Perfect Hashing for Network Applications, in IEEE Symposium on Information Theory), Seattle, WA, 2006, pp [20] I. Sourdis, D. N. Pnevmatikatos, and S. Vassiliadis, Scalable multigigabit pattern matching for packet inspection. IEEE Trans. VLSI Syst., vol. 16, no. 2, pp , [21] J. van Lunteren, Searching Very Large Routing Tables in Wide Embedded Memory, Global Telecommunications Conference, GLOBECOM 01. IEEE, vol. 3, [22] L. Tan and T. Sherwood, Architectures for Bit-Split String Scanning in Intrusion Detection, IEEE Micro, vol. 26, no. 1, pp , Jan-Feb [23] K. Chellapilla, A. Mityagin, and D. Charles, Gigahash: scalable minimal perfect hashing for billions of urls, in WWW 07: Proceedings of the 16th international conference on World Wide Web. New York, NY, USA: ACM, 2007, pp REFERENCES [1] Sourcefire 3d. [Online]. Available: [2] Fortinet. [Online]. Available: [3] P. E. Black, Minimal Perfect Hashing, in Dictionary of Algorithms and Data Structures. U.S. National Institute of Standards and Technology, July [Online]. Available: [4] N. S. Artan and H. J. Chao, TriBiCa: Trie Bitmap Content Analyzer for High-Speed Network Intrusion Detection, in 26th Annual IEEE Conference on Computer Communications (INFOCOM), 2007, pp [5] N. S. Artan, R. Ghosh, Y. Guo, and H. J. Chao, A 10-Gbps High-Speed Single-Chip Network Intrusion Detection and Prevention System, in 50th Annual IEEE Global Communications Conference, GLOBECOM 2007, Washington, DC, Nov [6] J. L. Carter and M. N. Wegman, Universal classes of hash functions (extended abstract), in STOC 77: Proceedings of the ninth annual ACM symposium on Theory of computing. New York, NY, USA: ACM, 1977, pp [7] N. S. Artan, M. Bando, and H. J. Chao, Boundary Hash for Memory- Efficient Deep Packet Inspection, in IEEE International Conference on Communications (ICC 2008), Beijing, China, May [8] [Online]. Available: [9] V. Paxson, Bro: A System for Detecting Network Intruders in Real- Time, Computer Networks, vol. 31, no. Dec, pp , 1999.