P ERFORMANCE C HARACTERISTICS BDD-BASED PACKET F ILTERS

OF

A DI ATTAR N OVEMBER 2001

P ERFORMANCE C HARACTERISTICS BDD-BASED PACKET F ILTERS

OF

A U NIVERSITY
OF THE

RESEARCH REPORT

SUBMITTED TO THE

FACULTY

OF

S CIENCE ,

W ITWATERSRAND , J OHANNESBURG ,

IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF

M ASTER

OF

S CIENCE

A DI ATTAR N OVEMBER 2001

Declaration
I declare that this research report is my own, unaided work. It is being submitted for the degree of Master of Science in the University of the Witwatersrand, Johannesburg. It has not been submitted for any degree or examination in any other University.

Adi Attar

day of

, 20

ii

Abstract
Packet lters are security devices that connect multiple packet-based networks and provide access control between them. The security policy enforced by a packet lter is specied as a set of rules, called an access list, that describes what types of network packets should be allowed to pass from one network to another, and what types should be discarded. These rules are expressed in terms of the values of the elds of the packet headers. The semantics of an access list dictate that the rst rule that matches a packet determines the action taken by the packet lter. Traditional packet lters evaluate the rules in an access list sequentially until a matching rule is found and this process is repeated for every packet passing through the lter. The latency incurred by this sequential lookup is proportional to the number of rules in the list. While this is not a problem for short access lists, long access lists can cause signicant system degradation. Also long access lists typically occur at high-bandwidth network interfaces such as on border routers, where fast packet processing is essential. This research is based on the observation that an alternative internal representation of an access list can eliminate the need for sequential lookup and hence provide better ltering performance. The representation proposed in this research follows from the fact that the policy of an access list can be expressed as a single Boolean expression relating the values of bits in the packet headers. Thus binary decision diagrams (BDDs), capable of providing compact representations for many Boolean expressions, are used as a basis for the representation of access lists in this study. The contribution of this research is an evaluation of the effectiveness of representing access lists using BDDs for the purposes of packet ltering performance. Both time and memory issues are considered. This evaluation contains both analytical and empirical aspects and shows that the proposed approach provides good time and space performance for packet ltering on medium to long access lists. Furthermore, using BDDs for the representation of access lists provides packet lters with other useful characteristics that makes this a benecial approach to ltering in many real and important situations.

iii

Acknowledgements
First and foremost, my gratitude goes out to my supervisor Scott Hazelhurst, whose insight and intellect inspired this project. The time, dedication and encouragement he provided went far beyond the call of duty. Thanks to my other panel members, Andr s Salamon and Vashti Galpin, for their valuable advice, a and to Andr s for his exceptional insight and willingness to help. a A hearty thanks goes out to Internet Solutions in particular to Richard van Katwijk for his time and effort for providing invaluable data for this project. Thanks to the NRF for providing nancial support, as well as to David Clark for his graphical expertise and ne tooth comb proofreading. I want to thank the School of Computer Science for providing a great working environment during my lengthy stay, as well as the technical support staff for all their help. The four years over which I completed my masters have been some of my most challenging, and the fact that I am writing my acknowledgements shows that I have accomplished what I set out to do. I thank my family for their support and in particular, my mother, whose strength and determination has always been my driving force. Special thanks go out to the Masters fellows of 1999-2002 Brynn Andrew, Nir Oren, Pekka Pihlajasaari, Raymond Sinnappan, Phillip Schmitz, Keith Mitchell and Tina G tschi o whose support, empathy and dedication inspired the completion of this document.

iv

Contents
Declaration Abstract Acknowledgements Contents List of Figures List of Tables 1 Introduction 1.1 Firewalling Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 1.1.2 1.1.3 1.2 1.3 1.4 Application-level Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . Circuit-level Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packet-ltering Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii iii iv v ix xi 1 2 3 3 4 4 6 8 9 9 10 12 13 14 15

Packet Filters and Access Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Research Aims and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outline of the Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Packet Filtering: Background and Related Work 2.1 Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 2.1.4 2.2 Access Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packet Filtering Pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packet Filtering with Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performance of Current Packet Filtering Implementations . . . . . . . . . . . .

Related Work on Packet Filtering and Classication . . . . . . . . . . . . . . . . . . . .

2.2.1 2.2.2 2.2.3 2.2.4

Theoretical Bounds on Packet Classication . . . . . . . . . . . . . . . . . . . . Table-driven Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specialised Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary of Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16 16 19 21 24 24 25 27 28 28 29 33 33 36 39 39 41 41 42 42 43 44 46 47 50 51 52 52 54

3 The BDD Approach to Packet Filtering 3.1 Binary Decision Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.1.3 3.2 Ordering and Reducing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Effect of Variable Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . Representing Integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The BDD Packet Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 3.2.3 Converting Access Lists into BDDs . . . . . . . . . . . . . . . . . . . . . . . . Performing Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . An Example of Access List Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3

Comparison to Other Approaches

4 Analytical Discussion of the BDD Packet Filter 4.1 BDD Representations of Access Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 4.1.2 4.2 The Effect of Rule Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Effect of Variable Ordering . . . . . . . . . . . . . . . . . . . . . . . . . .

Performing Lookup on a BDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 4.2.3 Worst Case Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Best Case Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Average Case Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3 4.4

Memory Usage of BDD Representations of Access Lists . . . . . . . . . . . . . . . . . Summary of Theoretical Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Experimental Methodology 5.1 5.2 Simulation Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Experimental Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 5.3 Control and Experimental Systems . . . . . . . . . . . . . . . . . . . . . . . . .

System Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3.1 5.3.2 5.3.3 5.3.4 5.4 5.5

Packet Filter Specications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Factors Affecting Implementation . . . . . . . . . . . . . . . . . . . . . . . . . Experimental System Implementation . . . . . . . . . . . . . . . . . . . . . . . Control System Implementation . . . . . . . . . . . . . . . . . . . . . . . . . .

54 55 55 59 60 62 63 66 66 68 71 72 76 79 81 89 92 92 92 94 94 96 97 97 98 99 101

Experimental Data and Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Experimental Results 6.1 Evaluation of Memory Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 6.1.2 6.2 Experiment A: Memory Usage with Random Data . . . . . . . . . . . . . . . . Experiment B: Memory Usage with Real Data . . . . . . . . . . . . . . . . . .

Evaluation of Lookup Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 6.2.2 6.2.3 6.2.4 Experiment C: Best Case Lookup . . . . . . . . . . . . . . . . . . . . . . . . . Experiment D: Worst Case Lookup . . . . . . . . . . . . . . . . . . . . . . . . Experiment E: Average Case Lookup with Synthetic Data . . . . . . . . . . . . Experiment F: Average Case Lookup with Real Data . . . . . . . . . . . . . . .

6.3

Summary of Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 Discussion 7.1 Discussion of Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.1 7.1.2 7.1.3 7.1.4 7.2 On External Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lookup Time Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . Space, Time and Variable Ordering . . . . . . . . . . . . . . . . . . . . . . . . Comparison to Other Approaches . . . . . . . . . . . . . . . . . . . . . . . . .

Practical Aspects of the BDD Packet Filter . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 7.2.2 On the Characteristics of the BDD Packet Filter . . . . . . . . . . . . . . . . . . On User Expertise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.3

Summary of Discussion and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 Conclusions and Future Work 8.1

Research Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 8.1.1 On the Memory Requirements of the BDD Approach . . . . . . . . . . . . . . . 102

8.1.2 8.1.3 8.1.4 8.2 8.3

On the Lookup Performance of the BDD Approach . . . . . . . . . . . . . . . . 102 On the Value of Exploring Variable Ordering Further . . . . . . . . . . . . . . . 103 On the Effectiveness of the BDD Approach . . . . . . . . . . . . . . . . . . . . 103

Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 108 117

A Converting Access Lists into BDDs: An Example B Complete Results for Experiment F

List of Figures
1.1 2.1 2.2 A typical rewall setup protecting an internal network. . . . . . . . . . . . . . . . . . . A typical packet lter setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . An access list implementing the security policy for the network 146.141.27.0/24 at its external interface. 2.3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4.1 4.2 4.3 5.1 5.2 5.3 5.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 13 2 10

The modied access list allowing web access from anywhere on the Internet. . . . . . . A decision tree for the Boolean expression A ROBDD for the Boolean expression Two BDDs for the function

. . . . . . . . . . . . . 25

. . . . . . . . . . . . . . . 26
.

for

. . . . . . . . . . . . .

27 29 30 33 34 34 38 40 48 49 51 53 56

Conceptual diagram of the BDD packet lter. . . . . . . . . . . . . . . . . . . . . . . . The IP Datagram Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Algorithm for converting an access list into its BDD representation. . . . . . . . . . . . Algorithm for performing lookup using a BDD representation of the access list. . . . . . An example access list to illustrate conversion into a Boolean expression. . . . . . . . . BDD representation of the access list in Figure 3.8. . . . . . . . . . . . . . . . . . . . . A simple access list with ltering elds protocol type and source address. . . . . . . . . A BDD for the access list in Figure 4.1 with the protocol variables at the root. . . . . . . A BDD for the access list in Figure 4.1 with the source address variables at the root. . . . The simulation environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The netlter/iptables framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Representation of a BDD as a two-dimensional lookup table. . . . . . . . . . . . . . . . The BDD lookup algorithm using the standard BDD representation of the access list compressed into a two-dimensional lookup table. . . . . . . . . . . . . . . . . . . . . . ix

58

5.5

The BDD lookup algorithm using an array of structures to store the BDD representation of the access list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 67

6.1 6.2

Node counts of BDD representations of random access lists of increasing lengths. . . . . Node counts of BDD representations of a single real access list, truncated at various lengths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69 73 73 77 77 80 80 83 83 84 84 85 85

6.3 6.4 6.5 6.6 6.7 6.8 6.9

Best case lookup times for access list A truncated at various lengths. . . . . . . . . . . . Best case lookup times for access list B truncated at various lengths. . . . . . . . . . . . Worst case lookup times for access list A truncated at various lengths. . . . . . . . . . . Worst case lookup times for access list B truncated at various lengths. . . . . . . . . . . Theoretical average case lookup times for access list A truncated at various lengths. . . . Theoretical average case lookup times for access list B truncated at various lengths. . . . Average lookup times for access list A truncated at various lengths. . . . . . . . . . . . .

6.10 Average lookup times for access list B truncated at various lengths. . . . . . . . . . . . . 6.11 Frequency distribution of lookup times for access list A. . . . . . . . . . . . . . . . . . 6.12 Frequency distribution of lookup times for access list B. . . . . . . . . . . . . . . . . . . 6.13 Cumulative frequency distribution of lookup times for access list A. . . . . . . . . . . . 6.14 Cumulative frequency distribution of lookup times for access list B. . . . . . . . . . . . 8.1

Example of a multi-node BDD-based structure. . . . . . . . . . . . . . . . . . . . . . . 106

A.1 An example access list to illustrate conversion into a Boolean expression. . . . . . . . . 108 A.2 BDD representation of the access list once the rst rule has been encoded. . . . . . . . . 113 A.3 BDD representation of the access list once the rst two rules have been encoded. . . . . 114 A.4 BDD representation of the access list once the rst three rules have been encoded. . . . 115

A.5 BDD representation of the access list once all four rules have been encoded. . . . . . . . 116 B.1 Complete frequency distribution of lookup times for access list A. . . . . . . . . . . . . 117 B.2 Complete frequency distribution of lookup times for access list B. . . . . . . . . . . . . 118 B.3 Complete cumulative frequency distribution of lookup times for access list A. . . . . . . 118 B.4 Complete cumulative frequency distribution of lookup times for access list B. . . . . . . 119

List of Tables
2.1 3.1 4.1 Summary of related work on packet ltering and classication. . . . . . . . . . . . . . . The Boolean variables required for a BDD representation of an access list. . . . . . . . . A comparison of the lengths of paths taken to accept various packets using BDDs with different variable orderings for the access list in Figure 4.1. 6.1 6.2 6.3 . . . . . . . . . . . . . . . 45 63 64 23 30

Experimental system specication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BDD variable orderings used in the experiments. . . . . . . . . . . . . . . . . . . . . . Overview of experiments to evaluate the memory requirements and lookup performance of the BDD packet lter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65 69

6.4 6.5

Number of BDD nodes required by real access lists of various lengths. . . . . . . . . . . Average number of nodes required by a real access list compared to random access lists at various list lengths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

6.6

Shortest traversable paths lengths for the BDDs representing access list A, truncated at various lengths, for the given variable orderings. . . . . . . . . . . . . . . . . . . . . . 74

6.7

Shortest traversable paths lengths for the BDDs representing access list B, truncated at various lengths, for the given variable orderings. . . . . . . . . . . . . . . . . . . . . . 74

6.8

Longest paths lengths for the BDDs representing access list B, truncated at various lengths, for the given variable orderings. . . . . . . . . . . . . . . . . . . . . . . . . . 78 86 86

6.9

Some experimental results for the experiment using access list A and real packet traces. .

6.10 Some experimental results for the experiment using access list B and real packet traces. .

xi

Chapter 1

Introduction
The Internet has been a phenomenal accomplishment in terms of data access and availability, growing exponentially over the past decade [9]. Many companies and institutions have connected their networks to the Internet to gain access to this large public network, as well as to advertise their own products and services to the rest of the world. The types of services and applications available on the Internet have become more powerful the static web pages of the World Wide Web in the early 1990s have given way to online banking, shopping and reservation systems. This, and the fact that the increasing number of people connected to the Internet implies an increasing number of potential sources of attack, means that systems and their networks require protection from unintentional incidents as well as malicious acts [18]. Although there are many benets to connecting ones local network to the Internet, there are security issues to consider. Hosts on the newly-connected network are automatically exposed to attacks from other hosts on the Internet. The security of individual machines on a network is weakened by poor congurations, defective software and problems inherent in the TCP/IP protocols and services [36]. And since machines within a local network typically trust one another in some way (and this is generally necessary for their usability), one penetrated machine can compromise the entire network [9]. There are numerous aspects to computer and network security. Perhaps the most well-known involves access control to machines and resources within the protected network. Other less-considered aspects involve data security controlling eavesdropping on data originating in, or destined for the protected network and data integrity ensuring the legitimacy of data sent and received [3]. To this end, many techniques for improving security exist, such as authentication, cryptography and rewalling. Firewalling provides a method for controlling access between networks and is usually the rst, and often only, mechanism employed by network administrators for improving security [3]. The principle behind rewalls is that controlling access to the network and its resources by protecting each host is difcult

and does not scale well: as the number of hosts in a local network increases, overall security often decreases [36]. Firewalls address this problem by acting as the connection point between multiple networks and providing a single security checkpoint through which all trafc moving between the networks must pass [18]. A security policy is imposed at this checkpoint, controlling the communication between the different networks, ensuring that only trafc authorised by the security policy is allowed to pass. It is implicitly assumed that the rewall itself is immune to penetration. One of the main criticisms of rewalls is that they often create bottlenecks [3]. To enforce a security policy, rewalls must in some way process all network packets passing through them, and this results in a loss of network performance. This motivates the need for faster rewalling technologies, keeping in mind that there is a tradeoff between performance and security high security requirements must warrant any loss in performance. The contribution of this research towards improving rewalling techniques is addressed later in this chapter, which is structured as follows. Section 1.1 introduces different rewalling technologies that are currently used, after which the specic rewalling technique of packet ltering is discussed further in Section 1.2. Section 1.3 motivates and describes the research contribution of this document. Finally, Section 1.4 outlines the remainder of the document.

1.1 Firewalling Technologies

The most common rewall setups protect a single internal network (such as a corporate network) from the Internet, as shown in Figure 1.1, although rewalls may also be placed between departmental networks within a company.
Firewall

Internet

11 00 1 0 1 0 1 0 11 00 1 0 1 0 1 0 1 0 11 00 1 0 1 0 1 0 11 00Internal 1 0 1 0 1 0 Network 1 0 11 00 1 0 1 0 1 0 11 00 1 0 1 0 1 0 1 0

Figure 1.1: A typical rewall setup protecting an internal network.

The level of security and behaviour exhibited by the rewall depends on the type of rewall used application-level gateway, circuit-level gateway, or packet-ltering gateway each operates at a different layer of the network model and thus offers different tradeoffs between security, exibility, simplicity and performance [28, 36].

1.1.1 Application-level Gateways

Application-level gateways operate at the application layer and offer the richest mechanism for security. An application-level gateway runs a proxy server for each application that it supports (for example, Telnet, HTTP, FTP). The proxy intercepts TCP connection requests (corresponding to its application) passing through it and, acting as a proxy on the users behalf, sets up a secondary TCP connection to the destination host. The proxy then relays application data between the two TCP connections. Users are often required to authenticate themselves to the application gateway before the second connection is established. Besides the requirement for user authentication, application gateways enhance network security in two ways. Firstly, the TCP connection between the gateway and the remote host has the IP address of the external interface of the gateway as the source IP address, so internal network addresses are never exposed to the Internet. Secondly, each proxy server has some understanding of the application it is supporting and can be congured to disallow certain commands or content considered dangerous (such as Java applets and ActiveX controls from HTTP trafc). One of the major drawbacks of application gateways is that each application requires a unique proxy server and so this rewalling technique is not easily extensible. Proprietary protocols (such as SAP) make this task even more difcult. Another problem involves connectionless applications, such as those based on UDP. These applications do not wait for a connection to be established before transmitting application data and, consequently, the application gateway cannot authenticate and authorise the request.

1.1.2 Circuit-level Gateways

A circuit-level gateway operates at the transport layer and consists of a single proxy server. This proxy server is similar to the servers used in application-level gateways, except that it relays connections without looking at the corresponding application data. This more general approach means that although they incur the overheads associated with application-level gateways, circuit-level gateways can act as a proxy for any TCP/IP application, the management of which is usually based on allowable port numbers. The major problem with this is that circuit-level gateways have no understanding of the application protocols they support. They cannot scan application data for dangerous commands or executable content. Also, if two cooperating users use an approved port number to run an unapproved application, this would go by undetected.

1.1.3 Packet-ltering Gateways

Packet-ltering gateways, or packet lters, are the simplest type of rewalling technology, operating at the network layer. Because of this, they naturally have no concept of applications or connections and thus security policies for packet lters are expressed in terms of individual IP packets. Strictly speaking, at the network layer, only the IP header is available to the rewall for inspection, which includes information such as the source and destination IP addresses of the packet as well as the transport protocol type. However, security policies for packet lters often refer to information available in the transport layer packet headers (such as source and destination ports for TCP and UDP). The key difference between packet lters and proxy servers is that proxy servers make secondary connections to the destination host on the users behalf, while packet lters do not. Packet ltering can be combined with network address translation (NAT) to provide one of the benets of proxies. NAT allows the mapping of a set of internal IP addresses onto a (usually) smaller set of external IP addresses, thereby allowing internal IP addresses to be hidden from external networks. In general however, packet lters themselves are not connection-oriented. Packet lters provide network security by inspecting IP packets passing through them and, according to their security policy, deciding whether these packets should be dropped or allowed to continue to their destination. Because they are such low-level devices, packet lters offer less expressive security policies and are often regarded as less secure than the proxy-based rewalls. However, packet lters are extremely efcient. Conversely, because the proxies operate at a higher level of the network model, they typically have access to more information than packet lters and are considered to behave more intelligently and thus more securely. This however comes at the price of complexity and performance. Packet lters remain widely used (either on their own on routers or as the rst line of defence before a higher-level rewall). There are numerous reasons for this [18, 28, 36]:

Packet lters are fast compared to other rewalling technologies (as mentioned previously). Packet ltering is normally transparent to applications and users. Packet ltering is a low-cost technology. Many commercial routers already have packet ltering capabilities, and free packet ltering software is available for some operating systems.

1.2 Packet Filters and Access Lists

The security policy for a packet lter is specied by a set of rules. Each rule has the structure: if condition then action, where the condition denes a logical statement based on elds within the packet header, and

the action species whether a packet matching that rule should be accepted or rejected. A set of rules is known as an access control list, or simply, access list [3]. Semantically, the rules of an access list are considered sequentially, so the condition of the rst rule that matches a packet will determine the action to be taken. This format for representing security policies has both advantages and disadvantages. The simplicity of its structure makes individual rules easy to specify. By specifying source or destination addresses as well as ports in the condition of a rule, it is fairly easy to dene security policies that allow access for specic services on specic hosts [9]. However, the semantics of access lists results in the order in which rules appear in the list being extremely signicant the interaction between the rules in an access list can make the interpretation of what types of packets it accepts difcult [36]. For this reason, packet ltering implementations traditionally represent access lists internally as a linear list of rules that is a direct translation of the original access list. The decision-making process that determines whether a particular packet passing through the packet lter should be accepted or rejected is called lookup and is closely tied to the semantics of access lists. During lookup, the rules of the access list are applied sequentially to the packet until a matching rule is found, at which point the corresponding action is taken. If no rule matches, the default rule is applied, which is usually to reject all packets. In general, no context is kept, so this lookup process must be repeated for every packet [9]. The latency incurred by this sequential lookup process is clearly proportional to the number of rules in the access list. While this is not a problem for very short lists, in cases where access lists are long lists with several hundred rules are common in border routers the performance of the system can be signicantly affected. The total degradation may be improved by reordering the rules in the access list so that the most common types of trafc are processed quickly, but since the order of the rules in the list is signicant, this can be a difcult and error-prone process [9, 36]. Routers are particularly sensitive to packet ltering for yet another reason. Routers are optimised for routing through special-purpose hardware accelerators, but packet ltering is implemented in software [3, 9]. This means that when packet ltering is enabled on a router, a disproportionate amount of the total packet switching time is spent in the ltering code. To illustrate, it has been noted that routers with packet ltering enabled can suffer up to a 90% performance loss in terms of packets processed per second [3]. Although access lists may not be an ideal representation for security policies a number of problems have been outlined in this section this issue falls beyond the scope of this research, which focuses on how different internal representations of access lists affect packet ltering performance. Two directions for improving on traditional packet ltering techniques are suggested:

Hardware-based approaches: Improvements to packet ltering performance using special-purpose

hardware include the implementation of the lookup algorithm on application specic integrated circuits (ASICs) and eld programmable gate arrays (FPGAs) [25, 35]. Since FPGAs are reprogrammable, they have also been used to store the representation of the rules to improve performance [40]. Other efforts include improving the memory that the rules (or representation of the rules) reside in, by improving access speeds and memory utilisation (using SRAM or CAMs) [33, 39]. Hardware-based approaches allow for packet processing speeds orders of magnitudes higher than software-based approaches. However, the fact that they are expensive, difcult to modify and highly specialised restricts their viability to high-end products.

Software-based approaches: Although software implementations are unlikely to ever match the speed of hardware implementations, many packet lters in use are software-based, and this justies the efforts made in software-based improvements. Software-based efforts at improving packet ltering include designing various alternative internal representations of access lists that facilitate faster lookup. This more general approach means that improvements have a far larger scope of applicability from high-end systems to general-purpose computers.

This research adopts a software-based approach. While the focus of the research is security-oriented, access lists are not used solely for access control through packet ltering. Access lists can be used as a general format for specifying any selection criteria based on packet headers. Examples of their use are in router congurations for controlling routing updates and specifying criteria for activation of dialup links [3]. While lookup on access lists for access control is likely to benet the most from improved lookup performance (since these access lists tend to be longer and applied more often), any improvements are directly applicable to access lists for other uses.

1.3 Research Aims and Objectives

The aim of the research is to nd an internal representation for access lists capable of providing fast lookup with reasonable memory requirements. Since access lists are consulted frequently (that is, for each arriving packet) and modied infrequently in comparison, the ability to perform fast lookups is the most important factor. This justies using a potentially large amount of effort initially to create an efcient internal representation. The reasoning behind why binary decision diagrams (BDDs) may be a good choice for the internal representation follows. Each rule of an access list describes the condition, based on the values of elds within the packet header, that a packet must meet in order to have the corresponding action effected. Thus the condition of a rule

is simply a logical, or Boolean, expression involving certain elds of the packet header to be accepted, a packet must satisfy this expression if the rules action is accept, and not satisfy the expression if the rules action is reject. Taking this idea a step further, the set of Boolean expressions dening the conditions for all the rules in an access list can be combined into a single, more complex expression describing what condition a packet must meet in order to be accepted by that access list. This forms the key insight of this research. Binary decision diagrams (BDDs) are a well-known data structure for storing and manipulating Boolean expressions compactly and efciently, are therefore a natural choice for representing the access lists of a packet lter. This research addresses the following question:

Can BDDs be used effectively in the representation of access lists for the purposes of lookup?

Research Objectives
Preliminary research in this area has contributed theoretical foundations for BDD representations of access lists, including a technique for converting access lists into their equivalent BDD representations [23]. Results of this preliminary study indicate that BDDs are indeed a promising representation for access lists. This research extends previous work by analysing BDD representations of access lists with particular focus on lookup and memory efciency. This investigation is predominantly empirical in nature but also includes some theoretical analysis of important characteristics of the proposed approach. The investigation into BDD representations of access lists includes an analysis of:

Lookup algorithm complexity: Associated with the BDD representation of access lists is the lookup algorithm which uses the BDD to make ltering decisions about incoming packets. Best, worst and average case performance is considered, as well as the relationships between them.

Memory usage: The memory requirements of BDD representations of access lists are analysed. BDDs cannot guarantee good space complexity for arbitrary Boolean expressions in the worst case BDD sizes can grow exponentially with the number of Boolean variables in the expression. The research attempts to discover how well-behaved Boolean expressions representing access lists are in this respect.

For the BDD approach to packet ltering to be viable, both lookup algorithm performance and memory

requirements must be reasonable. A common problem with many access list representations is that there is a tradeoff between time and space an approach that offers fast lookup often has poor memory requirements, and vice versa.

1.4 Outline of the Document

