Note: This is a ASCII'ized draft of a yet to be published paper on the
KarlBridge.  It is provided here in draft form for reference to convey
the philosiphy of and uses for the KarlBridge. It is copyrighted by
Doug Karl, Ohio State University.

Comments to kbridge@osu.edu are welcome!!  Thanks.
------------------------------------------------------------------------

		  Modern Campus Networks Demand Inexpensive,
		Robust and Easy to Configure Filtering Bridges.

Today's campus networking needs are growing beyond the capabilities of the
current bridge and router technology. This growth has provided unprecedented
access to diverse computer resources and has also brought many challenges.
Configuration and security problems are common due to the existence of
publicly accessible computer labs, campus wide file servers, CD-ROM servers,
and Telnet, SLIP and PPP servers accessible by modems. These problems can
be easily be remedied by the use of a new and inexpensive 286 based filtering
bridge program called the KarlBridge that has been developed and tested at
The Ohio State University. The KarlBridge is unique in that it was designed
for large diverse campus and enterprise wide LANs. It is robust in its
ability to filter different types of LAN traffic and is very easy to configure
by the use of simple menus. It is ideal for localizing LAN traffic within a
computer cluster by providing a "fire wall" for unwanted, unneeded and
erroneous packets. The KarlBridge has been optimized to help stop the "leaks"
that are inherent in normal Ethernet bridges and is an excellent tool to
manage growing networks. The KarlBridge program and instructions on how to
acquire and/or make one is available on the Internet via anonymous ftp.

THE KarlBridge SOLVES PROBLEMS FOR PUBLIC LABS

Many of the 4300 computers connected to the OSU network are housed in 33
"Public" labs. These labs contain Macintoshes or PCs, file servers, and
pay-per-page laser printers. Many of the computers are available for use
by the public and have Telnet and FTP capability along with network support
for the file servers and printers in the lab.

The users simply walk into the room, sit down at a PC and expect to be able
to down load programs from the file servers and print on the network connected
printers. The problem is that the PC's in these labs are connected to their
building's Ethernet segment and in many cases to adjacent buildings via fiber
repeaters. This connectivity is necessary for Telnet and FTP capability to the
campus and Internet but has several undesirable side effects.

	INTERNET AUTHENTICATION

One of the problems with connecting public labs to the campus network is that
they also become connected to the Internet.  OSU is a part of the Internet
community where it is generally considered good practice to only allow
"authenticated" access outside one's university.  A user is considered
"authenticated" if he has logged into a system with a name and password
prior to gaining access to the Internet. This is difficult to enforce when
publicly accessible micro-computers are connected to a campus network.
Some IP routers have capabilities to restrict IP traffic, and we have
considered putting one at the entrance to each lab, however, this solution
is expensive and has several limitations.

	OTHER ROOMS AND BUILDINGS ON THE SAME MAC OR PC LAN

An IP router at each lab would not allow us to pass other protocols than IP
and would only allow us to simply restrict packets by IP address. In some
labs there are non-IP Macintosh and PC file servers that need to communicate
with computers outside the lab, an IP router would route only IP. We have
common printers accessible via Macintosh's Ethertalk or various PC network
protocol's such as Novel, Banyan, LanManager, Lantastic, etc. We want the
users in one lab to communicate with their file server or networked printer
but not the file server or networked printer in the adjacent lab, or down the
hall, or in an adjacent building or in a faculty office. The printers in each
lab are pay-per-page printers and it is not at all desirable for users to be
able to print on free printers outside the lab. A common condition with
Macintoshes is to have printers and file servers appear in the "chooser" and
have no idea where there are located. Two printers appeared recently as an
option in a public Macintosh lab's  "chooser" and after several weeks of
investigation they were found to be located in a remote research lab inside
a neighboring building.

