1. University of Illinois, Urbana-Champaign David Dougherty CS 292 Senior Project Jeong-Woo Kim Team 8Matthew Nisnevich Djordje Pejovic Peter Stoimenov PARALLEL FIREWALL INTERFACECISCO SYSTEMS SUSAN HINRICHS, SPONSORFINAL REPORT December 10, 2001

2. Contents1. Preface.2 2. Introduction.3 2.1 Advantages4 2.2 Current Architectural Design5 2.3 Previous Solution..7 2.4 Real World Scenarios8 2.5 Constraints...10 3. Requirements.11 3.1 Introduction..11 3.2 Overview..11 3.3 Benefits12 3.4 Detailed Solution.13 3.5 Testing..15 3.6 Potential Customers.16 3.7 Technical Constraints...18 3.8 Summary..19 4. Design20 4.1 Hardware Usage...22 4.2 Cisco Router.21 4.2.1 Basic Router Hardware Components22 4.2.2 Router Installation Process...23 4.3 Parallelism24 4.4 Content Filtering..24 4.5 100Mbit Networking25 4.6 Load Balancing Algorithms.26 4.6.1 Hash Function...26 4.6.2 Dynamic Traffic Counter..28 5. Implementation..32 5.1 Initial Setup..32 5.2 Preprocessor Machines Setup..33 5.3 Behind the Firewall Setup37 5.4 Routing Problems38 5.5 Bridging Problems...39 5.6 Network Monitoring Tools..40 6. Plans for Spring Semester..42 6.1 A Decision...42 6.1.1 A New Timeline, Part One42 6.1.2 A New Timeline, Part Two...45 6.2 Algorithm Implementation..48 6.3 Additional Function Implementation..49 6.4 Documentation50 6.5 Fault Tolerance Research50 2 3. 7. Conclusion.51 3 4. 1. Preface The separation of connections through firewalls makes them exceptionally goodcandidates for parallelization. This is stems from the basic notion firewalls work on eachindividual traffic stream independently, making a parallel framework of firewalls a likelyand beneficial extension of this interface due to the enhanced reliability, reduced deviceload and the overall speed increase.According to Susan Hinrichs, the communication required for distributed [data]structures is one of the major overheads of parallelization. In her PhD thesis research,she further found that differences in the architectures of different parallel systems affecthow communication models perform on these systems. To minimize communicationoverheads, the parallel application should use the communication model that performsbest on the target machine. For many systems, a connection-based communication modelenables more efficient resource usage and improved communication performance.The goal of this project is to design and implement such a framework for multiplefirewalls working in parallel. Specifically, our project is designed to test the practicalityof implementing identical firewalls in a parallel fashion. The resulting solution would betransparent to the users and provide an increase in firewall processing bandwidth asopposed to a single firewall. Our group aims to deliver the solution design, as well as,statistics demonstrating the performance improvement to our sponsor, Cisco Systems.4 5. 2. IntroductionThe foremost goal of this project is to develop a driver component into the Linuxkernel/networking stack, which will distribute network traffic streams between a numberof independent firewalls.This driver will run on a pre-processing machine to beprovided by Cisco. There are various possibilities for the traffic-splitting paradigm to beused. Obvious choices include dividing the traffic by connection type, by destinationaddress, or by bandwidth requirements. Since the overall goal of this project is toincrease throughput by distributing the work of a single firewall among multiple devices,the final product will likely use a combination of these methods to achieve maximumresults.Additionally, a major goal is to determine a realistic suite of benchmarks so that thebenefits of the parallelism may be measured. This would include simulating traffic fromhundreds of different hosts, and monitoring the effectiveness of the division of the trafficstreams. Throughout the course of the project, these benchmarks will be used tocontinuously refine and rethink the algorithms by which the traffic is divided.Furthermore, data from this benchmarking can be provided to Cisco to demonstrate theviability of this implementation.At the projects conclusion, it is hoped that we can provide Cisco with working drivercode that is extendible to any number of firewall devices, as well as data demonstratingthe advantage in throughput gained by our implementation.5 6. 2.1 AdvantagesThe advantages of a parallel interface such as the one proposed are seeminglyobvious, but there are far-reaching subtleties, which increase the value of such a systemeven more. The primary benefit is to increase throughput. That is to say, if a singlefirewall device can process X bits of information per second from a given network trafficstream, it is hoped that by dividing the workload from this traffic stream among multiplefirewalls the total system will be able to process kX bits per second, where k is somequantifiable and measurable number. In addition, if the pre-processing machine which does the splitting of the trafficstream is sufficiently efficient, it is quite possible that the proposed implementation willreduce the overall cost of the firewall framework by allowing cheaper firewall devices tobe used in parallel, as opposed to a single expensive firewall device which is capable ofhandling an equivalent amount of traffic. The cost comparison is a somewhat easiermetric to measure than the throughput comparison, as the cost of all devices used isreadily available. The total cost of our implementation will be measured by Cost of Pre-processing Machine + n * Cost of Firewall Device for an n-way parallel interface. Using the performance benchmark results, it can bedetermined what value must be assigned to n in order to achieve the desired throughput.This cost can then be compared to the price of a higher-end firewall device to determinesavings versus throughput.6 7. Yet another benefit of the parallel framework is in the inherent redundancy of thesystem. That is, if a single device in the system fails, the traffic can be redirected to otherdevices as specified by an as-yet-undetermined algorithm within the driver code. Thus,whereas when using a single firewall, device failure means the cutting-off of the entirenetwork connection, using a multiple-firewall configuration will allow the connection tobe preserved while maintenance of the device is carried out. Moreover, as the potentialthroughput of the system is reached, more devices can be added easily to raise thatceiling, increasing the throughput of the entire system. 2.2 Current Architectural DesignThe architecture of the parallel framework has yet to be determined. The general layout of the system is as follows: 7 8. Figure 1 It is already known that the pre-processor will be able to communicate with theindividual firewall devices by MAC address, making a switch or a hub the most cost-effective (and simplest) way of implementing the above diagram. This implies that thepre-processor Linux box will only require two network interface cards (NICs), which canbe referred to as the external interface and the internal interface, respectively. While the specifics of the hardware involved in the pre-processor have yet to bedetermined, it has been decided that Cisco 2514 routers will be used for the firewalldevices. Optionally, the system will also need to incorporate a failure-detectingmechanism so that when one firewall device fails, its traffic can be routed to the other8 9. devices, either by one device taking on the workload of the failed device, or by splittingthe traffic from the failed device among the other n-1 devices. It is assumed that thisfunctionality can be incorporated into the Linux kernel/networking stack driver code. 2.3 Previous Solution The general layout of the last years architectural design for the parallelframework project can be summarized in the following diagram. A quick comparison between the two architectures reveals that the solution proposed lastyear, while still impressive, does not capitalize completely on the benefits ofparallelization. Furthermore, it requires that for every client on the subnet there has to bean IOS firewall device. The impracticality of this solution is especially evident when wetake in consideration that the typical corporate internal network can have hundreds if notthousands of clients. 9 10. 2.4 Real World Scenarios The most likely use of this parallel firewall framework is to provide low-cost securityto a number of internal hosts on a LAN. When the firewall detects unexpected packets inthe traffic stream, it can drop the packet, drop the connection, or actively reset theconnection. By splitting this traffic stream analysis among multiple devices in a simpleand cost-effective manner, security for an internal LAN can be provided withoutsacrificing bandwidth. Scenario 1: Corporate LANSamantha Fox is the IT manager for a Fortune 500 company. The corporateheadquarters have an internal network with several hundred clients, and she wants toallow them to have secure access to the outside Internet. Information security, as wellas, cost effectiveness is big issue for this company, especially because of the newreality of economic downturn combined with increased security concerns. The CIO hasapproved the lease of a single OC32 line from the local telecom, but leaves it up toSamantha to set up the security. She contacts the nearest Cisco VA and purchases abunch of low-cost Cisco 2514 routers and Ciscos Parallel Firewall Interface software.Utilizing an older Linux box to run the Parallel Firewall Framework software, she isable to deliver a secure, reliable and inexpensive security solution, without sacrificingthe integrity of the corporate internal network. The Chairman of the Board of Directorsis impressed. Samantha becomes the new CISO (Chief Information Security Officer).10 11. Scenario 2: The Russian Frarority (Fraternity+Sorority) The Russian Frarority at UIUC is renting several apartments in a private housingbuilding this school year. Most of the members are CS majors and many of them arenotoriously famous for their addiction to broadband Internet access, especially Andreyand Max. Since Russians in the US are particularly notable for their frugality, theydecide to share a common broadband connection leased from AT&T. The problem isthat, that their LAN is vulnerable from the DDoS attacks of a vicious Swiss-Macedonian hacker organization. Matt Motya, the go to high-tech expert for the Russian community has beencalled upon to solve the problem. He does not have much money to work with, butMatt happens to have an old Linux box lying in his room (he is a hardware fanatic),which he decides to put to good use as a preprocessor for the parallel firewallframework. A single router is capable of handling the relatively low bandwidth of thebroadband connection, but Matt uses the Parallel Firewall software to scale thefirewalls bandwidth utilizing several of the more powerful PCs of some of the peopleliving in the Russian Frarority. Another benefit would be that he can monitor the trafficcoming into and out. All members of the Russian Society are impressed with Motyas work. One of themembers of the Russian society is especially impressed, Marina. She decides to askMatt out to personally express her admiration for his insightfulness.11 12. 2.5 Constraints The constraints of this system have yet to be determined, but it is expected that asbenchmarking proceeds they will make themselves evident. Presumably, there will be apracticality cap as to the number of firewall devices that can be handled by a single pre-processing machine. It is also possible that introducing additional layers into the networkstack will slow down processing, and/or that introducing the pre-processor into the trafficstream will reduce bandwidth. These are all issues that will be explored throughout theprojects lifespan. 12 13. 3. Requirements3.1 Introduction Our project, the Parallel Firewall Project, is designed to test the practicality ofimplementing identical firewalls in a parallel fashion. The resulting solution would betransparent to the users and the rest of the network as well as provide an increase infirewall processing speed as opposed to a single firewall. Our group aims to deliver oursolution design as well as statistics, demonstrating the performance improvement, to oursponsor. 3.2 Overview The primary goal of our project is to prove through statistics that animplementation of firewalls in a parallel framework is both financially and technicallyfeasible. We will attempt to do this by directly modifying the network drivers underLinux to distribute and track the traffic through a parallel firewall framework. The drivermodification will contain a load-balancing algorithm to ensure the following constraints: Content Filtering must be able to operate as it would under a single firewall. No single firewall should be loaded with a disproportionate amount of traffic. The algorithm should be efficient enough to not hinder bandwidth. Additional firewalls should be detected automatically Malfunctioning firewall devices should be bypassed. 13 14. The modified driver will be present on two computers, hereafter called the Pre-Processing machines. These two machines reside on both sides of the firewall array,splitting and recombining streams, in a manner that is transparent to users and the rest ofthe network setup.As monitoring and recording the amount of traffic flow will be critical todetermining the technical feasibility of our solution, we will use a variety of networkperformance monitoring tools to provide us with data representing the increase ordecrease in traffic flow due to our solution. This data will be our key delivery to oursponsor. 3.3 BenefitsThe primary benefit of parallel firewall architecture is the ability for customers toincrease the bandwidth through their firewall configuration without purchasing aproportionately more expensive large firewall device. The increase in price for a newfirewall is typically greater than increase in performance. Our implementation will let theuser achieve the same level of performance that a new firewall would provide withouthaving to scrap the existing one. Also, since the addition of a new firewall would behandled automatically, there would be no additional labor costs. In this manner thefirewall becomes much more modular and cost-effective from a performance point ofview.From a reliability standpoint, the parallel firewall architecture provides anincreased amount of reliability among the firewalls.In a single firewall deviceconfiguration, if the firewall fails then the Internet connection of the customer becomesunavailable. In a parallel configuration, having a single device fail does not block14 15. Internet and network access, the load is merely shifted to the other firewall devices. Thusthe parallel firewall architecture employs firewalls for redundancy much as RAID 5employs redundancy for data storage. 3.4 Detailed Solution The specific problem that our team will face will be the distribution of the trafficamong the firewall devices in a manner that is transparent, is properly balanced amongthe devices, and is efficient enough to provide a bandwidth advantage as opposed to asingle firewall device. The entire architecture must be transparent from the user point of view. Thusanyone who is not the network administrator monitoring the firewalls should not be ableto see or affect the preprocessors or determine that more than one firewall is in operation.15 16. As the above diagram shows, the architecture is symmetrical. This is becausetraffic flows in two directions, hence a pre-processing machine must appear on bothsides. The switches represent some sort of 100TX Ethernet hub or switch to physicallyconnect all of the devices together. It is best to use a switch since every host connectedto it will get full duplex 100 megabit connection, as opposed to a hub that splits 100megabits between all its connections.To ensure that the traffic is balanced properly, we will use an algorithm whichincorporates both session tracking and volume counting. The session tracking is requiredto allow the content filtering found in the Cisco IOS Firewall Feature Set to function.Simply put, if all of the packets from a TCP session do not go through the same firewall,the content filtering is unable to properly track the session numbers and the firewallsblock the valid session. We believe that our caching tables implemented alongside theload-balancing algorithm will allow content filtering to function as specified for a singlefirewall.One side function that we will have to implement is a form of message passingbetween the two preprocessors. In order for the content filtering to work, the twopreprocessors must both send the packets for a single session through the same firewall.By using Linux as the operating system on the pre-processing machines, webelieve that we will be able to modify the networking code at the kernel level and be ableto keep the computer processing associated with load balancing small enough to notaffect throughput significantly. This will be heavily tested.16 17. In addition, we plan on incorporating functions that will provide an ability toswitch traffic between firewalls, such as in the case of a firewall device failure. At thistime, we are uncertain as to the method of implementation of those functions. 3.5 Testing To determine the benefits of a parallel firewall framework, we will do extensivebenchmarking to ascertain the bottlenecks and speed increases with different hardwareand algorithms. First we will need to measure the throughput from one pre-processor tothe other. Since that path is not inhibited by any processing, an addition of a firewallshould present a decrease in overall throughput. If no decrease is seen when using anaggressive firewall configuration, then the pre-processing machines are not able to supplytraffic fast enough and they will need to be upgraded. There are certain benefits to usinga switch instead of a hub.We will test configurations with hubs and switches. If aswitch does not provide additional throughput then we will just utilize the hubs to savemoney for ourselves and the potential customers. After removing all the bottlenecks inthe system, not including the actual firewalls, which is the sole variable that should existin our system, we will add additional firewalls and test throughput. We expect theoverall throughput to increase in the magnitude of fifty percent per firewall added.Some of the metrics that will be used to benchmark our system will be throughput inactual Bytes/second or KB/s, packets per second with variable packet sizes and numberof active connections and sockets open at the same time. Network throughput can beoptimized by using variable packet sizes. Depending on the type of configuration used,small or large packets can be used. We will use both and test the effects on bandwidthbetween the two pre-processors and through the firewall. The addition of a firewall may 17 18. help push small packets through more than large packets, or vice versa. The packet sizeused will translate into total MB/s, which is something that the end user will probably seeeveryday when downloading files. The end user will probably not notice the increasedspeed effects of the additional firewall, but will always be happy to see top notchdownload speeds. Since we are implementing a state-full parallel firewall system where packets foreach connection leave and come back through the same device, we will test for the effectof different types of connections on firewall throughput. Typical connections are Telnet,SSH, FTP, XSession, HTTP and the like. They vary in the amount of data and the datachunks that are being passed through. HTTP sessions are typically fast and short, telnetsessions periodically deal with small chunks, and FTP sessions are high load, highbandwidth connections. We will test with varying connection types, lengths and size ofpackets traveling through each to determine where parallel firewalls will give the greatestgain in bandwidth. The data from these benchmarks will reveal the circumstances under whichbuilding a parallel firewall array is most beneficial. If the gain in throughput occurs onlyunder very specific situations, then Cisco might not believe it to be a very viable solution.Otherwise they may decide to further research and fully develop such a product. 3.6 Potential Customers The intended use of the parallel firewall architecture is to provide low-costsecurity to a number of internal hosts on a Local Area Network. When the firewalldetects unexpected packets in the traffic stream, it can drop the packet, drop theconnection, or actively reset the connection. By splitting this traffic stream analysis18 19. among multiple devices in a simple and cost-effective manner, security for an internalLAN can be provided without sacrificing bandwidth. Therefore the potential customers for this technology encompass any small ormedium sized business, organization, or corporation that is looking to provide securityfrom malicious Internet users. With the scalable nature of the parallel framework, a gapin the current firewall market will be filled.END USER SITUATION 1: Paranoid Frank is the President and CEO for a major hacking corporation. Forthe time being, him and his brother Jerry are the only ones employed at the company.They are not new to computer hacking and are well aware of threats from hackers andviruses (some of which they created) and that their fairly small Gigabit network needsprotection. They did their research and found out that Cisco offers very good off theshelf IOS firewalls. Being the paranoid type, Frank thinks of the future and theupgrading costs that will incur. His business will grow, each of his new employees willwant an additional Gigabit network which will most surely require security. But Franksparanoia pays off. Through additional research he discovers that Ciscos teamimplemented a simple way of adding additional firewalls to a system. Their solution willlet Frank and Jerry simply connect an additional firewall to the system without having toscrap the old one. The new firewall will be detected and configured dynamically, and bevirtually transparent to the rest of the system. Frank opts to buy the starter system with aslightly higher initial cost due to the preprocessors. He will sleep well knowing that hewont have to worry about being attacked even by some of the software his companycreated.19 20. END USER SITUATION 2: Ken, Barbie and their best friend Pat decide to live in a three-bedroom apartmentjust north of Green. They are very glad that the area they chose has access to anindividual T1 line per apartment. They are ecstatic until they find that the T1 carries ahefty price tag. Being the smart bunch that they are, they decide to connect their internalnetwork to their friends, Sleepy, Grumpy and Joe who live in the apartment below them.They have known them for years, but still decide to secure their system. Wisely, theychoose a Cisco IOS firewall. They see that their downstairs friends computers are beinghacked in everyday by software created by someone known as Paranoid Frank. Lots ofbad packets and denial of service attacks, and viruses happen to the computersdownstairs. The single firewall is able to stop the attacks, but it cant handle the load andthe T1 runs at a measly 28.8 Kbps. Since they chose Ciscos firewall implementation sowisely, they merely run out to their local Cisco retailer and purchase an additionalfirewall. Not knowing anything about setting up networks, they simply connect thefirewall and it goes to work.This saved them much time and let them go back to thedaily chores of fixing plastic cars and buying hair products. 3.7 Technical Constraints At the moment we dont think that the pre-processing hardware provided to us byCisco will be lacking in power to run the pre-processing functions. The computers areHP Pavilions with Pentium 200Mhz and two 100TX network cards. The remainingconstraint would then be the networking.We will be using 100 Mbit networkinghardware, which should be able to handle a sufficient amount of traffic for our purposes.Considering that most of the potential customers would have internet connections that20 21. max out well shy of 100Mbit, we dont believe that there is a technical constraint thereeither. Thus we will go into this project with our eyes open and ready for anything thatmight pop up. 3.8 SummaryOur goal is to prove that the parallel firewall architecture is a viable and cost-effectivesolution in the Internet security field. With Cisco as our sponsor and a team of hardworking dedicated people, we will be able to reach that goal. 21 22. 4. Design 4.1 Hardware usage This is the general layout of our system. We have two preprocessor machines, threeservers behind the firewall, a Cisco router(with firewall software and hereafter referred toas a firewall), Fast Ethernet Switches, and lots of network cabling. 22 23. Our hardware list includes:Two HP Vectra XM machines, Intel Pentium 200MHz processors with 64MB of RAM as the pre-processors. One HP Vectra Dual Pentium Pro 150MHz with 64MB of RAM as our first serverOne Dell Optiplex Pentium Pro 200MHz with 64MB of RAM as our second serverOne Generic Pentium 133MHz with 64MB of RAM as our third serverOne Cisco 2514 router with the IOS v12 Firewall Feature SetTwo 10/100 Fast Ethernet SwitchesOne 10/100 Fast Ethernet Hub 4.2 Cisco router The major function of a router is to transfer packets from one network to another.Routers operate at the network layer that represents the third layer of the open systemsinterconnection (OSI) reference Model. By examining the network address of packets,routers are programmed to make decisions concerning the flow of packets. Cisco Systems routers support two types of access lists, basic and extended accesslists. A basic access list controls the flow of information based on the network address.An extended access list enables the flow of information to be controlled by both thenetwork address and the type of data being transferred within a packet. Although accesslists can be considered to represent the first line of protection for a network, as currentlyimplemented they usually do not examine the actual contents of the information fields ofpackets. Also, they do not maintain information about the state of a connection. In other 23 24. words, each packet is examined individually without the router attempting to determinewhether the packet is part of a legitimate conversation stream. 4.2.1 Basic Router Hardware Components The picture below is a generic schematic of router components.CPUFlashROMRAM NVRAM MemoryBUS I/O Port I/O Port MSCMSCThe Central Processing Unit (CPU) is responsible for executing instructions thatmake up the routers operating system as well as user command entered via the consoleor via a telnet connection. Flash memory is erasable type of ROM memory andrepresents an option that can be used to hold an image of the OS and the routersmicrocode. ROM contains code that performs power on diagnostics similar to the power onself-test (POST) that many PCs perform. Although many routers require softwareupgrades to be performed by removing and replacing ROM chips on the routers systemboard, other routers may use different types of storage to hold the OS. Random Access 24 25. Memory (RAM) is used to hold routing tables, perform packet buffering, and furnish anarea for the queuing of packets when they cannot be directly output due to too muchtraffic routed to a common interface, and to provide memory for the routersconfiguration file when the device is operational. Nonvolatile RAM keeps its contentswhen a router is turned off. By storing a copy of its configuration file in the NVRAM,the router can quickly recover from a power failure. The I/O port represents theconnection through which packets and exit a router. Each I/O port is connected to amedia specific converter. 4.2.2 The Router Initialization ProcessWhen you apply power to the router, the router initially performs a series ofdiagnostic power on tests (POST). Once POST is completed, the bootstrap loaderexecutes. The primary function of the loader is to initialize or place a copy of the OSimage into main memory. To do so, the loader must first determine where the image ofthe OS is located. The image could be located on Flash memory, Rom, or even on thenetwork. To determine the location of the image of the OS, the bootstrap loader checks therouters configuration register. The configuration registers values can be set either byhardware jumpers or via software, depending on the router model. The setting of theregister indicate the location of the OS and define other device function, such as how therouter reacts to the entry of a break key on the console keyboard and whether diagnosticmessage are displayed on the console terminal. 25 26. 4.3 Parallelism Our design is a true parallel design, as compared to the previous years attempt atparallelism. We utilize a perfectly symmetric architecture, which has two preprocessormachines and two switches. This will help to provide true load balancing, whereas theprevious solution had individual clients or networks connected to dedicated routers. Oneof the other methods of determining that our solution is truly parallel is that the traffic,whether going inbound or outbound, is not restricted to a particular firewall. Thepossibility exists for traffic to flow across any of the given firewalls. 4.4 Content Filtering:Packet filtering is a network security mechanism that controls what data can flow in toand out of a network. Internet data communications occur in unique data flows ofmultiple packets. Packet filters inspect each packet and then make a decision to eitherforward the packet onto its intended destination or simply to discard the packet. Packetfilters can be implemented to make a decision based on source or destination addresses,services provided (identified by TCP/UDP ports), or any another information containedin the packet header. Content filtering is a very useful ability for a firewall because content filtering cango beyond basic packet inspection and actually determine if the material embedded in apacket is valid or safe data for that given service. Because Cisco specified that contentfiltering was a very necessary requirement, all of our algorithm finalists for the loadbalancing contain methods to assure that content filtering will function properly. 26 27. 4.5 100 Mbit Networking: When designing networks, it is appropriate to consider the level of currenttechnology and any possible bottlenecks that might appear. The two technologiescurrently in use that we pay attention to are Ethernet(10 Mbit) and Fast Ethernet(100Mbit). For our purposes, 100Mbit speeds are favored due to the sheer bandwidthincrease. Considering that both speeds run over the same type of equipment, as long asdevices can have 100Mbit capability that will be our default. 100Mbit equipment is forthe most part cheap and easily configured. Our design originally had all of the network equipment listed as 100Mbit devices.Due to the obtained firewall having solely 10Mbit Ethernet interfaces, we has to makesome minor changes to our design. The current design has a 10Mbit networkimplementation in between the two pre-processors to accommodate the Cisco firewall.This 10Mbit segment could become a bottleneck in our testing in later phases, as it ismuch easier to flood a 10Mbit segment than it is to flood a 100Mbit segment. While thefact that it is switched 10Mbit will likely reduce collisions and help improve speed, wewill have to be very diligent in our baseline testing to determine if we can use 10Mbitwithout serious repercussions. One significant factor as to why the 10Mbit segment may not be as critical as onemight think is that the likely customer base would not notice a difference in speed versushaving that segment be 100Mbit. Potential customers of the parallel firewall frameworkwill likely only have one or two T1 lines, with each line having a 1.5Mbit bandwidthlimit. This results in an Internet connection bandwidth that is less than the internalfirewall bandwidth, and thus the Internet connection becomes the bottleneck. Only when 27 28. the Internet connection bandwidth capacity becomes much greater than the internalfirewall bandwidth capacity would a difference be noticed.4.6. Load Balancing Algorithms In the course of our research on load balancing algorithms we have encounteredtwo algorithms for a possible implementation in the project. These three algorithms areHash Function and Dynamic Traffic Counter. We shall briefly describe these twoalgorithms, their strengths and weaknesses and how they compare to each other. As ofright now the group has not made a final decision on which approach to take, as we stillhave to complete the research. 4.6.1 Hash Function Major strength of this algorithm is that it is simple. Many of networking tools relyon this type of balancing. The main idea behind any hash algorithm is to take some kindof input value hash it to a key and based on the key value either return a specific valueor take a certain course of action. In our project we could use the destination/sourcepacket information (destination address, destination port, sender address, sender port) thatis included in the header of every packet coming over the Internet as the input to a hashfunction. Based on those values we would generate the key that would determine whichfirewall would the packet go over. What is important to note is that hash function wouldhave to generate the same key when packets related to this session are going outbound. Inother words if one of the servers receives a packet over a specific firewall we have tomake sure that packet sent from a server to the original sender as a response goes over thesame firewall. This packet will have destination and source information in reverse since 28 29. what used to be destination is now sender and vice versa. It is important to have suchhash function that will return the same key when the packet header information isreversed. But even this should not really present a major obstacle since there are severalsuch algorithms that handle their job really well. As mentioned above this approach isfairly simple and implementing this algorithm should not be extremely difficult. Anotherstrength of Hash Function algorithm is that it has no or very little overhead. Thus theprocessing power of the computer system is not crucial to the overall performance of thealgorithm. There are several reasons for why this is so. First reason is that hash functiondoes not involve any complicated calculations. It has to perform only light and basicarithmetic operations on the source/destination pairs of information. Second reason is thatthere is no need to keep any tables with values that will be modified or compared to.Hash function returns a value immediately and does not need to store it temporarily orpermanently. There are, however drawbacks of using the hash function load-balancingalgorithm. In a sense it is not a true balancing algorithm for two reasons. First, it ispossible to have several connections that, because of their packet header information, gothrough the same firewall. If hash function is implemented correctly this should nothappen often but it is still possible for this case to occur. In this situation one firewallcould be flooded by traffic while other firewalls might have none or very little trafficthrough them. However it is also possible to have this problem when using a single IOSdevice. We consulted with Cisco experts regarding this problem and a response that wegot was that even though it is possible to run into these kinds of troubles that is a riskvery often taken since probability of such an event happening is not very great. Anotherreason for hash function not being true load balancing is that it is actually session29 30. oriented instead of traffic volume oriented. In other words hash function redirects trafficto different firewalls based on the session information and not the information regardingload through each firewall. So it would be possible to have a large FTP session gothrough one firewall and a small telnet session go through another firewall and than whena new connection is established have it go through the first firewall just because the keyvalue returned by the hash functions. But as mentioned above representatives from Ciscohave ensured us that such risks are not great especially if hash function is implementedcorrectly. Another drawback of a hash function is that it has static nature. Therefore everytime a new firewall was added to the stack or one was removed hash function would haveto go through some changes. For example if a firewall was removed from the stack hashfunction would have to modify its keys so that no traffic is directed to non-existingdevice. As of right now we are still working on the solution to the static nature of thehash function algorithm. 4.6.2 Dynamic Traffic Counter Unlike the hash function algorithm dynamic traffic counter is a true load-balancing algorithm. It is both session and traffic volume oriented. What this algorithmdoes is it keeps the table of all the connections on IOS devices and at the same time keepstrack of the packet volume on each one of these. This prevents the possibility of onefirewall overflowing with data while other firewalls are not getting any traffic through.The internal tables kept by dynamic traffic counter algorithm would hold the informationhow much traffic is going through each firewall and the firewall with least amount oftraffic would receive the new incoming connection. It would not matter if the firewall incharge of a new connection has large number of smaller connection it would still be30 31. assigned a new connection if other firewalls have larger traffic volume through them.This algorithm is in a way session oriented because it would have to make sure that allthe packets from a same session go through the same IOS device. There would be a tablekept with the information on which firewall is assigned to which connection. There are,however drawback to using this algorithm. First, there is a very large overhead. Keepingthe track of all the active sessions and the traffic load for each one of them can get a lot ofprocessing power from a computer system. Also, constant lookup through the tableswhere the information is stored can take up time. This may get to the point where thetraffic of the whole network would depend on the processing power of the preprocessormachine, which is far from an ideal situation. This was solved in a much more elegantway in the hash function algorithm. There is another problem that arises with thedynamic traffic count algorithm. And that is making sure that both incoming andoutgoing packets belonging to the same session go through the same IOS device. Thiswill require both of the preprocessor machines to keep the same tables at all time. Whichimplies that there has to be some king of a connection between two preprocessorcomputers. Initially we considered making a crossover between these two computers butwe soon realized that this might create a security breach. Since security is the main focusof Cisco we decided against this approach. Instead we thought we should have firstpreprocessor that receives a connection send the information to second preprocessorregarding any updates. Under updates we mean what IOS device is assigned for thatpacket and for that connection. The best way to send this kind of information is to place itin the one of the header fields of each packet that goes across the firewall stack. There aretwo fields in the IP header that are not used, TOS and IP options. We consulted with 31 32. Cisco experts and they advised us to use a TOS field because it requires less processing.And processing used to modify a packet header field and to look into it would be verysignificant. Which just goes back to say that major drawback of dynamic count algorithmis the processing power it requires. Another drawback would be complexity of thealgorithm itself. It would be necessary to constantly poll for traffic volume as well as forany incoming connections. And though this algorithm implements true load balancing itmight not be the best possible solution for our project32 33. 5. Implementation When talking about the implementation of the project there are two different typesof difficulties encountered. Hardware related problems and software related problems.Since this project is very hardware oriented but also needs software implementation bothof these areas were equally important. 5.1 Initial Setup What needed to be done first is get the correct equipment from Cisco. Since, asmentioned above, the project is very hardware specific we could not start working on itbefore acquiring proper hardware. Thanks to prompt response from Cisco contact personwe were able to get bare necessities in a couple of weeks. What we were temporarilydonated were Cisco 2514 (2500 series) router, which has enough memory to implementsuch features that would provide firewall services, and two Pentium class computers touse as preprocessor machines. That was enough to get us started and we were promisedmore equipment in the future when the need for it arises. After we received devices mentioned above the question was where to store them.What we really wanted was to obtain a room in DCL where we could leave all thehardware. The second option was to keep all of the equipment in one of project membershouse, which was not an ideal solution for two reasons. First, the amount of hardwarewas sufficient enough to crowd one persons house or room and second we needed aplace where each one of us could go at any time and work on their part of the project.Luckily, we were able to obtain a room in DCL to host all of the equipment and that was33 34. lock protected. This was we had access to hardware any time the lab was open and wedidnt have to worry about someone stealing it. 5.2 Preprocessor Machines Setup At this point of time we had what we needed to start actually working on theproject. We still did not have computers that we would use as servers behind firewall andwe needed some hubs and switches but what we could do is install operating systems ontwo preprocessor machines. Before doing so we consulted with contact person fromCisco in case there were some special requirements regarding OS. But we were informedthat choice was up to us. What we needed, when it comes to OS, was a platform thatwould be supported by the hardware we have and that would be network oriented. Inother words an OS that supports routing. That left us with Windows NT and severaldifferent Linux distributions. Since most of the Linux distributions are free and no licenseis required we decided to use Linux instead of Windows NT. The question now wasshould we use full distribution of Linux or a so-called mini-distribution that is veryrouting oriented. On one hand mini-distribution are better because they take less harddrive space and would already have some of the routing features that we wanted toimplement. Also, it would be easier to present the final project to Cisco if we used mini-distribution instead the full Linux distribution. Shown bellow is the list and a briefdescription of most popular mini-distributions of Linux that focus on routing. 34 35. LRP The Linux Router Project. This is the most famous distribution that directly targets routing. It also supports more than just basic routing. The whole distribution fits on one floppy so it is easy to get the system up in case it crashes. And even thought this is the most well know distribution for routing all of the documentation is somewhat old and not very accurate with regard to newest version.tomsrtbtThis distribution also fits on a single floppy but it is even less documented than LRP. Also, it covers just basic set of instructions, which might not be enough for our project.TrinuxTrinux is based on multiple floppies and focuses on providing network security and monitoring tools. It does not focus on routing though although it is able to provide basic routing services. Just how basic these services are might decide if it is suitable for parallel firewall project.myLinux This distribution, just like Trinux, targets workstations but has the basis for a router. Probably needs a lot of work to be suitable for our project. mini-distributions of LinuxOn the other hand what mini-distributions were missing were developing tools.Since routing is just the basis of our project on which we would need to add componentswe would also have to use compilers and other developing tools. Another reason forusing the full Linux distribution is that we would need network-monitoring tools fortesting purposes that might not be easy to install on a mini-distribution of Linux. So wedecided to use a complete distribution of Linux and we decided to use Red Hat 7.0 sincemost of the project members were familiar with it. This version of Red Hat has kernelversion 2.2.16, which supports routing and most of the network-monitoring tools.Once we made decision regarding the OS we could go ahead and install it on twopreprocessing machines. During the installation of Linux on one of the machines wediscovered that hard drive was damaged to the point where it could not be fixed. At leastnot with any tools that we had on our hands. Luckily, that system had two hard drives and 35 36. the one that was corrupted was of a smaller capacity. We were able to take the bad harddrive out and to place the second hard drive as a master device and install the operatingsystem. Also, we informed Cisco representative of a hard drive failure. Other than thatinstallation of the OS was relatively simple. After the operating systems were installed we had to do some OS configuration inother to protect two preprocessor machines from any malicious attacks. It was necessaryto check which services were running on the systems and which ports were left open.Any of the services that were not necessary should be disabled so that ports used by theseservices were not a possible access to the system. After all, these preprocessor machineswere supposed to be located one on the each side of the firewall stack. In case someonewas able to get access to these machines they could possibly bypass firewalls and thewhole point of the project would vanish. We managed to disable all ports that were notnecessary for proper function of the system. These were the function left running on eachone of the preprocessor machines:#netstat a Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 00 *:ssh*:* LISTEN raw 00 *:icmp *:*7 raw 00 *:tcp*:*7 Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node Path unix 2[ ]DGRAM406/dev/log unix 0[ ]STREAM CONNECTED 193@00000020 unix 0[ ACC ]STREAM LISTENING 1056 /tmp/.font- unix/fs7100 unix 0[ ]DGRAM4128 unix 0[ ]DGRAM420services running on preprocessor machines 36 37. Second part of the initial setup was to connect two preprocessor machines on thenetwork. By this time we were able to acquire more hardware that would help upaccomplish this. We had a dual speed hub that was temporarily donated by one projectmember and we had a fast Ethernet switch also from another project member. Togetherwith router that Cisco gave us we would be able to connect all of the devices into anetwork. At this point we encountered another problem with computers donated byCisco, which was incompatibility of network interface cards with Linux. Each system hadtwo NICs but unfortunately the OS did not recognize some of them. What we had to dowas find more network interface cards to replace those currently in use. And insteadasking Cisco for help, which might take another couple of weeks, project members wereable to come up with enough NICs for both machines. It took us some time to findcorrect modules that were necessary so that OS would recognize NICs but in a matter offew hours we had both preprocessing machines equipped with working network interfacecards. Here is the example of interface setup on one of the preprocessor machines:#ifconfigeth0 Link encap:Ethernet HWaddr 00:00:21:E0:20:9Finet addr:128.174.243.180 Bcast:128.174.243.255Mask:255.255.254.0UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1RX packets:6000163 errors:0 dropped:0 overruns:0 frame:0TX packets:8911 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:100Interrupt:11 Base address:0xfc00eth1 Link encap:Ethernet HWaddr 00:10:4B:D4:C3:2Cinet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1RX packets:1877 errors:0 dropped:0 overruns:0 frame:0TX packets:1593 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:100Interrupt:10 Base address:0x300lo Link encap:Local Loopback37 38. 5.3 Behind the Firewall Setup In the mean time people from DCL office donated three PCs to us in the durationof our project. These three machines were to be used to provide server functionalitybehind the firewall stack. Again we had to decide what operating system to use for thesethree computer systems. What we needed were computers that would be used as HTTP orFTP servers. These machines were not crucial to our project but no testing could be donewithout them. One more time we decided to use Linux Red Hat 7.0 as an operatingsystem. Reason for it was that HTTP and FTP servers were easy to install on Red Hat andour hardware limitation did not allow us to use Windows 2000. During the installation ofthe OS we discovered that one of the computers donated by the office of DCL did nothave an i386 family processor. This particular PC had a Motorola processor that wouldnot allow us to install Linux on it. After we explored all of the possibilities for theoperating system on this machine we decided to return in and instead ask for anothermachine with a Pentium or AMD processor on it. Few days later we were given anothercomputer system that satisfied all the requirements we needed. After that installation ofoperating system on three machines went without any problems. We were also able toinstall several different services on each one of these machines such as HTTP server, FTPserver, telnet server and Ssh server. This time we did not have to worry about having toomany ports open since all of these machines will be located behind the firewall stack.Showing bellow is the list of all the services present and all the ports occupied on thesethree machines.38 39. #netstat -a Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign AddressState tcp 00 *:www*:* LISTEN tcp 00 *:https*:* LISTEN tcp 00 *:ssh*:* LISTEN tcp 00 *:telnet *:* LISTEN tcp 00 *:ftp*:* LISTEN tcp 00 *:sunrpc *:* LISTEN udp 00 *:sunrpc *:* raw 00 *:icmp *:*7 raw 00 *:tcp*:*7 Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node Path unix 0[ ]STREAM CONNECTED 194@00000020 unix 3[ ]DGRAM366/dev/log unix 0[ ]DGRAM698 unix 0[ ]DGRAM431 unix 0[ ]DGRAM378services running on three servers 5.4 Routing Problems Once all of the machines were set up correctly it was necessary to enable routingon two preprocessing machines so that packets from outside can reach internalcomputers. Initially this did not seem like a great problem because routing was native to2.2.16 kernel and we had some documentation on how to set up routing. Unfortunately itturned out that this task was a bit more difficult that what we had expected. We were ableto establish routing tables on two preprocessor machines but were not able to set correctentries. What was even worse is that we could not remove the routing tables and createthem again. Even if during a session, correct values were placed into tables once thecomputer was rebooted old, incorrect values were showing. Since there seemed no way topermanently fix the routing tables we had to reinstall the operating system on the twopreprocessor machines and start over. Second time we consulted with experts from Ciscoand were able to get the routing fully enabled. Bellow is the example of a routing tablefrom one of the preprocessor machines. 39 40. #route -nKernel IP routing table Destination GatewayGenmask Flags Metric Ref Use Iface 128.174.243.181 192.168.1.2255.255.255.255 UGH000 eth1 128.174.243.182 192.168.1.2255.255.255.255 UGH000 eth1 128.174.243.183 192.168.1.2255.255.255.255 UGH000 eth1 128.174.243.184 192.168.1.2255.255.255.255 UGH000 eth1 192.168.1.0 0.0.0.0255.255.255.0 U000 eth1 128.174.242.0 0.0.0.0255.255.254.0 U000 eth0 127.0.0.0 0.0.0.0255.0.0.0 U000 lo 0.0.0.0 128.174.242.10.0.0.0 UG 000eth0 routing table for one of the preprocessor machines5.5 Bridging Problems Just as it seemed that we resolved all of the problems related to routing we raninto another difficulty regarding forwarding packets to correct destination. This time wehad problem with bridging. It turned out that the way we had the network set up was ontwo different subnets that had a firewall in between. This created an illusion that therewere two Ethernet networks connected together when in fact it was the same network.Basic routing set up on two preprocessor machines does not support bridging so weended up with a situation where servers located behind the firewall were not able tocontact the gateway located in front of the first preprocessor machine. And even thoughtsolving this problem was not crucial at the moment, because we could work on thenetwork itself without involving the gateway just yet, we wanted to solve the problem assoon as possible and not have to go back to it later. Unfortunately as of yet we did not 40 41. come up with the solution to this problem. Right now we are in process of finding thebest possible way to remove his problem and we are still waging the two possiblesolutions. First is to rearrange the network so that all of the components are on the samesubnet. This will eliminate the bridging problem completely but might be impossible todo with the firewall stack setup that we are trying to implement. Second solution is toresearch bridging and find the way to implement this feature on two preprocessormachines. In order to make a final decision on which way to take when solving thisproblem we might contact people from Cisco and ask for their advice as well as peoplefrom the office of DCL.5.6 Network Monitoring Tools As described in our project statement we are to research the possible improvementof firewall implementation using the parallel firewall stack versus a single firewall. Partof this improvement that we are looking for is related to speed increase when using moredevices at the same time. To be able to test for any improvements regarding to speed weneeded to do a fare amount of baseline testing. This means testing the performance of twopreprocessor machines and a single firewall so that later on we can compare those resultswith results obtained when using several IOS device. Right now we have done some ofthe testing but there are still areas in which we need to do much more. Prior to the testingsequence we spent certain amount of time looking for best network monitoring tools andgetting to know how to use them. There are several different software packages that wehad tried using and during this period of time we ran into some problems with getting theprograms to run correctly. For example most of the network monitoring tools have a41 42. graphical interface and can be run only on X11 Windows. During our originalconfiguration of preprocessor machines we did think GUI will be necessary and thereforedid not even worry about configuration of graphical interface on these computers. But asit turned out that we needed X11 to properly run most of the network monitoring tools wewent back and configured this option for the two computers. Currently we have few verygood monitoring tools that we can use and that we got familiar with. What is left is tofinish testing the base performance and we are hoping to accomplish that in a near future. 42 43. 6. Plans for the Spring Semester We now turn our focus to what we are going to achieve next semester. When acomparison is made between our original objectives and our current progress, it is easilyseen that we are not at the completion level that we wish to be at. This is due to thefactors that have been detailed in previous sections; they will not be expounded uponhere. Covered in the following sub-sections will be the primary areas that we will focuson during this next semester, in chronological order. 6.1 A Decision:At the moment we have an open request for a change in our assigned IP numberslogged with Chuck Thompson. As he has been very helpful in the past, we have faiththat he will once again come through for us and provide us with proper numbers tobypass our primary problem. Despite this faith, we also have a plan that would come intoeffect if we were not able to obtain new numbers. We will begin with the assumptionthat he will be successful on our behalf. 6.1.1 A New Timeline, Part One:Upon obtaining a separate routable subnet, the last of our routing problems woulddisappear, and allow us to begin testing immediately. We believe that this subnet will beready for us the week that we arrive back on campus. We would begin testingimmediately. 43 44. Our testing under this scenario begins by activating the 3 donated servers ascontent servers. A multitude of protocols would become available, including HTTP,FTP, Telnet, SSH, and Streaming Multimedia. By having these servers provide materialthat we can access remotely, we can then proceed with the client area of testing. Thiswould involve going to a lab in DCL and then using multiple workstations to access ourprovided content. Testing the speed of the implementation through this approach givesyou a very accurate picture of the networks ability to split traffic across firewalls, underthe duress of a large number of connections as well as a large volume of data beingtransferred through the connections. It is also a reasonably accurate representation of theprospective customer base for this innovation, small-medium sized corporations. Suchbusinesses would provide content approximating what we are arranging for, and theywould have traffic in the volumes approximating what we will be generating.44 45. We believe that we will have basic testing using this setup completed by the endof January. This allows us to get into the detailed aspects of algorithm implementationvery soon after the semester begins. Our revised timeline would then appear as such:Timeline Under Scenario 1 Item: Estimated Length Work Range:Minor reconfiguration toJan 14th - Jan1 week existing network. 20thBaseline Testing to determine Jan 21st - Jan 1.5 weeks Network Capacity31st Learn C for coding of network Feb 1st - Feb2 weeks drivers 15th Code Load-BalancingFeb 16th - Feb1 week Algorithms22ndIntegrate code into network Feb 23rd - Mar2 weekscard drivers8thIntegrate code into kernel and Mar 9th - Mar2 weeksoptimize 22nd 45 46. Additional testing of load-Mar 23rd - Mar 1 weekbalancing 29thAdditional FunctionMar 30th - Apr3 weeks Implementation 5thDocumentationConcurrentFault Tolerant Firewall Apr 6th - May Remaining Research 10th 6.1.2 A New Timeline, Part Two:Being the fairly thorough people that we are, we have a plan for the occurrence ofan inability to obtain a routable subnet for our testing purposes. Without a routablesubnet, we will not be able to use any of the DCL backbone for testing purposes. Quitesimply a bridged implementation violates too many of the project parameters associatedwith transparency and feasibility. In order to obtain a routable subnet, we can take all of our equipment off of theDCL subnet and use our own self-contained network. While this is certainly easier toadminister and keep track of, it results in a far smaller and less realistic testingenvironment. But we will do what we have to.46 47. A number of changes would result of having to take this course of action. Thefirst would be that we would need to reconfigure our local network to the newconfiguration shown above. This would not take very long. The second is that we would need to bring in an additional machine or two tobalance our both sides of the network. If additional machines are not brought in, wewould save ourselves configuration time but our ability to run multiple simultaneous testswould drop to approximately nil. This is highly undesirable and as such would strive toobtain the necessary additional equipment. This could take up to an additional month toget more equipment in and correctly configured.47 48. The third item on our agenda would be to obtain a traffic-generating tool. Thecurrent frontrunner in this category would be NetSpec from the University of Kansas. Ithas the ability to simulate numerous types of traffic, and would be suitable for our tests inthis rather limited environment. It does not appear to be terribly complicated, andinstalling/configuring it could run in parallel to bringing in additional equipment,however due to the experiences which we have had this semester, an additional week ortwo would likely be necessary to become familiar with this tool.Timeline Under Scenario 2 Item: Estimated Length Work Range: Minor reconfiguration to Jan 14th - Jan1 weekexisting network.20thJan 21st - FebObtain additional equipment2 weeks 3rd Configure AdditionalFeb 4th - Feb 2 weeks Equipment 17thLearn new traffic generatingFeb 18th - Feb1 week tool24th Baseline Testing to determineFeb 25th - Mar1 weekNetwork Capacity 3rd Learn C for coding of network Mar 4th - Mar 2 weeksdrivers17thCode Load-Balancing Mar 18th - Mar1 weekAlgorithms 24th Integrate code into networkMar 25th - Apr 2 weeks card drivers 7th Integrate code into kernel andApr 8th - Apr 2 weeks optimize21stAdditional testing of load- Apr 22nd - Apr1 weekbalancing28th Additional FunctionApr 29th - MayRemaining Implementation10thDocumentationConcurrentFault Tolerant Firewall N/AN/A Research48 49. It is apparent from the revised schedule above that having to reconfigure thenetwork at this point could cost us a serious amount of time compared to being able tocontinue with our original plan. The following sections are rather time independent ofthe two scenarios listed above, however going with the latter scenario might force us torush completion on some areas below or leave them unfinished. 6.2 Algorithm Implementation:This is the key item on our agenda for this next semester. Implementing andtesting our algorithms will provide the key to whether or not a parallel firewallframework will be a useful product. Hence this item will be the most significantbenefactor of our available resources. There are three main areas that we can seespending time on, algorithm coding, driver integration, and kernel integration. The first area is the actual coding of our algorithm. The coding will be done in C,as that is the preferred language for the network card device drivers that we will beinterfacing with. Coupled with this is the heavy learning curve for C. Our group is notvery strong in this area, and a fair bit of time will be consumed regaining familiarity withC. Once the algorithms themselves are actually coded, we must turn our attentiontoward integrating this code with the code that exists for the network card drivers in ourpre-processors. This action will, as is probably not surprising, take another good chunk 49 50. of time. We will have to first learn what the current driver code does in detail, and thendecide on where to put our modified code into that. The final aspect of algorithm implementation is expected to be kernel integration.There are likely to be parts of the algorithms that require a higher amount of interactionwith data structures and other items that are nominally found in the kernel. Optimizingthe code to run in kernel space could also provide us an increase in network processingthroughput, and as such we will take a look at that too. The primary factor in this entire part is the amount of learning that we will have todo to be able to modify code in the various places that we need to. We acknowledge thedifficulty of the task before us, but we look forward to the challenge. We have learnedmuch already, and will learn a lot more before we are done. 6.3 Additional Function Implementation:There are some additional functions that are not directly part of the algorithm thatwe will likely want to implement. Such functions include the ability to add or removefirewalls on the fly. Since we can hardcode the number of firewalls directly into thealgorithms and be able to test different configurations faster, we may rely upon that at thebeginning. However we will try for the more elegant solution to determine if it can beaccomplished in a practical manner. 50 51. The functions that we have tentatively identified at the moment forimplementation are: Add Firewall, Remove Firewall, Firewall Status Check. In order,they will allow you to dynamically add a firewall to the balancing algorithm, dynamicallyremove a firewall from the configuration, and probe a firewall to determine if it is stillavailable. 6.4 Documentation:We anticipate having to document the modifications to the device drivers and toany other code that we modify. This should not take very long. The primary other pieceof documentation that we expect to produce is the report to Cisco at the end of thesemester containing a detailed comparison of the base results versus the differentconfigurations we can come up with. This report will contain our conclusion based uponour research as to the feasibility of the parallel firewall framework. 6.5 Fault Tolerance Research:One area that Cisco has specified an interest in is having the parallel firewallframework be fault tolerant. Thus if one firewall was to fail, its load would be distributedamong the remaining firewalls with little or no disruption in the traffic flow. This is aninteresting area of research, and could comprise a whole project in and amongst itself,however out of curiosity and given enough time, we will take a look at the feasibility ofhaving a fault tolerant network. 51 52. 7. Conclusion This semester has been a very interesting semester, full of unseen challenges andopportunities to learn. Overall we are not quite at the point where we want to be, butmany of the roadblocks that we have run into have been sequential in nature. Perhapswith better problem anticipation we could have avoided a few of the stumbling points,next semester we will certainly be able to see more in advance.With most of the environmental variables out of the way, this next semester will see usable to focus on various implementations and a comparison between them. We will alsobe able to spread tasks out better and utilize our groups resources more efficiently.Because of this, we have confidence that we will reach our goal of obtaining acost/performance analysis for a parallel firewall framework.52