The remainder of the document proceeds as follows. Chapter 2 presents background information on packet ltering and access lists, particularly useful to readers unfamiliar with this area of network security. It also presents a survey of other research contributions towards improving packet ltering and classication. Chapter 3 presents the BDD background information necessary for understanding the details of this research. It then presents the existing theory on BDD representations of access lists, including an algorithm for converting an access list into its corresponding BDD representation and an algorithm for performing lookup using this representation. Some qualitative comparisons between the BDD approach and alternative approaches to packet ltering are made. Chapter 4 is where new contributions to this area of research begin. The chapter makes an informal qualitative assessment of BDD representations of access lists. Its major contribution is insight into factors affecting the lookup performance and memory requirements of BDD representations of access lists. Chapters 5 and 6 deal with the empirical aspects of the research. Chapter 5 discusses the experimental methodology, including the choice of control system used for comparison. Chapter 6 covers the details of the experiments and their results. Experiments include comparing the control and experimental systems in terms of memory usage, as well as their best, worst and average case lookup performance. Chapter 7 presents a discussion of the research results in terms of the expected use and performance of the BDD approach beyond the research environment. Also, the comparison between the BDD approach and alternative approaches is revisited in this chapter, in light of the experimental results. Finally, Chapter 8 summarises the most important results and key issues of the research, and identies potential areas for future work.

Chapter 2

Packet Filtering: Background and Related Work

In this chapter, the current state of packet ltering knowledge is presented. First, a description of packet ltering as a means of improving network security is described in Section 2.1, which includes an overview of current packet ltering implementations. A fair amount of research work has been devoted to designing techniques to improve packet ltering a review of this research area is the topic of Section 2.2. This chapter assumes a reasonable understanding of IP networking as well as a basic knowledge of the TCP/IP protocols. For a good coverage of these topics, the reader is referred to [43].

2.1 Packet Filtering

Packet ltering is a technique used to achieve access control in and out of computer networks. As mentioned previously, packet lters are widely deployed (particularly on networks connected to the Internet) because of their simplicity and low cost. Routers are obvious points at which to apply packet ltering because they occur naturally at network borders. Many commercial routers provide support for packet ltering and some free software implementations are available for PCs used for routing [36]. Packet ltering can also be applied on individual hosts to lter out packets destined for that machine, but this application of packet lters is less interesting since the access lists associated with individual machines tend to be quite short. In this document, the term packet lter is used to describe any device that provides packet ltering capabilities. In general terms, a packet lter is a multi-interfaced device that applies a set of rules to lter IP packets 9

passing through its interfaces. Each interface on the device represents a connection to a network. So, for example, a company protecting their internal LAN from the Internet would need a packet lter with two interfaces one to the local network and another to the external network to which the local network connects (such as the companys Internet service provider). This setup is depicted in Figure 2.1.
Packet Filter ISP Network External Interface (146.141.16.28)

Internal Interface (146.141.27.1)

11 00 1 0 1 0 1 0 11 00 1 0 1 0 1 0 1 0 11 00 1 0 Internal 1 0 1 0 11 00 1 0 1 0 1 0 Network 1 0 11 00 1 0 1 0 1 0 11 00 1 0 1 0 1 0 1 0

Figure 2.1: A typical packet lter setup.

Filtering on a packet lter may occur in several places. In theory, packets can be ltered in both inbound and outbound directions on all the interfaces of a packet lter, although this exibility may differ between various implementations of packet lters [9]. Thus the rules of a packet lter are organised into a set of access lists and each list is then applied to a particular interface, in a specied direction.

2.1.1 Access Lists

An access list describes the security policy of the packet lter at the point at which it is applied. Although the syntax of access lists may differ from one implementation of a packet lter to another, their exibility and semantics remain fairly constant. Each rule in an access list consists of a selection criterion and an action eld.

The action eld species what should happen if the packet meets the selection criterion. Packet lters usually offer the two actions P ERMIT (or ACCEPT) and D ENY (or D ROP)1 [3]. P ERMIT means the packet should be allowed to continue towards its destination IP address whereas D ENY means that the packet should be discarded. Some implementations allow a third action, R EJECT, which acts like D ENY with the exception that an ICMP port unreachable packet is sent back to the sender [38].

The selection criterion of a rule is a Boolean expression involving values of elds available in the packet headers. The number of elds that may be specied for ltering is known as the dimension of a lter. In theory, any information available in the packet headers can be used as ltering criteria. In practice, the common ltering elds include [45]:

Permit and Deny is used synonymously with Accept and Drop respectively throughout this document.

 Source and destination IP addresses. These addresses can be found in the IP header of every packet. Trafc restriction is facilitated by allowing the administrator to specify the set of well-known hosts or networks that may use the system. Transport protocol, like TCP, UDP, or ICMP, which is also found in the IP header. IP options, like the source route option, which is often considered dangerous for network security. Source and destination port numbers, associated with TCP and UDP. These can be found in the TCP and UDP headers respectively. Filters using port numbers can restrict the network trafc to a limited set of services that are associated with well-known ports. TCP ags, such as the ACK and SYN ags. These ags indicate whether a packet is initiating a new connection and can be used to restrict TCP connections from being initiated in certain directions. ICMP message types. These are found in the ICMP header. Filtering on ICMP types allows the administrator to restrict ICMP trafc to a limited set of message types.

The classication for each packet (i.e. whether it should be accepted or rejected) is given by the action eld of the rst rule whose selection criterion matches the packet. If no rules match, the default rule is applied. The default rule is determined by the security policy and is usually set to reject all packets, since this is the preferred security stance [47].

A Note on Notation

Since the syntax of access lists differs from system to system (and these technicalities do not affect this research), this document adopts a generic tabular representation for these lists that attempts to be intuitive. In terms of network addresses and masks, two conventions are used and are illustrated by example:

base address / bit count notation: The expression 146.141.27.0/24 represents the block of IP addresses in the range 146.141.27.0 to 146.141.27.255. In other words, the number after the slash indicates the number of bits in the address (starting at the most signicant) that are signicant for comparison.

address, mask tuple: The address block 146.141.27.0/24 can be alternatively expressed with a base address of 146.141.27.0 and a mask of 0.0.0.255. Both the address and the mask consist of 32 bits, with each bit in the mask specifying whether the corresponding bit in the address is signicant for comparison. In this document, reverse masking is used, which means that 0 species signicance.

A Packet Filtering Example

As an example, consider the following scenario. The network administrator of a department within a university wishes to disallow access to his2 network from the Internet. His department owns the network 146.141.27.0/24 within the university network 146.141.0.0/16. His department is involved in a collaborative project with various other departments within the university, so he would like to grant access to the network from the rest of the university with one exception. The department owning the network 146.141.16.0/24 is known to be insecure and a haven for crackers, so the administrator would like to disallow access from that network. As a nal security measure, the administrator decides to protect his network from spoong attacks packets arriving at the external interface claiming to have originated from his own network must be fake, and are most often the result of an intentional attack. For simplicity, consider only the access list applied to inbound trafc at the departments external interface. The access list dening the departments policy is shown in Figure 2.2.
Rule 1 2 3 Proto IP IP IP Src Addr 146.141.16.0 146.141.27.0 146.141.0.0 Src Mask 0.0.0.255 0.0.0.255 0.0.255.255 Src Port any any any Dest Addr 146.141.27.0 146.141.27.0 146.141.27.0 Dest Mask 0.0.0.255 0.0.0.255 0.0.0.255 Dest Port any any any Action Deny Deny Permit Deny

Default Policy:

Figure 2.2: An access list implementing the security policy for the network 146.141.27.0/24 at its external interface.

The rst rule denies access from the insecure department the protocol is specied as IP which matches all IP packets regardless of their transport protocol (TCP, UDP or ICMP). The second rule lters out any spoofed packets, and the third rule grants access to the rest of the university. The default deny all policy will ensure that no other trafc (Internet trafc) will be allowed through.

2.1.2 Packet Filtering Pitfalls

One of the biggest criticisms of packet ltering is that while a rule in an access list on its own is fairly simple to understand, the interaction between the rules due to their order in the list is often less obvious. Referring back to the example presented in Section 2.1.1, suppose that after several months, the department launches a website to attract more potential students to enrol for their courses. In order for people to be able to access the website from off-campus, the original restriction disallowing access from the Internet needs to be modied to allow web access. This can be achieved by adding a rule to the access
2

All pronouns should be interpreted as including both genders.

list that allows TCP trafc destined for the webserver (IP address 146.141.27.44) on the default HTTP port 80 (from anywhere). The modied access list is shown in Figure 2.3.
Rule 1 2 3 4 Proto TCP IP IP IP Src Addr 0.0.0.0 146.141.16.0 146.141.27.0 146.141.0.0 Src Mask 255.255.255.255 0.0.0.255 0.0.0.255 0.0.255.255 Src Port any any any any Dest Addr 146.141.27.44 146.141.27.0 146.141.27.0 146.141.27.0 Dest Mask 0.0.0.0 0.0.0.255 0.0.0.255 0.0.0.255 Dest Port 80 any any any Action Permit Deny Deny Permit Deny

Default Policy:

Figure 2.3: The modied access list allowing web access from anywhere on the Internet.

The problem with this new access list is that web connections from the untrusted network 146.141.16.0/24, as well as spoofed packets destined for the webserver, will be accepted by the rst rule and never blocked by subsequent deny rules, as intended by the security policy. This error could be easily solved in this instance by placing the new rule at the end of the access list, but serves to illustrate the signicance of the order of rules in an access list. In companies with many large access lists and several network administrators, the tasks of adding, deleting, modifying and reordering rules may be difcult to comprehend and manage.

2.1.3 Packet Filtering with Caches

So far, all the packet lters described have been stateless, meaning that the access list is consulted for each IP packet passing through the lter, independently of what occurred in the past. However, some packet ltering implementations may maintain state for two important reasons: handling packet fragmentation and stateful inspection.

Filtering Fragmented Packets

A packet travelling along an IP network may be fragmented into several smaller packets when part of the underlying media along its route does not support IP packets above a certain size. The fragments are then reassembled into the original packet at the destination machine. The problem that this poses for packet ltering is that only the rst fragment of a fragmented packet contains the transport protocol header, which often contains important ltering information such as source and destination ports [8]. There are various ways in which packet lters can deal with the subsequent fragments. One technique is to lter the fragments based on the information that they do contain this includes all the IP header information such as the source and destination addresses as well as the protocol type [15].

Another approach is to keep a cache of the recently received rst fragments together with the ltering decisions made for those fragments. Then, when a subsequent fragment arrives, the cached decision corresponding to its rst fragment is used [31]. The problem with the former approach is that it may open the network up to fragment ooding. However, with the latter approach, there is no guarantee that the rst fragment will appear before all the subsequent fragments, so the packet lter should ideally be capable of reconstructing the entire packet, or buffering subsequent fragments until the rst one arrives.

Stateful Inspection

Packet lters that support stateful inspection are capable of maintaining state relating to TCP as well as UDP sessions [36]. This is useful for controlling the direction in which sessions may be established (for example, only allowing sessions to be established from inside an internal network to the Internet). The state information for stateful inspection is cached in a similar way to the fragmented packet caches described previously. The effect of caching, if implemented efciently, is that it can reduce the overall lookup time taken by the packet lter, since some ltering decisions can be made by inspecting the cache and thus the access list does not need to be consulted for every packet. Nevertheless, since many sessions are short-lived and some protocols (such as ICMP) are stateless by nature, it is not sufcient to rely on caching for good performance an efcient lookup algorithm is essential [17].

2.1.4 Performance of Current Packet Filtering Implementations

It has already been mentioned that packet lters used in practice incur a lookup latency linear in the number of rules in the access list. This point is difcult to generalise to all current implementations of packet lters because neither the source code nor the implementation details are generally available. However, the state of research in this area suggests that it is unlikely that many implementations use a non-sequential lookup algorithm exceptions to this that are stated in the literature will be mentioned explicitly, and this is discussed in more detail in the next section. A large and popular family of packet lters open to discussion is the subset of the Unix packet lters written for the free versions of Unix. There have been two separate endeavours in this area one involving Linux and the other involving the BSD variants (FreeBSD, OpenBSD and NetBSD). The latter development has resulted in various versions of the ltering package IP Filter [14] that also runs on some versions of the Solaris, SunOS, Irix and Linux operating systems. The former pure Linux development has resulted in a family of packages starting with ipfw, followed by ipfwadm and ipchains, to the newest package iptables [38], where each new package claims to have more features and be easier to use than

its predecessors. All the abovementioned packages are almost identical in terms of how they deal with access lists and lookup. Access lists are stored as linked lists of structures that represent the rules and so the lookup algorithm performs a sequential search through the list. While this technique stores the rules fairly compactly, the lookup time is linear in the size of the linked list, and hence the length of the access list. There have however been attempts to improve the performance of this straightforward implementation. Because the internal representation of the access lists is a direct mapping from the original rules, optimising the access lists for performance will result in a direct improvement in lookup times. Ways in which access lists can be optimised include:

Reordering the rules so that the most common types of trafc are processed rst [9]. This is usually performed manually by the administrator although attempts have been made to automate this process. The major difculty either way lies in preserving the semantics of the list when changing the order of the rules. Correctly specifying access lists is a difcult process on its own (as illustrated in Section 2.1.2). For that reason, reordering the rules is an extremely delicate and error-prone process [8]. Some even suggest that optimising an access list for readability is more important than optimising for speed [47].

Dening rule groups. IP Filter allows the administrator to dene rule groups [14]. These allow the creation of a tree of rule groups, rather than one linear list of rules, so that if a packet is completely unrelated to a set of rules, these rules need never be consulted.

Regardless of the techniques used to improve the performance of standard packet lters, their lookup times will always grow linearly with the number of rules in the worst case. This is due to the fact that the internal representation used to represent the access lists is a list structure a direct translation from the original access list and thus the lookup algorithm is forced to perform a linear search through the elements of the list. In order to improve on this worst case performance, an internal representation of the access lists that facilitates a faster lookup algorithm must be used. This observation provides the starting point for research related to packet ltering, which is discussed next.

2.2 Related Work on Packet Filtering and Classication

Packet ltering as a means of network access control is a fairly new concept. Early packet lters refer to the part of the operating system that demultiplexes (delivers) packets to the appropriate user process running on the machine [32]. For each new user process, the operating system adds another rule to

the packet lter to specify what incoming packets should be sent to it, and similarly to its more recent context, the performance of these packet demultiplexers degrades linearly with the number of processes. A number of improvements have since been made on the original design, and interest in the more general problem of packet classication emerged [2]. Packet classication is the problem of nding the least cost rule that matches a packet. In the demultiplexing sense this would be the path (or process) ID to which a packet belongs. In the case of packet ltering as a means of access control, the cost of a rule can be thought of as its position in the access list. Packet demultiplexing, ltering and classication have a common component a lookup algorithm that classies packets according to a set of rules. This section focuses on the lookup algorithms and internal rule representations proposed by previous research work in these areas. A summary of these approaches can be found at the end of this section in Table 2.1 (on page 23).

2.2.1 Theoretical Bounds on Packet Classication

In general, packet classication algorithms trade off space for time, or vice versa. Traditional packet lters use a sequential algorithm to classify packets. This algorithm has time complexity linear in the number of rules and constant space requirements 3 . This is considered very efcient in terms of space, but not extremely efcient in terms of time. On the other hand, by precomputing the matching rule for all possible inputs (where is the number of bits of interest in the packet header) in a table, the lookup time is constant. However, the memory requirements grow exponentially with memory requirements even when

resulting in unreasonable

is relatively small. Thus the real challenge lies in nding a solution

that is efcient in terms of both space and time. An overview of previous approaches to packet ltering and classication is presented next. The different techniques used can be roughly categorised into table-driven approaches and approaches that use specialised data structures to improve performance.

2.2.2 Table-driven Methods

Table-driven methods are characterised by algorithms that preprocess the lters into some tabular representation. In some cases hashing is used to improve performance. Table-driven methods tend to be sensitive to the type of data that they receive they rely on the structure and redundancy found in typical access lists, so that access lists with similar looking rules result in better performance than access lists with arbitrary rules. Data that is not well-behaved may cause either poor memory or time performance.
3

Space complexity measures the amount of extra storage required by the algorithm, not including the storage required for

the representation of the input, which in this case is the access list.

Recursive Flow Classication

Recursive ow classication (RFC) [19] is a good example of a technique that attempts to exploit the structure that is typically found in real access lists to reduce lookup times. RFC is based on the idea mentioned earlier of precomputing the matching rule for all possible inputs. Except, to avoid the unreasonable memory requirements of such a scheme, RFC performs the matching over several steps, instead of just one. The algorithm maps input bits from the packet header into the rule number (where set at each step. During the rst step, the packet header is split into chunks that are used to index multiple tables in parallel. Each lookup yields a number (requiring fewer bits than the original) that the authors refer to as equivalence class IDs. In subsequent steps, the index into each table is formed by combining the results of lookups from earlier steps, until nally, only one number results from the lookup which corresponds to the correct rule number (due to the way in which the tables were precomputed). Intuitively, this algorithm groups pieces of information that are equivalent in terms of their nal classication into equivalence class IDs at each step, narrowing the search. (For example, if the distinction between the two destination addresses 146.* and 147.* makes no difference to the outcome of the lookup, then these rst eight bits might map to the same equivalence class in the rst step.) RFC works well when large amounts of information can be grouped into equivalence classes, and tends to work well in practice due to the structure lters typically exhibit. However, the amount of memory required by RFC is sensitive to the amount of structure present in the access list, and so no good memory guarantees can be given. In fact, in the general case, its memory requirements can grow exponentially with the number of rules.

bits representing the

is the number of rules and

) by reducing the set of values to a smaller

Cross-producting

Cross-producting [42] is another technique that relies heavily on the structure present in the rules to maintain reasonable memory requirements. The precomputing phase of this technique generates a list of distinct prexes for each eld of the lter. It then builds a table of cross-products of the distinct prex lists, i.e. there exists a row in the table for every possible combination of distinct prexes from the original lists. Then for each row, the algorithm precomputes the least cost rule for the cross-product. The lookup algorithm uses the result that the best matching cross-product of a packet matches the same least cost rule as the actual packet. Lookup requires calculating

best matching rule elds (for a entries (where is the number of

dimensional lter) plus one hash table lookup, so lookup time is independent of the number of rules. However, in the worst case the cross-product table can require

rules), so this method can become unusable for even moderate values of and . Attempts have been made to reduce the memory usage by only computing the necessary entries on demand and using a cache instead of a complete table, but this has either unpredictable space requirements or unpredictable lookup times.

Tuple Space Search

The tuple space search [41, 44] denes a tuple where

represents

to be a -length vector (for a -dimensional lter)

the number of fully-specied bits in the th eld of a rule. The preprocessing stage

of this algorithm calculates the set of distinct tuples of the access list. Again, due to the structure typically found in access lists, the number of distinct tuples specied by the rules tends to be much smaller than the total number of rules. Once the tuple set has been calculated, each rule is hashed into a hash table with a hash key created by concatenating its fully-specied bits. Then, given a packet, the lookup algorithm steps through the tuple set and queries the hash table by concatenating bits of the packet as specied by the tuples (remembering the least cost lter seen so far). The lookup time of this algorithm is therefore linear in the number of tuples, and since the number of distinct prex lengths of an access list tends to be signicantly smaller than the number of rules, a linear search through the set of tuples is likely to be faster than a linear search through the original rules. However, because of its reliance on the structure of the access list, this algorithm cannot guarantee a good worst case search time for arbitrary access lists. In the worst case, the tuple set will have the same size as the original list of rules.

Multi-dimensional Range Matching

Multi-dimensional range matching [26] is a technique that solves the classication problem as the inter-

as the number of rules and as the dimensionality of the lter, the lookup algorithm is actually linear in . However, it makes use of bit-parallelism the
section of a number of simpler problems. Given time taken for a single bit operation is the same as the time taken for a word operation, so multiple bit operations can be executed in parallel at no extra cost to reduce the actual lookup times. The classication algorithm is a geometric algorithm that views the rules an encompassing a rectangular area in dimensions, the packets as points in the -dimensional space, and the lookup algorithm

as nding the least cost rectangle that contains the point (since the rectangles may overlap). The preprocessing part of the algorithm projects the edges of the rectangles to their corresponding axes, cutting each axis into a number of intervals. In the worst case, there may be intervals in each dimension. For each interval in each dimension, a bitmap is created that has its th bit set if and only if rectangle

overlaps with that interval. The lookup algorithm then works as follows: when a packet arrives, the intervals that contain this point are located for each axis. This requires

comparisons. Then the bitmaps for those intervals are

ANDed bitwise, and the rst bit that is set in the resulting bitmap corresponds to the least cost rectangle (this is due to the fact that the rectangles are numbered based on their priorities, in the order that the rules appear in the access list). Making use of bit-parallelism, this step requires

memory accesses

where is the word length. While this algorithm is an improvement on the traditional linear algorithm, its strength lies in hardware implementations that can perform much more of the processing in parallel.

Parse Tables

One way in which standard parsing techniques have been applied to packet ltering is by encoding the description of the pattern to be matched as a context-free language, so that packets (treated as bit strings) that are accepted by the language correspond to packets accepted by the lter, and vice versa [24]. This method can make use of standard parsing tools to generate a parse table for the language. However, since general-purpose parse tables can be too large and slow for the purposes of packet ltering, some optimisations have been implemented based on the following insights. Firstly, standard parsers sequentially scan through the entire input. In contrast, parts of the packet header are irrelevant for ltering and can be ignored. Secondly, since the language is specied at the bit level, the input would ordinarily be scanned one bit at a time. Bit-parallelism can be used effectively to speed up the parsing. Since a parser for a context-free language only scans through its input once and never backtracks, one can argue that this lookup algorithms execution time is independent of the number of rules, and is related quite closely to the number of bits in the packet header viewed by the parser. Unfortunately, the authors do not offer any analysis.

2.2.3 Specialised Data Structures

Classication algorithms that use specialised data structures to represent the access lists internally tend to be less sensitive to the types of lists they encounter compared to the table-driven methods. Data structures used to represent access lists are often graph-based and tend to perform quite well in practice.

Grid of Tries

A trie is a binary branching tree whose edges are labelled either 0 or 1, and so the path from the root to a particular node corresponds to the unique bit sequence of the node [10]. Tries are associated with

routing algorithms that match routing table rules according to the destination address of the packet. This structure has been extended to support matching on two elds instead of just one with a grid of tries [42]. Essentially after the trie for the rst eld has been constructed, tries for the second eld are constructed off relevant nodes in the original trie. This nal data structure behaves somewhat like an automaton

where is the maximum bit size of the elds, and with special optimisation, space where is
scanning one bit of the input at a time and never backtracking. This results in a lookup time of the number of rules. Unfortunately, this scheme does not extend to multi-dimensional lters, since it implicitly builds longest prex matching into the structure and has the constraint that the specied bits in each prex must be contiguous and start matching from the start of the input string. So while this structure is useful for applications such as multicast forwarding, it is not very useful for general packet ltering applications.

Expression Trees

The earliest work on packet classication (demultiplexing) used expression trees to represent the rules [32]. This data structure was a natural choice due to the stack-based implementation used. An expression tree is a binary tree that has Boolean predicates at its leaf nodes and Boolean operations (such as AND and OR) at its internal nodes. The value of the expression is given by performing an in-order traversal of the tree. One of the major problems with this approach is that it does not maintain state, meaning that the packet may need to be parsed several times to evaluate the expression, resulting in redundant computations. The original implementation using this data structure is called CSPF (CMU / Stanford packet lter) and has lookup times that grow linearly with the number of rules.

Binary Directed Acyclic Graphs

Following CSPF is the Berkeley packet lter (BPF) [30] that improves on the original design by using control ow graphs (CFGs) to represent the rules instead of expression trees. CFGs are directed, acyclic graphs whose nodes represent Boolean predicates (such as destination=foo) and edges represent control transfers (one edge is traversed if the corresponding predicate is true; the other edge is traversed if it is false). Unlike expression trees, the CFG model allows state information to be implicitly built into the data structure which avoids recomputing identical predicates. Various optimisations have been applied to the original CFGs that further attempt to reduce redundant computations which has the effect of reducing both the lookup times and memory requirements [2, 4, 46]. Although these packet lters perform much better than the original CSPF, no theoretical results have been published to describe time or memory requirements in general.

Decision Graphs

Decision graphs used to classify packets consist of nodes that represent a test of a variables value. The branches of the node represent the path taken depending on the current value of the variable. They may represent one value or a range of values. They differ from the types of graphs discussed previously in that a node may have more than two children and can thus have more complex expressions at the nodes, rather than just Boolean predicates. In one implementation of such a graph, the graph is constructed in a number of layers corresponding to the dimensionality of the lter so each layer corresponds to the test of one eld in the packet header [17]. Because of this, the depth of the graph is same as the number of elds ltered on and thus the lookup time is roughly linear in number of elds and independent of the number of rules. However, no results are given regarding the memory requirements of this scheme. Another technique called HiCuts [20] builds a decision graph in a similar way, except that each leaf stores a number of lter rules (rather than just the single matching rule or rule number). The lookup algorithm traverses the decision graph, which is typically quite shallow, to a leaf node and then performs a linear search through the list of rules stored at the leaf node. The depth, shape and decisions to be made at each node greatly affect the performance of the resulting decision graph and so the algorithm is heavily guided by heuristics. During the construction of the graph, the partition that leads to the most uniform distribution of the rules across the nodes is chosen. When the number of rules at a node drops below a certain threshold, the node is not partitioned any further. Experimental work on access lists ranging from 100 to 1700 rules in size (with 4 elds) and the above threshold set to 8, measured a worst case lookup requiring 12 memory accesses and a linear search on 8 rules. No analytical results are given.

2.2.4 Summary of Related Work

Many of the research efforts described above try to exploit the structure common in access lists to narrow the search space. While this may lead to impressive experimental results on some access lists, the lack of good worst case bounds for either time or memory means that the techniques may become unusable in certain realistic instances. It is interesting to note that besides the research related to packet demultiplexing (CSPF, BPF and their successors), many of the ideas suggested by the researchers remain unused. Most packet ltering implementations currently in use still use a sequential model of evaluation and this is probably due to to its simplicity in both implementation and algorithm behaviour. However, there are a few exceptions worth mentioning:

