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.