Two Novell file servers, each in a different departments or public labs, but
on the same repeated or bridged Ethernet, can adversely interfere with each
other. This is difficult to avoid since it is common that the personnel in
neighboring buildings or on different floors of the same building are unaware
of each others activities and they usually pick #1 as a network number. Public
lab files servers can conflict with departmental faculty or administrative
file servers. This problem is not unique to Novell, similar problems are
experienced with other PC and Macintosh LAN's

	THE USE OF LANWATCH PROGRAMS

Internet authentication and PC Lan isolation are not the only problems faced
with public labs. We also have the problem of students running any of the
publicly available network listening programs, such as LANWATCH. They can use
it to capture packets from other computers on their Ethernet segment and look
at passwords and data. It is not unusual for the labs to share the same
Ethernet segment with faculty offices which makes listening on the network
more interesting and more dangerous.

	TELNET'ING TO SMTP SOCKETS

Finally, at the irritant level, is the the ability of the public to Telnet to
an SMTP socket to create bogus e-mail.  Anonymous junk and prank mail can be
easily sent to the SMTP socket of a machine without any danger of its
originator being detected.

SITE LICENSE PROBLEMS WITH CD-ROM DATABASES AND CAMPUS FILE SERVERS

Many of the software packages that we used are purchased under a "site
license" agreement. Anyone can use these programs on our computers but not
persons outside of our campus. We violate our site license agreement when we
install these programs on campus wide file servers having IP connectivity,
unless we restrict access to on campus users only.

Our CD-ROM servers can be can be accessed from any machine on campus via
telnet. This also means that they can be accessed from anywhere on the
Internet, a violation of our CD-ROM license agreements. If someone from
outside OSU wants to use a CD-ROM that is licensed to OSU there is nothing
preventing them without the addition of a filtering bridge at the CD-ROM
server.

DIAL IN & OUT MODEMS CONNECTED TO THE NETWORK

We have several dial-in and dial-out modem lines connected to the campus
network and hence the Internet. They act as forward or reverse Telnet
terminal servers and are access points for unauthenticated users. It is not
desirable for users outside of OSU to simply Telnet to the modem pool and
dial any local number. Likewise we don't want anyone to dial into the modem
pool and have unauthenticated access to the Internet. These are some of the
common "security holes" that RFC 1173 has recommended plugging.

SECURE SYSTEMS CONNECTED TO THE NETWORK

There are some computer sites that wish to access the network but they have
great restrictions as to which computers they wish to have access to their
systems. One of our VAX sites wanted to communicate via DECNET to the Cray
system and wanted to send and receive SMTP mail but did not want any
possibility for network users to log into their systems or transfer files.
Until we were able to make an affordable filtering bridge with very strict
filtering capabilities, these types of users were unwilling to join the
network even though they had requirements for its services.

SOLUTION:

Filtering bridges have the capability to solve these networking problems but
have had primitive and difficult to configure filters and have been to
expensive to use widely throughout a campus network. To solve this problem we
wrote a special filtering bridge program. We have used standard 286 clones
containing 2 Western Digital 16Bit "Elite" Ethernet cards along with the
KarlBridge filtering bridge program to construct a reliable, inexpensive, and
easy to configure filtering bridge. The hardware is assembled, configured and
tested by a local company, "NetTek", and has proven to be very reliable.

The idea for this approach came from a public domain bridge program from
Northwestern University called pcbridge. However, the KarlBridge program,
a complete rewrite, greatly surpasses the packet forwarding rate of pcbridge
and compares favorably with commercially available non-filtering bridges.
The KarlBridge supports 2 Western Digital Ethernet boards, allows for
several configurable filters, and has IP/ICMP "Ping" support.