Cisco Systems standard packet ltering implementation searches sequentially through its access lists. On their more recent software releases, they offer compiled access lists whose implementation offers a constant lookup time at the expense of memory (access lists may be compiled in this way until the router has exhausted its memory) [12]. No experimental evidence is given for the performance of this implementation, and also no implementation details are offered, but their system requirements are symptomatic of some of the table-based methods discussed above.

Although the packet lters written for Linux and the BSD variants use an ordinary linked list to represent the rules internally, network tools (such as tcpdump and arpwatch) that also perform packet ltering as part of their packet processing use control ow graphs as used in the BPF implementation [30].

A problem with much of the literature on the topic of packet ltering and classication is that conclusive, analytical results are rare. Most of the approaches are evaluated experimentally, which makes comparing one approach to another difcult. Proprietary systems offer even less information and renders the task of comparison almost impossible. However, the known theoretical bounds as well as qualitative comments regarding related approaches are summarised in Table 2.1 on page 23. Having said that, comparisons between the approaches proposed in the literature and the BDD approach proposed in this research are made wherever possible. A qualitative comparison is presented in Section 3.3 following the explanation of the BDD approach in more detail. These alternative approaches are also revisited once the experimental results of the BDD approach have been discussed, in Section 7.1.4.

Technique Sequential evaluation

Time Complexity

Space Complexity

tremely simple.

Requires very little preprocessing. Lookup algorithm is ex-

RFC

in worst case

Can work well in practice, but extremely sensitive to rule structure. Roughly

Cross-producting

in worst case

Memory requirements extremely sensitive to rule structure, so only viable with caching for moderately sized access lists which may result in unpredictable lookup times. Tuple space search

, in worst case
Sensitive to the rule structure works well when the tuple set is signicantly smaller than .

Range matching

Better suited for hardware implementations, where the parallelism can be exploited. Roughly

Parse table

High overhead in creating the table since context free grammars are not an ideal representation for access lists.

Grid of tries

Not extendible to more than two elds. Not suitable for non-contiguous masks. Gives excellent performance for 2dimensional lters.

Expression tree

Trees contain many redundant computations.

CFG

Eliminates the redundancy of expression trees. Seemingly good performance in practice. Roughly Performance depends on good choice of algorithm parameters choosing values is not an obvious process.

Decision graph

Table 2.1: Summary of related work on packet ltering and classication. Fields may be missing in cases where the authors did not publish the relevant information. ( represents the number of rules,

the dimensionality of the lter, the number

of tuples, the word length and the maximum bit size of the elds of the lter.)

Chapter 3

The BDD Approach to Packet Filtering

The strengths of the BDD approach to packet ltering lie in its exible and powerful access list representation. The motivation for this approach is that the selection criterion of each rule of an access list is simply a Boolean expression consisting of a number of predicates. Furthermore, the policy of the access list itself can be expressed as a Boolean expression in terms of the individual rules. In general, the representation of Boolean expressions grows exponentially in size with the number of variables. However, binary decision diagrams (BDDs) are well-known structures for representing Boolean expressions compactly potentially requiring far less than exponential space. The BDD approach to packet ltering uses BDDs for the representation of access lists, and the many useful properties that BDDs possess lead to the strengths of this approach. The original idea of the BDD packet lter was developed by Hazelhurst et al [23]. This contribution included an algorithm to convert access lists into BDDs, a framework for reasoning about access lists using their BDD representation (answering questions such as whether two access lists are equivalent), and an algorithm for performing lookup for packet ltering on BDD representations of access lists. This chapter is devoted to describing the BDD approach to packet ltering in detail: Section 3.1 provides the necessary background on BDDs while Section 3.2 shows how BDDs can be used for packet ltering. Finally, Section 3.3 compares the BDD approach to some of the approaches found in the literature.

3.1 Binary Decision Diagrams

Binary decision diagrams represent Boolean functions as rooted, directed acyclic graphs [7]. In its simplest form, a BDD can take the form of a decision tree, as depicted in Figure 3.1. Each non-terminal

24

in the tree refers to a test of a particular variables value and the edges to the two children of the nonterminal represent the paths taken by either possible value (0 or 1). The dashed (low) edge corresponds to the case where the variable is assigned 0 and the solid (high) edge corresponds to the case where the variable is assigned 1. The terminal nodes of the tree are one of the Boolean constants 0 and 1.
x 1 x 2 x 2

x 3

x 3

x 3

x 3

x 4 0 0 0

x 4 0 0

x 4 1 1

x 4 1 0

x 4 1 1

x 4 1 0

x 4 1 1

x 4 1

Figure 3.1: A decision tree for the Boolean expression

. Note that the

terminals correspond to the rows of the truth table for this expression in number and value. For a given assignment of the variables, the value of the Boolean expression is determined by starting at the root of the BDD and following the edges at each non-terminal as dictated by the values of the variables until a terminal node is reached. The value at this node gives the value of the function.

3.1.1 Ordering and Reducing

Figure 3.1 shows a BDD as a direct translation from its expressions truth table. The problem with this representation is that the number of nodes grows exponentially with the number of Boolean variables in the expression. Bryant [7] introduced the concept of reduced, ordered binary decision diagrams (ROBDDs) that potentially provide a much more compact representation for many Boolean expressions. ROBDDs are BDDs with the following restrictions [7]:

The variables of a ROBDD must obey a total ordering, so that for any vertex labelled and any of its children labelled , appears before along any path from the root of the graph to a leaf. A ROBDD may not contain duplicate terminals. This leaves a ROBDD with two terminal vertices (one labelled 0 and the other labelled 1).

A ROBDD may not contain duplicate non-terminals. Duplicate non-terminals are those that represent the same variable where the corresponding branches lead to the same place. A ROBDD may not contain redundant tests. If, at a particular vertex in the graph, both possible values of the variable lead to the same place, then this test is unnecessary.

These restrictions result in ROBDDs possessing some useful properties. Firstly, they provide compact representations of Boolean functions, as illustrated in Figure 3.2. Although in the worst case, their graph sizes can be exponential in the number of variables, many non-trivial Boolean functions have a polynomially sized ROBDD [7]. Secondly, there are many efcient algorithms for manipulating and performing logical operations on ROBDDs [1]. This is due to the fact that the ROBDD representation of a Boolean expression is canonical for a given variable ordering, meaning that there is exactly one ROBDD representing it [7]. Efcient ROBDD operations include testing for functional equivalence, satisability (the ROBDD does not correspond to the single terminal vertex labelled 0), and testing for tautology (the ROBDD corresponds to the single terminal vertex labelled 1).
x1 x2 x3 x4 0 1

Figure 3.2: A ROBDD for the Boolean expression

. Notice how the

elimination of redundancy has resulted in a compact representation with only 4 non-terminal nodes compared to the 15 non-terminals present in the decision tree version for the same expression, shown in Figure 3.1.

A ROBDD for a Boolean expression can be constructed by rst generating its decision tree and then applying the rules specied above multiple times, until the decision tree is reduced to a ROBDD. This approach is only feasible for expressions with a small number of variables since the decision tree for an expression has size exponential in the number of variables. Instead, ROBDDs are usually reduced iteratively at each step during their construction. Readers interested in more detail regarding the construction of ROBDDs are referred to [6]. Since ROBDDs offer many advantages over unrestricted BDDs, most applications that use BDDs actually use ROBDDs, to the extent that it is common for ROBDDs to simply be referred to as BDDs [1]. In

this spirit, since this research is only interested in the restricted form of BDDs, all subsequent references to BDDs should be inferred as meaning ROBDDs.

3.1.2 The Effect of Variable Ordering

The variable ordering chosen for a BDD has a strong impact on its shape and size [7]. In fact, it can mean the difference between a linearly sized and an exponentially sized BDD for the same Boolean function, as illustrated in Figure 3.3. On the other extreme, there are some functions that cannot be expressed compactly using BDDs, regardless of the variable ordering chosen [6]. An example of such a function is in integer multiplication the functions representing the middle two outputs of an integer multiplier have exponentially sized BDD representations in the best case.
x1 y1 x2 y2 x3 y3 0 (i) 1 0 (ii) y3 1 y2 y2 x3 x2 x3 y1 x3 y1 y1 x1 x2 x3 y1

Figure 3.3: Two BDDs for the function depicts the ordering
non-terminal

for . Figure (i) which yields a BDD with

nodes in the general case, which is linear. Figure (ii) depicts the

ordering

which yields a BDD with non-terminal nodes, which is exponential in [7].

For those functions that do have compact BDD representations, it is important to choose a good variable ordering. BDDs provide an efcient method for representing and manipulating Boolean functions as long as the graph sizes are not at their worst case of being exponential. However, nding the optimal variable ordering for a BDD is an NP-complete problem [5]. As a result, variable orderings are often chosen either manually (there are known good orderings for certain functions) or using heuristics. It is not necessary to nd an optimal variable ordering an ordering that avoids exponential growth is good

enough.

3.1.3 Representing Integers

Another strength of BDDs is that numbers can be expressed and manipulated symbolically. By representing integers as bit vectors, symbolic manipulation can be done as bit operations. Numeric operations such as comparison and addition have efcient and compact BDD implementations [21]. The following example illustrates how integer expressions can be represented by BDDs. Consider the unsigned integers in the range
,

represented by the bit vector

where each is an

ordinary Boolean variable and is the most signicant bit. Then,

Integer constants can be easily represented. For example, the constant vector

is represented by the bit

Testing for equality is relatively straightforward. The expression x

or (where primes indicate negation reduces to the simple Boolean expression

and juxtaposition indicates conjunction).

The other relational operators ( ,

) can be handled with simple recursive functions. For

example, the less-than function is given by:

The other operators can be dealt with similarly.

3.2 The BDD Packet Filter

The BDD packet lter represents an access list internally as a BDD, and uses this BDD to perform lookup for incoming packets. The BDD packet lter can be conceptually viewed as shown in Figure 3.4 on page 29. This diagram shows a packet lter connecting an internal network to an external network with an access list applied to incoming packets at its external interface. A BDD representation of the access list is stored in the packet lter and used to perform lookup. This BDD is a representation of the Boolean expression that describes exactly what packets that are accepted by the access list must look like. In other words, all paths through the BDD that lead to the terminal labelled 1 represent the types of packets that are accepted, and the opposite is true for all paths leading to the terminal labelled 0. Each variable in the BDD corresponds to a particular bit in the packet header. More detail is given later.

BDD Packet Filter

Incoming Packet
01101011

External Network

11010100 11110010 01001111 01010011 10000111

11 00 1 0 1 0 1 0 11 00 1 0 1 0 1 0 1 0 11 00 1 0 1 0 1 0 11 00Internal 1 0 1 0 1 0 Network 1 0 11 00 1 0 1 0 1 0 11 00 1 0 1 0 1 0 1 0

Access List

Figure 3.4: Conceptual diagram of the BDD packet lter.

Although the packet lter in Figure 3.4 consists of only one access list applied at one interface, this approach can be used more generally by creating a new BDD for each access list.

3.2.1 Converting Access Lists into BDDs

This section explains how an access list is converted into a Boolean expression, which can then be used to create its BDD representation. It begins by discussing issues relating to the choice and number of Boolean variables in the Boolean expression. Then a description of how individual rules are converted into Boolean expressions is given, followed by the technique for combining these expressions into a single expression that represents the entire access list. These algorithms, adopted from Hazelhurst et al [23], have been slightly modied for efciency reasons.

Dening the Boolean Variables

Since each variable in the BDD represents a particular bit in a packet header, it follows that all bits in the header of interest to the packet lter for ltering should have a corresponding BDD variable. As an example of how this might be done, consider the IP packet header shown in Figure 3.5 on page 30. Suppose that a given access list uses the source and destination addresses as well as the protocol type from a packets IP header for ltering. The addresses are represented by 32 bits in the header, and the protocol eld is represented by 8 bits. Thus a total of 72 Boolean (and hence BDD) variables would be required to encode ltering information corresponding to these elds in the Boolean expression of the access list. Supposing that the access list also contains information regarding source and destination ports for TCP

32 bits

Version

IHL

Type of Service

Total Length

Identification Time to Live Protocol

DM FF
Source Address Destination Address

Fragment Offset Header Checksum

Options (0 or more words)

Figure 3.5: The IP Datagram Header.

and UDP, additional variables must be dened to represent the port information. Since the headers for these protocols encode the port information in 16 bits per port, 32 extra variables are required to encode port information. In this example, a total of 104 variables would be required to encode the access list as a Boolean expression. These are shown in Table 3.1. In general, any information available in the packet headers can be used for ltering, and the number of variables required for the Boolean expression (and hence the BDD) representing an access list corresponds to the number of distinct packet header bits the rules in the access list refer to. Header Field Source IP address Destination IP address Protocol type Source port Destination port Total: Boolean Variables Total Number

32 32 8 16 16 104

Table 3.1: The Boolean variables required for a BDD representation of an access list ltering on source and destination IP addresses, protocol type, and source and destination ports. Highest numbered variables represent the most signicant bits.

Converting Individual Rules

During lookup, a packet matches a rule if it matches the entire selection criterion of that rule. So a single rule in an access list can be thought of as a conjunction of predicates, where each predicate is a simple Boolean expression over one eld of the packet header. In converting individual rules, each predicate of the rule is converted into its corresponding Boolean expression this largely involves applying the theory on representing integers described in Section 3.1.3 the conjunction of these expressions gives the complete expression for the rule. Different types of predicates that may be encountered include:

Predicates involving equality: These are predicates of the form eld

value. Testing for spe-

cic protocol types and port numbers are good examples of this. To encode a predicate of this form, the Boolean variables representing the bits of the header eld are set equal to the bit vector representation of the value. For example, the predicate protocol TCP converts to

since the IP header value for TCP is 6, which simplies to .

Predicates involving order: These are predicates that represent a range of values using the relational operators , , and . Port numbers are often specied in this way. The expressions for

predicates of this form are constructed recursively. For example, the predicate source port converts to

which simplies as follows:

Predicates of the form eld

can be expressed as eld

eld

and the two

sub-expressions treated as above.

Predicates involving masks: IP address criteria in rules specify the addresses using a base address and a mask. Assuming that reverse masking is used, 0-valued bits in the mask signify relevance and 1-valued bits signify irrelevance. This means that bits in the base address masked by a 1valued bit can effectively be ignored when constructing the Boolean expression. Thus the predicate

source address As an example,

base address mask converts to source address mask

base address mask.

source address source address source address

Note that this technique can handle arbitrary non-contiguous masks. Also, in the case where the mask species all bits as being relevant (0.0.0.0 for IP addresses), the algorithm simplies to the algorithm for encoding predicates with equality.

Combining the Rules

A Boolean expression that represents an entire access list describes, in essence, what packets accepted by the access list look like, while preserving the order of the rules within the list. In other words, packets are accepted by the list if and only if they satisfy the Boolean expression. This conversion can be performed using a recursive function that processes the access list from top to bottom. Intuitively, the function behaves as follows:

If the current rules action is P ERMIT then a packet is accepted if it matches that rule or if it is accepted by the rest of the list. The algorithm generates the disjunction of the current rules representation and the expression representing the remainder of the rules.

If the current rules action is D ENY then a packet is accepted if it does not match that rule and it is accepted by the rest of the list. The algorithm generates the conjunction of the negation of the current rules representation and the expression representing the remainder of the rules.

If no rules are left, the default policy takes effect the resulting Boolean expression is 0 if the policy is to reject all packets and 1 if the policy accepts all packets.

Assuming the function C ONVERT RULE converts a single rule into its corresponding Boolean expression as described in Section 3.2.1, the pseudocode for the function that converts an entire access list is given in Figure 3.6.

function C ONVERT L IST (access list) if length (access list) == 0 return default policy else current rule = head (access list) rest = tail (access list) if action (current rule) == permit return (C ONVERT RULE (current rule) OR (C ONVERT L IST (rest))) else if action (current rule) == deny return (NOT C ONVERT RULE (current rule) AND (C ONVERT L IST (rest)))

Figure 3.6: Algorithm for converting an access list into its BDD representation.

A detailed example showing how an access list is converted into a Boolean expression is given in Section 3.2.3.

3.2.2 Performing Lookup

Once the BDD representation of the access list has been constructed, performing lookup for a packet is a simple matter of testing whether the interpretation of the variables given by that packet satises the BDD. This is performed as follows. Starting at the root of the BDD, the algorithm checks the value of the variable corresponding to that node, following the low edge if it is false and the high edge if it is true to the next node. This process is repeated until a terminal node is reached, at which point the ltering decision is made P ERMIT if the terminal node is labelled 1, and D ENY if it is labelled 0. Simple, iterative pseudocode for this is given in Figure 3.7 on page 34.

3.2.3 An Example of Access List Conversion

The example below demonstrates symbolically how an access list is converted into a Boolean expression using the technique described in Section 3.2.1. The access list that will be used in this example is shown

function L OOKUP bdd ptr = root (bdd) while (bdd ptr != 0) and (bdd ptr != 1) /* packet header value(j) gives the value in the packet header corresponding to bdd variable j */ if packet header value[bdd ptr] == 1 bdd ptr = high(bdd ptr) else bdd ptr = low(bdd ptr) return (bdd ptr == 1 ? permit : deny)

Figure 3.7: Algorithm for performing lookup using a BDD representation of the access list.

in Figure 3.8. This access list shows some sample rules applied to inbound trafc at the external interface of the 146.141.0.0/16 network. It allows all inbound mail connections, as well as ICMP trafc and web requests that do not claim to originate from the internal network. Its default policy is to deny all packets. What follows is a high-level illustration of how the conversion occurs. A detailed description is presented in Appendix A and the complete BDD representation of the access list is shown in Figure 3.9 on page 38. This BDD has its protocol variables ordered rst, followed by the variables corresponding to destination information, followed by the variables corresponding to the source information. The choice of variable orderings is discussed in detail in later chapters.
Rule 1 2 3 4 Proto TCP IP TCP ICMP Src Addr 0.0.0.0 146.141.0.0 0.0.0.0 0.0.0.0 Src Mask 255.255.255.255 0.0.255.255 255.255.255.255 255.255.255.255 Src Port 1023 any 1023 Dest Addr 146.141.0.0 146.141.0.0 146.141.0.0 146.141.0.0 Dest Mask 0.0.255.255 0.0.255.255 0.0.255.255 0.0.255.255 Dest Port 25 any 80 Action Permit Deny Permit Permit Deny

Default Policy:

Figure 3.8: An example access list to illustrate conversion into a Boolean expression.

Step 1: Dene the Boolean Variables

The access list lters on the following ve elds: source address, destination address, source port, destination port and protocol. Summing the corresponding eld sizes in the appropriate headers gives a total

of 104 bits thus up to 104 variables are required for the BDD representation of this access list. For convenience, these variables will be named as in Table 3.1.

Step 2: Convert Individual Rules

This step of the algorithm involves converting the selection criterion for each rule into a Boolean expression. This is accomplished by forming a conjunction of each predicate in the selection criterion. Let denote the Boolean representation of Rule . To convert the rst rule: Let

Proto

TCP

and

Src Port

and

Dest Addr

and

Dest Port

Then

The expressions

and

are constructed similarly.

Step 3: Combine the Rules

Using the algorithm described in Section 3.2.1, the

expressions generated above can be combined into

a single expression dening the access list. For ease of explanation, suppose that ACCEPTED() denotes the statement a packet is accepted by the access list . Also suppose the access list is represented in the form = F (false). The conversion then takes place as follows. Since

where each represents the rule numbered in Figure 3.8 and so the rules

in are evaluated from left to right. Since the default policy of this access list is D ENY, ACCEPTED([])

s action is P ERMIT, a packet is accepted by the

access list if

holds or if it is accepted by the remainder of the list

. In other words,

ACCEPTED

iff i.e. iff iff iff iff iff iff

holds or ACCEPTED
ACCEPTED

ACCEPTED

ACCEPTED

ACCEPTED F

This nal Boolean expression denes exactly what packets are accepted by the access list, as desired. The BDD representation of this expression would now be applied at the external interface of the BDD packet lter at the border of the 146.141.0.0/16 network, and the lookup algorithm of Section 3.2.2 would be used to perform the ltering.

3.3 Comparison to Other Approaches

At this point, the BDD packet lter has been described sufciently to show how the BDD approach differs conceptually from those proposed in the literature (covered in Section 2.2). The salient points are that the BDD approach:

Performs no redundant computations. The reason expression trees perform so poorly is because many of the subtrees are identical, requiring the lookup algorithm to recompute these expressions. CFGs are an improvement on this, but cannot guarantee complete non-redundancy, which BDDs can. Because the variables of the BDD representing the access list are ordered, and the lookup algorithm performs a single pass from the root of the BDD to a terminal node, the lookup algorithm never encounters the same variable twice, meaning that expressions are never re-evaluated.

Represents information at the bit level. BDDs naturally represent information at the bit level, since the nodes of the BDD test for a particular bits value. On the other hand, structures like CFGs and decision graphs represent much more information at their nodes, such as tests for values of integers. The disadvantage of this for the BDD approach is that bit operations on a standard CPU (such as testing for the value of a bit) are as expensive as word operations due to the parallel computation in the hardware. To illustrate, testing the expression most signicant protocol bit = 0 in a BDD could potentially take as long as testing the expression protocol = TCP in a CFG. The

advantage is that it allows BDD representations to perform optimisations at the bit level a very ne level of granularity to eliminate any bit that is irrelevant to the nal representation. The parsing technique for packet ltering that considers packets as input to be parsed also deals with information at the bit level, since the input is parsed a bit at a time. However, one of the weaknesses of this approach is that the input has to be parsed in the order that it appears, which could result in processing information that is irrelevant to the nal result. In contrast, the variables of a BDD representing bits in packet headers can appear in any order, meaning rstly, that the lookup algorithm never looks at irrelevant packet data and secondly, that the variable ordering can be manipulated to optimise lookup times and / or memory usage of the BDD.

Supports multi-dimensional ltering. The grid of tries structure performs two-dimensional packet classication with excellent time and space complexity. However, because a grid of tries structure behaves like an automaton that performs a longest prex matching on the input, the way in which it is constructed limits its use to only two dimensions. The BDD structure is a more general representation that can represent an arbitrary number of dimensions. Unfortunately, this generalisation must come at the cost of memory and / or lookup performance.

Supports rules with non-contiguous masks. As mentioned above, the grid of tries approach represents longest-matching prexes within its structure and so inherently cannot support matching on non-contiguous masks. Another such approach is the tuple space search whose tuples consist of the numbers representing the specied rules prex lengths. Thus it also requires that masks be contiguous. In contrast, unlike the grid of tries, the BDD approach does not rely on reading its input sequentially, and the algorithm for constructing the BDD handles non-contiguous masks with no modication.

An interesting question about the BDD approach is with regard to how robust the BDDs are to the access list rule structure. Techniques such as RFC, cross-producting and the tuple space search rely heavily on structured access lists for good performance some even become unusable in extreme conditions. This question is tackled in Chapter 6 once the experimental evidence has been presented.

p7

p6

p5

p4

p3

p2

p1

p0

da31

da30

da29

da28

da27

da26

da25

da24

da23

da22

da21

da20

da19

da18

da17

da16

dp15

dp14

dp13

dp12

dp11

p1

dp10

p0

dp9

da31

dp8

da30

dp7

da29

dp6

da28

dp5

da27

dp4

da26

dp3

da25

dp2

da24

dp1

da23

dp0

da22

da21

sa31

da20

sa30

da19

sa29

da18

sa28

da17

sa27

da16

sa26

sa25

sa31

sa24

sa30

sa23

sa29

sa22

sa28

dp5

sa21

sa27

dp4

sa20

sa26

dp3

sa19

sa25

dp2

sa18

sa24

dp1

sa17

sa23

dp0

sa16

sa22

sp15

sa21

sp14

sa20

sp13

sa19

sp12

sa18

sp11

sa17

sp10

sa16

Figure 3.9: BDD representation of the access list in Figure 3.8.

Chapter 4

Analytical Discussion of the BDD Packet Filter

The previous chapter provides a framework for constructing BDD representations of access lists and using them to perform lookup in packet lters. This chapter presents an analytical and qualitative investigation into this approach to packet ltering. It aims to highlight some of the behavioural aspects of the BDD packet lter in order to understand what lookup times and memory requirements can be expected from it. Wherever possible, theoretical bounds on performance are given. However, some aspects of performance are based on actual trafc distribution in the packet lters environment, and cannot be analysed without further knowledge. The discussion begins in Section 4.1 with an investigation into what BDD representations of access lists look like and what determines the structure of these BDDs, since the shape and size of a BDD directly affects its time and space performance. Section 4.2 then discusses bounds for, as well as factors affecting, the lookup time of the BDD packet lter, while Section 4.3 discusses factors affecting memory usage. Important results and their consequences are summarised in Section 4.4.

4.1 BDD Representations of Access Lists

Recall that a BDD representation of an access list is a BDD that describes, at the bit level, what packets that are accepted by that access list look like. The terminal nodes of the BDD, labelled 1 and 0, represent the two actions P ERMIT and D ENY respectively. Individual variables of the BDD refer to a specic bit in the packet headers. Each path through the BDD from root to terminal node represents a set of packet headers (possibly of size 1). The set of all paths through the BDD represents the entire search space

39

the paths that lead to the terminal labelled 1 represent the packet headers of packets that are accepted by the BDD, and the opposite is true for the paths that lead to the terminal labelled 0. To illustrate these concepts, consider the access list given in Figure 4.1, which has been restricted to a small number of ltering elds for ease of explanation. This list accepts any IP trafc arriving from networks 146.200.0.0/16 and 109.200.0.0/16 (this typically includes transport protocols TCP, UDP and ICMP) and ICMP trafc from networks 146.0.0.0/8 and 109.0.0.0/8. Although this is a somewhat contrived and unlikely access list, it shares some properties with real access lists, the most important of which is the recurrence of certain subexpressions in multiple rules in the list. The access list in Figure 4.1 is used to aid discussion throughout this chapter. Rule 1 2 3 4 Proto ICMP ICMP IP IP Src Addr 146.0.0.0 109.0.0.0 146.200.0.0 109.200.0.0 Src Mask 0.255.255.255 0.255.255.255 0.0.255.255 0.0.255.255 Action Permit Permit Permit Permit Deny

