Development Framework for Firewall Processors T.K. Lee, S. Yusuf, W. Luk, M. Sloman, E. Lupu and N. Dulay Department of Computing, Imperial College, 180 Queen’s Gate, London SW7 2BZ, England {tk197, sy99, w.luk, m.sloman, e.c.lupu, n.dulay}@doc.ic.ac.uk Abstract High-perfor,,~rr,ice firewalls caii benefit from the in- ci-easing size, speed aitdjle.ribiliry of advanced reconfrg- irrnble hardware. Howevez direcr rranslation of convem tionalfirewall rides in a rotaer-based rule set ofen leads to iireflciem liardware iiiipleiiie,itario,i. Moreovez such low- level desci-iprioii of firewall rides teiids to be difficult fo ,nariage mid to exrerid. We describe a frariiework, based on rhr high-level policy speclfcation language Pondec for crii~tiii-iitSfirei,,nll rides as aurkorizatioii policies with user- defiiloble coiistraiias. Oiir framework supports opriinisa- rioits to achieve efficient u~ilisation ofhardware resources. A pipeliiied firewall impleineittarion developed using this approach riritiiiiig af IOMHz is capable ofprocessing 2.5 niillioii packers per secoiid, which provides similar perfor- iiiniice ro a versioii withotit optimisarion and is about 50 rimes fuster than n mufmure implemerzmrion running on a 7OOMHz PI11 processor: 1 Introduction Internet Protocol (IP) packet filtering is considered an effective firewall architecture, and is often used for net- work security [2, 121. Packet filters control data flow be- tween a protected network and the outside space. Each packet contains a header which gives information about the type of transport layer used, source and destination ad- dresses, a header checksum, and some optional administra- tive bits. A packet filter works by checking the content of the IP packet header and then decides whether communi- cation is allowed based on a set of rules. Currently, most packet filters rely on processors run- ning entirely in software. However, with the recent ad- vance’in field-programmable gate m a y @’PGA) technol- ogy. custom-developed hardware packet filters that out- perform their software counter parts become possible [6,7, 8, lo]. Software based packet filters suffer from increased 0-7803-7574-2/0211617.00 CO2002 IEEE 352 look-up times as the number of filter rules grow. They therefore have difficulty in keeping up with the current net- work throughput, and may reduce network performance. Hardware, on the other hand, also has limitations; for in- stance, the amount of available reconfigurable resources on an FPGA can limit the number of concurrent matches in a packet filter. While some studies [6, 7, IO] focus on opti- misation of the usage of hardware resources, they do not take into account the redundancy among the firewall rules in a rule set, and they did not utilize information other than those offered by the IP packet headers. We describe how Ponder [4, 51, a policy specification language, can be used to capture an authorization policy. User-definable constraints, which are not normally found in the syntax of conventional firewall rules, is supported for conditional checking of information other than those offered by IP headers. We define policy types, which uses domain hierarchies, that map to an intermediate firewall representation. In addition, knowledge of network topol- ogy and available services within organization can assist ‘don’t care’ discovery and rule elimination. Finally, we describe a parallel matching process by using filters to sep- arate acceptance and rejection actions. and pipelining to achieve higher throughput. The rest of the paper is organised as follows. Section 2 gives an overview of our development framework. Sec- tion 3 illustrates the platform-specific hardware implemen- tation, while Section 4 provides a summary of our work. 2 Design framework Organizational security policies restrict the acceptable behaviour on the network by controlling access to re- sources or services [2, 121. Firewalls use packet filtering to implement authorization policy, whereby packets are per- mitted or denied according to their source or destination IP and/or port addresses. Rules are applied at the network edge for both incoming and outgoing traffic. The order-