Packet Filtering in an IP Router
Bruce Corbridge, Robert Henig, Charles Slater  Telebit Corporation
ABSTRACT
By using existing information in packet headers, routers can provide system
administrators a facility to manage network connections between computers. Host address,
network number, interface, direction, protocol, and port number are parameters that may be
used to implement an access control policy.
We present experiences developing the packet filtering facility in the NetBlazer dial-up
IP router. We address the sometimes conflicting design goals of efficient performance and
ease of administration by choosing internal data structures that simplify per packet lookup
and then devoting 90 per cent of our code to implementing commands that maintain these
tables in manner that is easy for system administrators.
Introduction provides proxy access to the Internet. A third tech-
nique uses a combination of a packet filtering gate-
Wide area networks provide remote sites con-
way and an authentication server.
venient access to local networks. With this
increased convenience comes the often complex
Packet Filtering Gateway
problem of unauthorized access to network
resources. Packet filtering in an IP router can be Digital Equipment Corporation s screend is
used to manage this complexity by controlling which packet filter that runs as a UNIX process [13].
hosts and which services may be accessed from Packets are filtered on input. The decision to accept
remote locations. or deny a packet may be based on host address, sub-
net or application (port or ICMP type code). Screend
In a typical application, host address filters
supports one-way or bi-directional filters, source or
allow remote stations to log in to a host that is
destination addresses, and wildcards (accept any
known to have carefully administered usernames and
value). Figure 1 shows examples of filter
passwords but prevent access to hosts that are less
specifications.
secure. Protocol filters allow logins, ftp and mail,
but deny remote access to X11 or NFS. If the keyword notify is appended to a reject
specification, screend will send an ICMP destination
All IP routers do packet filtering to reduce net-
unreachable message to the source of a rejected
work load. Broadcast packets, packets for which the
packet. If the keyword log is included, screend will
router does not have a route, packets with bad IP
log each application of that packet specification.
headers, and packets that have been bouncing around
over too many gateways (packets with TTL = 0) are Most of the code in screend is devoted to pars-
not forwarded [2]. ing the configuration file and building internal data
structures. The syntax for the configuration language
Routers from several manufacturers can use IP
is specified with a BNF and implemented using lex
source and destination address to provide administra-
and yacc.
tive control of which hosts or networks may com-
municate with each other. Some also use UDP or Screend uses a cache of recently used packet
TCP port or ICMP message type to control what descriptions and decisions to reduce lookup time.
applications network connections are used for [4, 14,
15].
Application-Layer Proxy
In the application-layer gateway used at AT&T
Techniques for Secure Internet Gateways
Bell Laboratories described by Cheswick [6], two
Packet filtering is one of two common tech-
specialized machines are used: inet and r70. Only
niques for implementing a secure internet gateway.
inet is visible to the outside world. It contains a
The other is an application-layer gateway that
very limited amount of secret information. For
from host xx.lcs.mit.edu tcp port 3
to host score.stanford.edu tcp port telnet reject;
between host sri-nic.arpa and any accept;
Figure 1: Examples of Filter specifications
LISA V  Sep. 30-Oct. 3, 1991  San Diego, CA 227
Packet Filtering in an IP Router Corbridge, Henig, & Slater
inbound connections, a challenge response authenti- the output interface and sends the packet only if a
cation service is provided by r70. Most user permit rule is found. In the case where the external
accounts use this service rather than passwords. Inet gateway has only two interfaces (e.g., one 56Kbps
is used to provide anonymous ftp and a store and and one Ethernet), this method can be used to limit
forward mail router. In the outbound direction cus- traffic from outside the organization to a particular
tomized applications such a ptelnet and pftp send set of hosts. Because the filter table is separate from
connect to inet via datakit or via Ethernet through the routing table, it is secure against routing protocol
r70. To hosts external to Bell Labs, these connec- packets and can only be updated by a user with sys-
tions appear to come from inet. tem administrator privileges.
The advantage of the application layer gateway Version 1.0 of Telebit Corporation s NetBlazer
is the addresses of hosts on the internal network are provides such a destination filter facility. Because
completely hidden from the external network. The we were able to reuse the routing table maintenance
disadvantages are that it is more complicated and it and lookup code, it took us less than a week to
runs slower. The inet gateway is a MIPS M/120. implement. One benefit to system administrators
File transfer rates peak at 44Kb per second. This is that this approach provides is the routing and filter
more than enough a for 56Kbps link, but not fast commands have a consistent syntax.
enough to take advantage of a T1 (1.54 Mbps) link.
Input and Output Filtering
Packet Filtering Gateway and Authentication
Filtering only on the output interface is often
Server
less than optimal. Consider a router that has a
Several sites use a combination of a packet 56Kbps interface to the external network and several
filtering gateway and an authentication server to fast local area network (LAN) interfaces to internal
secure an internet connection. The MITRE Corpora- networks. To control the flow of traffic without
tion uses a cisco router to limit the number of hosts knowledge of the input interface requires filters be
exposed to the Internet [8]. Applications such as tel- applied to LAN interfaces. Time spent in filter table
net, rlogin, and ftp have been modified to use a lookup tends to reduce LAN-to-LAN packet
SecureID smartcard system. Connections from the throughput. If instead filtering is done only on the
Internet are validated with a challenge/response sys- 56Kbps interface both in the input direction and the
tem. output direction, the same security objectives can be
achieved without slowing down LAN-to-LAN rout-
Strategies for Packet Filtering Gateways
ing.
There are two benefits from filtering packets:
reduction in unneeded packet traffic and protection Source Address Filtering
from unwanted, perhaps malicious use of network
Some organizations apply one authentication
resources. How effective routers are at providing
scheme to connections within the internal network
these benefits is largely a function of the flexibility
and another to connections from outside the network.
and usability of the tools provided to the system
Connections are considered internal if the source-
administrator.
destination pair is within the organization s internal
address space. The integrity of this assumption is
Routing Table Solutions improved by applying a filter to the external inter-
face that rejects packets in which the source and
All IP routers decide to route or not route a
destination address are both in the internal network.
packet based on the result of routing table lookup.
This prevents an external host from avoiding more
In principle, the routing table could be used to
rigorous authentication by masquerading as an inter-
decide to which destinations packets may be routed
nal host.
and to which they may not. This solution is secure
if only static routes are used. Commonly used rout-
ing protocols such as RIP are not secure [9]. Protocol Port Filtering
Some routers can choose from which source By looking at the destination port, the router
address they will accept RIP information [4, 11]. can control which daemons can be accessed. Each
This helps secure against acquisition of incorrect of the TCP services, smtp, nntp, ftp-data, ftp, finger,
routing information that was accidentally provided. telnet, login, and shell begins by connecting to a
However, because RIP information is passed in an well-known socket which is listening to a port
easily forged datagram an unauthorized user to fool reserved for that service. The same is true for UDP
a gateway listening to RIP into adding a route. destined for Sun RPC, RIP, and Domain daemons.
By restricting the set of destination ports that may
A solution to this problem is to maintain a des-
be accessed from the external network, system
tination filter table of permit and deny rules in the
administrators may control which services may be
same format as the routing table. In addition to
accessed from the external network. One could, for
routing lookup, the router looks in the filter table for
228 LISA V  Sep. 30-Oct. 3, 1991  San Diego, CA
Corbridge, Henig, & Slater Packet Filtering in an IP Router
example, deny external UDP access to Sun RPC flush remove all filters from an interface
(e.g., NFS) and routed but allow domain name ser- lookup tests a packet specification against the filter table
vice by limiting UDP access to port 53. One could list displays the filter table for an interface
allow external access for mail and netnews by limit-
ing TCP access to ports 25 and 119.
What You See Is How It Works
When the NetBlazer administrator lists the filter
Special Cases
table it displays the rules in the order in which they
IP allows some special cases which make secu- are applied. The NetBlazer also provides a lookup
rity through packet filtering a challenge: These command which takes as arguments a source and
include source routed packets and fragments. destination address, an input interface, and optionally
a protocol and destination port number. The com-
Source routed packets may slip through a filter-
mand displays the results of input filter, routing, and
ing router by appearing to be destined for an author-
output filter table lookup.
ized host and then being forwarded to an unauthor-
ized host. Screend solves this problem by not routing
source routed packets [13]. Lookup Order
Traditionally, a 32-bit IP address has been con-
Except for the first one, fragments of a packet
sidered to have three components: network, subnet,
do not contain the next level protocol information
needed to do port filtering. Passing subsequent frag- and host [1]. Phil Karn s ka9q views an IP address
simply as network and host with the network portion
ments is relatively harmless since it is difficult to
being of a variable length that is defined by the sub-
compromise a system without sending it complete
packets. On the other hand, one could flood a net- net mask [7]. Routing lookup is done by searching
the network numbers with the longest subnet masks
work with fragments. One option is to simply pass
first. In this scheme host routes are treated as net-
or reject fragments based on an address filter rule.
work numbers with 32-bit subnet masks. Routes are
This is what the NetBlazer does. Another is to
specified with a convenient network/bits syntax. For
simulate the reassembly algorithm by keeping a
example
cache of previously seen fragments and match the
decision for subsequent fragments with the one made
route add 143.191.10/24 en0
for the first. This is what screend does.
routes subnet 143.191.10 via the interface en0.
The NetBlazer s IP Packet Filtering Facility When a packet comes in the first 24 bits of the desti-
nation address are compared to 143.191.10. If they
In addition to working correctly and efficiently
match, the packet is sent out via en0.
we wanted the the NetBlazer s filter facility to be
The same lookup policy and specification syn-
easy to use. We chose an internal data structure
tax is used in the NetBlazer s filter facility. Except
which made the per packet lookup processing simple
for the default behavior each filter rule has a net-
and then put a lot of effort into providing commands
work specification associated with it. Filter rules
to maintain these tables. To reduce code size and
can specify a source network, a destination network,
insure consistency, all filter commands use the same
or a source network and a destination network (a
parsing function. Yet more than 50 per cent of the
source-destination pair). If the /bits field is omitted,
lines of filter source code are devoted to parsing
it s value is assumed to be 32 and the rule is applied
command lines, almost 40 per cent are devoted to
only if the address is an exact match.
updating the tables, and only 10 per cent are devoted
to the per packet lookup.
A Millisecond in the Life of an IP Packet
One-line Commands When an IP packet enters the the NetBlazer,
the first test is to see if it was a hardware broadcast.
Other implementations use configuration
Information in broadcast packets may be consumed
languages to create a filter configuration file. In
by the NetBlazer, but it does not forward them. The
these implementations, rules are applied to packets
second step is to determine if the packet is a valid
in the order in which they were entered [4, 13]. We
IP packet. The packet is then tested against the
wanted administrators to be able to update the filter
input interfaces input filters (if any). If permission
table with one-line commands in much the same
to route the packet is granted, routing table lookup is
way that they update the routing table and we
done. Having found a route to the destination
wanted the search process to be order of entry
address, the NetBlazer now knows the output inter-
independent.
face. Output filter table lookup determines whether
The NetBlazer IP filter facility contains the fol-
to send or reject the packet. Thus the NetBlazer for-
lowing one-line commands:
wards a packet only when the following conditions
permit adds a permit filter to an interface
are true: (1) not a broadcast, (2) valid IP packet, (3)
deny adds a deny filter to an interface
permitted by input filters, (4) a route to the
delete deletes a filter from and interface
LISA V  Sep. 30-Oct. 3, 1991  San Diego, CA 229
Packet Filtering in an IP Router Corbridge, Henig, & Slater
deny 143.191/16 syn0 udp output source
destination address exists, (5) permitted by output
filters.
The list command now displays the filter table
shown in Figure 4.
NetBlazer Examples
This has two undesirable side effects: (1)
The following examples apply to a NetBlazer domain name service from ftp.telebit.com is no
with a synchronous interface (syn0) to the Alternet longer available to the Alternet and (2) the default of
and several local area network connections. deny is now applied to all outbound traffic. In a
prototype that Telebit showed to some customers,
The filter commands shown in Figure 2 would
there were separate defaults for input and output.
limit inbound access to internal network to ftp, mail,
Having more than one default behavior was some-
news, and domain name service requests directed to
times useful, but often very confusing. The side
the host ftp.telebit.com.
effects can be corrected with the following two com-
The NetBlazer permits shortening commands to
mands:
the shortest unique abbreviation and specifying an IP
deny 143.191/16 syn0 udp !=53 output source
address instead of a host name. The permitcom-
permit any syn0 output source
mand in figure 2 could have been specified as:
The list command now shows the results displayed
p 143.191.3.1 syn0 tcp 20 21 25 53 119 i d
in Figure 5.
The list command displays the filter table shown in
The following filter command prevents an
Figure 3.
external host from spoofing the authentication server
The filter facility has an implied on/off switch
by pretending to be a host on the 143.191.1 network
which operates on a per interface per direction basis.
and sending a host route in a RIP packet to the gate-
Because no filters exist in the output direction, out-
way.
bound traffic is not filtered. When the first filter is
deny 143.191.1/24 143.191.1/24 syn0
created, a complementary default behavior is created
The list command shows the results displayed in
at the same time. Adding an outbound filter enables
Figure 6.
filtering in the outbound direction. For example, to
forbid the transmission of any UDP packets from the
143.191 network:
filter
permit ftp.telebit.com syn0 tcp 20 21 25 53 119 input dest
Figure 2: Filter commands limiting inbound access
Source Destination Interface Protocol I/O Permit/Deny
143.191.3.1/32 syn0 TCP In Permit
port rules: =20 =21 =25 =53 =119
Default syn0 In Deny
Figure 3: Result of list command
Source Destination Interface Protocol I/O Permit/Deny
143.191.3.1/32 syn0 TCP In Permit
port rules: =20 =21 =25 =53 =119
143.191.0.0/16 syn0 UDP Out Deny
Default syn0 Deny
Figure 4: Filter table after forbidding UDP packets
Source Destination Interface Protocol I/O Permit/Deny
143.191.3.1/32 syn0 TCP In Permit
port rules: =20 =21 =25 =53 =119
143.191.0.0/16 syn0 UDP Out Deny
port rules: !=53
any syn0 Out Permit
Default syn0 Deny
Figure 5: Listing after correcting side effects
230 LISA V  Sep. 30-Oct. 3, 1991  San Diego, CA
Corbridge, Henig, & Slater Packet Filtering in an IP Router
Because input or output was not specified, the
Maximum Total Packets Per Second Throughput
NetBlazer created both an input filter and an output
Type of Filters PPS Hit Rate
filter. The list command displays filter table entries
(Per Cent)
in the order in which they are searched. Input filter
Address and Protocol 320 -
lookup is done first then routing table lookup, then
Address Only 440 77
output table lookup. The most significant network
None 470 81
number (the ones with the most bits) are searched
Background Traffic 100 64-byte pings per second (200 PPS total)
first.
Foreground Traffic: 1500-byte packets
Performance
Future Work
Studies indicate that traffic through routers
The NetBlazer needs to provide more flexibility
tends to flow between pairs of addresses [10, 16].
in the way it deals with ICMP. It should distinguish
While a cache size of two entries, Heimlich observes
between different ICMP packet types and provide
a hit rate of 0.48 doing wide area routing and 0.38
customer selectable notification options including no
doing LAN-to-LAN routing. With a cache size of
notification and a choice of Destination Unreachable
16 entries, hit rates exceed 90 per cent [10].
type including the new RFC1122 defined types
The NetBlazer has a simple two-entry cache in
shown in Figure 7.
which routes to the source address and destination
We would like to spoof TCP connections with
address of the last packet are stored. If address-only
the NetBlazer and map one connection in to two.
filters are used, the appropriate filter tables are first
This would hide the the Internal Network from the
checked. If permission to route the packet is granted
outside world without requiring modification of
the address is cached. The cache is not used when
application software. Options to filter on protocol
port filtering is enabled on either the input or output
source port and to log filter decisions are needed.
interface. Our observations of NetBlazers used to do
Ethernet-to-Ethernet routing internally at Telebit find
Conclusions
cache hit rates typically between 80 and 90 per cent.
By providing powerful, flexible filters, the Net-
So far, we have not seen hit rates below 25 per cent.
Blazer minimizes the number of interfaces the sys-
Throughput was measured between two Ether-
tem administrator must deal with. One-line com-
nets with a filter table size containing four entries.
mands make it easy to modify, list, and test the filter
The NetBlazer CPU is a 16-Megahertz Intel 386/SX.
set.
One way traffic from one host to another via the
The NetBlazer uses simple internal data struc-
NetBlazer was varied until the maximum number of
tures to provide security filters while maintaining a
packets routed by the NetBlazer was observed.
performance level that is at least 50 per cent as fast
While this was being done, 100 ICMP Echo
as routing without filters. A global two-entry cache
Requests and 100 ICMP Echo Replies per second
can provide average hit rates that range from 25 to
were sent between a second pair of hosts to generate
90 per cent. By making this cache two entries per
background traffic.
interface, performance can be further improved.
Source Destination Interface Protocol I/O Permit/Deny
143.191.3.1/32 syn0 TCP In Permit
port rules: =20 =21 =25 =53 =119
143.191.1.0/24 143.191.1.0/24 syn0 In Deny
143.191.1.0/24 143.191.1.0/24 syn0 Out Deny
143.191.0.0/16 syn0 UDP Out Deny
port rules: !=53
any syn0 Out Permit
Default syn0 Deny
Figure 6: Listing after correcting for spoofing
9 = communication with destination network administratively prohibited
10 = communication with destination host administratively prohibited
Figure 7: Two new RFC1122 defined types
LISA V  Sep. 30-Oct. 3, 1991  San Diego, CA 231
Packet Filtering in an IP Router Corbridge, Henig, & Slater
Author Information the Amateur Packet Radio Network Using the
KA9Q Internet Software", Version 1.0, May 9,
Bruce Corbridge received an electronic
1990
engineering degree from DeVry Institute of Techno-
[8] Goldberg, David S., "The MITRE User Authen-
logies in 1974. Over the past sixteen years, he has
tication System", USENIX Security II
been employed as a test engineer and technical
Workshop, Summer 1990, pp. 1-4.
writer for several companies in Silicon Valley,
[9] Hedrick, C.L. "Routing Information Protocol",
including ISS Sperry Univac, Diablo Systems and
RFC 1058, June 1988
Convergent Technologies. He is currently working as
a technical writer in the Network Products division
[10] Heimlich, Steven A., "Traffic Characterization
at Telebit Corporation in Sunnyvale, CA. Reach him
of the NSFNET National Backbone", USENIX
via U .S. Mail at Telebit Corporation; 1315 Chesa-
Washington, D.C. Conference Proceedings,
peake Terrace; Sunnyvale, CA 94086-1100. Reach
Winter 1990, 0.25i7-227.
him electronically at uunet!telebit!bac or
[11] Honig, Jeffrey C., "Gated(8)" manual, Cornell
[e-mail] .
Theory Center, Cornell University, Ithaca, NY
Robert Henig received an BSCS from January 1989.
Northeastern University in 1984. He then spent six
[12] McNeill, Keith, "SUMMARY: Need firewall
years working for Intel Corporation in network pro-
telnet/ftp gateway", Electronic Newsgroup:
gramming and network management roles. He
alt.security, May 8, 1991.
joined Telebit Corporation in Sunnyvale, CA in Janu-
[13] Mogul, Jeffrey C., "Simple and Flexible
ary, 1991 to develop software for the NetBlazer.
Datagram Access Controls", USENIX Baltimore
Reach him via U. S. Mail at Telebit Corporation;
Conference Proceedings, Summer 1989, pp
1315 Chesapeake Terrace; Sunnyvale, CA 94086-
0.25i3-221.
1100. Reach him via electronic mail at
[14] Mogul, Jeffrey C., "Re: well-behaved firewalls",
uunet!telebit!rhenig or [e-mail].
Electronic Newsgroup: comp.protocols.tcp-ip,
Charles Slater received an MS in Social Science
June 25, 1991.
from the California Institute of Technology in 1980.
[15] Nussbacher, Henry, "Comparison of Multiproto-
After spending 10 years in support organizations
col Routers", Version 1.7, Electronic Mailing
helping various Silicon Valley companies work
List: [e-mail], November 1990
around flaws in network products, he decided to go
[16] Paxson, Vern, "Measurements and Models of
to work for a manufacturer to see if he could do a
Wide Area TCP Conversations", Computer Sys-
better job than his former vendors. He has spent a
tems Engineering Department, Lawrence Berke-
little more than a year Telebit Corporation in Sun-
ley Laboratory, University of California, Berke-
nyvale, CA writing software for the NetBlazer.
ley, CA, LBL-30840, May 1991.
Reach him via U. S. Mail at Telebit Corporation;
[17] Postel, J.B., "Internet Protocol. RFC 793", Sep-
1315 Chesapeake Terrace; ; Sunnyvale, CA 94086-
tember 1981.
1100. Reach him via electronic mail at either
uunet!telebit!cslater or [e-mail] . [18] Postel, J.B., "Internet Message Control Protocol.
RFC 792", September 1981.
References
[19] Postel, J.B., "Transmission Control Protocol
[1] Braden, R.T., "Requirements for Internet Hosts RFC 793", September 1981.
 Communication Layers RFC 1122", October
[20] Postel, J.B., "User Datagram Protocol. RFC
1989
768", August 1980.
[2] Braden, R.T.; Postel, J.B., "Requirements for
Internet gateways. RFC 1009", June 1987
[3] Bradner, Scott O., "Testing Multiprotocol
Routers: How Fast Is Fast Enough?", Data
Communications, February 1991, pp 70-86.
[4] cisco Systems, Inc., "Gateway System
Manual/Software Release 8.2", Menlo Park, CA,
November 1990.
[5] Carlin, Jerry M., "Internet Gateway Security
Checklist", USENIX Security II Workshop,
Summer 1990, pp. 145-147.
[6] Cheswick, Bill, "The Design of a Secure Inter-
net Gateway", USENIX Anaheim Conference
Proceedings, Summer 1990, pp 233-237.
[7] Ford, G. E., "Beginner s Guide to TCP/IP on
232 LISA V  Sep. 30-Oct. 3, 1991  San Diego, CA