Default Policy:

Figure 4.1: A simple access list with ltering elds protocol type and source address.

A BDD representation for this access list is shown in Figure 4.2 on page 48. This BDD consists of 24 variables and 46 non-terminal nodes. Other interesting facts are that there is a total of 272 paths through the BDD, of which 18 paths lead to P ERMIT and the remaining 254 lead to D ENY. The average path length is 13.9, with a minimum path length of 3 and a maximum path length of 24. The inquiring reader may wonder what these numbers mean whether 24 is a good number of variables to have, or what it means to have an average path length of 13.9. This section explores these types of questions. The shape and size of a BDD representing an access list (attributes such as the number of nodes, number of variables and BDD depth) are affected by various factors, and they, in turn, affect the performance of the BDD packet lter. Of the factors affecting the structure of the BDD, some can be controlled and others cannot. The two main factors involved are the access list itself and the variable ordering of the BDD. The variable ordering of the BDD can be manipulated to improve the performance of the packet lter, whereas the access list is generally xed. Variable orderings can also often be chosen to take advantage of the rule structure in the access list. The next two sections discuss how these factors affect the structure of the BDD.

4.1.1 The Effect of Rule Structure

In Section 3.2.1 it was stated that the number of variables in a BDD representation of an access list corresponds to the number of distinct packet header bits that the rules in the access list refer to. This number generally coincides with the sum of the eld sizes ltered on, but not always. In converting the access list in Figure 4.1 into its BDD representation, typically 40 variables would be needed (8 for the protocol and 32 for the source address). However, the BDD in Figure 4.2 has only 24 variables. This is because the 16 least signicant bits of the source address are never referred to by any of the rules in the access list they are always masked out by the source address mask. This illustrates two important points. Firstly, variables that are unnecessary for making ltering decisions are automatically excluded from the BDD during its construction. This is an optimisation that is inherent in the BDD packet lter. Secondly, the number of variables in the BDD depends on the complexity of the access list in terms of the number of elds ltered on and how specic the rules are. The more information a rule requires in its specication, the greater the number of variables needed to encode that knowledge. Another way in which the access list affects the BDD is in the inter-relatedness of the rules. Rules with similar predicates can often share parts of the BDD. To illustrate, rules 3 and 4 in the example both have 200 as the second octet of the source address. In the BDD representation of this access list, the predicate loosely stated as source address second octet = 200 is encoded in the shaded area labelled 200 of the BDD. The multiple entry points into this area shows how it is shared by multiple paths in the BDD. This aggregation of similar expressions greatly affects the size of the BDD, since the degree to which expressions in the BDD can be shared determines the number of nodes required for the BDD. The more related the data, the more the nodes can be shared, and vice versa.

4.1.2 The Effect of Variable Ordering

The variable ordering chosen for the BDD in the example has the protocol variables appearing rst followed by the source address variables (both from most to least signicant bits). So during lookup, the protocol of the packet is always tested rst, and the only test is to check for ICMP packets. If the ICMP test fails, tests on the source address determine whether the packet should be permitted based on other criteria. If a different variable ordering is used for example having the source address variables appear before the protocol variables then the address of an incoming packet will always be tested before the protocol. The BDD with this alternative variable ordering is shown in Figure 4.3 on page 49. This BDD also has 24 variables and a maximum path length of 24, but has 31 non-terminal nodes, 160 paths through it, a minimum path length of 2 and an average path length of 16.29.

As this example shows, while changing the variable ordering of the BDD does not change its semantics (the two BDDs for the given access list are semantically equivalent), it does change the structure of the BDD. The number of nodes, path lengths and the order in which the variables appear from root to terminal nodes differs between BDDs with different variable orderings. An interesting point to note is that placing the source address variables before the protocol variables in this example has allowed the 146 and 109 address prexes to be aggregated and shared by rules 1 and 3, and 2 and 4 respectively. This explains the lower node count in the new BDD. By ordering the protocol before the source address, this aggregation is not possible because the BDD is forced to make the protocol decision rst, after which separate subtrees are needed for the source address checking, one for the case where the packet is an ICMP packet and another for the opposite case. Different variable orderings often trade off various aspects of a BDD. It is common to nd a variable ordering that will reduce the number of nodes at the expense of average path length, or vice versa. The fact that the memory usage of the BDD packet lter is related to the node count and its lookup times are related to the BDDs path lengths (as will be explained in the upcoming section) suggests that different variable orderings create different space-time tradeoffs.

4.2 Performing Lookup on a BDD

As explained in Section 3.2.2, the lookup algorithm tests, for each incoming packet, whether the interpretation of the variables given by the packet satises the BDD. The algorithm starts at the root of the BDD, checks the value of the variable at that node and follows the appropriate edge to the next node. This process is repeated until one of the terminal nodes is reached, at which point the packet is accepted if the terminal node reached corresponds to P ERMIT (labelled 1) and rejected if it corresponds to D ENY (labelled 0). Thus the time taken to perform the lookup is proportional to the length of the path traversed by the lookup algorithm.

4.2.1 Worst Case Analysis

For each incoming packet the BDD must be traversed from the root to one of its terminal nodes, and so the worst case occurs when the longest path in the BDD is chosen. Since the variables in the BDD are ordered, no variable can appear more than once on any path from root to terminal node, so in the worst case all the variables occurring in the BDD may be inspected once. This has the following important consequences:

1. For a given access list there is an upper bound on the worst case lookup time. The maximum number of variables in the BDD representation of an access list corresponds to the sum of the eld sizes of the packet header elds ltered on. Since the lookup algorithm never inspects more variables than the number of variables in the BDD, the maximum path length can never exceed the maximum number of variables in the BDD, and this number is xed for a given access list. This result can in fact be stated more strongly: 2. For a given access list format there is an upper bound on the worst case lookup time. A packet ltering implementation species the syntax, or format, for rule specication and this determines the expressiveness of its access lists. The total number of variables representing an access list in a given format cannot exceed the sum of the eld sizes available for rule specication. And since the total number of elds is nite the corresponding protocol headers either have a xed length or they have a variable length and the number of extra options is limited this limit is bounded. The upper bound on the worst case lookup time for a given access list is less than or equal to that of its access list format. 3. For a given access list there is a lower bound on the worst case lookup time. The longest path in the corresponding BDD must contain at least as many nodes as the maximum number of variables needed to encode any (non-redundant part of a) rule in the list. The reason for this is that in order to match on a rule requiring

variables to encode it, the minimum work that needs to be done is to check the values of those variables. If any less work is done, a lookup algorithm can never

conclusively match a packet on that rule. 4. The actual worst case lookup time for a given access list depends on the access list structure and the variable ordering of the BDD. In general, the worst case lookup time of a BDD can fall anywhere between its lower and upper bounds as described in points 1 and 3 above. Multiple BDDs for the same access list with different variable orderings will often result in different maximum path lengths, and hence worst cases, for the different BDDs.

It should be mentioned that, in practice, it is quite likely for an access list to contain a rule which species a matching criterion that involves all the elds of the access list, and more specically, all the variables of the access lists BDD. In such a case, the worst case lower and upper bounds coincide and the worst case corresponds exactly to the number of variables in the BDD and is independent of the variable ordering.

4.2.2 Best Case Analysis

The best case occurs when the shortest path through the BDD is chosen by the lookup algorithm. In most BDDs representing access lists, the best case will occur on packets that do not match any rules in the list

because matching on a rule usually requires at least eight comparisons (this is equivalent to checking the protocol of the packet or a single octet of one of its addresses). The BDDs can often have paths shorter than this (as do the BDDs in Figures 4.2 and 4.3). The best case of the lookup algorithm depends on the variable ordering of the BDD, and will differ for BDDs representing the same access list with different variable orderings. Optimising the BDD for the best case is only worth while if that shortest path through the BDD is traversed often by the lookup algorithm. A point worth noting about the theoretical best case for a given BDD is that it can often be deceptive. Consider an access list whose rules specify transport protocol types, and a corresponding BDD with the protocol variables ordered rst. Since the three protocols (ICMP, TCP and UDP) all have relatively small protocol numbers (1, 6 and 17 respectively), the rst node of the BDD will check the most signicant bit of the protocol and have its high edge leading directly to the terminal dening the default policy. Thus the BDD will have a shortest path consisting of one edge, that will be taken when the most signicant protocol bit of a packet has the value 1. This result is misleading because, practically, since there are no protocol numbers in use with values 128 or higher [37], this case will never actually occur. In this scenario, if only protocols ICMP, TCP and UDP occur in the trafc, the shortest possible traversable path is of length 4. If all existing protocols are considered, shortest traversable paths of length 2 are possible. Thus the theoretical best case for a BDD can underestimate the actual best case unless only traversable paths are considered in the calculations. Even so, the best case lookup for a BDD has little practical value because it is unlikely to occur often in practice. The reason is that shortest paths often lead to D ENY (the default policy) and packet lters process far more accepted packets than dropped packets under normal conditions, since dropped packets never result in established connections. (An exception to this rule is when the shortest traversable path leads to P ERMIT.) Given this characteristic, the average case lookup should provide a better measure of the efcacy of this approach.

4.2.3 Average Case Analysis

The average case lookup is intended as an indication of how the BDD packet lter will perform in general. Unfortunately, average case analysis is very difcult to perform accurately because, in practice, it depends on many external factors, some of which may be impossible to measure. Average case analysis can be made with respect to a number of different parameters, including the path lengths of the BDD and the set of possible packet headers. Ideally, the average case analysis should be related to the actual trafc ow that the lter would encounter, but it can be difcult (and sometimes impossible) to determine what the actual packets and their frequencies would be.

For the purposes of the experimental work presented in chapters 5 and 6, this research considers two measures of average case. The rst is the average case under normal operation which takes into account actual trafc patterns encountered by the packet lter. This is achieved by using packet traces from the packet lters original network as a sample of typical network trafc that can be expected under normal network conditions. Since packet traces can be difcult to obtain, and since this measure of average case is difcult to analyse and generalise, a second theoretical measure of average case is also used. This measure makes the simplifying assumption that each traversable path through the BDD is equally likely to be chosen during lookup. Thus the theoretical average case is taken with respect to the paths of the BDD and the average case lookup time is then directly proportional to the average traversable path length of the BDD. This is where variable reordering can be useful. Since changing the variable ordering of the BDD changes the shape of the BDD, a variable ordering can be chosen that minimises the average tree depth, and hence the time to perform lookup on average. (This would have to be done using heuristics, since nding optimal orderings for BDDs is known to be NP-complete [5].) To understand some of the pragmatic issues involved when evaluating the average case behaviour of the BDD packet lter, consider once again the two BDDs representing the access list in Figure 4.1. As a rough comparison of these two BDDs with their different variable orderings, Table 4.1 shows the number of edges the lookup algorithm would need to traverse to accept the various classes of packets that are permitted by the access list. As this comparison clearly shows, the original BDD (depicted in Figure 4.2 referred to as BDD 1) results in faster lookup for certain packet types, but there are also packet types for which the second BDD (BDD 2, depicted in Figure 4.3) is faster. Packet Type ICMP from 146.0.0.0/8 ICMP from 109.0.0.0/8 TCP from 146.200.0.0/16 UDP from 146.200.0.0/16 TCP from 109.200.0.0/16 UDP from 109.200.0.0/16 BDD 1 Path Length 16 16 22 20 22 20 BDD 2 Path Length 1724 1724 16 16 16 16

Table 4.1: A comparison of the lengths of paths taken to accept various packets using BDDs with different variable orderings for the access list in Figure 4.1.

BDD 1 has an average traversable path length of 14.23 while BDD 2 has an average traversable path length of 15.47, so according to the assumption made earlier that all paths are equally likely, the former BDD has better average case performance. On closer inspection, it can be seen that of all the packet types accepted by the access list, BDD 1 only performs better on the ICMP packets, whereas BDD 2 performs better on the TCP and UDP packets. Since TCP trafc forms the bulk of typical network trafc

(far more so than ICMP trafc under normal operation), BDD 2 would probably be a better choice in this instance, even though it has the greater average path length. This example shows that true average case performance depends mostly on the actual trafc ow experienced by the packet lter, and this itself could vary from one time period to another. Ideally, the variable ordering for the BDD should be chosen in such a way that the more commonly occurring packet types have shorter paths through the BDD. An even better enhancement would reorder the BDD dynamically from time to time to optimise the BDD lookup through changing trafc patterns. Since the true average case behaviour for a given BDD is difcult to determine analytically, the bulk of the evaluation is done experimentally. More detail regarding this is given in the next two chapters.

4.3 Memory Usage of BDD Representations of Access Lists

The memory usage of BDDs that represent access lists corresponds directly to the number of nodes in the BDD. As shown in Section 4.1, the two main factors affecting the number of nodes in the BDD is the variable ordering and the structure of the rules in the access list. Together, these factors determine to what extent the logic in the rules can be aggregated and subexpressions in the BDD shared by different paths. Referring back to the two BDDs for the example access list, it can be seen that the BDD that has the address variables ordered before the protocol (BDD 2) has far more aggregated expressions than the BDD with the protocol variables ordered rst (BDD 1). This results in a signicantly lower node count of 31 nodes compared to the 46 nodes of BDD 1. Notice also that the average path length of BDD 1 is less than that of BDD 2. This reiterates the fact that there is often a tradeoff between various aspects of the BDD. Variable orderings can be chosen to optimise particular features of the BDD (such as average path length), but often at the expense of others (such as BDD size). In practice, access lists can be expected to have a great deal of similarity between the rules because they typically lter between multiple specic networks, or some specic networks and an unspecied network (like the Internet). Unspecied networks do not need encoding in alternative representations of access lists (including BDDs) and so do not contribute towards the memory requirements. Hosts on a specied network all have the networks address prex as the prex of their IP addresses, which is usually at least 16 bits in length. This contributes greatly to the structure of access lists, thus allowing BDDs to keep their representation compact (if the shared variables appear contiguously in the variable ordering). In general, it is difcult to predict the number of nodes required to represent an access list, although in specic cases, knowledge of the access list structure can help to choose a variable ordering that will keep

the BDD compact. In this research, the evaluation of the memory requirements of the BDD packet lter is done experimentally and is covered in the next chapters. The only requirement is that the BDD size is not exponential in the number of variables, and so, it is worth mentioning at this point that preliminary experimental work in this area has shown extremely promising results in terms of BDD sizes for typical access lists [21].

4.4 Summary of Theoretical Results

In a BDD representation of an access list, the number of variables affects the lookup time, while the number of nodes determines the memory requirements. Both the number of variables and nodes in the BDD are inuenced primarily by the variable ordering of the BDD and the structure of the rules in the access list. For a given access list there is an upper bound on the maximum path length of any BDD representing it equal to the sum of the bits ltered on. This important result means that the worst case lookup is independent of the number of rules in the access list. However, the fact that there is also a lower bound on the maximum path length for a given access list means that the worst case lookup cannot be improved beyond a certain point. While at rst this may seem poor, there is an information-theoretic argument that this is optimal for a given access list and variable ordering, since the lookup never does more work than necessary, and so any other algorithm would have to do at least as much work to make a correct ltering decision. One of the strengths of BDDs as a data structure is that changing the variable ordering of the BDD does not change the semantics. Thus the variable ordering of a BDD representation of an access list can be manipulated to optimise various aspects of the BDD. While the variable ordering has a signicant effect on the size and average case lookup of the BDD, it can probably be used most effectively to improve lookup performance, since the memory requirements of the BDD seem unlikely to be unreasonable. Theoretically speaking, the BDD packet lter is extremely efcient because it never inspects more variables than it needs to make a ltering decision. In practice however, its performance is likely to incur high overhead in a software implementation due to the fact that it operates at the bit level. Bit operations are expensive because they are executed as word operations and so the majority of the processors computing capability is wasted in some sense. The experimental component of this research is intended to explore to what extent this inuences the performance of the BDD packet lter. Furthermore it explores the questions that are difcult to determine analytically, most important of which is the average case lookup performance of the packet lter. Measuring the performance under simulated conditions of real networks provides a good indication of how the BDD packet lter will behave in the real world.

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p7 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p6 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p5 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ICMP aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p4 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p3 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p2 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p1 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p0 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa31 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa30 sa30 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa29 sa29 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 146 109 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa28 sa28 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa27 sa27 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa26 sa26 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa25 sa25 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Proto = ICMP aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa24 sa24 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa sa23 sa31 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 146 aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa sa30 sa30 sa22 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa sa21 sa29 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 109 aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 200 aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa sa28 sa20 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa sa19 sa27 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa sa18 sa26 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa sa17 sa25 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa sa16 sa24 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 0 1

sa29

sa28

sa27

sa26

sa25

sa24

Figure 4.2: BDD 1: Variables representing the protocol appear rst, followed by the variables representing the source address, each from most to least signicant bits. Note that, since only IP trafc is considered as a network-layer protocol, the predicate Proto = IP does not have an explicit encoding in the BDD.

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa31 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa30 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 109 146 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa29 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa28 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa27 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa26 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa25 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa24 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa23 aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa22 aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa sa21 aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa 200 aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa sa20 aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa sa19 aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa sa18 aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa17 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa sa16 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p7 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p6 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ICMP aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p5 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p4 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p3 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p2 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p1 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa p0 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
0 1

sa30

sa29

sa28

sa27

sa26

sa25

sa24

Figure 4.3: BDD 2: Variables representing the source address appear rst, followed by the variables representing the protocol, each from most to least signicant bits.

Chapter 5

Experimental Methodology
Experimental evaluation is the predominant technique used in this research for evaluating the BDD packet lter and fullling the research objectives. To recap, the research objectives include:

Analysing the BDD packet lter in terms of memory usage, and Analysing the BDD packet lter in terms of the time required to perform lookup. This includes best case, worst case and average case performance.

This is achieved by comparing the BDD packet lter to a packet lter that evaluates its rules sequentially. Two sequential packet lters are used for comparison and details regarding these are given later. In order to achieve meaningful and generalisable results, it is important for the experimental methodology to provide an experimental environment that is as realistic as possible. This chapter is devoted to discussing how this is achieved, starting with the overall experimental setup and then investigating its components separately. Section 5.1 introduces the simulation environment in which all the experiments are conducted. This is followed by an explanation of the experimental framework in Section 5.2, which describes how the control and experimental packet lters are integrated into the simulation environment. Section 5.3 then describes issues surrounding the implementation of the control and experimental systems, with Section 5.3.3 dealing with the data structures and algorithms used in this research important contributions in their own right. Next, Section 5.4 discusses how data is used and collected to produce realistic and accurate experimental results. Section 5.5 then concludes the chapter with a summary of important points.

50

5.1 Simulation Environment

In order to simulate real packet ltering scenarios, at least two networks are needed, with one computer capable of routing packets from one network to the other. Although a router often routes and lters packets between more than just two networks, an access list is applied to an individual interface and so a single computer connecting two networks is sufcient to simulate this. The simulation environment uses two computers as depicted in Figure 5.1. One computer has two network cards that provide interfaces to the two networks this machine contains the control and experimental packet lters. The other computer, located on one of the two networks, generates and sends IP packets to the packet ltering machine.

1 0 1 0 11 00 111111 1 000000 11 00 1 0 1 0 1 0 1 1111 0 0000 1 0 1111 0000 1111 0000 1 1111 0 0000 1 1111 0 0000 1 1111 0 0000 1 0

Network A

1 0 1 0 11 00 111111 1 000000 11 00 1 0 1 0 1 0 1 1111 0 0000 1 0 1111 0000 1111 0000 1 1111 0 0000 1 1111 0 0000 1 1111 0 0000 1 0

Network B

Packet Generator

Packet Filter

Figure 5.1: Simulation environment capable of simulating packet ltering between any two networks. The experimental framework on the packet ltering machine, described in detail in the next section, is restricted to low-level (kernel) system calls for experimental timing that can only measure elapsed time. Thus, having a separate computer to generate the packets increases the accuracy of the results. Only the execution time of the lters lookup code is measured, so each measurement indicates how long it took to make a ltering decision. This also ensures that interfering variable delays such as network latency and network card overhead are not included in the experimental results. Using the design in Figure 5.1, with the packet generator on network packets from network to network and the packet lter ltering

, all possible network scenarios can be simulated. For example,

to simulate ltering packets from a large external network (or the Internet) to a small local network, network (and hence the generator) can simulate the external network while network simulates the

internal network. By swapping the roles of these networks, the scenario where an access list lters packets generated in an internal network destined for an external network (such as the Internet), or just another internal network, can be simulated.

5.2 Experimental Framework

The most important feature of the experimental framework is to enable multiple packet lters to be compared accurately. A simple approach would be to simulate packet ltering in user-space. However, since real packet lters operate as part of the kernel for efciency, it was decided that this would be the best approach for the research too. The problem with kernel development is that it is extremely sensitive to software errors and typically difcult to debug. Fortunately, there is an existing packet-manipulation package to make this task easier. Netlter is the ofcial Linux framework for manipulating packets as they traverse through various parts of the networking system [34]. Netlter development began in 1999 on the Linux 2.3 developmental kernels and it was released for general use with the Linux 2.4 stable kernels in early 2001. Built into the framework are applications for packet ltering, masquerading and network address translation, to name a few. Netlter (with its components) was developed with scalability and extensibility as its major design principles, which makes it an ideal platform for integrating new packet ltering code. Iptables is the packet ltering component of Netlter and plays a pivotal role in the integration of the control and experimental systems into the framework.

5.2.1 Control and Experimental Systems

The efcacy of the BDD packet lter is analysed experimentally by comparing it to sequential packet lters. The reason for this is that sequential evaluation of access list rules is still the most commonlyused packet ltering method in production systems. Another reason is that the few commercially-used packages that employ alternative techniques use proprietary software. Two sequential packet ltering implementations are used for comparison. The rst, called the naive packet lter, was written specically for this purpose and has the same functional specication as the BDD packet lter implementation. Its purpose is to provide a comparison of raw performance between the two packet ltering techniques under the same specication. Note that naive in this context refers to its simplicity and absence of unnecessary complexity, and not to efciency in any way. The second sequential packet ltering implementation used for comparison is iptables itself. Its purpose is to provide a measure for how commercially-used sequential packet lters perform compared to the

BDD packet lter. Iptables was chosen for a number of reasons:

It is the most current, freely available and supported packet lter that stores its rules in a linear structure and performs sequential lookups. It has a large user base, since it forms part of the standard Linux distribution. The source code is freely available. This means that its internal data structures and algorithms can be veried. It also allows for experimental modications to the system, such as the insertion of timing code.

Iptables is likely to perform much slower than the naive packet lter because its functional specication is more complicated and because it operates in a modular fashion. Figure 5.2 illustrates how matching on a single rule is carried out in the iptables implementation. Each boxed item in the picture represents a kernel module responsible for performing matching on a single aspect of a network packet. For a given access list rule and incoming packet, any matching criteria in the rule based on the IP header will be checked by the IP module. If this match is successful, any additional matching criteria in the rule will be checked by one of the extension modules. For example, a rule that species a source address, protocol type TCP and source port will have the source address and protocol type tested by the IP module, and the source port tested by the TCP module. Rule matching continues in this way with subsequent rules in the access list until a match is found both IP header testing and extended header testing modules return a match or the rules are exhausted.
IP Header Matching Extended Matching TCP ICMP IP UDP BDD NAIVE

Figure 5.2: The netlter/iptables framework. Each boxed element represents a kernel module. The dashed elements represent the new modules integrated into the framework for experimental purposes.

The netlter/iptables framework provides the ability to integrate new extended-matching modules, which makes it easy to substitute the standard packet ltering process with a new one. By adding a new module, such as a BDD module, to the framework and providing one iptables rule to perform an extended match

using the BDD module only, iptables passes control to the BDD module on arrival of each packet. The naive and BDD packet lters are both implemented as iptables extensions. Collectively, the naive packet lter and iptables form the control system, while the BDD packet lter is the experimental system in this research. Implementation details of the various systems are presented next.

5.3 System Implementation

First, this section discusses the functional specications of the packet lters in this research, as well as some important factors affecting their design and implementation. It then presents the implementations of the BDD and naive packet lters.

5.3.1 Packet Filter Specications

The key requirement of the packet lters used in this research is that they be stateless, meaning that the decision of whether to accept or reject a packet is based on each packet individually, independently from what happened in the past. This forces each lter to invoke its lookup algorithm for every packet. The packet lters are not required to handle fragmented packets since fragmentation can be resolved with caching. Since caching and stateful ltering can be added to any packet ltering implementation, irrespective of its lookup algorithm, it is not of interest to this research. Furthermore, each packet lter must allow ltering of IP packets on the following elds:

Source and destination address(es): Single and multiple aggregated addresses can be specied by supplying a base IP address and associated address mask. Source and destination port numbers: Single numbers and ranges are accepted. Protocol type: This refers to the transport protocol type. Accepted values are TCP, UDP and ICMP.

If any eld is omitted from a rule, it is not used as a criterion for matching. For example, the protocol type can be omitted from a rule for it to apply to a packet with any transport protocol. Finally, each packet lter must support the two actions P ERMIT and D ENY. The iptables implementation meets the criteria specied above and is used unmodied in the experiments, except for the addition of timing code. The fact that iptables offers more than just the functionality necessary for the research is one of the reasons the naive lter is used for comparison as well to

determine to how much better a sequential packet lter dedicated to its limited functionality can perform compared to a large production system.

5.3.2 Factors Affecting Implementation