To solve the Internet Authentication, Telnet'ing to SMTP and site license
software problems, we have configured the KarlBridge's filters to allow IP
connections only to machines within our network 128.146.x.x and not to the
SMTP socket. We place these bridges at the entrance to our public labs which
allows public lab users to Telnet and FTP to machines on campus but not off
campus. These same filters are used on bridges connected to our dial in and
dial out modem pool.  This allows dial in users to Telnet into on-campus
machines only, and not to any SMTP sockets. Likewise our dial out modems
can only be accessed from on campus. We use the KarlBridge with the same
filter connected to our campus wide CD-ROM servers and file servers. This
will ensure that only users from within our campus have access to those
systems honoring our site license agreements.

The KarlBridge helps protect against users viewing others packets (by use
of a LANWATCH type program) since it only allows packets that pass its
strict filter to enter the computer cluster or public lab. The KarlBridge
also has options for restricting the "leakiness" of standard bridges. Since
the KarlBridge will not pass packets that do pass its filter much fewer
packets "leak" through the bridge. Also, Multicast and Broadcast packets and
packets to unknown Ethernet addresses can be selectively restricted. This
feature helps reduce unwanted or unneeded packets from entering or leaving
the local computer network.

The KarlBridge has been configured with filters to disallow Apple's EtherTalk
to flow between labs. This isolates one lab's printers and file servers from
the others, and has solved the problem of users from one lab printing on
printers that are not within their lab.

BRIDGE PERFORMANCES TESTS:

We have done several performance tests on the KarlBridge, the Northwestern
University's pcbridge program, and some commercial bridges. The intent is not
to compare commercial bridges with each other but to ascertain the relative
performance of the KarlBridge as compared with some commercial bridges we had
access to. There were two types of tests performed at several packet sizes.

The first table shows the packet forwarding rate of the bridges at each of
several different packet sizes. Different bridges forward packets at
different rates depending upon packet size. As can be seen from the tables,
the KarlBridge performs well forwarding packets of all sizes.


	Packets Forwarded per Second For Several Packet Sizes

Pkt Size:		   64	   128	   256	   512	   1024	   1500

Ideal Bridge		 14200	  8220	  4460	   2330	   1190	   820
HP 28673A		 10360+	  6950+	  4050+	   2215+   1160+   805+
LanBridge 100		 10360+	  6950+	  4050+	   2215+   1160+   805+
Allied Telesis		*10215	 *6900	 *3600	  *1650	   *900   *700
KarlBridge		  8100	  5800	  3645	   2130	   1145	   780
Retix 224		  7500	  6400	  3875	   2160	   1145	   800
pcbridge		  8160	  4300	  2200	   1110	    550	   370

All tests were done under 90% network load.
+ This is the maximum number of packets per second our LANalyzer could put out.
* Estimate due to erratic behavior


The second graph shows the delay that a bridge imposes on a given packet that
is forwarded through it. The "forwarding delay" is the number of microseconds
from the start of the packet as it enters the bridge to the start of the
packet as it is transmitted out the other end. This delay varies between
manufacturer depending upon the bridge's architecture, which Ethernet chips
are used, and how the bridge's algorithm is optimized. The theoretical bridge
is one in which the instant the packet is received it is transmitted out the
other port. This theoretical packet forwarding delay will be greater for
larger packets since larger packets take longer to receive. Bridges, like
the KarlBridge and Northwestern's pcbridge, that copy the packets from their
receive buffers to their transmit buffers will display slower forwarding
delays for large packets and good forwarding delays for short ones. As can be
seen from the graphs the KarlBridge has very good delay times for short
packets (less than 200 bytes) but is slower than the commercial bridges when
forwarding larger packets. This type of performance is very encouraging since
the typical network passes predominantly short packets.

	Packets Forwarding Delay in MicroSeconds For Several Packet Sizes

Pkt Size:		 64	 128	 256	 512	1024	1500

Ideal Bridge		 60	 100	 200	 400	 800	1200
HP 28673A		 92	 132	 232	 432	 832	1232
LanBridge 100		 120	 160	 260	 460	 860	1260
Allied Telesis		*135	*190	*325	 580	1100	1600
KarlBridge		 140	 225	 400	 725	1400	2000
pcbridge		 140	 250	 450	 850	1600	2400
Retix 224		 200	 250	 350	 550	 950	1350

