- 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