To understand the implications of the design decisions surrounding the BDD and naive packet lters, it is important to understand how restrictions placed by the TCP/IP model affect networking applications such as these. Since protocols such as IP and TCP have variable length headers, arbitrary bits of information cannot be extracted from the transport layer header or payload by knowing the start address of the packet in memory. In particular, the Linux networking system manages its packets by a doubly-linked list of structures containing pointers to parts of the actual packets in memory [16]. Each structure (called sk buff) contains a set of pointers: one points to the start of the link layer header, another points to the start of the network (IP) layer header, another points to the start of the transport layer header, and so on. Therefore, one of the parameters passed by iptables to an extended-matching module is a pointer to a sk buff structure that provides access to the current packet to be ltered. The implication of this is that packet ltering lookup algorithms can expect to access data in a network packet through at least two pointers in the simplest case the network and transport layer header pointers. In the case of the BDD packet lter, this requires a check for each variable encountered in the BDD to decide from which pointer to nd the corresponding bit of information. More detail is given in the next section.

5.3.3 Experimental System Implementation

The BDD packet lter, integrated into the netlter/iptables framework as an extended-matching module, is a kernel-space implementation of the BDD packet lter. It maintains its own BDD-based data structure for representing the access list rules internally, and has a lookup function M ATCH that interfaces with the framework to perform lookup using its BDD-based representation of the rules. The most straightforward internal BDD representation of the rules is simply the BDD that results from converting the access list as described in Section 3.2.1. This implementation and its associated lookup algorithm are discussed next.

An Initial Approach

This approach uses the BDD in essentially the same form as it is constructed by the BDD package. Even so, some optimisations can be made. BDD packages and applications typically use a number of tables to store and manipulate the BDDs [1]. One table is generally used to hold the BDD node information and, in addition to that, hash tables are used to provide fast access to the BDD nodes to ensure that BDD construction and manipulation can be performed efciently. One of the advantages of the BDD packet lter is that the BDD does not need to be modied once it has been constructed, and the BDD is only constructed once, at the start of the packet lters execution. (There is, of course, the question of access list changes and the possibility of incremental updates to the BDD, but this falls beyond the scope of this research.) The fact that the BDD does not change after its initial construction allows the auxiliary BDD data structures to be discarded and the necessary BDD nodes in the BDD table to be compressed into a small lookup table. Thus the single BDD can be represented in a table that stores the nodes of the BDD. Node information includes the variable that the node represents, as well as the indices of the nodes at the low and high edges. The nodes at indices 0 and 1 are reserved for the respective terminal nodes. Figure 5.3 depicts how a BDD can be represented as a table.
7

x 1
5 6

index 0

var

low

high

x 2
4

x 2 x 3
2 3

1 2 3 4 5 6 4 4 3 2 2 1 1 0 2 4 0 5 0 1 3 0 4 6

x 4 0 1

x 4

Figure 5.3: Representation of a BDD as a two-dimensional lookup table. Each table entry represents the node numbered by the index, shown in the leftmost column for clarity. The second column stores the number of the variable at that node, given by the ordering of the variable in the BDD. The last two columns store the indices of the nodes at the low and high edges of the BDD, respectively.

Given this data structure, the lookup algorithm that decides whether an incoming packet should be accepted or rejected is a specialisation of the algorithm given in Section 3.2.2, that takes into account

the fact that the incoming packet is not in a xed memory location and that a pointer to the structure representing the packet in memory is given. Assume the existence of the following functions:

G ET P TR bdd var

NET TRANS takes a bdd variable and returns NET if the variable corre-

sponds to a bit in the network layer header (IP header), and TRANS if the variable corresponds to a bit in the transport header layer (TCP, UDP or ICMP header).

G ETO FFSET bdd var

takes a bdd variable and returns the bit offset that the variable repre-

sents. The offset is with respect to the pointer type returned by G ET P TR. G ET B IT ptr offset

takes a pointer and an offset and returns the bit value offset bits

from the pointer. The implementation of this function deserves explanation. On a 32-bit operating system, an efcient method of performing this operation is to extract the 32-bit word in which the required bit is located, and perform a bitwise AND with a 32-bit mask whose bits are all zero except for a single bit in the position corresponding to the bit that needs to be extracted. The required bit has the value one if and only if the result of the bitwise AND is non-zero.

The lookup algorithm can then be written as shown in Figure 5.4 on page 58. Some of the inefciencies in this implementation are introduced by the calculation of which pointer should be used, the required word offset and the relatively expensive G ET B IT operation, each of which occur on every iteration. By precomputing some of this data, and storing it with the BDD node, the lookup time can be improved, albeit by a small constant factor. This improvement is discussed next.

A More Optimised Approach

This approach uses the fact the some data calculated during lookup can be precomputed, thus speeding up the execution of the lookup algorithm. Data that can be precomputed for each BDD node includes whether the bit corresponding to the node is located in the network layer header, or transport layer header; the word offset of the corresponding bit from the start of the header; and the mask originally generated by G ET B IT to extract the value of the required bit. Finally, by transforming the BDD table into an array of structures, retrieving an arbitrary data eld in a node is faster (requiring two pointer lookups instead of a pointer lookup and multiplication operation). The precomputed data is stored with the BDD node and so a BDD node can be represented as follows:

function M ATCH (struct sk buff *skb) /* bddtable stores the BDD table for lookup root index indexes the root node in bddtable */ nhp = skb nh thp = skb h /* get network header pointer */ /* get transport header pointer */

bdd index = root index while (bdd index != 0) and (bdd index != 1) ptr = G ET P TR(bddtable[bdd index, var]) offset = G ETO FFSET(bddtable[bdd index, var]) if ptr == NET if G ET B IT(nhp, offset) bdd index = bddtable[bdd index, high] else bdd index = bddtable[bdd index, low] else if ptr == TRANS if G ET B IT(thp, offset) bdd index = bddtable[bdd index, high] else bdd index = bddtable[bdd index, low] return (bdd index == 1 ? permit : deny)

Figure 5.4: The BDD lookup algorithm using the standard BDD representation of the access list compressed into a two-dimensional lookup table.

struct bddnode { u_int16_t ptr_type; /* network ptr, or transport ptr? */

u_int16_t word_offset; /* the word offset of the corresponding bit */ u_int32_t mask; u_int32_t low_index; u_int32_t high_index; }; /* the mask for the GetBit operation */ /* index of node at low edge */ /* index of node at high edge */

Using this data structure, the lookup algorithm requires slight modication. The modied algorithm, shown in Figure 5.5 on page 59, is used in the implementation of the BDD packet lter for the experimentation in this research.

function M ATCH (struct sk buff *skb) /* bddtable stores the BDD array of structs for lookup root index indexes the root node in bddtable */ nhp = skb nh thp = skb h /* get network header pointer */ /* get transport header pointer */

bdd index = root index while (bdd index != 0) and (bdd index != 1) node = bddtable[bdd index] if node ptr type == NET if nhp[node word offset] & node mask bdd index = node high index else bdd index = node low index else if node ptr type == TRANS if thp[node word offset] & node mask bdd index = node high index else bdd index = node low index return (bdd index == 1 ? permit : deny)

Figure 5.5: The BDD lookup algorithm using an array of structures to store the BDD representation of the access list. Each structure stores corresponding BDD node information as well as additional precomputed information to speed up the lookup algorithm.

5.3.4 Control System Implementation

The workings of iptables are briey described Section 5.2.1 and are not discussed further in this section, which concentrates on the naive packet lter implementation. The naive lter, integrated into the netlter/iptables framework as an extended-matching module, is a kernel-space implementation of a standard sequential packet lter. It maintains its own linear data structure for representing the access list rules internally and has a lookup function M ATCH that interfaces with the framework to perform lookup. To keep the structure of the naive lter as close as possible to the BDD lter, its rules are stored in an

array of structures, where each structure represents a single rule and has the following elds:
struct naive_rule { u_int32_t saddr; u_int32_t smask; u_int32_t daddr; u_int32_t dmask; u_int16_t sport_l; u_int16_t sport_h; u_int16_t dport_l; u_int16_t dport_h; u_int8_t u_int8_t protocol; action; /* source address */ /* source address mask */ /* destination address */ /* destination address mask */ /* source port lower bound */ /* source port upper bound */ /* destination port lower bound */ /* destination port upper bound */ /* protocol type */ /* permit or deny */ /* pad to align rules on word boundaries */

u_int16_t pad; };

The M ATCH function then performs the lookup by stepping through the array from beginning to end, until a matching rule is found.

5.4 Experimental Data and Measurement

The previous sections discuss the implementation and integration of the control and experimental packet lters into the simulation environment. This section discusses the remaining elements of the methodology, including the access lists and IP packets used in the experiments, as well as the timing of the lookup for each packet lter implementation. These items are discussed separately.

Access Lists
Since real access lists are highly structured and non-random (one can expect the IP addresses of at least one of the networks a list protects to appear frequently in its rules), it does not make sense to generate articial access lists for use in the experiments for evaluating lookup. While care can be taken to construct true-to-life access lists, it was decided that using real, active lists would produce more convincing results. The exception to this is in the experiments evaluating memory usage where random access lists can provide a measure of worst case performance this is discussed further in the following chapter. Real access lists were obtained from two sources: a university and a local Internet service provider. The university access list provides an example of a list used to control access to networks from any

external networks, including the Internet. The Internet service provider access lists are lists used to control internal network trafc between departmental networks of their large company. For the experiments that determine how a particular characteristic changes with increasing access list length, shorter lists were created by truncating some of the originals at the required lengths (so a list of length would contain the rst rules of the original access list). The reasons for choosing this method of access list generation follow. Firstly, the order of rules in an access list is signicant, so a new access list should keep its rules in the same order as the original. This eliminates the possibility of choosing rules at random for the new list. Secondly, since access lists are generally constructed by hand, it should be assumed that some care was taken in the positioning of the rules in the original lists. So discarding the rst few rules of an original access list could seriously alter the intention of the list. Thus it was decided that this method of access list generation would generate the required data in the most realistic and credible way.

IP Packet Generation
The packet generating machine in the simulation environment can create IP packets in three ways:

Satisfying a Boolean expression. In situations where some specic behaviour must be induced, if packet types causing this behaviour can be described by a Boolean expression over the elds of the packet headers, synthetic packets that satisfy the expression can be generated using this technique. This method of packet generation is particularly useful for testing aspects such as best and worst case behaviour of the control system, since this behaviour can be expressed as a Boolean function for a given access list.

Subject to BDD characteristics. Implementations for determining important BDD features such as longest and shortest paths allow packets to be generated in this way. This method of packet generation is particularly useful for testing aspects such as best and worst case behaviour of the experimental system.

Via packet traces. To recreate actual network trafc that the access lists were subjected to, packets can be generated using packet traces collected from the original environment. Some of the longer access lists provided for this research have associated packet traces that can be used to simulate actual network conditions.

Experimental Timing
For each experiment performed, three sets of timings were collected one from each packet lter: iptables, the naive packet lter and the BDD packet lter. Timing functionality was implemented by inserting the appropriate code into the iptables framework. Measurements record the time elapsed during the execution of each lters lookup code, accurate to the nearest microsecond.

5.5 Summary
The experimental methodology is important in determining the extent to which the results can be generalised. Measures taken to maximise generalisability include the use of real access lists and real packet traces in a dedicated simulation environment. In the experimental evaluation, the efcacy of the BDD approach to packet ltering is evaluated with respect to traditional (sequential) packet lters, in terms of both lookup time and memory usage. The control system offers two points for comparison to the BDD packet lter. The most important is the naive packet lter, since it experiences the same treatment as the BDD packet lter identical functional specications and integration processes into the netlter/iptables framework. Control and experimental systems were installed on the same machine where only the execution times of their lookup processes were measured to prevent interfering events from affecting the results. The details of the experiments and their results are the subject of the following chapter.

Chapter 6

Experimental Results
This chapter covers the results of the experimental evaluation of the BDD packet lter. The experiments and their results are presented, and the results interpreted. Recall from earlier chapters that the evaluation of the BDD packet lter includes an analysis of the memory usage and lookup algorithm time complexity. In this chapter, the terms BDD packet lter (or just BDD lter) and experimental system are used synonymously. The naive and iptables systems are collectively referred to as the control systems, or sequential lters. Some experiments are repeated with different variable orderings for the BDD packet lter. The results obtained are meant as a preliminary investigation into the sensitivity of the BDD packet lter to variable ordering as well as an indication of whether it is worth exploring variable reordering in this context further. As such, the variable orderings used are restricted to a few simple congurations. These, together with their abbreviations, are shown in Table 6.2 on page 64. The system specications of the packet ltering machine in the simulation environment is shown in Table 6.1. Only the specications of this machine are important, since the packet generator does not affect any of the experimental measurements. Processor Memory Operating System Iptables version Language Compiler Pentium II 300 MHz 64 MB Linux 2.3.39 0.1.16 C gcc version egcs-2.91.66

Table 6.1: Experimental system specication.

63

Ordering PDS

Description Protocol-Destination-Source. The variables representing the protocol appear rst, followed by the destination address, destination port, source address and source port. Within each eld, the variables are ordered from the variable representing the most signicant bit to the variable representing the least signicant bit.

PSD

Protocol-Source-Destination. The protocol variables appear rst, followed by the source address and port variables, followed by the destination address and port variables.

PI

Protocol-Interleaved. The protocol variables appear rst, followed by interleaved source and destination addresses the ordering alternates between the two and nally interleaved source and destination ports.

DPS

Destination-Protocol-Source. The destination address and port variables appear rst, followed by the protocol variables, followed by the source address and port variables.

DSP

Destination-Source-Protocol. The destination address and port variables appear rst, followed by the source address and port variables, followed by the protocol variables.

SDP

Source-Destination-Protocol. The source address and port variables appear rst, followed by the destination address and port variables, followed by the protocol variables.

SPD

Source-Protocol-Destination. The source address and port variables appear rst, followed by the protocol variables, followed by the destination address and port variables. Table 6.2: BDD variable orderings used in the experiments.

Experiment Experiment A (section 6.1.1)

Description Memory usage with random data

Aim To determine worst case bounds for the memory requirements of the experimental system as the access list length grows.

Experiment B (section 6.1.2) Experiment C (section 6.2.1)

Memory usage with real data Best case lookup

To determine the expected memory requirements of the experimental system on real access lists. To determine the lookup time of the experimental and control systems in the best case as the access list length grows.

Experiment D (section 6.2.2)

Worst case lookup

To determine the lookup time of the experimental and control systems in the worst case as the access list length grows.

Experiment E (section 6.2.3)

Average case lookup with synthetic data

To determine the lookup time of the experimental and control systems in the theoretical average case as the access list length grows.

Experiment F (section 6.2.4)

Average case lookup with real data

To determine the comparative lookup times of the experimental and control systems in a real environment.

Table 6.3: Overview of experiments to evaluate the memory requirements and lookup performance of the BDD packet lter.

This chapter begins with the experimental evaluation of the BDD packet lters memory requirements in Section 6.1. Next, Section 6.2 covers the experimental evaluation of the BDD packet lters lookup times. An overview of the experiments covered in this chapter is shown in Table 6.3 on page 65. Finally, the results of the experimental work are summarised in Section 6.3.

6.1 Evaluation of Memory Usage

Recall that the memory requirements of an algorithm is a measure of memory usage over and above that required to represent the input. Since a sequential packet lter essentially uses the input (the access list) in an unmodied form, it can be considered to have constant memory requirements. Hence, this section considers only the memory requirements of the BDD packet lter as the input size grows. The metric for memory usage is the number of nodes used in the BDD representation of an access list. The actual storage size is a multiple of the number of nodes the implementation used in this research (as presented in Section 5.3.3) uses 16 bytes per node.

6.1.1 Experiment A: Memory Usage with Random Data

Aim: To determine worst case bounds for the memory requirements of the experimental system as the access list length grows.

Method: This is the only experiment in which articial access lists are used the access lists generated are completely random. Each rule is generated by randomly choosing an action (permit or deny) and a protocol (TCP, UDP or ICMP). Source and destination addresses, and masks are generated as random bit strings of length 32. In the case where TCP or UDP is chosen as the protocol type, source and destination port information is optionally added by rst choosing an operator ( port, port, range low high, or

none) and then generating random 16-bit positive integers for the port numbers where necessary. The use of random access lists serves two purposes. Firstly, it is easy to generate lists of any length, whereas it is harder to nd real access lists above a certain size. Secondly, random access lists have far less structure than real access lists, so this can be though of as eliciting the worst case behaviour of the BDD packet lter with respect to memory usage. (This excludes the possibility of pathological instances which, given that access lists are highly structured in reality, are not of much concern.) Thus, if results from this experiment are reasonable, then the BDD packet lter is likely to behave well in practice. In this experiment, access lists were generated in increasing lengths of 5 rules. For each list size, 100 lists

were generated and their average node count recorded. All the variable orderings appearing in Table 6.2 were used in separate runs of this experiment.

Results: The combined results are shown in Figure 6.1. As can be seen, the variable orderings resulted in two groups of very similar datasets. On closer inspection it can be seen that the orderings which place the protocol variables rst (PDS, PSD and PI) produced the shallower set of curves, while both the source-rst and destination-rst orderings produced the steeper set of curves.
450000 400000 350000 Average BDD Nodes 300000 250000 200000 150000 100000 50000 0 0 100 200 300 400 500 600 Access List Length 700 800 900 DPS DSP PDS PI PSD SDP SPD

Figure 6.1: Node counts of BDD representations of random access lists of increasing lengths, over different variable orderings.

Plotting the logarithm of the node count in each dataset produces logarithmic graphs (not shown in this document) which establishes the node count growth as polynomial rather than exponential in each instance. The set of protocol-rst curves seem best approximated by the quadratic function

. The remaining curves t the function

particularly well which suggests that

these curves grow closer to quadratic than cubic, and in any event all the curves are bounded above by a polynomial function. The largest BDD produced by the protocol-rst orderings has ordering PDS and 362 195 nodes. This translates to approximately 5659 KB of memory for the implementation used in this research. The largest BDD produced by the rest of the orderings has ordering DPS and 564 539 nodes which translates to approximately 8820 KB, or 8.6 MB of memory. These BDDs are representations of access lists with 900 rules.

Interpretation:

Overall, these results are extremely promising since, in general, BDD representations

of Boolean expressions can be exponential in the number of variables in the worst case. The results show that BDD representations of access lists are more likely to be quadratic, even in the worst case where the lists are poorly structured. The split between the protocol-rst orderings and the other variable orderings can be explained with reference to domain knowledge. Since there is only a handful of protocols that an access list can refer to in practice (this research considers three possibilities), placing the protocol information at the top of the BDD has the effect of narrowing the structure, thereby containing the width of the BDD and hence node growth. In contrast, the variables representing the other access list elds can take on all possible values given by those variables. This suggests that choosing a protocol-rst ordering is a good heuristic to reduce BDD size when no other information about the access list is known, or when the list is poorly structured.

6.1.2 Experiment B: Memory Usage with Real Data

Aim: To determine the expected memory requirements of the experimental system on real access lists.

Method: The purpose of this experiment is to determine how the BDD packet lter is likely to behave with respect to its memory requirements in practice. For this, a number of real access lists were collected as described in Section 5.4. The experiments had two parts. The rst involved converting the access lists with no modications into their BDD representations and recording the BDD node sizes. In the second part, the longest access list was split into multiple lists of different lengths by considering the rst rules of the original from to

in increments of ve. The node count of the BDD

representation of each new list was recorded. The objective of this experiment is to give an indication of how the memory requirements of real access lists could grow in practice with increasing list lengths. It is noted that results from this part of the experiment have limited predictive power: a single access list is not representative of all access lists; partitions1 of the access list may not be representative of real access lists and the access list is not long enough to predict trends for longer lists. Nevertheless, it provides an interesting point for comparison to the results obtained in Experiment A. Once again, all the variable orderings appearing in Table 6.2 were used in separate runs of both experiments.
1

Throughout this chapter, partitions of an access list refer to truncations of the list at various lengths, not decomposition

into disjoint sets.

Results: The results for the rst section of the experiment are presented in Table 6.4. Each row represents one access list and shows the number of rules in the access list as well as the number of nodes required by its BDD representation for each of the seven variable orderings used. The nal two columns give the average and standard deviation of the node counts for that row. The results for the second section of the experiment are shown in Figure 6.2. This shows the number of nodes required by access list 8 truncated at various lengths. List 1 2 3 4 5 6 7 8 Length 15 21 24 28 50 81 139 162 DPS 132 409 226 648 412 1024 1485 2482 DSP 132 527 409 592 457 1068 1867 3688 PDS 132 401 339 592 452 1104 1484 2428 PI 132 373 531 1060 1183 1182 3115 3648 PSD 132 336 405 458 747 1016 2043 2955 SDP 132 281 173 458 581 742 1392 3076 SPD 132 318 253 514 727 935 1874 3040 Average Std Dev

132 .00 377 .86 333 .71 617 .43 651 .29 1010 .14 1894 .29 3045 .29

0 .00 80 .09 124 .93 208 .02 292 .96 141 .11 591 .83 497 .29

Table 6.4: Number of BDD nodes required by real access lists of various lengths, over different variable orderings.

4000 3500 3000 2500 2000 1500 1000 500 0 0

DPS DSP PDS PI PSD SDP SPD

BDD Nodes

20

40

60

80 100 Access List Length

120

140

160

Figure 6.2: Node counts of BDD representations of a single real access list truncated at various lengths, over different variable orderings.

Interpretation:

As this experiment clearly shows, results obtained from experiments using real access

lists are not as consistent as those using random data. This strongly supports the point that access lists are far from random in reality. In fact access lists are so context-dependent that two lists with a similar number of rules can behave very differently (as shown by the results in Table 6.4 for lists 3 and 4). Results of this experiment will be discussed with respect to two important aspects: sensitivity to variable ordering and effect of access list length.

Sensitivity to variable ordering: The effect of variable ordering on memory requirements is strongly linked to access list structure. Thus, to make sense of the results in Table 6.4, some knowledge about the access lists themselves is required. Lists 2, 3, 6, 7 and 8 are access lists applied to outgoing interfaces on a router separating internal networks. They specify both source and destination information in many of their rules but, since they typically protect an internal network from multiple other internal networks, predicates involving a small set of source networks appear often. The variable ordering that produces the smallest BDD for each of the abovementioned lists, with the exception of list 8, is SDP. This effect is similar to the one produced by placing the protocol variables rst in the case of random access lists placing the source address bits at the top of the BDD reduces the choice at the beginning and narrows the structure. A similar phenomenon is observed with access list 5. This list controls trafc entering a number of (class C sized) internal networks from the Internet and, unlike the access lists described above, species mostly destination information allowing access to services provided by the internal networks it protects. The destination addresses are all similar since they share the rst 16 to 24 bits and thus, when this destination information is grouped at the top of the BDD, the size of the BDD is reduced. This is supported by the small BDDs produced by the destination-rst orderings. It is interesting to note that, while the protocol-rst variable orderings perform well on the random access lists, they do not outperform many of the other variable orderings on real access lists. This implies that the protocol information does not play an important part on real access lists, suggesting that the addresses themselves provide a lot more structure by which to narrow the BDD than the protocol. Given that the protocol is 8 bits in length and that addresses often share 24 higher-order bits, this is not hard to accept. This explains the particularly poor behaviour of variable ordering PI, which interleaves the source and destination information of the rules, eliminating the possibility of the common address information being shared between rules in the BDD. A nal point worth discussing is that the BDD sizes for access list 1 are not affected by variable ordering. This is once again caused by the structure of the access list. The list consists of 15 rules, no source information is specied in any rule, and all the deny rules appear before all the permit rules. This illustrates that the order in which the actions of the rules appear also has an effect on the size of the BDD, since the order affects the complexity of the Boolean expression that is created,

and this complexity directly affects the BDD size. It is easy to see, for example, that an access list with only permit rules will create a very simple Boolean expression (with the subexpression for each rule separated by disjunctions). Interleaved permit and deny rules cause both conjunctions and disjunctions to be embedded in one another, complicating the nal Boolean expression. Effect of access list length: As illustrated in Figure 6.2, the number of nodes required by an access list grows as the length of the list increases. Although it seems like a straight line could be a good predictor for the graph, there is insufcient data to determine this with condence. What can be seen, however, is that with the real access list the growth is far less than that for random access lists. Table 6.5 tabulates the number of BDD nodes used by access list 8 truncated at various lengths, averaged over the variable orderings compared to the number of nodes required by the random access lists averaged over the protocol-rst orderings. List Length 15 40 65 90 115 135 160 Nodes for Random List 467.75 1486.98 2827.30 4470.24 6517.46 8376.96 11241.21 Nodes for Real List 611.57 1083.14 1526.57 2200.14 2289.57 2582.00 3045.29 Ratio 0.76 1.37 1.82 2.03 2.85 3.24 3.69

Table 6.5: Average number of nodes required by a real access list compared to random access lists at various list lengths.

The node sizes of the BDDs for the real access list are considerably lower than those for the random access lists and this gap increases as the list sizes increase. In fact, the seemingly linear growth of the ratios between the two suggests that the growth depicted in Figure 6.2 could be closer to linear, rather than quadratic.

6.2 Evaluation of Lookup Time

The following experiments provide empirical results for the performance of the BDD lters lookup algorithm. In each experiment, the experimental and control systems were set up concurrently on the packet ltering machine with identical access lists. Each IP packet generated by the packet generating machine was passed, in turn, through each packet ltering system and the time taken to classify the packet by each system was recorded. In the case where only a single system was involved in an experiment, the

second set of timings was discarded. The types of packets that were generated depend on the experiment and so this is discussed separately for each experiment. Each experiment in this section was conducted with two of the access lists used in the previous section. The rst, corresponding to access list 5, is an access list with 50 rules that controls access from the Internet to a few internal networks. In this section, this access list will be termed access list A. The second list, corresponding to access list 8, has 162 rules and controls access into a single network from other networks within the same organisation. This access list will be termed access list B. For experiments that evaluate packet lter behaviour as the access lists grow, smaller lists were created by truncating the original access lists at various lengths. Access list A was partitioned into 10 lists, at increasing intervals of 5 rules. Access list B was partitioned into 16 lists, at increasing intervals of 10 rules.

6.2.1 Experiment C: Best Case Lookup

