throbber
Published in IET Networks
`Received on 20th December 2011
`Revised on 19th February 2012
`doi: 10.1049/iet-net.2011.0048
`
`www.ietdl.org
`
`ISSN 2047-4954
`
`Design and evaluation of deep packet inspection
`system: a case study
`M.-Y. Liao1 M.-Y. Luo2 C.-S. Yang1 C.-H. Chen3 P.-C. Wu3 Y.-W. Chen1
`1Institute of Computer and Communication Engineering, Department of Electrical Engineering, National Cheng Kung
`University, Taiwan
`2Department of Computer Science and Information Engineering, National Kaohsiung University of Applied Sciences,
`Taiwan
`3Department of Computer Science and Engineering, National Sun Yat-sen University, Taiwan
`E-mail: myluo@cc.kuas.edu.tw
`
`Abstract: An increasing number of Internet applications and services render network management more troublesome for
`bandwidth misuse and security concern. As a result, network traffic identification plays an increasingly important role in
`network management. Deep packet inspection (DPI) is one of the effective approaches. Conventional network devices lookup
`the header of a packet, but DPI means the network device is required to match a pattern in the payload of a packet. This
`study proposes a DPI system and WMT (Wu-Manber with trie) algorithm to classify popular network services; The Net-DPIS
`is developed based on Netfilter framework in Linux kernel. The authors show how to rearrange the rule policies to increase
`the performance of Net-DPIS. In the results, the authors show that WMT algorithm is faster than WM algorithm; Net-DPIS
`has higher average accuracy and performance than L7-filter.
`
`1
`
`Introduction
`
`More and more Internet applications bind random port
`number to transmit message and data; the port number is
`not exactly mapping to a network service and to identify
`traffic with protocol type and port number is not enough
`[1]. As a result,
`there are many challenges in traffic
`classification. A running instance of a network application
`may generate a series of packets. A packet is composed
`with header and payload, and the header carries layering
`information, such as the IP address is in the layer three and
`the port number is in the layer four. The payload carries
`upper layer application protocol and data. Network services
`transmit data over the application protocol. HTTP uses GET
`or PUT as method and MSN uses NLN or BSY as user
`status. These strings are generally unique so that they could
`be thought as
`the patterns or
`signatures of network
`applications. DPI mechanism plays an important role in
`traffic characterisation and fine-grained network monitoring
`by searching the payload of network packets for known
`patterns or signatures [2].
`In this paper, Net-DIPS (Netfilter [3]-based deep packet
`inspection system) is proposed and developed based on
`Linux Netfilter framework. The first part of a DPI system is
`to capture packets
`from network interface cards, and
`manipulate them for
`further detecting certain network
`patterns while trying to minimise packet processing latency.
`We extend the Netfilter
`framework of Linux kernel
`to
`implement an efficient mechanism to achieve this. As a
`result, the result of this paper can be applied to all network
`
`system equipped Linux kernel. The second part of a DPI
`system is to search known signature patterns in the payload
`of packets. Variable pattern length and location, and
`constantly added rules make pattern matching a difficult
`task. Net-DPIS improves the WM multi-pattern matching
`algorithm [4] with a novel design of
`the rule table.
`Rajkumar [5] indicates that feature analysis of network
`service is able to avoid unnecessary matching; this study
`also improves the rule table of Net-DPIS.
`The remainder of this paper is organised as follows:
`Section 2 describes the related work. We describe the
`Netfilter framework and our extension in Section 3. We
`detail how to construct the rule table to increase the speed
`of Net-DPIS effectively in Section 4. Section 5 measures
`the performance of WMT algorithm and compares Net-
`DPIS with L7-filter [6], IPP2P [7] and Sen-Spatscheck-
`Wang (SSW) [8]. Finally, Section 6 concludes the paper.
`
`2
`
`Related works
`
`Increasingly, network traffics are classified not only by the
`fields of their packet headers (e.g. port number defined by
`Internet Assigned Numbers Authority), but also by the
`content of their payloads. As a result of these trends, there
`has been a considerable amount of
`recent work on
`implementing signature-based DPI in software system [6, 9,
`10] or networking devices [11]. Therefore some approaches
`[12 – 15] have been proposed to identify the network traffic,
`and DPI is one of the effective approaches.
`
`IET Networks, pp. 1 – 8
`doi: 10.1049/iet-net.2011.0048
`
`1
`& The Institution of Engineering and Technology 2012
`
`EX 1008 Page 1
`
`

`

`www.ietdl.org
`
`2.1 Deep packet inspection
`
`DPI technique inspects both the header and the payload of a
`packet. String matching algorithms such as KMP (Knuth–
`Morris–Pratt) [16], AC (Aho–Corasick) [17], BM (Boyer–
`Moore)
`[18], CW (Commentz–Walter)
`[19] and WM
`(Wu–Manber) [4] algorithms have been the foundation for
`many DPI systems over many years. Owing to the variable
`position of a signature in packet payload, the string matching
`algorithm directly affects the matching performance of an
`identification system. The authors of [8, 20, 21] suggest that
`the signature in packet payload can be used for generating
`service rules. This paper proposed a design of rule table can
`improve the performance of traffic identification.
`Many DPI systems use regular expressions to depict pattern
`signatures as more general cases. There have been numerous
`studies on regular expression matching [22 – 24]. L7-filter is a
`packet
`identification system whose regular expression is
`based on Henry Spencer’s Bell Version 8 Regular
`Expression. This version of the regular expression has the
`following limitations; Bound, Character Class and Back
`Reference are not used. Currently, L7-filter supports to
`identify 120 types of services, including 23 types of P2P
`applications. Different platforms have been used to
`implement DPI
`system,
`including ASICs
`[25], field
`programmable gate arrays [26], network processors [27] and
`even cloud platform [28].
`As shown in Fig. 1, the depth (N ) means that the first N
`bytes of the payload are required to be searched by DPI
`system; Hsu [29] indicates that Net-DPIS finds 99% of
`identifiable network flows in the first 600 bytes of a
`payload, DPI
`system could set a suitable depth (N )
`according to the tradeoff of accuracy and cost time.
`
`2.2 Netfilter framework
`
`The Netfilter framework is located in the Linux kernel IP
`layer; it provides a set of hooks to intercept and manipulate
`the packets. Netfilter
`framework provides
`the packet
`processing function such as packet filtering, packet
`forwarding, connection tracking, network address translation
`(NAT), packet mangling for packet modification etc. The
`Netfilter framework for kernel version 2.6 implements five
`hooks to intercept and manipulate packets as illustrated in
`Fig. 2. If the packets are forwarded to the next hop, they go
`through the path of PREROUTING, FORWARD and
`POSTROUTING chains. The packets are received to local
`network service via the PREROUTING and INPUT chains.
`Outgoing
`packets
`are
`sent
`out
`via OUTPUT and
`POSTROUTING chains. Netfilter firewall is registered at
`INPUT chain for end-host servers.
`Netfilter framework provides the iptables utilities for users
`to configure the Netfilter framework, for example, firewall
`rules configuration. The iptables utilities in user space
`communicate with the Netfilter framework in the kernel
`space via the Netlink socket. Netlink socket is socket-like
`system calls for accessing the kernel space. Unlike other
`
`Fig. 2 Netfilter framework
`
`system calls, Netlink socket has the benefits that support
`asynchronous
`operations,
`duplex
`characteristics,
`multicasting and short
`response
`time
`for user-space
`applications etc. Netfilter firewall manages the firewall rules
`using the linked-list data structure. So every packet must
`check all firewall rules until
`it finds the rule-matching
`result. As a consequence, the number of rules and incoming
`packets determine firewall’s computation complexity. With
`the growth of rules and incoming packets, CPUs would
`spend considerable time on the Netfilter firewall;
`this
`situation would influence the overall performance of
`network application.
`
`3 Design and implementation of Net-DPIS
`
`Net-DPIS is a network traffic classification system; Fig. 3 is
`the network topology. The core switch clones the network
`traffic between local area network (LAN) and Internet to a
`mirror port. The advantage of using port mirror is that we do
`not need to change the network topology and the Net-DPIS
`will not be the bottleneck while network traffic is large.
`What we have to do is to enable the port mirror feature of the
`core switch and to connect Net-DPIS with the mirror port of
`the core switch. If we use online mode, we have to make
`the network traffic go through Net-DPIS;
`the processing
`delay of Net-DPIS may cause packet lose. We show the
`details of design and implementation in this section.
`
`3.1 System architecture
`
`A core switch enables the port mirror function to clone all
`packets in LAN and all of the cloned packets are sent to a
`Net-DPIS. The system components are shown in Fig. 4.
`The Net-DPIS sets the network interface card (NIC) in
`promiscuous mode and captures all the cloned packets from
`the core switch. Net-DPIS is developed based on Netfilter
`
`Fig. 1 Inspection depth length
`
`Fig. 3 Network topology (port mirror)
`
`2
`& The Institution of Engineering and Technology 2012
`
`IET Networks, pp. 1 –8
`doi: 10.1049/iet-net.2011.0048
`
`EX 1008 Page 2
`
`

`

`www.ietdl.org
`
`study, we proposed a patch of PROMISC hook for Linux
`kernel 2.6.31 [35].
`
`3.3 Traffic classification
`
`Traffic classification is the core module of Net-DPIS for
`identifying the network traffic;
`the purpose of
`traffic
`classification is to match signatures in payload. Notations
`used in this paper are explained in Table 1.
`Formula (1) is used to define how to classify the signatures
`into the four types of matching policies:
`|p| = 1 and x = 0
`|p| = 1 and 0 % x % (L − S)
`|p| . 1
`|p| = 1 and c = L
`
`(1)
`
`⎧⎪⎪⎨
`⎪⎪⎩
`
`a if
`b if
`g if
`l if
`
`t =
`
`Fig. 4 System architecture
`
`[3] framework in Linux kernel. A PROMISC hook is added
`to Netfilter
`framework;
`the PROMISC hook cloned
`packets from NIC. Connection tracking module is a native
`module on Netfilter framework and maintains the connection
`information. Cloned
`packets
`are
`classified
`in
`traffic
`classification module and the classified results are recorded in
`database. Net-DPIS uses
`simple network management
`protocol (SNMP) trap message to communicate with network
`management system (NMS) [30, 31]. While event handler
`sends the results of traffic classification with updating the
`private management information base (MIB), Net-DPIS sends
`connection information and service types to NMS over the
`SNMP trap message.
`
`3.2 PROMISC hook
`
`In Netfilter framework, there are five native hooks which are
`called NF_IP_PRE_ROUTING, NF_IP_LOCAL_IN, NF_
`IP_FORWARD, NF_IP_LOCAL_OUT and NF_IP_POST_
`ROUTING as shown in Fig. 3. While a NIC runs in
`promiscuous mode,
`the NIC captures all
`the incoming
`packets. If the destination media access control (MAC)
`address of a packet is not the same with the NIC of Net-
`DPIS,
`the packet
`is dropped;
`if
`the destination MAC
`address of a packet is the same with the NIC of Net-DPIS,
`the packet is allowed to enter Netfilter framework [32, 33].
`In order to allow all packets from NIC to enter Netfilter
`framework, we modified receive module and added a
`PROMISC hook on Netfilter
`framework to receive the
`packets that should be dropped. Shishlov [34] proposed a
`patch of PROMISC hook for Linux kernel 2.4;
`in this
`
`Net-DPIS uses four matching policies to increase the
`performance of pattern matching; the following statements
`describe four matching policies: As shown in Fig. 5, zero
`offset policy and fixed offset policy match signatures at a
`static offset x, zero offset policy is a case of fixed offset
`policy whereas the offset x is at 0. ‘PASV’ is one of zero
`offset signatures; ‘BitTorrent protocol’ is one of fixed offset
`signatures and starts at offset 1. Variable offset policy
`matches signatures at dynamic offset x; ‘SMTP’ signature
`belongs to variable offset type. Arithmetic policy computes
`the message header; an example of arithmetic policy,
`the message header of eDonkey has the following data
`structure: protocol field, message length field and message
`
`IET Networks, pp. 1 – 8
`doi: 10.1049/iet-net.2011.0048
`
`3
`& The Institution of Engineering and Technology 2012
`
`EX 1008 Page 3
`
`

`

`www.ietdl.org
`
`Table 1 Notations definition
`
`Symbol
`
`Definition
`
`L
`S
`c
`t
`a
`b
`g
`l
`x
`p
`|p|
`
`N
`R
`m
`B
`
`length of the payload of a packet
`length of the signature
`content of the signature
`type of the signature
`zero offset signature type
`fixed offset signature type
`variable offset signature type
`arithmetic signature type
`position of the signature
`the position set of the signature, p = {x [ 0 % x % (l − s)}
`number of the elements in p set, |p| . 1 means that the
`signature occurs at more than one position
`the deep length of payload which is inspected by Net-DPIS
`the rule of identifying a service type
`length of shortest pattern
`the number of characters is matched in a matching cycle
`
`Fig. 5 Locating the signature
`
`3.5 Rule table
`
`Fig. 7 Refined traffic classification flowchart
`
`In the latter result of this paper will show that WMT
`effectively improves the cost time in pattern matching.
`
`ID field [35]; eDonkey traffic is identified with counting the
`message size in byte and compares the counting result with
`the message length field in message header.
`Fig. 6 shows the flowchart of traffic classification. While
`traffic classification module gets a packet, four policies are
`used to search if there are any signatures in the packet; the
`rule table identifies the service type of the packet according
`to the results of four policies.
`
`3.4 Pattern matching
`
`WMT (WM with trie) is an evolution from WM pattern
`matching algorithm. WM algorithm uses hash structure
`to lookup patterns and the maximum offset of shift
`is
`(m 2 B + 1). WMT algorithm uses a trie structure to reduce
`the hash collisions; shift distance table (SDT) of fast string
`matching algorithm for network processor (FNP) algorithm
`[36] is referred by WMT to design the shift table of WM.
`
`To understand the features of network services is useful to
`prevent the unnecessary pattern matching. The rules in rule
`table are used to identify the service type of the network
`traffic;
`there are more than 300 rules in Net-DPIS. We
`rearrange the rule policies of the rule table in order to
`effectively reduce the time of lookup table. In the pattern
`matching of the four policies, the variable offset policy is
`the most
`time consuming;
`thus,
`to separate the variable
`signatures can reduce the time. The improved traffic
`classification procedure is as shown in Fig. 7. Zero offset,
`fixed offset and arithmetical signatures are first used for
`traffic classification state one. In cases of failure to search,
`the name of the corresponding service is returned;
`the
`variable offset policy is not required.
`
`3.6 Connection tracking table
`
`In general, there are more than one packet in a connection;
`the packets in an identified connection should not be
`inspected in the reason of saving computing performance.
`In order to prevent to match the remainder packets in an
`identified connection, a connection tracking table is used
`and records the following records: (i) source IP address, (ii)
`
`Fig. 6 Traffic classification flowchart
`
`Fig. 8 Experimental environment
`
`4
`& The Institution of Engineering and Technology 2012
`
`IET Networks, pp. 1 –8
`doi: 10.1049/iet-net.2011.0048
`
`EX 1008 Page 4
`
`

`

`destination IP address, (iii) source port, (iv) destination port,
`(v) protocol,
`(vi) packet count,
`(vii) byte count,
`(viii)
`connection state, (ix) connection expired time, (x) service
`type. When a connection is identified,
`the connection
`information will be recorded in the connection tracking table.
`If a packet belongs to the identified connection, the traffic
`classification module is not required to match the packet; on
`the contrary,
`if the connection is not
`identified yet,
`the
`connection information does not exist
`in the connection
`tracking table and the traffic classification is necessary. The
`connection recorded by connection tracking is two-way
`information; when Net-DPIS receives the first packet in one
`connection to be identified; opposite direction information
`would be generated. The packet count and byte count of a
`connection can be obtained with the sum of both ways.
`
`4
`
`Performance evaluation of Net-DPIS
`
`This section describes that we measure the time cost in each
`stage and reconstruct the policies of Net-DPIS to increase
`the performance effectively.
`
`4.1 Experimental environment
`
`the experimental environment and the
`Fig. 8 shows
`specification of the Net-DPIS and packet generator will be
`described in the following statements. The Net-DPIS is a
`personal computer with dual-core CPU, Ubuntu Linux
`10.04 operating system, a Linux kernel version 2.6.31 and a
`D-Link DGE-530T Gigabit Ethernet Adapter;
`the packet
`generator
`is a personal computer with dual-core CPU,
`Ubuntu Linux 10.10 operating system and a Intel(R)
`82567LM Gigabit Ethernet Adapter;
`the switch supports
`Gigabit Ethernet and port mirror. The packet generator
`
`Table 2 Time cost in different inspection depths
`
`www.ietdl.org
`
`generates the network traffic to the user client, and the
`switch will mirror the traffic between the packet generator
`and the user client to Net-DPIS with port mirror function.
`
`4.2 Time measurement of Net-DPIS
`
`is conducted to observe the time cost.
`This experiment
`The packet generator sends UDP packets to the user client.
`Each experiment is repeated ten times and lasts 10 s. The
`packet size is the sum of L2 header, L3 header, L4 header
`and payload length in byte;
`the Net-DPIS matches
`the signatures in the payload and is configured to inspect
`the payload in the depth of 60, 300, 900 and 1500 bytes. The
`packet generator sends user datagram protocol (UDP) packets
`at 1514 bytes to the user client. The results are as shown in
`Table 2; the unit of time is microsecond. From the results,
`we can find that most of time is used to lookup rule table.
`
`4.3 Time cost of traffic classification
`
`In this experiment, the inspection length of the Net-DPIS is at
`60, 300, 900 and 1500 bytes; the packet generator sends UDP
`packets at 82, 342, 937 and 1514 bytes to the user client; each
`experiment is repeated ten times. Table 3 shows a comparison
`of the time cost in traffic classification; the unit of data is
`microsecond. The time cost of
`the Net-DPIS and the
`modified Net-DPIS are reduced with the reduction in packet
`length, when the packet length is fixed; the total time cost
`of the modified Net-DPIS is 23(cid:2)35% less than the Net-DPIS.
`
`4.4 Time cost of look-up table
`
`Table 4 shows a comparison of the look-up table time.
`The average time of the Net-DPIS is 79.4 –88.1 ms. The
`
`Zero offset
`time, ms
`
`Fixed offset
`time, ms
`
`Variable offset
`time, ms
`
`Arithmetic
`time, ms
`
`Lookup rule
`time, ms
`
`Total time,
`ms
`
`60
`300
`900
`1500
`
`14.3
`14.2
`14.3
`14.4
`
`9.7
`9.8
`9.8
`9.9
`
`7.14
`14.5
`33.6
`55.1
`
`5.2
`5.4
`5.6
`5.3
`
`80.3
`79.9
`80.2
`79.4
`
`116.6
`123.8
`143.5
`164.1
`
`Table 3 Time cost of traffic classification
`
`1514
`
`937
`
`342
`
`82
`
`Net-DPIS
`
`Modified
`
`Net-DPIS
`
`Modified
`
`Net-DPIS
`
`Modified
`
`Net-DPIS
`
`Modified
`
`60
`300
`900
`1500
`
`116.6
`123.8
`143.5
`164.1
`
`79.9
`87.1
`104.7
`125.1
`
`117.7
`123.2
`130.3
`–
`
`80.9
`85.4
`94.3
`–
`
`124.2
`125.9
`–
`–
`
`80.2
`82.4
`–
`–
`
`117.3
`–
`–
`–
`
`79.3
`–
`–
`–
`
`Table 4 Time cost of lookup table
`
`1514
`
`937
`
`342
`
`82
`
`Net-DPIS
`
`Modified
`
`Net-DPIS
`
`Modified
`
`Net-DPIS
`
`Modified
`
`Net-DPIS
`
`Modified
`
`60
`300
`900
`1500
`
`80.3
`79.9
`80.2
`79.4
`
`43.3
`43.7
`43.2
`42.9
`
`80.2
`80.4
`79.4
`–
`
`43.5
`43.4
`43.4
`–
`
`88.1
`87.9
`–
`–
`
`44.3
`44.0
`–
`–
`
`81.6
`–
`–
`–
`
`43.7
`–
`–
`–
`
`IET Networks, pp. 1 – 8
`doi: 10.1049/iet-net.2011.0048
`
`5
`& The Institution of Engineering and Technology 2012
`
`EX 1008 Page 5
`
`

`

`www.ietdl.org
`
`Fig. 9 Performance measurement of byte count
`
`average time of the modified Net-DPIS is 42.9 – 44.0 ms. The
`modified Net-DPIS reduces 45 – 49% cost time in look-up
`table. The time cost is related to the rule sequence when
`packets can be identified. The higher priority of the rule,
`the shorter the lookup time; otherwise, the rule has a lower
`priority, and the lookup time is longer.
`
`4.5 Packet processing
`
`This section explains the performance of Net-DPIS and its
`modified version. The Net-DPIS runs the netperf
`[37]
`service and sets the inspection length at 1500 bytes; the
`packet generator generates UDP packets to the user client.
`Fig. 9 shows the throughput of Net-DPIS and modified Net-
`DPIS; the throughput of the modified Net-DPIS is better
`than the original Net-DPIS.
`In Fig. 10, Net-DPIS processes 57 000 packets per second
`at most and 26 000 packets per second at least. The modified
`Net-DPIS processes 84 000 packets per second at most and
`
`Fig. 10 Performance measurement of packet count
`
`Fig. 12 Performance comparison of L7-filter, Net-DPIS, SSW and
`IPP2P
`
`Fig. 11 Performance of pattern matching
`
`6
`& The Institution of Engineering and Technology 2012
`
`IET Networks, pp. 1 –8
`doi: 10.1049/iet-net.2011.0048
`
`EX 1008 Page 6
`
`

`

`www.ietdl.org
`
`Table 5 Measurement accuracy
`
`Bittorrent
`
`Edonkey
`
`Gnutella
`
`Directconnect
`
`KaZaA
`
`Net-DPIS
`
`IPP2P
`
`L7-filter
`
`SSW
`
`Connection number
`
`matched
`false positive
`false negative
`matched
`false positive
`false negative
`matched
`false positive
`false negative
`matched
`false positive
`false negative
`
`33 285
`
`30 386
`0
`2899
`30 031
`0
`3254
`29 275
`32
`3978
`29 136
`0
`4149
`
`10 346
`
`10 063
`0
`283
`10 026
`0
`320
`10 038
`0
`308
`10 063
`0
`283
`
`25 781
`
`16 093
`0
`9688
`13 699
`0
`12 082
`13 848
`15
`11918
`4125
`0
`21656
`
`2907
`
`2705
`0
`202
`2705
`0
`202
`2705
`0
`202
`2705
`0
`202
`
`1618
`
`1281
`0
`337
`1277
`0
`341
`1100
`96
`422
`905
`0
`713
`
`the
`In particular,
`least.
`30 000 packets per second at
`improvement
`rate of modified Net-DPIS for processing
`small packets exceeds 40%.
`
`experiments, we showed that Net-DPIS has better average
`accuracy than L7-filter, IPP2P and SSW.
`
`5
`
`Performance evaluation
`
`This section shows the evaluation WMT algorithm, FNP, Set-
`wise Boyer-Moore-Horspool (SBMH) [29], WM, IPP2P, L7-
`filter, SSW and Net-DPIS.
`
`5.1 Performance of WMT algorithm
`
`The experiment is conducted to evaluate the performance of
`FNP, SBMH, WM and WMT algorithm; 3000 patterns
`(m ¼ 5) are used and 100 000 packets are processed; the
`platform is Intel IXP-2400. The results in Fig. 11 show that
`the time cost of WMT algorithm is the lowest.
`
`5.2 Accuracy evaluation
`
`The performance of Net-DPIS and L7-filter is evaluated. The
`Net-DPIS and L7-filter enable their P2P rules only. The traffic
`of residence hall at National Sun Yat-sen University in
`Taiwan is used to be compared with Net-DPIS, IPP2P,
`SSW and L7-filter. The network traffic is captured with
`tcpdump [7]
`and lasts
`three hours; which contains
`80 000 000 TCP packets. Authors found that the speed of
`Net-DPIS is faster 13 times than L7-filter (Fig. 12). Table 5
`is the results of measurement accuracy of Net-DPIS, IPP2P,
`L7-filter and SSW. In the illustration of Bittorrent,
`the
`connection number of Bittorrent in the network traffic is
`33 285; Net-DPIS identifies 30 386 connections which is
`better than other classifications. The results show that the
`Net-DPIS
`has
`higher
`accuracy
`than
`other
`traffic
`classifications.
`
`6
`
`Conclusions
`
`This paper proposes Net-DPIS which is used to identify
`the network traffic. Net-DPIS supports to identify the P2P
`network
`service; Net-DPIS
`is
`useful
`for
`network
`management system to manage network traffic. Net-DPIS
`matches variable patterns with proposed WMT algorithm
`which is useful to increase the speed of pattern matching.
`We
`also showed that how the policies
`affect
`the
`performance of a DPI
`system. From the results of
`
`7 Acknowledgments
`
`This research was supported by a grant from the National
`Science Council, Taiwan, Republic of China, under grants
`No. 100-2218-E-006-031-MY3 and 99RA21, for which we
`are grateful. The authors also gratefully acknowledge the
`helpful comments and suggestions of the reviewers, which
`have improved the presentation. The Net-DPIS is running
`and identifying the traffic of
`the edge router
`for
`the
`department of Electrical Engineering at National Cheng
`Kung University in Taiwan.
`
`8
`
`References
`
`1 Moore, A.W., Papagiannaki, K.: ‘Toward the accurate identification of
`network
`applications’.
`Proc.
`Passive
`and Active Network
`Measurement, 2005, pp. 41 –543
`‘Using string
`2 Lin, P.C., Lin, Y.D., Lai, Y.C., Lee, T.H.:
`matching for deep packet inspection’, IEEE Comput., 2008, 41, (4),
`pp. 23 –28
`3 Netfilter: http://www.netfilter.org/, accessed December 2011
`4 Wu, S., Manber, U.: ‘A fast algorithm for multi-pattern searching’,
`Technical No. TR-94-17, Department
`of Computer Science,
`University of Arizona, 1994
`5 Rajkumar, K.V., Vaidehi, V., Pradeep, S., Srinivasan, N., Vanishree, M.:
`‘Application level
`IDS using protocol analysis’.
`Int. Conf. on
`Signal
`Processing, Communications
`and Networking,
`2007,
`pp. 355–359
`6 Application Layer Packet Classifier for Linux: http://l7-filter.source
`forge.net/, accessed December 2011
`7 Tcpdump/Libpcap: http://www.tcpdump.org/, accessed December 2011
`8 Sen, S., Spatscheck, O., Wang, D.M.: ‘Accurate, scalable in-network
`identification of P2P traffic using application signatures’. Proc. 13th
`Int. Conf. on World Wide Web, 2004, pp. 512– 521
`9 Snort: http://www.Snort.org/, accessed December 2011
`10 Bro: http://bro-ids.org/, accessed December 2011
`11 Cisco Systems: ‘Cisco ASA 5505 adaptive security appliance’, 2007.
`http://www.cisco.com, last accessed December 2011
`12 Wagner, A., Dubendorfer, T., Hammerle, L., Plattner, B.: ‘Flow-based
`identification of P2P Heavy-Hitters’,
`Internet Surveillance and
`Protection, 2006, pp. 15 –21
`13 Zheng, J., Xu, Y.: ‘Identification of network traffic based on support
`vector machine’.
`Int. Conf. on Advanced Computer Theory and
`Engineering (ICACTE), 2010, V3-286–V3-290
`14 Ding, A.L., Zhao, X.M., Jiao, L.C.: ‘Traffic flow time series prediction
`based on statistics learning theory’. IEEE Fifth Int. Conf. on Intelligent
`Transportation Systems, 2002, pp. 727– 730
`15 Knuth, D.:
`‘The art of computer programming: semi-numerical
`algorithms’ (Addison-Wesley, 1997, vol. 2, 3rd edn.)
`16 Aho, A.V., Corasick, M.J.:
`‘Efficient string matching: an aid to
`bibliographic search’, Commun. ACM, 1975, 18, (6), pp. 333–340
`
`IET Networks, pp. 1 – 8
`doi: 10.1049/iet-net.2011.0048
`
`7
`& The Institution of Engineering and Technology 2012
`
`EX 1008 Page 7
`
`

`

`www.ietdl.org
`
`17 Boyer, R.S., Moore, J.S.: ‘A fast string searching algorithm’, Commun.
`ACM, 1977, 20, (10), pp. 761– 772
`18 Commentz-Walter, B.:
`‘A string matching algorithm fast on the
`average’. Proc. Sixth Colloquium, on Automata, Languages and
`Programming, 1979, pp. 118 –132
`19 Madhukar, A., Williamson, C.: ‘A longitudinal study of P2P traffic
`classification’. Proc. of the 14th IEEE Int. Symp. on Modeling,
`Analysis, and Simulation, 2006, pp. 179–188
`20 Spognardi, A., Lucarelli, A., Pietro, R.D.: ‘A methodology for P2P file-
`sharing traffic detection’. Proc. Second Int. Workshop on Hot Topics in
`Peer-to-Peer Systems, 2005, pp. 52 –61
`21 Sen, S., Wang, J.: ‘Analyzing peer-to-peer traffic across large networks’,
`IEEE/ACM Trans. Netw., 2004, 12, (2), pp. 219– 232
`22 Brodie, B.C., Cytron, R.K., Taylor, D.E.: ‘A scalable architecture for
`high-throughput regular-expression pattern matching’ (ISCA, Boston,
`MA, June 2006)
`23 Kumar, S., Dharmapurikar, S., Crowley, P., Turner, J., Yu, F.:
`‘Algorithms to accelerate multiple regular expression matching for
`deep packet inspection’. SIGCOMM, Pisa, Italy, September 2006
`24 Tan, L., Sherwood, T.: ‘Architectures for bit-split string scanning in
`intrusion detection’. IEEE Micro Micro’s Top Picks from Computer
`Architecture Conf., January–February 2006
`25 Dharmapurikar, S., Lockwood, J.: ‘Fast and scalable pattern matching
`for network intrusion detection systems’,
`IEEE J. Sel. Areas
`Commun., 2006, 24, (10), pp. 1781– 1792
`26 Piyachon, P., Luo, Y.:
`‘Efficient memory utilization on network
`processors for deep packet inspection’. ACM Symp. on Architecture
`for Network and Communication Systems, San Jose, CA, December 2006
`
`27 Li, Z., Yu, N., Li, Y.: ‘Asynchronous parallel finite automaton: a new
`mechanism for deep packet
`inspection in cloud computing’,
`J. Internet Technol., 2010, 11, (2), pp. 269–277
`28 Yang, C.S., Liao, M.Y., Luo, M.Y., Wang, S.M., Yeh, C.E.: ‘A network
`management system based on DPI’. Int. Conf. on 13th Network-Based
`Information Systems (NBiS), 2010, pp. 385–388
`29 Fisk, M., Varghese, G.:
`‘Fast content-based packet handling for
`intrusion detection’, Technology Report CS2001-0670, University of
`California at San Diego, La Jolla, CA, USA, 2001
`30 Net-SNMP, available on http://www.net-snmp.org/, accessed December
`2011
`31 Wehrle, K., Pahlke, F., Ritter, H., Muller, D., Bechler, M.: ‘Linux
`networking architecture’ (Prentice Hall, 2004)
`32 Herbert, T.: ‘The Linux TCP/IP stack: networking for embedded
`systems’ (Charles River Media, 2006, 3rd edn.)
`33 Shishlov, A.E.: Promiscuous patch for Linux Kernel 2.4
`34 Linux kernel: http://www.kernel.org/, accessed December 2011
`35 Kulbak, Y., Bickson, D.: ‘The eMule protocol specification’, http://www.
`cs.huji.ac.il/labs/danss/p2p/resources/emule.pdf, accessed December 2011
`36 Liu, R.T., Huang, N.F., Chen, C.H., Kao, C.N.:
`‘A fast string
`matching
`algorithm for
`network
`processor-based
`intrusion
`detection system’, ACM Trans. Embedded Comput. Syst., 2004, 3, (3),
`pp. 614–633
`37 Netperf: http://www.netperf.org/netperf/, accessed December 2011
`38 Hsu, Y.S.: ‘Analysis and impact evaluation of random change of
`network flow of communication port’. Master thesis, National Sun
`Yat-sen University, Taiwan, 2008
`39 IPP2P: http://www.ipp2p.org/, accessed December 2011
`
`8
`& The Institution of Engineering and Technology 2012
`
`IET Networks, pp. 1 –8
`doi: 10.1049/iet-net.2011.0048
`
`EX 1008 Page 8
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket