For simplicity and maintainability, we only used off-the-shelf components, even though available components did not always behave optimally. For example, we would prefer that our telnet server and clients encrypt an S/Key session with the next key in sequence, or that our X server use a well-defined static mapping function so that a given client could be told, under program control, which logical display on the bastion host to use. Hopefully, to the extent that such features are generally useful for firewalls, they will be incorporated into these components in the future.
We are using an off-the-shelf switching Ethernet bridge for our packet filtering. As with most Ethernet bridges, it was not designed with firewalls specifically in mind, and we consequently faced several problems. The switch's biggest shortfall occurs during reboots. It begins forwarding packets before its filters are enabled. For approximately 30 seconds, the bridge forwards packets with no filtering. Furthermore, carefully chosen packet sequences can crash the bridge, so an intruder could intentionally crash the bridge and wreak havoc during the window of opportunity.
To reduce the likelihood of such a break-in, we have installed a simplified version of our filter in the router connecting our network to the rest of the campus network. Because this machine is not under our administrative control, we choose not to depend on the router's filters during the normal course of events. However, it does provide an added level of protection, and in particular, protects against compromising our network while the bridge is rebooting.
Currently, even when the network is idle (fewer than 15 incoming packets per second), our filters block one or two packets per second. These packets are usually not breakin attempts but instead are benign packets such as rwho packets, unauthorized multicast packets, SNMP, etc.
Our experience with the switch's packet filtering performance reveals that anyone deploying a firewall must measure the actual packet latencies, which may not match the manufacturer's specifications. Our switch re-parses its filtering rules for every incoming packet, and we conjecture that our packet filtering rules are much larger than the manufacturer expected. Without packet filters, the switch takes about 6.4 microseconds to process each packet. According to the manufacturer's specification, our filters should add about 11.8 and 14.1 microseconds, tripling the total processing time. This overhead is still less than the time it takes to transmit a minimum size Ethernet packet, so if dispatching were done in parallel with transmission, the firewall filters should introduce no additional latency. However, actual measurements show that packet filtering increases the round-trip delay per packet by approximately 180 microseconds. In addition, this increased processing time also increases the average packet queue length in the firewall during heavy load. Under load, the packet filter introduces an average additional latency (including additional waiting time on the queue) of 400 microseconds.
The expressive power of the filter rule language also leaves much to be desired---to the point that we developed a richer filter language of our own and an optimizing translator to the switch's native inputs. Although these observations are based upon experiences with a single switch, poor filtering performance is characteristic of most switches on the market. Switch and router vendors rate their products on packets-per-second throughput, ignoring the need for filtering in today's Internet. As switch manufacturers realize the increasing importance of firewalls, we hope and expect that such failings will be eliminated and that necessary features will be added to better support firewall development.