Aim: To determine the lookup time of the experimental and control systems in the best case as the access list length grows.

Method: The best case for the experimental system occurs when the lookup algorithm traverses a shortest path in the BDD. Recall that this refers to a shortest traversable path in the BDD since some paths refer to invalid protocol numbers or unroutable IP addresses. The best case for the control system occurs when the rst rule in the access list matches the incoming packet. In this experiment, the best case for the experimental and control systems was simulated in two separate runs and IP packets that elicit the best case behaviour in each case were generated synthetically. 10000 packets were generated for each access list on each system, with packet headers chosen randomly from the set of packet headers that elicit best case behaviour. In the case of the experimental system, the experiment was repeated for all seven variable orderings given in Table 6.2.

Results: Best case results for the control and experimental systems are summarised in Figures 6.3 and 6.4 on page 73. Figure 6.3 shows the results of the experiments on access list A and Figure 6.4 shows the results of the experiments on access list B. In these graphs, the BDD lter lookup times over all seven variable orderings are shown as a range of values, bounded above by the maximum times and below by the minimum times. In order to analyse the effect of different variable orderings on the best case lookup time of the BDD lter, shortest traversable path lengths for each partition of the access lists are given in Tables 6.6 and 6.7 on page 74 for access lists A and B respectively.

10 bdd iptables Best Case Lookup (s) 8 naive

10

20 30 Access List A Length

40

50

Figure 6.3: Best case lookup times for access list A truncated at various lengths. The shaded area indicates values between the minimum and maximum lookup times for the experimental system over all variable orderings used.

10 bdd iptables Best Case Lookup (s) 8 naive

20

40

60

80 100 Access List B Length

120

140

160

Figure 6.4: Best case lookup times for access list B truncated at various lengths. The shaded area indicates values between the minimum and maximum lookup times for the experimental system over all variable orderings used.

List length 5 10 15 20 25 30 35 40 45 50

DPS 6 10 10 10 10 10 10 10 10 1

DSP 7 7 7 7 7 7 7 7 7 1

PDS 8 8 8 8 8 8 8 8 8 6

PI 8 8 8 8 8 8 8 8 8 6

PSD 8 8 8 8 8 8 8 8 8 6

SDP 7 7 8 8 8 8 8 8 8 3

SPD 9 9 10 10 10 10 10 10 10 8

Table 6.6: Shortest traversable paths lengths for the BDDs representing access list A, truncated at various lengths, for the given variable orderings.

List length 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 162

DPS 1 1 1 1 9 9 9 9 9 9 9 9 9 9 9 9

DSP 1 1 1 1 9 9 9 9 9 9 9 9 9 9 9 9

PDS 7 7 7 7 10 12 12 12 12 12 12 12 12 12 12 12

PI 7 7 7 7 9 9 9 9 9 9 9 9 9 9 9 9

PSD 7 7 7 7 9 9 9 9 9 9 9 9 9 9 9 9

SDP 3 3 3 3 10 10 10 10 10 10 10 10 10 10 10 10

SPD 8 8 8 8 10 10 10 10 10 10 10 10 10 10 10 10

Table 6.7: Shortest traversable paths lengths for the BDDs representing access list B, truncated at various lengths, for the given variable orderings.

Interpretation:

Figures 6.3 and 6.4 show that the best case lookup times are constant for both iptables

and the naive lter, as expected, with the iptables times a constant factor higher than the naive lters. This clearly illustrates the extra overhead that iptables exhibits compared to the specialised sequential lter built for experimental purposes only. Between the two graphs, the overall times for access list A are notably lower than those for access list B. This is due to the fact that in the best case, the rst rule in the access list is matched, and the rst rule in access list A is much simpler and requires less computation to match than the rst rule in access list B. Clearly the complexity of the rules themselves, and not only access list length, affects lookup times but this less important factor is not examined further in this research. The best case lookup for the BDD lter is directly related to the path length traversed by the lookup algorithm. In this implementation, every path length is at least 1 and less than or equal to 104 (the sum of eld bits allowed in the specication of the rules). Theoretically, it is possible to construct a BDD that has its shortest traversable path equal in length to the sum of the elds ltered on (in this case, the best and worst case would coincide), but this is extremely unlikely in practice because is requires an exhaustive specication of the entire search space which is not possible when ltering between specic networks. Figures 6.3 and 6.4 both suggest that in practice, best case lookup times are likely to be better than those for iptables but worse than those for the naive lter. Looking specically at the BDD lookup times and corresponding minimum path lengths, it can be seen that as the access list length increases, the minimum traversable path length and hence lookup time can increase (as in Figure 6.4) or actually decrease (as in Figure 6.3). Minimum paths lengths are entirely dependent on the access list. Increasing the number of rules in the access list can cause the decision making to become more complex the BDD must inspect more bits in the packet header before a conclusive decision can be made this causes the shortest path length to increase. Alternatively, increasing the number of rule in the access list can relax the decision making such as when a very general rule is introduced that allows the lookup algorithm to escape to a terminal node faster this causes the shortest path length to decrease. Looking at the effect of variable ordering on the shortest traversable path highlights some interesting points. In access lists that specify protocols non-redundantly somewhere in their rules, the protocol-rst orderings cannot produce a BDD with traversable path length less than 4. This is because the 3 most signicant bits of the protocols supported by this application are always 0. Address-rst orderings can do better as can be seen in Tables 6.6 and 6.7.

6.2.2 Experiment D: Worst Case Lookup

Aim: To determine the lookup time of the experimental and control systems in the worst case as the access list length grows.

Method: The worst case for the experimental system occurs when the lookup algorithm traverses a longest path in the BDD. Worst case lookup does not have the same problem as best case lookup in that a longest path in the BDD is always a valid, traversable path (otherwise it would not have been created in the rst place). The worst case for the control system occurs when none of the rules in the access list match the incoming packet, and the packet lter is forced to check all its rules before applying the default policy. In this experiment, the worst case for the experimental and control systems was simulated in two separate runs and IP packets that elicit the worst case behaviour in each case were generated synthetically. 10000 packets were generated for each access list on each system, with packet headers chosen randomly from the set of packet headers that elicit worst case behaviour. In the case of the experimental system, the experiment was repeated for all seven variable orderings given in Table 6.2.

Results: Worst case results for the control and experimental systems are summarised in Figures 6.5 and 6.6 on page 77. Figure 6.5 shows the results of the experiments on access list A and Figure 6.6 shows the results of the experiments on access list B. In these graphs, the BDD lter lookup times over all seven variable orderings are shown as a range of values, bounded above by the maximum times and below by the minimum times. Maximum path lengths for the different variable orderings of the BDDs for access list B and its partitions are shown in Table 6.8 on page 78. These results for access list A are not tabulated because maximum paths lengths for all its BDDs are at their maximum of 104.

Interpretation:

Figures 6.5 and 6.6 both show the linearity of worst case lookup for the control sys-

tems, as expected. Between the two control systems, iptables again has the higher constant factors. The shaded areas of the two graphs show that worst case lookup for the BDD lter is fairly constant. Variations in the lookup times are due to variations in the maximum path lengths, which directly affect lookup. However, the line that denes the maximum lookup times for the experimental system shows the clear constant upper bound on the worst case lookup time when the BDD paths lengths are at their maximum of 104. The points at which the experimental systems and the control systems graphs intersect show at what access list length the former approach becomes faster than the latter under respective worst case con-

30 bdd 25 Worst Case Lookup iptables naive 20

(s)
15 10 5 0 0

10

20 30 Access List A Length

40

50

Figure 6.5: Worst case lookup times for access list A truncated at various lengths. The shaded area indicates values between the minimum and maximum lookup times for the experimental system over all variable orderings used.

70 bdd 60 iptables naive 50 40 30 20 10 0

Worst Case Lookup

(s)

20

40

60

80 100 Access List B Length

120

140

160

Figure 6.6: Worst case lookup times for access list B truncated at various lengths. The shaded area indicates values between the minimum and maximum lookup times for the experimental system over all variable orderings used.

List length 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 162

DPS 104 104 104 104 88 88 88 88 88 88 88 88 88 88 88 88

DSP 104 104 104 104 96 103 103 103 104 104 104 104 104 104 104 104

PDS 104 104 104 104 88 88 88 88 88 88 88 88 88 88 88 88

PI 104 104 104 104 88 88 88 88 88 88 88 88 88 88 88 88

PSD 104 104 104 104 88 88 88 88 88 88 88 88 88 88 88 88

SDP 104 104 104 104 104 104 104 104 104 104 104 104 104 104 104 104

SPD 104 104 104 104 104 104 104 104 104 104 104 104 104 104 104 104

Table 6.8: Longest paths lengths for the BDDs representing access list B, truncated at various lengths, for the given variable orderings.

ditions. In Figure 6.5, the BDD lters worst case lookup is better than that of iptables on a list length greater than somewhere between 9 and 14, depending on the variable ordering chosen. It never intersects with the naive lters graph which means that access list A is too short to make the BDD approach benecial in this instance. However, in the graph in Figure 6.6, the BDD lters worst case lookup surpasses that of iptables at about 20 rules, and also surpasses the naive lters lookup between 78 and 110 rules. Thus, with a good choice of variable ordering, the BDD lter can outperform the naive lters worst case behaviour on access list B on partitions of just under 80 rules in the worst case. Table 6.8 shows the maximum paths lengths of the BDDs representing the partitions of access list B using different variable orderings. This table shows that the maximum path length can vary when different sections of the access list are considered, and also on the same access list for different variable orderings. The table only shows examples of the length decreasing with increasing list length, but the reverse is also possible the only invariant is that the path length can never exceed the sum of the bits of all elds ltered on, which in this case is 104. The reason the maximum path length can increase when more rules are added to the BDD is that an added

rule may make the decision-making more complex and require more header bits to be inspected before a decision can be made. Alternatively, the reason the maximum path can decrease when more rules are added to the BDD is that an added rule may make the decision-making less complex this occurs when new rules allow aggregation between themselves and existing rules so that fewer header bits need to be inspected in total. The important result is that the maximum path can never increase beyond a certain point (as discussed in Section 4.2.1), and this places a constant upper bound on the worst case lookup time.

6.2.3 Experiment E: Average Case Lookup with Synthetic Data

Aim: To determine the lookup time of the experimental and control systems in the theoretical average case as the access list length grows.

Method: This research denes the theoretical average case of the BDD lter with respect to traversable paths and so the average case for the experimental system is the time taken to perform lookup when each traversable path in the BDD is equally likely. The theoretical average case of the control system is taken with respect to the rules and is the time taken to perform lookup when each rule is equally likely to match an incoming packet. Recall (as mentioned in Chapter 4) that the average case lookup should be evaluated with respect to actual trafc ow, so this experiment is intended to determine the behaviour of the control and experimental systems on random data, rather than their actual average case. Combined with the fact that random data for the two systems are generated differently, the results of this experiment are meant to aid the overall analysis by helping to assess the robustness of the other results. In this experiment, the average case for the experimental and control systems was simulated in two separate runs and IP packets that elicit the average case behaviour in each case were generated synthetically. 20000 packets were generated for each access list on each system. For the control system, packets were generated in such a way that they would match rule , where is a number between 1 and the length of the list, chosen randomly each time (matching rule requires that the packet does not match rules

). For the experimental system, packets were generated by picking a path through the access lists
BDD at random, as long as the path was a traversable path. For this system, the experiment was repeated for all seven variable orderings given in Table 6.2.

to

Results: Theoretical average case results for the control and experimental systems are summarised in Figures 6.7 and 6.8 on page 80. Figure 6.7 shows the results of the experiments on access list A and

30 bdd Average Case Lookup (s) 25 iptables naive 20

15

10

10

20 30 Access List A Length

40

50

Figure 6.7: Theoretical average case lookup times for access list A truncated at various lengths. The shaded area indicates values between the minimum and maximum lookup times for the experimental system over all variable orderings used.

70 bdd 60 iptables naive 50 40 30 20 10 0

Average Case Lookup

(s)
0

20

40

60

80 100 Access List B Length

120

140

160

Figure 6.8: Theoretical average case lookup times for access list B truncated at various lengths. The shaded area indicates values between the minimum and maximum lookup times for the experimental system over all variable orderings used.

Figure 6.8 shows the results of the experiments on access list B. In these graphs, the BDD lter lookup times over all seven variable orderings are shown as a range of values, bounded above by the maximum times and below by the minimum times.

Interpretation:

Figures 6.7 and 6.8 show that the average case lookup for the control systems increases

linearly with the number of rules, as expected. Once again, iptables shows higher constant factors than the naive lter. Notice how the gradients of the lines are about half that of the worst case behaviour for both control packet lters this makes sense since the lookup is directly proportional to the number of rules and each rule is equally likely to match an incoming packet. The shaded areas of the two graphs show that the average case lookup for the BDD lter is near constant, with slight deviations up and down with increasing list lengths. The width of the shaded area is relatively thin signicantly thinner than those of the worst case graphs which shows that the average case lookup (as dened for this experiment) is fairly resistant to variable ordering. Also, the average case lookup times lie between those for the best and worst case, but are much closer to the best case times. Comparing the performance of the experimental and control systems suggests that the BDD lter does extremely well in the average case it even outperforms the naive lter at small access list lengths which it does not do in the best or worst cases. However, it is more likely that the average case metric chosen for the BDD lter is too optimistic and that in reality, the longer paths in the BDD are more likely to be traversed than the shorter paths. Intuitively this makes sense because real packets encountered by the access list will in most cases have either source or destination address covered by a rule in the list. The argument is that real packets will tend to match large portions of individual rules in an access list, and thus long BDD path segments, rather than be completely different in structure and terminate the BDD lookup quickly.

6.2.4 Experiment F: Average Case Lookup with Real Data

Aim: To determine the comparative lookup times of the experimental and control systems in a real environment.

Method: In this experiment, packets were generated according to actual packet traces that were collected from the access lists original networks. The packet trace for access list A was created over a period of three days, yielding just over 133000 packets. The packet trace for access list B was created by sampling packets from the network at various times of the day for two days, resulting in just under 30000 packets. Both traces were generated during normal working days under normal conditions to obtain data

that was representative of the trafc encountered on those networks at the time. The focus of this experiment was in testing the control and experimental systems with the two complete access lists and their respective packet traces. In addition, however, this experiment was repeated on all partitions of the two access lists to determine the effect on the packet lters when the assumptions of experiment E are eliminated in favour of real trafc. Once again, each part of this experiment was repeated for all seven BDD variable orderings given in Table 6.2.

Results: The results for the control and experimental systems using the packet traces on all partitions of the access lists are summarised in Figures 6.9 and 6.10 on page 83. Figure 6.9 shows the average lookup times for access list A, while Figure 6.10 shows the average lookup times for access list B. In these graphs, the BDD lter lookup times over all seven variable orderings are shown as a range of values, bounded above by the maximum times and below by the minimum times. The results of the experiments on the complete access lists are presented in various ways. First, frequency distributions of lookup times for access lists A and B are given on page 84 in Figures 6.11 and 6.12 respectively. Secondly, these frequency distributions are represented cumulatively over lookup time on page 85 in Figures 6.13 and 6.14 for access lists A and B respectively. Note that although these gures should be represented graphically as histograms, they are shown as continuous functions to aid readability. Also, for clarity, these gures show only the results for the naive lter and the BDD lter with the variable ordering that produced the lowest average lookup time. The complete gures that include the results for iptables and the BDD lter with the variable ordering that produced the highest average lookup time can be found in Appendix B. Also, summary information for this experiment for each variable ordering is given on page 86 in Tables 6.9 and 6.10 for access lists A and B respectively. This information includes the average, 95th percentile and standard deviation of all lookup times corresponding to the packets in the packet trace. Note that new values for the control systems were obtained for each variable ordering and that, although this is not strictly necessary, it does provide reassurance that network conditions were consistent during each run of the experiment.

Interpretation:

The effect of access list length on lookup in real environments is discussed rst, with

reference to Figures 6.9 and 6.10 on page 83. In both graphs, iptables and the naive lter show identical behaviour with iptables slower by a constant factor. The graph for access list A shows, for the control systems, the traditional linear increase in lookup times with increasing list size. However, this increase is actually greater than the increase observed in the theoretical average case experiment (see Figure 6.7) which suggests that packets in the trace match the

30 bdd Average Lookup Time (s) 25 iptables naive 20

15

10

10

20 30 Access List A Length

40

50

Figure 6.9: Average lookup times for access list A truncated at various lengths, with packets generated from a packet trace. The shaded area indicates values between the minimum and maximum lookup times for the experimental system over all variable orderings used.

70 bdd 60 Average Lookup Time (s) 50 40 30 20 10 0 iptables naive

20

40

60

80 100 Access List B Length

120

140

160

Figure 6.10: Average lookup times for access list B truncated at various lengths, with packets generated from a packet trace. The shaded area indicates values between the minimum and maximum lookup times for the experimental system over all variable orderings used.

60 naive bdd min Access List A - Packets Classified (%) 50

40

30

20

10

10

15

20 25 30 Lookup Time (s)

35

40

45

Figure 6.11: Frequency distribution of lookup times for access list A, with packets generated from a packet trace. Represented systems include the naive lter and BDD lter with the variable ordering that produced the best results with respect to average lookup time.

45 40 Access List B - Packets Classified (%) 35 30 25 20 15 10 5 0 0 5 10 15 20 25 30 Lookup Time (s) 35 40 45 naive bdd min

Figure 6.12: Frequency distribution of lookup times for access list B, with packets generated from a packet trace. Represented systems include the naive lter and BDD lter with the variable ordering that produced the best results with respect to average lookup time.

Access List A - Cumulative Packets Classified (%)

100 naive bdd min 80

60

40

20

10

15

20 25 30 Lookup Time (s)

35

40

45

Figure 6.13: Cumulative frequency distribution of lookup times for access list A, with packets generated from a packet trace. Represented systems include the naive lter and BDD lter with the variable ordering that produced the best results with respect to average lookup time.

Access List B - Cumulative Packets Classified (%)

100 naive bdd min 80

60

40

20

10

15

20 25 30 Lookup Time (s)

35

40

45

Figure 6.14: Cumulative frequency distribution of lookup times for access list B, with packets generated from a packet trace. Represented systems include the naive lter and BDD lter with the variable ordering that produced the best results with respect to average lookup time.