All tests were done under 10% network load.
* Estimate due to erratic behavior

CONCLUSION:

The KarlBridge is an excellent choice for coping with growing campus networks.
It solves several network problems, including Internet authentication, SMTP
pranks, management of printer and file server resources, and site license
requirements. It has very flexible filters, good performance, and is
inexpensive.

SIDEBAR -> What makes an Ethernet bridge a "filtering" Ethernet bridge?

Filtering Ethernet bridges perform the same functions as normal Ethernet
bridges with the additional capability to look into the data portion of each
Ethernet packet and forward or drop it based upon its contents. Normal
bridges do filter in a sense, since the nature of a bridge is to pass some
Ethernet packets and drop others.  This is however only based upon Ethernet
address as it is automatically "learned" by the bridge software. Typically
things like Ethernet protocol type (DECNET, IP, XNS, IPX, AppleTalk, etc),
IP address, IP socket number, DECNET address, and DECNET object number are
evaluated to determine if the packet is to be dropped.

SIDEBAR -> Is a 286 a reliable platform to use as a bridge?

We have found that the 16Mhz - 286 platform is excellent for making network
bridges, monitors and special function devices. There is clearly a problem
with the quality of many PC clone parts. This has been overcome by setting
up our supplier with heat test chambers and strict guidelines as to testing
prior to shipment. Without these extra procedures we had noticed a 10 to 20%
infant mortality rate. With the extra burn in and careful screening of
suppliers we have decreased this to much less than a 1% infant mortality rate.
As with all electronic equipment if it passes the first few weeks without
failure it will last for several years.

SIDEBAR -> Knowing your bridge; Why are bridges leaky and vulnerable to bad
	   Ethernet packets.

The standard bridging algorithm is very general and will not interfere with
normal Ethernet traffic, however, it does deserve further study. The first
thing to point out is that for every packet the bridge receives the source
address is examined, and if a new one is discovered it is added to the
"learned address" table. This table contains one entry for each unique
source address seen and the port it was received on. The destination
address of each packet received is examined to determine if the bridge
should forward it or drop it. The bridge always forwards broadcast packets
(destination address = FFFFFF) and also Multicast packets (destination
address has the first bit equal to 1). If the destination address is not a
broadcast or Multicast and is not found in the "learned address" table it is
forwarded by default. The only condition where a packet is dropped is if its
destination address is found in the "learned address" table and determined
to be associated with the same port it was received on.

This algorithm has some undesirable side effects.

     1) If the "learned address" table is not large enough to hold all of
	the different source address seen then it will become overwhelmed
	and subsequent packets will be forwarded by default.
     2) If an Ethernet interface fails in a mode where it sends out
	erroneous data (a common failure mode) it will be forwarded (since
	its destination address is random and will be considered a Multicast
	address %50 of the time or not in the "learned address" table the
	rest of the time) but it will also flood the "learned address" table
	with random source addresses.

     3) Many bridges age their "learned address" tables and clear them out
	periodically if a machine is not communicating with the network (a
	common event when PC's are shut off) then the bridge will not have
	its source address in the table. Any packets destined for this "shut
	off" machine will be forwarded by default, a phenomenon we have seen
	often.

The KarlBridge algorithm can be configured to plug up most of the leaks
mentioned above. The KarlBridge's "learned address" table contains 4096
address entries many more than any Ethernet could contain. The KarlBridge
drops packets immediately if they do not pass its filter. The source address
of the packet received is not added to the "learned address" table unless it
passes the filter. When an Ethernet interface on the network fails and floods
the network with erroneous packets, they will most likely be dropped
immediately since they will not pass the filter. The KarlBridge has an option
to shut off the default forwarding after a certain predetermined time which
will not effect most network protocols such as IP and will plug this hole.