Parameter Average lookup time per packet ( iptables naive bdd iptables naive bdd iptables naive bdd

DPS 20.51 5.52 4.31 28 8 6 10.05 2.44 0.89

DSP

PDS 20.60 5.46 4.65 28 8 6 10.12 2.39 1.24

PI 20.61 5.48 6.19 28 8 8 10.18 2.40 1.62

PSD 20.82 5.52 6.11 29 8 8 10.23 2.44 1.74

SDP 20.72 5.67 6.34 28 8 7 10.22 2.47 0.91

SPD

20 .59 5 .51 4 .22 28 8 6 10 .12 2 .44 1 .11

20 .79 5 .52 6 .77 29 8 8 10 .23 2 .44 1 .45

Interval in which 95% of packets classied (

Lookup time standard deviation

Table 6.9: Some experimental results for the experiment using access list A (entire list) and real packet traces, over all variable orderings. While different variable orderings do not affect the control systems, DSP gives the best results for the BDD lter, while SPD gives the poorest results. The BDD results for the former variable ordering are plotted in Figures 6.11 and 6.13.

Parameter Average lookup time per packet ( iptables naive bdd iptables naive bdd iptables naive bdd

DPS 28.17 6.95 6.35 35 9 8 9.35 2.54 1.15

DSP 28.03 6.76 6.96 35 9 9 9.85 2.22 1.28

PDS 28.11 6.84 6.80 35 9 8 9.31 2.27 1.32

PI

PSD 28.03 6.78 6.33 35 9 8 9.39 2.21 1.64

SDP

SPD 28.79 6.79 7.08 37 9 9 10.20 2.32 1.50

28 .27 6 .75 6 .20 35 9 8 9 .43 2 .21 1 .45

28 .04 6 .88 7 .33 35 9 9 9 .15 2 .50 1 .35

Interval in which 95% of packets classied (

Lookup time standard deviation

Table 6.10: Some experimental results for the experiment using access list B (entire list) and real packet traces, over all variable orderings. While different variable orderings do not affect the control systems, PI gives the best results for the BDD lter, while SDP gives the poorest results. The BDD results for the former variable ordering are plotted in Figures 6.12 and 6.14.

rules in the second half of the complete list more often than rules in the rst half. In contrast, the graph for access list B shows a linear increase at rst, followed by a levelling-out, resulting in performance much better than in the theoretical average case experiment (Figure 6.8). In this case, the packets in the trace tend to match rules earlier on in list, so that the addition of rules 90 onwards have little effect on the average lookup time of the control systems. (Access list B is a good example of a list well-tuned for sequential lookup.) In both instances, the experimental packet lter produced its traditional range of fairly constant lookup times with increasing list length. However, the constant factor is higher than that in the theoretical average case experiment (Figures 6.7 and 6.8) as anticipated by the fact that the assumption made by that experiment is overly optimistic. Again, thin bands in these graphs indicate the BDD lters robustness to variable ordering. Note that the minimum line in the band gives the minimum average lookup time for some variable ordering, which may (and does) differ for different access list lengths. What this means is that a good variable ordering can usually be found, but that nding it may require some work. (Encouraging news is that good variable orderings were found for the important experiments in this research amongst just seven orderings.) Next, in comparing the experimental and control systems, the graph for access list A shows that the BDD lter outperforms iptables on all list lengths, while it only begins to compete with the naive lter at approximately 47 rules, with some variable ordering. Thus, the BDD approach becomes benecial at this length on a network with similar trafc and access list structure. The same experiment on access list B also results in the BDD lter outperforming iptables on all access list lengths. However, this time there are variable orderings that make the BDD approach preferable to the naive lter at approximately 43 rules (which is a much smaller fraction of the lists size). From this point onwards, the naive lters and BDD lters averages on all variable orderings are very close. Unfortunately for the BDD lter, this result does not mirror the results of the theoretical average case and is due to the theoretical assumption of each rule in the access list being equally likely to match an incoming packet not holding in this case. The results of experiment E suggest that the lookup times for the control systems should continue to grow at the point of intersection, and that the BDD lter should outperform the naive packet lter regardless of variable ordering. This is not the case here, because the majority of packets in the trace still match on rules early on in the list, even when the longer lists are used. However, given that the well-tuned access list causes the control system to perform better than it should, the BDD lters average lookup times are very close to those of the naive lter for list lengths above 43, and there is always a variable ordering that allows the BDD lter to outperform the naive lter beyond this point. The next set of important results which determines how the BDD lter compares with the sequential

lters in a real environment is obtained by looking only at the complete access lists and how classication occurs on packets obtained from the traces. This is the focus of the remainder of this section, with particular reference to Figures 6.11, 6.12, 6.13 and 6.14 on pages 84 and 85. An important characteristic worth noting, that is only obvious in the versions of these gures in Appendix B, is that iptables and the naive lter have similarly-shaped graphs, with the one offset from the other. The same is true for the graphs of the BDD lter with best and worst variable orderings. This effect, due to constant factors, is expected. Thus, the areas that receive the most attention in this discussion are the results for naive lter and the BDD lter with best variable ordering (the best variable ordering in this context is the variable ordering that results in the lowest average lookup time). Unless mentioned otherwise, the BDD results in the discussion that follows refer to the BDD results for the best variable ordering. For both access lists A and B, the resulting frequency distributions (Figures 6.11 and 6.12) show two peaks in the distribution for the naive lter, while the BDD lter has one large peak in the center. Multiple peaks in the lookup time distributions for sequential lters is quite common and occurs when a rule (or group of closely situated rules) dominate the classication of a large part of the trafc. For example, access list A has its rst rule accept all ICMP trafc, which accounts for the small peak at approximately 2

in Figure 6.11. In contrast, the BDD lter is prone to generating a unimodal distribution because the

BDD representation makes the amount of work required to classify packets very similar across different packet types. (This effect is evident in the small standard deviations the BDD lter experiences compared to the sequential lters, as shown in Tables 6.9 and 6.10.) This makes the BDD lter extremely consistent in terms of lookup times. The fact that the BDD lters peak occurs between the two peaks of the naive lter (on both access lists) means that while the BDD lter is slower than the naive lter at classifying certain types of packets, it is faster at classifying others, and in both cases, the average lookup times for the BDD lter are less than those for the naive lter. The variable orderings that produced these results were DSP for access list A and PI for access list B. The variable ordering that produced the worst results for the BDD lter was SPD for access list A and SDP for access list B. The peaks produced by these variable orderings in their respective graphs are not that far off from those of the naive and BDD lter with best variable ordering, but are far enough away to make their average lookup times higher than the naive lters in both cases. Graphs showing the cumulative distributions of the lookup times Figure 6.13 for access list A and Figure 6.14 for access list B illustrate how quickly the different packet lters can classify all the packets. Of particular interest is the 95th percentile, which describes at what lookup time bound, 95% of all packets can be classied by a given packet lter on a particular set of packets. Both access lists result in similar behaviour in this respect: the naive lter has the fastest cumulative growth initially

this coincides with the rst peak observed in each frequency distribution graph and is soon overtaken by the BDD lter with best variable ordering, which reaches its 95th percentile rst, followed closely by the naive lter and the BDD lter with worst variable ordering. Tables 6.9 and 6.10 on page 86 give the actual 95th percentile gures. Tables 6.9 and 6.10 also allow some analysis of the effect of variable ordering on lookup times when real data is involved. The results obtained for the BDD lter do not differ dramatically amongst the variable orderings used which suggests that this approach is fairly robust with respect to variable ordering. For both access lists, there are some variable orderings that produce better average lookup times compared to the naive lter, as well as variable orderings that produce worse average lookup times. But even the variable orderings with the worst average lookup times do not produce bad results: the BDD lters 95th percentiles are never worse than the naive lters in these two cases and are better for more than half of the variable orderings used. However, variables orderings that produce good (or bad) results are not the same across the two access lists, and so the choice of good variable orderings is list dependent. It must be stressed that the results for access list B, given its length, would have been signicantly better if there was a more even distribution of matching rules. In fact, if the distribution was even, the BDD lters averages would have been signicantly lower than the naive lters for all the variable orderings. This shows that true performance relies heavily on actual trafc patterns.

6.3 Summary of Experimental Results

The previous sections present experimental work evaluating the memory requirements and lookup performance of the BDD packet lter compared to packet lters that perform lookup sequentially. The results of the experiments to evaluate memory usage are summarised below:

The sizes of BDD representations of access lists are likely to grow quadratically with access list length in the worst case where the lists are poorly structured. In general, BDD representations of real access lists have much smaller BDDs than random access lists.

BDD representations of real access lists are more sensitive to variable ordering than those of random access lists. Where no prior information about the access list is known, or if the list is poorly structured, a protocol-rst variable ordering is a good heuristic for reducing BDD size.

Good variable orderings for reducing the BDD size of a given access list are strongly dependent on the structure of the access list. The greatest reduction in size occurs when the longest and most common subexpressions in the rules are placed at the top of the BDD. This has the effect of narrowing the BDD by reducing the number of choices at the start.

Increasing access list lengths and complexity increases the number of nodes in the BDD. Complexity refers to the amount of information specied in the rules as well as how the rules interrelate. Conversely, reduced complexity and ability to aggregate common subexpressions decreases the number of nodes in the BDD.

The salient points of the comparisons of best, worst and average case lookup can be summarised as follows:

Iptables has high overhead due to its design and implementation, making it not as good for comparison to the BDD packet lter as the naive lter. Iptables can only outperform the BDD lter on small access lists or longer access lists with unusual packet distributions.

In the best case, both the control systems and experimental systems lookup remains fairly constant, with the BDD lter experiencing a higher constant factor than the naive lter in general. Occasionally, there are orderings that produce better results for the BDD lter compared to the naive lter in their respective best cases.

In the worst case, lookup times for the BDD lter are fairly constant, while the control systems lookup times grow linearly with access list length. An intersection of the two curves indicates the access list length at which the BDD approach begins to outperform the sequential one when both exhibit worst performance. The point at which this occurs depends on the complexity of the access list and the variable ordering used.

In the average case, lookup times for control and experimental systems are similar to that of the worst case with lower constant factors for all packet lters. Again, an intersection of the BDD and a control system curve indicates the access list length at which the BDD approach begins to outperform the sequential one when both exhibit average case performance. This depends on the complexity of the access list and the variable ordering used.

Best, worst and average case lookup of the BDD lter with increasing access list lengths are all fairly constant, subject to small variations caused by changes in path lengths, but always bounded above by a constant worst case corresponding to the number of variables in the BDD. In general, the best case performance is notably lower than the worst case performance, with the theoretical average case close to the best case, and the actual average case closer to the middle.

The BDD lter produces fairly constant lookup times in the best, worst and average cases for a given set of ltering elds. Fluctuations in the lookup times in all three cases are caused by changes in variable orderings as well as structural differences in the access lists used. Both factors affect lookup by creating different minimum, maximum and average path lengths.

Variable orderings that produce special behaviour (such as longest or shortest paths, and minimal memory usage) are not consistent between different partitions of the same access list, although sometimes there is a trend towards a well-behaved ordering. Even when this is the case, the choice of good variable ordering is access list dependent.

In the case where real network trafc is used, the effect on the BDD lter is an increase of the theoretical average case by a constant factor. This suggests that in reality, the longer paths through the BDD are more likely to be traversed by the lookup algorithm than the shorter paths. The effect of real trafc on the control systems is determined by the frequency distribution of rules matching the packets: If the distribution favours rules closer to the end of the list, the linear growth in lookup times with access list length is steeper than in the theoretical average case. If the distribution favours rules closer to the start of the list, the linear growth in lookup times with access list length is less than in the theoretical average case, and will approach a constant value. The benet of the BDD approach over the sequential approach depends on the complexity of the access list, variable ordering used and trafc patterns.

In a real environment, the BDD lter tends to produce a unimodal distribution of lookup times, while the sequential lters are more prone to multimodal distributions. In the experiments simulating real networks with packet traces, the BDD packet lter proved to be a benecial approach to ltering on access lists longer than 47 rules on access list A, and 43 rules on access list B. Since access lists on important routers often contain hundreds of rules, this suggests that the BDD approach is an improvement on the traditional sequential approach in many real situations.

This concludes the summary of the important results of the experimental work. The extent to which these results can be generalised is the focus of the next chapter, which also discusses broader issues regarding the expected use and performance of the BDD packet lter.

Chapter 7

Discussion
The preceding chapters present both analytical and empirical evaluations of the BDD packet lter. This chapter presents a discussion of the results in terms of issues such as applicability and utilisation. Section 7.1 rst presents a discussion of the experimental results, and revisits the alternative approaches to packet ltering for comparison to the BDD approach. Section 7.2 then investigates issues relating to the use of the BDD packet lter in real networks and environments. The important research results, as well as issues raised in this chapter, are then summarised and used to direct ideas for future work in Section 7.3.

7.1 Discussion of Experimental Results

This section discusses some of the experimental results of this research. The discussion begins in Section 7.1.1 with a case for the generalisability of the experimental results. This is important in providing the ability to reason about the behaviour of the BDD packet lter on other access list, in other networks. Following this, Section 7.1.2 deals with important issues relating to the BDD lters lookup algorithms time complexity while the relationship between memory, lookup time and variable ordering is examined in Section 7.1.3. Finally, Section 7.1.4 presents an informal comparison between the BDD approach and the other approaches to packet ltering and classication presented in Chapter 2, in terms of the experimental results of the previous chapter.

7.1.1 On External Validity

The section justies the extent to which the experimental results presented in this research can be generalised. It discusses issues that may threaten external validity in terms of the data used in the experiments. 92

The Simulation Environment

The experiments simulated two different network environments (as

dictated by the origin of the access lists). The rst, corresponding to access list A, simulates access control to a group of networks from all other networks. The second, corresponding to access list B, simulates access control between internal networks within an organisation. The differences in the access lists due to these environments is that the rules of access list A specify destination information frequently compared to source information while access list Bs rules specify source and destination information fairly evenly. It can be argued that these two environments are representative of most packet ltering environments because the rules of an access list correspond to a security policy of source-destination pairs, so at least one of source or destination information should occur frequently in an access list. Also, the results in the lookup time experiments using the synthetically generated packets are consistent across the two access lists. This suggests that differences in packet ltering environments (such as number and sizes of networks involved, direction of ltered trafc and security policies) would not alter results signicantly.

The Access Lists The question to be asked is how the representative the access lists used in the experiments are. The issue of rule specicity the structure of individual rules is covered in the point above. Another aspect which affects results is that of rule positioning. The experiments using the packet traces showed that access list A is not well-tuned for sequential lookup while access list B is, with respect to the types of packets they encounter. The effect of these access lists on lookup time is most clearly visible in Figures 6.9 and 6.10 on page 83. The fact that these two access lists represent extremes in this respect is good for generalisability because their results provide bounds for expected behaviour on unseen access lists. Access list A produces results that are optimistic for the BDD lter while access list B produces results that are pessimistic. In reality, other access lists are likely to produce results that fall somewhere between the two.

The Packet Traces

The traces were created to be as representative of their networks trafc as possible,

and were collected during normal working hours over a number of working days. The effect of a different or abnormal distribution of trafc can be described in terms of the positioning of the rules in the access list, which is dealt with in the point above. The discussion above argues that the simulations in the experiments are highly representative of most real packet ltering situations. Moreover, the results obtained from experiments on synthetic data set bounds on possible behaviour. In particular, the bounds dictated by the best and worst case lookup performance of the BDD packet lter limit the extent to which unseen access lists and different networks can affect performance.

The remainder of this section discusses some BDD packet lter characteristics that can be generalised from the experimental results.

7.1.2 Lookup Time Characteristics

The frequencies of lookup times for the BDD packet lter on a given access list are consistently close together and form a unimodal distribution. Thus the lookup times on a range of packets do not vary much, regardless of the rule they match in the original access list. Compare this to the sequential packet lters whose range of lookup times is much larger, and unbounded in theory. This unimodal distribution is caused by the fact that the best and worst case performance of the BDD lters lookup algorithm are reasonably close together. An advantage of this is that it makes the BDD approach extremely robust with respect to its input, and effectively removes the effect that rule positioning and access list length have on traditional packet lters. The characteristic of small deviations in lookup time is good when the aim is to minimise lookup over all packets. However, it is conceivable that a scenario exists in which certain common packet types must be classied quickly at the expense of other less frequently occurring types. Thus, a disadvantage of the BDD approach is that its best case performance suffers from high overheads which means that it is not always the better option. In particular, short access lists and lists where the rst few rules match most often are not good candidates for the BDD approach. The variable ordering of the BDD inuences the mode of lookup time frequencies different variable orderings shift the mode in small amounts, affecting the overall average lookup time. Thus when the average lookup times of the BDD lter and a sequential lter are similar, putting effort into choosing a variable ordering that results in good lookup performance for the BDD lter is justied. When the distribution of rules matching packets is uniform, the performance of the BDD lter over sequential lters improves with increasing access list lengths (actually, the BDD performance stays constant while the sequential lter performance degrades). In this situation, the BDD approach only becomes benecial when the access list becomes long enough, and the average lookup times of both lters are similar. The length at which this occurs depends on the variable ordering. If the access list length grows beyond this point, the BDD lter will eventually outperform the sequential lter on all variable orderings.

7.1.3 Space, Time and Variable Ordering

The memory requirements of the BDD packet lter, its lookup times and its variable orderings are not independent concepts, but inuence one another in interesting ways. This section attempts to use the

knowledge acquired from the research results to argue more general aspects regarding the interrelatedness of these three concepts, particularly as they relate to prediction and tradeoffs. Some interesting questions are presented below:

What effect would variable orderings not considered in this research have on lookup and memory? The seven variable orderings used were not picked randomly from the set of possible orderings, but were chosen in an intuitive manner. The fact that octets in packets headers appear contiguously in the variable orderings (for example, the protocol bits always appear together in the variable orderings used) plays an active role in reducing both memory usage and lookup times. There is a chance that all seven variable orderings are good candidates for this application. However, in terms of lookup, all variable orderings would still obey the worst case lookup bound that is dependent on the access list and independent of the variable ordering. A poor variable ordering would have the effect of pushing the average case performance closer to the worst case, which would increase the average case lookup by a constant factor. In terms of memory, a poor variable ordering would result in requirements of the BDD being polynomial (most likely quadratic) in relation to access list length. This follows from the fact that random access lists on the known variable orderings produce quadratic memory requirements, and the effect of random lists on memory is the prevention of sharing common subexpressions in the BDD.

Given an access list and a set of variable orderings, can the ordering that produces the lowest memory usage, or lowest average lookup time on real trafc, be predicted? The experiments show that variable orderings that produce the best lookup times and / or memory usage differ on different partitions of the same access list. On this micro-level, the BDD can be quite sensitive to the variable ordering used, and the process that causes these slight changes is not obvious. However, in terms of memory usage, the fact that for a given access list there are reasonable explanations for why certain variable orderings result in smaller BDDs than others, suggests that there could be an algorithm, or at least a heuristic, capable of choosing a good variable ordering for BDD size. In terms of lookup, a good variable ordering is dependent on the actual trafc. Thus the best variable ordering cannot be predicted without prior knowledge of the trafc patterns. This suggests that there is scope for a packet lter that can dynamically reorder its variables based on its access list and the most recently encountered packet types.

To what extent does the BDD packet lter exhibit a space-time tradeoff? Different variable orderings change both the memory and lookup performance of the BDD lter. However, this tradeoff is not at its extreme a variable ordering that provides the best average case lookup amongst a

set of variable orderings does not necessarily result in a BDD that requires the most memory. In fact, a comparison between memory and lookup produces extremely varied results when all cases of lookup are considered (best, worst, average, and average case with packet traces). Thus the experimental results suggest no causal relationship between lookup time and memory usage. Given this, since the experiments show that the memory requirement of the BDD lter are likely to be reasonable regardless of the variable ordering chosen, it seems more worthwhile to choose a variable ordering that optimises lookup, rather than memory usage.

7.1.4 Comparison to Other Approaches

The most successful packet ltering techniques published make use of the structure of access lists to create data structures that provide fast lookup. As a result, these techniques perform well on access lists that are well structured but experience degraded time or memory performance when their access lists are not ideal. RFC and cross-producting are examples of approaches that suffer from memory problems, while the tuple space search has a lookup algorithm that degrades to that of a sequential lter under bad conditions. One of the strengths of the BDD approach, in comparison, is that it is less dependent on good access list structure for good performance. While structure does indeed help, the difference in the performance of the BDD lter between structured and unstructured access lists is not as signicant as the differences in some of the approaches mentioned above. More importantly, the BDD lters performance is never degraded by badly behaved access lists or network trafc to the point where it is unusable. The BDD approach is most similar to the parse table and grid of tries methods in that they perform lookup at the bit-level. The lookup time complexity of the parsing method is the grid of tries approach is

while the complexity for

, where is the dimensionality of the lter and is the maximum bit

size of the elds of the lter. Since the grid of tries lters on a maximum of two elds, these complexities are equivalent in some sense. The BDD lters time complexity can be stated as represents ltering eld . This is equivalent to

where

. However, the BDD approach is faster than the

parsing method since it provides more control over the order in which bits in the packet are inspected, while avoiding redundant checks. It is stronger than the grid of tries approach in that it handles any number of ltering elds. A comparison that is not possible to make is how CFGs compare with BDDs for lookup. CFGs are similar in nature in that they are graph structures that eliminate redundant nodes. The difference is that nodes of a CFG test whole Boolean predicates instead of single bits, thus eliminating the overhead of expensive bit computations. An experimental comparison between these two approaches would be interesting.

As mentioned previously, techniques for packet ltering and classication are subject to a tradeoff between space and time. At the extremes, methods exist that provide constant memory requirements with linear time complexity, and constant time complexity with exponential memory requirements. In this regard, the BDD approach offers an elegant tradeoff that is reasonable in both space and time complexity.

7.2 Practical Aspects of the BDD Packet Filter

This section discusses issues pertaining to the use of the BDD packet lter in the real world. Section 7.2.1 examines the effect of, and choice issues relating to, various characteristics of the BDD packet lter. These issues are central to this discussion since knowing the effect of network conditions and system parameters on the BDD packet lter is essential for the ability to choose between alternatives. Section 7.2.2 then investigates user expertise requirements in using different packet ltering approaches.

7.2.1 On the Characteristics of the BDD Packet Filter

The BDD packet lter has characteristics that make it a benecial approach in certain situations. This section attempts to highlight some factors that affect its use. The characteristics considered are:

Lookup performance. As mentioned previously, the high overhead of the BDD packet lter limits its use to packet lters with long access lists, such as those normally found on core and border routers. Shorter lists and lists where the majority of trafc matches rules that appear early in the list are more suited to traditional approaches such as a sequential packet lter, whose overhead is much smaller by nature. Experimental results show that the BDD approach can give better results than the sequential approach on access lists of just under 50 rules and above. While this number depends on the access list, trafc distribution and variable ordering used by the BDD packet lter, it can be used as a guideline for when to consider this approach. Due to its bit-level optimisation and support for multiple elds, the BDD approach is preferable to other bit-level ltering techniques such as parsing and the grid of tries approach. Of the graphbased techniques, the most successful approach seems to be the CFG representation which uses predicates instead of single-variable tests at each node. Since this approach also removes redundant computations (at the predicate level), there is a chance that it could outperform the BDD approach in terms of lookup time but there is insufcient evidence to decide this conclusively. There is also no indication of the space complexity of CFGs, which could render them unusable in certain situations. Other approaches such as RFC, cross-producting and the tuple space search may also outperform the BDD approach in terms of lookup time, but this depends on the access list and

actual trafc encountered since these approaches rely on structure in the access lists for good lookup performance.

Sensitivity to access list structure. One of the strong characteristics of the BDD approach is that it is much less sensitive to rule structure than most of the successful alternative approaches. Good access list structure does reduce the memory usage and lookup time of the BDD packet lter, but poor rule structure does not render the approach unusable. In that respect, the BDD approach is fairly robust with respect to both memory usage and lookup performance. This makes it particularly benecial for use in situations where good access list structure is not guaranteed, the access list changes fairly often, or where memory is a concern and good memory performance is essential. In these situations, the robust space-time tradeoff of the BDD approach makes it an extremely safe bet.

Other characteristics. Some other features that are inherent in the BDD approach are its support for non-contiguous masks, as well as consistently low deviations in lookup times on a given access list. While sequential packet lters can support non-contiguous masks in theory, some of the alternative approaches cannot. Situations in which support for non-contiguous masks could be useful include setups in which there is a correlation between the security policy and some pattern in the corresponding IP addresses. An example is applying a security policy to odd-numbered computers in a lab. The small deviations in lookup times mean that the BDD packet lter is a robust packet ltering approach in terms of lookup performance. Coupled with the xed maximum bound it provides for a given access list, the BDD packet lter can be used to guarantee service levels. On busy or bursty networks where speed and low latency are critical, the BDD packet lter is an extremely reliable choice.

7.2.2 On User Expertise

Both sequential lters and the BDD lter depend on user expertise to optimise their performance. Tuning an access list for sequential lookup requires extremely skilled people, since reordering rules in a list is difcult and error-prone. One of the major advantages that the BDD approach offers is due to the fact that the BDD representation of an access list is canonical for a given variable ordering. This effectively removes the traditional sensitivity of rule ordering on lookup performance and gives the network administrator the freedom to write access lists for readability, thereby improving the chances of correctness. The BDD packet lter, however, also currently requires some user expertise in the choice of good variable orderings. While a poor choice of variable ordering will not degrade the system as badly as a poorly structured access list can for sequential lters, a good variable ordering can have a signicant effect

on lookup performance and is therefore worth putting some effort into nding. Experimental results suggest that the variable orderings used in this research offer a good variety from which to pick and that variable orderings not considered in this research will probably not offer any signicant benets. Still, choosing one variable ordering from seven requires some work. Since there are currently no heuristics or algorithms for choosing a variable ordering to minimise average lookup time, this process would have to be performed manually by experimentation.

7.3 Summary of Discussion and Results

This chapter discusses the behaviour of the BDD packet lter in unseen situations, and identies factors affecting its utilisation. The characteristics of the BDD packet lter highlighted by the experimental results suggest that it should only be considered for use in certain situations. Specically, the BDD lter is more suited for high-capacity networks where longer access lists are more likely. Next, a summary of some important characteristics of the BDD packet lter is presented, and this knowledge is used to suggest directions for future work. For completeness, results from the analytical evaluation, empirical evaluation, as well as the discussions of this chapter are included in the summary.

For a given access list, the BDD packet lters lookup times are bounded above by a constant value. This is a powerful characteristic that guarantees lower average lookup times than sequential packet lters on access lists above a certain length (assuming a reasonably even distribution of matching rules).

The BDD packet lter exhibits a high overhead on lookup. This is due to the fact that longer paths through the BDD are more likely to be chosen during lookup, and the extraction of a bit value at each node is executed as a sequence of word operations which makes it an expensive process. One of the consequences of this is that the current approach to BDD packet ltering is limited to longer access lists.

The BDD packet lter is robust with respect to network trafc. This follows from the unimodal distribution of lookup times exhibited by the BDD packet lter. As mentioned, this removes the effect that rule positioning and access list length have on traditional packet lters. An important consequence of this is that the focus during access list creation can be placed on readability and correctness rather than speed.

The BDD packet lter is reasonably robust with respect to variable ordering in terms of space and time. While variable ordering does affect localised performance, the effect that different variable orderings have on the BDD packet lter is limited. However, there are cases where putting effort

into nding a variable ordering is justied in particular to minimise the average lookup time. There are currently no heuristics for this, but simple experimentation can give fairly good results.

The BDD packet lter exhibits a good space-time tradeoff. The BDD packet lter has good worst case behaviour in terms of both lookup time and memory usage, which other approaches lack. Its good space complexity suggests that memory can be traded off in exchange for improved lookup in future endeavours.

The positive characteristics described above contribute to making the BDD approach to packet ltering reliable, robust and stable. Its characteristics make it a good alternative to traditional (and alternative) packet ltering approaches in many real situations. This justies spending time and effort to improve its weaker points, thereby broadening its scope of use. Two immediate directions for improvement are suggested by the discussions in this chapter. Lookup time is currently the limiting factor in the BDD lters overall performance. There are undoubtedly situations in which the BDD lter is outperformed by the sequential lter and other approaches. Thus nding ways to reduce its lookup time is a denite priority. An advantage here is that the memory requirements of the BDD packet lter are low enough to offer the option to trade off some memory for speed. The choice of variable ordering is another prominent theme in many of the discussions in this chapter. A better understanding of the orderings effect on BDD representations of access lists would be benecial in this regard. Creating tools for the automation of choosing orderings, or dynamic variable reordering would shield a network administrator from the need to understand the technical details of the BDD packet lter. These tools could employ heuristics or experimental techniques to aid the system or user in making choices.

Chapter 8

Conclusions and Future Work

This research is concerned with nding an internal representation for the access lists of packet lters capable of providing fast lookup with reasonable memory requirements. Packet ltering as a mechanism for controlling access between networks is a widely-used technique for improving network security. The problem with traditional packet lter implementations is that the evaluation of the rules in an access list for each incoming packet is done sequentially. Thus, in general, the latency incurred by this lookup process is proportional to the number of rules in the list. Alternative approaches to packet ltering have been proposed, whose performances are subject to the effects of space-time tradeoff. Techniques that are extremely efcient in terms of memory usage do so at the expense of lookup time efciency, and vice versa. Many of the proposed techniques depend on the access lists being well-structured for their good performance. In these cases, badly-behaved access lists cause degraded lookup performance or unreasonable memory requirements. The internal representation for access lists considered by this research is based on BDDs. This follows from the fact that BDDs provide compact representations for many Boolean functions and that the criterion given by an access list for accepting a packet is expressible as a Boolean function. The aim of this research has been to evaluate BDD-based representations of access lists in terms of their lookup performance and memory requirements in order to answer the question:

Can BDDs be used effectively in the representation of access lists for the purposes of lookup?

This chapter addresses this question and summarises the major contributions of this research in Section 8.1. Thereafter, Section 8.2 identies some areas for further research.

101

8.1 Research Contributions

The evaluation of BDD representations of access lists for lookup was performed both empirically and analytically. While the majority of the results were obtained from the experimental work, the theoretical analysis revealed some important consequences. The two main objectives of the research were to analyse the BDD approach in terms of lookup algorithm complexity and memory usage. A sub-objective of the experimental work was to provide a preliminary investigation into the sensitivity of this approach to variable ordering in order to determine whether this is worth exploring further. This section summarises the contributions of this research in terms of these objectives.

8.1.1 On the Memory Requirements of the BDD Approach

The memory requirements of a BDD representation of an access list are unlikely to be worse than quadratic in the number of variables with increasing access list lengths. There is evidence to suggest that on well-structured access lists, the growth could even be linear. Since elds in an individual access list rule are not interdependent, it can be argued that an access list format that allows more elds to be specied in its rules will not affect the worst case memory results as obtained in this research. Since the space requirements of BDDs can grow exponentially with the number of variables, the compactness of access list representations obtained in this research is an excellent result. Also, some of the faster alternative approaches to packet ltering suffer from exponential memory requirements in the worst case. The fact that the BDD approach can offer reasonable time and space requirements in the worst case makes it a considerably robust technique.

8.1.2 On the Lookup Performance of the BDD Approach

For every access list and corresponding access list format there is an upper bound on the lookup time. In this research, the access list format used limited the resulting BDDs to a maximum of 104 variables. This limit determines the maximum path length, and hence the worst case lookup time of the BDD packet lter. Since the worst case lookup is directly proportional to the maximum number of variables in the BDD, the worst case of the BDD lter grows linearly with the maximum number of variables generated by an access list format. However, this number is also bounded since the number of packet header elds available for specication is limited. The bit-level operations of the BDD packet lter result in the lookup algorithm experiencing a high overhead. As a result, the lookup times incur high constant factors in general. However, the BDD representation has the effect of minimising the difference between best and worst case lookup times, so

that a unimodal distribution of lookup times is produced. Thus the approach results in packet lters that are robust with respect to their inputs in terms of lookup time, and removes the effect that rule positioning and access list length have on traditional packet lters. In terms of lookup time performance, there are techniques that outperform the BDD packet lter, at the expense of memory. Even the traditional sequential packet lters outperform the BDD lter under certain conditions. However, the upper bound that the BDD approach imposes on its lookup times for a given access list is a strong result that ensures good lookup times on longer access lists. Since long access lists often occur on border routers, where they worsen existing packet processing bottlenecks, the value of this result is evident.

8.1.3 On the Value of Exploring Variable Ordering Further

Good variable orderings for optimising memory requirements and / or average lookup times are highly dependent on the particular access list. To reduce memory usage, the greatest gains occur when the longest subexpressions shared by many rules in the list are placed at the top of the BDD. To reduce average lookup time, the greatest gain occurs when the average BDD path length traversed by the lookup algorithm is minimised. This depends on the access list and actual trafc patterns. Tradeoffs between space and time with respect to variable ordering are not predictable, and since the BDD representations have shown to be quite compact, effort should be put into reordering BDD variables for time, rather than space. While different variable orderings produce different results for memory usage and average lookup times on the same access list, the results produced by the worst orderings are only slightly worse than the results produced by the better orderings. The results also suggest that variable orderings not considered in this research would not cause radically different behaviour. Given this, there is little value in repeating the experimental work of this research to explore other variable orderings. Instead, it is more worthwhile to consider algorithms or heuristics for choosing good orderings for improving lookup, especially those taking trafc patterns into account.

8.1.4 On the Effectiveness of the BDD Approach

The average lookup time of a packet lter that performs sequential rule evaluation grows linearly with the average of the frequency distribution of rule positions of the matching rules. If this distribution is fairly even, or if the trafc pattern is not taken into account, this can be simplied by stating that the average lookup time grows linearly with the length of the access list.

When this is the case, the BDD packet lter performs worse than sequential lters on short access lists and better than sequential lters on long access lists. In between, there is a range of access list lengths that results in comparable behaviour for both packet lters. It is on these access lists that variable reordering can be used effectively to reduce the average lookup time of the BDD packet lter so that it outperforms the sequential lter. Good variable orderings reduce the access list length at which the BDD approach outperforms sequential lookup. The BDD approach can be considered preferable as soon as there is some variable ordering that produces lower average lookup times compared to the original packet lter for a given access list. Results of this research suggest that the BDD approach can be viable on lists of approximately 50 rules or more when compared to a sequential packet lter with the same functional specication. Since border routers often have long access lists (several hundred rules are not uncommon), and it is at these routers that reducing packet ltering latency is most important, this is a good result. It also suggests that for shorter access lists, the overhead of the BDD approach will not produce any benet, which is a reasonable and acceptable result. The BDD approach also offers advantages over the traditional sequential approach to the network administrator. By removing the sensitivity of access list rule positioning on lookup performance, it allows the administrator to focus on correctness when specifying rules, rather than optimising for speed. With the implementation of tools to manage the variable ordering aspects, the BDD packet lter can be integrated into the workplace with ease. Finally, compared to the alternative approaches proposed in the literature, the BDD approach provides good lookup performance with a small space-time tradeoff, which no other approach claims to provide. In general, the BDD packet lters robustness with respect to access list structure and trafc distribution coupled with its guarantee of constant lookup bounds for a given access list makes it a reliable packet ltering technique in any situation.

8.2 Future Work

Section 7.3 suggests that worthwhile directions for future work include improvements in the lookup performance of the BDD packet lter, and an investigation into the effect of variable ordering on performance in order to improve ordering choices. These ideas, as well as others, are investigated in more detail in this section. Some ideas for extensions are relatively simple, while others are more ambitious.

Improvements in variable ordering and reordering:

Algorithms or heuristics capable of choosing

good variable orderings for improving either memory requirements or lookup performance would be

extremely benecial. This would involve a deeper investigation into the effect of variable ordering on BDD representations of access lists. Choosing good variable orderings for lookup is most effective when trafc patterns are taken into account, so an algorithm that monitors the network trafc continuously and dynamically reorders BDD variables from time to time would maximise the potential of the BDD packet lter.

Incremental updates: Currently, any change to the access list requires its BDD representation to be regenerated. The ability to incrementally update the BDD has a number of important consequences. Firstly, the amount of time required to update the modied BDD in the packet lter would be minimised and policy changes to the BDD packet lter could be done in real-time. Secondly, this would allow dynamic access control features to be implemented. An existing application of dynamic access control allows access lists to be dened on a per-user basis [11]. Once authenticated, the users security policy is added dynamically to the routers inbound and outbound interfaces. When the session is closed or expires, the dynamic rules are automatically removed. In general, dynamic access control allows more exible security policies to be specied. A framework for the implementation of dynamic access control, using BDDs for efcient ltering updates and lookup, has been proposed [22]. What remains is to evaluate the efcacy of the proposed approach, especially in terms of the time taken to make the incremental updates.

Multi-node BDD-based representations:

The high overhead exhibited by the BDD packet lter is

caused by the expense of the bit-level operations. Since bit operations are executed as a sequence of word operations involving bit-level masking, testing the value of multiple bits in the same word in memory requires no extra computation. Thus more effective use of the BDD packet lters lookup time can be made by testing the value of more than one bit simultaneously. If two bits are tested at each node of the BDD, this has the effect of squashing the BDD lengthwise, halving the maximum path length traversable by the lookup algorithm. This technique would result in a considerable reduction in average lookup time as long as the bits tested at each node occur in the same word in memory. Figure 8.1 on page 106 shows the resulting data structure when two variables are combined at each node. In theory, this method could be extended from combining two variables to combining as many variables as the size of a computer word (which depends on the architecture). However, this technique is a classic example of a space-time tradeoff squashing the original BDD also makes the resulting structure wider. Preliminary results show the viability of this technique for up to eight bit structures [27, 29]. Its effect on memory needs to be investigated further in order to nd the point at which a reasonable tradeoff between space and time occurs.

x1 x2 x3 x4 0 (i) 1 0 (ii)

x1x2

00 01 10 11

x3x4

Figure 8.1: Example of a multi-node BDD-based structure. (i) A BDD for the Boolean ex-

. (ii) The tests for and have been combined into one node in the new representation, and similarly for variables and .
The depth of the BDD has been halved by this process.

pression

Multi-terminal BDD representations:

Extending the BDD packet lter to perform packet classica-

tion rather than packet ltering would have enormous benets. Recall that packet classication involves nding the least cost rule that matches a packet, and that packet ltering is a special case of classication where the cost of a rule is its position in the access list. Extending the BDD approach presented in this research to support packet classication creates the need to represent functions that map Boolean variables to a nite set of values. Multi-terminal binary decision diagrams (MTBDDs) [13] are suggested as a starting point for this extension. With a BDD-based approach to packet classication, many useful applications exist, including:

IP routing: The routing of IP packets involves performing lookup on a routing table at each hop along the packets route. Routing table lookups are different from access list lookups in two ways. Firstly, the most specic rule in a routing table is chosen, rather than the rst matching rule. Secondly, the decision of a routing table determines what outbound interface the packet should be queued at, as opposed to the binary decisions made by packet lters. Thus extending BDDbased packet ltering to support routing involves extending the BDD data structure to support multiple terminal nodes as well as producing an algorithm that converts a routing table into this new representation.

Fast packet processing: Once a BDD-based technique for routing exists, the next powerful step involves combining routing and packet ltering into one process. Routing and packet ltering occur in multiple steps on most routers: as the packet arrives at the router it may be subjected to

ltering at the inbound interface. If accepted, a lookup in the routing table decides at what interface the packet should be queued for the next hop. This outbound interface may also have access lists applied to it. Thus packets may be inspected multiple times during processing. By incorporating routing tables and ltering access lists into one expression, and hence one internal structure, the amount of computation required for packet processing can be greatly reduced.

8.3 Conclusion
The aim of this research has been to investigate the effectiveness of using BDDs to represent access lists for the purposes of packet ltering performance. This aim was achieved in two ways. Firstly, an analytical investigation into BDD representations of access lists was carried out, revealing some important properties that bound the lookup time provided by the BDD representation for a given access list. Secondly, the implementation of a packet lter that uses a BDD-based representation of its access list, and subsequent experimental work, gave evidence to suggest that this approach will outperform traditional sequential packet lters in many real and important situations. The advantages of this approach extend beyond performance as it helps to alleviate other known problems with traditional packet ltering such as access list correctness. Not only are these results important in their own right, they also provide a starting point for many extensions to this research. This includes the possibility of fast packet processing on routers, necessary for reducing current bottlenecks on high-capacity networks.

Appendix A

Converting Access Lists into BDDs: An Example

This appendix presents a detailed example showing how the rules of an access list are converted into a Boolean expression describing what types of packets are accepted by the list, and how this expression is represented as a BDD. The access list used in this example is the list used in the shorter presentation of this example in Section 3.2.3, and is given again in Figure A.1 below. This access list shows some sample rules that could be applied to inbound trafc at the external interface of the 146.141.0.0/16 network. It allows all inbound mail connections, as well as ICMP trafc and web requests that do not claim to originate from the internal network. Its default policy is to deny all packets.
Rule Proto (Field 1) 1 2 3 4 TCP IP TCP ICMP Src Addr (Field 2) 0.0.0.0 146.141.0.0 0.0.0.0 0.0.0.0 255.255.255.255 0.0.255.255 255.255.255.255 255.255.255.255 Src Mask Src Port (Field 3) 1023 any 1023 Dest Addr (Field 4) 146.141.0.0 146.141.0.0 146.141.0.0 146.141.0.0 0.0.255.255 0.0.255.255 0.0.255.255 0.0.255.255 Dest Mask Dest Port (Field 5) 25 any 80 Permit Deny Permit Permit Deny Action

Default Policy:

Figure A.1: An example access list to illustrate conversion into a Boolean expression.

The example is presented as follows. The conversion of each rule into its corresponding Boolean expression is shown symbolically using the Boolean variables dened in Table 3.1 on page 30. Also, resulting Boolean expressions and BDDs are given to depict what happens at each step as a rule is added. The BDD resulting from the addition of the nal rule corresponds to the complete representation of the ac-

108

cess list. The variable ordering used in all BDDs in this appendix is PDS, which orders the variables representing the protocol rst, followed by the destination address, destination port, source address and source port. Variables within each eld are ordered from most to least signicant with respect to the bits they represent.

Notation:

Let

denote the Boolean predicate representing the encoding of eld of rule . Also, let

denote the Boolean representation of rule . Then

, where is the dimensionality of

the access list. The eld numbers used in this example are shown in the column headings of the access list in Figure A.1. The Boolean values true and false are denoted by T and F respectively. Also, primes are used to indicate negation and juxtaposition used to indicate conjunction. Finally, natural language is used in addition to formal notation to aid discussion.

Converting the First Rule

An individual rule is converted by forming a conjunction of all the predicates in its selection criterion. Since an unspecied eld in a rule does not add any information to the rules Boolean representation, Boolean predicates for unspecied elds have the value T. In converting the rst rule:

Proto

TCP

Src Addr T

Src Port

Dest Addr

Dest Port

Since the rst rules action is P ERMIT, the access list so far accepts any packet matching else. The BDD representing this expression is given in Figure A.2 on page 113.

and nothing

Converting the Second Rule

In converting the second rule:

Proto T

IP

Src Addr

Src Port T

Dest Addr

Dest Port T

Notice that the predicate Proto = IP is encoded as T. The assumption here is that only IP trafc needs to be considered. If the packet lter encountered network protocols other than IP, the predicate Proto = IP would need to be encoded explicitly to differentiate it from other possibilities. Since the second rules action is D ENY, the access list so far accepts any packet matching the rst rule or not matching the second rule, i.e.

. The BDD representing this expression is given in Figure A.3

on page 114. The addition of the D ENY rule has complicated the expression signicantly.

Converting the Third Rule

In converting the third rule:

Proto

TCP

Src Addr T

Src Port

Dest Addr

Dest Port

Since the third rules action is P ERMIT, the access list so far accepts any packet matching the rst rule or alternatively, matching the third rule but not the second, i.e.
.

The addition of the third

rule has actually narrowed the set of packet types that are accepted and thus the BDD representing the access list at this point has fewer nodes than the BDD representing just the rst two rules (Figure A.3). This new BDD is shown in Figure A.4 on page 115.

Converting the Fourth Rule

In converting the fourth rule:

Proto

ICMP

Src Addr T

Src Port T Dest Addr

Dest Port T

Since the fourth rules action is P ERMIT, the access list now accepts any packet matching the rst rule or alternatively, matching the third or fourth rules, as long as it does not match the second, i.e.
.

This is equivalent to

. The BDD representing this expression is given in

Figure A.5 on page 116. Although this BDD may look complicated, the complexity is not due to the addition of the fourth rule which is quite simple, but rather from applying the restriction of the second rule to the encoding of the fourth rule when this new rule is added.

Encoding the Default Policy

Encoding the default policy explicitly into the Boolean representation is only necessary when the default policys action is the same as the last rules in the list. If they are different, the default policy is built into the expression automatically. In this example, the four encoded rules result in the expression

. This expression denes exactly what types of packets are accepted and everything else is

rejected hence the implicit deny all policy. If the default policy was ACCEPT then the nal expression would change. In this example, the last two rules would be redundant because they would have the same action as the default policy, and the nal expression would simplify to

. A similar effect occurs when D ENY rules appear at the end of an

access list with D ENY default policy. Fortunately, these semantics are dealt with automatically by the conversion algorithm of Section 3.2.1.

p7

p6

p5

p4

p3

p2

p1

p0

da31

da30

da29

da28

da27

da26

da25

da24

da23

da22

da21

da20

da19

da18

da17

da16

dp15

dp14

dp13

dp12

dp11

dp10

dp9

dp8

dp7

dp6

dp5

dp4

dp3

dp2

dp1

dp0

sp15

sp14

sp13

sp12

sp11

sp10

Figure A.2: BDD representation of the access list once the rst rule has been encoded.

p7

p6

p5

p4

p3

p2

p1

p0

da31

da31

da30

da29

da28

da27

da26

da25

da24

da23

da22

da21

da20

da19

da18

da17

da16

dp15

dp14

da30

dp13

da29

dp12

da28

dp11

da27

dp10

da26

dp9

da25

dp8

da24

dp7

da23

dp6

da22

dp5

da21

dp4

da20

dp3

da19

dp2

da18

dp1

da17

dp0

da16

sa31

sa31

sa30

sa29

sa28

sa27

sa26

sa25

sa24

sa30

sa23

sa29

sa22

sa28

sa21

sa27

sa20

sa26

sa19

sa25

sa18

sa24

sa17

sa23

sa16

sa22

sp15

sa21

sp14

sa20

sp13

sa19

sp12

sa18

sp11

sa17

sp10

sa16

Figure A.3: BDD representation of the access list once the rst two rules have been encoded.

p7

p6

p5

p4

p3

p2

p1

p0

da31

da30

da29

da28

da27

da26

da25

da24

da23

da22

da21

da20

da19

da18

da17

da16

dp15

dp14

dp13

dp12

dp11

dp10

dp9

dp8

dp7

dp6

dp5

dp4

dp3

dp2

dp1

dp0

sa31

sa30

sa29

sa28

sa27

sa26

sa25

sa24

sa23

sa22

sa21

dp5

sa20

dp4

sa19

dp3

sa18

dp2

sa17

dp1

sa16

dp0

sp15

sp14

sp13

sp12

sp11

sp10

Figure A.4: BDD representation of the access list once the rst three rules have been encoded.

p7

p6

p5

p4

p3

p2

p1

p0

da31

da30

da29

da28

da27

da26

da25

da24

da23

da22

da21

da20

da19

da18

da17

da16

dp15

dp14

dp13

dp12

dp11

p1

dp10

p0

dp9

da31

dp8

da30

dp7

da29

dp6

da28

dp5

da27

dp4

da26

dp3

da25

dp2

da24

dp1

da23

dp0

da22

da21

sa31

da20

sa30

da19

sa29

da18

sa28

da17

sa27

da16

sa26

sa25

sa31

sa24

sa30

sa23

sa29

sa22

sa28

dp5

sa21

sa27

dp4

sa20

sa26

dp3

sa19

sa25

dp2

sa18

sa24

dp1

sa17

sa23

dp0

sa16

sa22

sp15

sa21

sp14

sa20

sp13

sa19

sp12

sa18

sp11

sa17

sp10

sa16

Figure A.5: BDD representation of the access list once all four rules have been encoded. This is the complete representation of the access list.

Appendix B

Complete Results for Experiment F

This appendix presents some results given in Section 6.2.4 in more detail. The gures presented depict the frequency and cumulative frequency distributions of lookup times for access lists A and B on packets generated from packet traces. In addition to the results for the naive system and the BDD lter with variable ordering that produces the lowest average lookup time, these gures also show the results for iptables and the BDD lter with variable ordering that produces the highest average lookup time.
60 Access List A - Packets Classified (%) iptables naive bdd min bdd max

50

40

30

20

10

10

15

20 25 30 Lookup Time (s)

35

40

45

Figure B.1: Frequency distribution of lookup times for access list A, with packets generated from a packet trace. Represented systems include iptables, the naive lter and BDD lter with the two variable orderings that produced the best and worst results with respect to average lookup time.

117

45 40 Access List B - Packets Classified (%) 35 30 25 20 15 10 5 0 0 5 10 15 20 25 30 Lookup Time (s) 35 40 45 iptables naive bdd min bdd max

Figure B.2: Frequency distribution of lookup times for access list B, with packets generated from a packet trace. Represented systems include iptables, the naive lter and BDD lter with the two variable orderings that produced the best and worst results with respect to average lookup time.

Access List A - Cumulative Packets Classified (%)

100 iptables naive bdd min bdd max

80

60

40

20

10

15

20 25 30 Lookup Time (s)

35

40

45

Figure B.3: Cumulative frequency distribution of lookup times for access list A, with packets generated from a packet trace. Represented systems include iptables, the naive lter and BDD lter with the two variable orderings that produced the best and worst results with respect to average lookup time.

Access List B - Cumulative Packets Classified (%)

100 iptables naive bdd min bdd max

80

60

40

20

10

15

20 25 30 Lookup Time (s)

35

40

45

Figure B.4: Cumulative frequency distribution of lookup times for access list B, with packets generated from a packet trace. Represented systems include iptables, the naive lter and BDD lter with the two variable orderings that produced the best and worst results with respect to average lookup time.

References
[1] H. R. Andersen. An Introduction to Binary Decision Diagrams. Department of Information Technology, Technical University of Denmark, Lyngby, Denmark, October 1997. Lecture notes for Advanced Algorithms. [2] M. L. Bailey, B. Gopal, M. A. Pagels, L. L. Peterson, and P. Sarkar. PathFinder: A Pattern-Based Packet Classier. In Proceedings of the First USENIX Symposium on Operating Systems Design and Implementation, pages 115123, Monterey, CA, November 1994. [3] S. M. Ballew. Managing IP Networks with Cisco Routers. OReilly & Associates, 1997. [4] A. Begel, S. McCanne, and S. L. Graham. BPF+: Exploiting Global Data-ow Optimization in a Generalized Packet Filter Architecture. Computer Communication Review, 29(4):123134, October 1999. [5] B. Bollig and I. Wegener. Improving the Variable Ordering of OBDDs is NP-Complete. IEEE Transactions on Computers, 45(9):9931002, September 1996. [6] R. E. Bryant. Graph-Based Algorithms for Boolean Function Manipulation. IEEE Transactions on Computers, 35(8):677691, December 1986. [7] R. E. Bryant. Symbolic Boolean Manipulation with Ordered Binary-Decision Diagrams. ACM Computing Surveys, 24(3):293318, September 1992. [8] D. B. Chapman. Network (In)Security Through IP Packet Filtering. In Proceedings of the Third USENIX UNIX Security Symposium, pages 6376, Baltimore, MD, September 1992. [9] W. R. Cheswick and S. M. Bellovin. Firewalls and Internet Security: Repelling the Wily Hacker. Addison-Wesley, Reading, MA, 1994. [10] G. Cheung and S. McCanne. Dynamic Memory Model based Framework for Optimization of IP Address Lookup Algorithms. In Proceedings of the Seventh Annual International Conference on Network Protocols, pages 1120, Toronto, Canada, OctoberNovember 1999.

120

[11] Cisco Systems Inc. Cisco IOS Lock and Key Security, 1996. Available at http://www.cisco.com/ warp/public/cc/pd/iosw/ioft/iolk/tech/landk wp.htm. Last accessed March 2002. [12] Cisco Systems Inc. Turbo Access Control Lists, 1999. Available at http://www.cisco.com/univercd/ cc/td/doc/product/software/ios120/120newft/120limit/120s/120s6/turboacl.htm. Last accessed August 2001. [13] E. Clarke, M. Fujita, and X. Zhao. Multi-Terminal Binary Decision Diagrams and Hybrid Decision Diagrams. In T. Sasao and M. Fujita, editors, Representations of Discrete Functions, pages 93108. Kluwer Academic Publishers, 1996. [14] B. Conoboy and E. Fichtner. IP Filter Based Firewalls HOWTO, July 1999. Available at www. linuxsecurity.com/articles/rewalls article-241.html. Last accessed August 2001. [15] B. Corbridge, R. Henig, and C. Slater. Packet Filtering in an IP Router. In Proceedings of the Fifth Large Installation Systems Administration Conference, pages 227232, San Diego, CA, SeptemberOctober 1991. USENIX Association. [16] A. Cox. Network Buffers and Memory Management. Linux Journal, October 1996. Available at http://www2.linuxjournal.com/lj-issues/issue30/1312.html. Last accessed August 2001. [17] D. Decasper, Z. Dittia, G. Parulkar, and B. Plattner. Router Plugins: A Software Architecture for Next Generation Routers. Computer Communication Review, 28(4):229240, October 1998. [18] M. Goncalves. Firewalls: A Complete Guide. McGraw-Hill, New York, 2000. [19] P. Gupta and N. McKeown. Packet Classication on Multiple Fields. Computer Communication Review, 29(4):147160, October 1999. [20] P. Gupta and N. McKeown. Classifying Packets with Hierarchical Intelligent Cuttings. IEEE Micro, 20(1):3441, JanuaryFebruary 2000. [21] S. Hazelhurst. Algorithms for Analysing Firewall and Router Access Lists. In Proceedings of the Second Annual South African Telecommunications and Networks Applications Conference, pages 259264, Durban, South Africa, September 1999. University of Durban-Westville. [22] S. Hazelhurst. A Proposal for Dynamic Access Lists for TCP/IP Packet Filtering. Technical report, School of Computer Science, University of the Witwatersrand, 2001. Available at ftp://ftp.cs.wits. ac.za/pub/research/reports/TR-Wits-CS-2001-2.ps.gz. Last accessed October 2001. [23] S. Hazelhurst, A. Fatti, and A. Henwood. Binary Decision Diagram Representations of Firewall and Router Access Lists. Technical Report TR-Wits-CS-1998-3, School of Computer Science, University of the Witwatersrand, October 1998. Available at ftp://ftp.cs.wits.ac.za/pub/research/ reports/TR-Wits-CS-1998-3.ps.gz. Last accessed August 2001.

[24] M. Jayaram and R. K. Cytron. Efcient Demultiplexing of Network Packets by Automatic Parsing. In ACMSIGPLAN 95 Conference on Programming Language Design and Implementation. ACM Press, 1995. Available at http://citeseer.nj.nec.com/jayaram94efcient.html. Last accessed March 2002. [25] V. P. Kumar, T. V. Lakshman, and D. Stiliadis. Beyond Best-Effort: Router Architectures for the Differentiated Services of Tomorrows Internet. IEEE Communications Magazine, 36(5):152163, May 1998. [26] T. V. Lakshman and D. Stiliadis. High-Speed Policy-based Packet Forwarding Using Efcient Multi-dimensional Range Matching. Computer Communication Review, 28(4):203214, October 1998. [27] V. Lala. Improving Lookup Time for Packet Filtering by Squashing BDDs. Honours Research Report, School of Computer Science, University of the Witwatersrand, October 2000. [28] P. Mariet. DECUS Presentation: Altavista Firewall. WWW Document, April 1997. Available at http://elias.decus.ch/presentations/ge 19970415 av/index.htm. Last accessed August 2001. [29] M. Matsoso. Squashing the Height of Firewall Decision Trees. Honours Research Report, School of Computer Science, University of the Witwatersrand, October 2001. [30] S. McCanne and V. Jacobson. The BSD Packet Filter: A New Architecture for User-level Packet Capture. In Proceedings of USENIX Winter Conference, pages 259269, January 1993. [31] J. C. Mogul. Simple and Flexible Datagram Access Controls for Unix-based Gateways. In Proceedings of the Summer 1989 USENIX Technical Conference, pages 203221, Baltimore, MD, 1989. [32] J.C. Mogul, R.F. Rashid, and M.J. Accetta. The Packet Filter: An Efcient Mechanism for Userlevel Network Code. In Eleventh ACM Symposium on Operating Systems Principles, pages 3951. ACM Press, November 1987. [33] R. Neale. Is Content Addressable Memory the Key to Network Success? Electronic Engineering, 71(865):912, February 1999. [34] The Netlter Project Homepage. http://netlter.samba.org/. Last accessed August 2001. [35] D. Newman. Firewall on a Chip: Fores FSA Boosts Throughput to Multigigabit Rates. Data Communications, 28(1):4445, January 1999. [36] R. Oppliger. Internet and Intranet Security. Artech House, Norwood, MA, 1998. [37] RFC 1700: Assigned Numbers, October 1994. Available at ftp://ftp.is.co.za/rfc/rfc1700.txt. Last accessed August 2001.

[38] P. Russell.

Linux Netlter-HOWTO, July 1999.

Available at http://netlter.kernelnotes.org/

netlter-HOWTO.html. Last accessed June 2000. [39] S. Sikka and G. Varghese. Terabit IP Lookups. In Proceedings of SIGCOMM 2000 Annual Technical Conference, Stockholm, Sweden, August 2000. Available at http://www.acm.org/sigs/sigcomm/ sigcomm2000/conf/paper/sigcomm2000-9-3.ps.gz. Last accessed March 2002. [40] R. Sinnappan. A Recongurable Approach to TCP/IP Packet Filtering. MSc Research Report, School of Computer Science, University of the Witwatersrand, June 2001. [41] V. Srinivasan, S. Suri, and G. Varghese. Packet Classication using Tuple Space Search. Computer Communication Review, 29(4):135146, October 1999. [42] V. Srinivasan, G. Varghese, S. Suri, and M. Waldvogel. Fast and Scalable Layer Four Switching. Computer Communication Review, 28(4):191202, October 1998. [43] W. R. Stevens. TCP/IP Illustrated, Volume 1. Addison-Wesley, Reading, MA, October 1999. [44] S. Suri and G. Varghese. Packet Filtering in High Speed Networks. In Proceedings of the Tenth Annual ACM-SIAM Symposium on Discrete Algorithms, pages 969970, Baltimore, MD, January 1999. [45] J. Vos and W. Konijnenberg. Linux Firewall Facilities for Kernel-level Packet Screening, November 1996. Available at http://www.xos.nl/linux/ipfwadm/paper/. Last accessed August 2001. [46] M. Yuhara, B. N. Bershad, C. Maeda, and J. E. B. Moss. Efcient Packet Demultiplexing for Multiple Endpoints and Large Messages. In Proceedings of the 1994 Winter USENIX Conference, pages 153165, January 1994. [47] R. L. Ziegler. Linux Firewalls. New Riders, Indianapolis, Indiana, 2000.