Re: FW-1 throughput question

[Alex Goldney <adgoldney () yahoo com au>]

Randy,
                We did throughput testing on our Ultra
5's using a failover technology, and found that we
went to 45Mbs.  The thing became CPU bound after that.
 Note, that 30% of the CPU was used to maintain state
synchronisation and failover heartbeats etc.

So, you can sustain about  1.5Mbs per 1% of CPU. Note,
this was running about 50 big ftps.  So if you had a
large number of concurrent sessions, it may affect the
results.

I would guess that 2 CPUs should cover you.

Alex.



From:   Randy Garbrick <randy.garbrick () gettyimages com>
on 05/03/2000 12:06 AM GMT
Please respond to Randy Garbrick
<randy.garbrick () gettyimages com>
To:     Firewall Wizards <Firewall-Wizards () nfr net>
cc:      (bcc: Alex Goldney/SYD/QANTAS)
Subject:        [fw-wiz] FW-1 throughput question



Does anyone have any throughput specs for Firewall-1
installed on Sun E-220s
and E-420s?  I would like to be able to scale each box
in a redundant pair
(using StoneBeat) to a max throughput of 50
Megabits/sec, and I am trying to
decide whether I will have to go to 4 processors to
achieve that or if 2
will be enough.  I plan to put in encryption
accelerator cards if the
encryption CPU load gets too high.  I am assuming that
we will have a small
to moderately sized ruleset.  This is to provide high
speed access to a
relatively small number of machines.


Thanks,

Randy Garbrick
WAN Administrator
Seattle Network Operations
Getty Images, Inc.

Telephone: 1 206 695 3690
Fax:  1 206 695 3601



-----Original Message-----
From: Jackie_Soares () gap com
[mailto:Jackie_Soares () gap com]
Sent: Tuesday, March 07, 2000 2:01 AM
To: Magosanyi Arpad
Cc: Firewall Wizards;
John_Williams-CRMProductDev () peoplesoft com
Subject: Re: [firewall-wizards] Trusted OS...



> Having a trusted OS have little to do with the
firewall functionality.
> Firewalls are substitues of real security on the
defended nets, and they
> tend to have very few users, usually only with one
level of trust (fully
> trusted).

I think you've hit it on the nose.  In TCSEC security
models (higher than
C2), the underlying TCB helps manage single-level or
multi-level secured
subjects. In order for a network to be "trusted", all
the components are
trusted; and evaluated as trusted on the same security
level.  The devices
attached to this single level secured network are
controlled with MAC
(Mandantory Access Control).  Multi-level secured
(MLS) software must be
written (with trust and modelling (i.e. INAJO, etc.))
so that it connects
two or more single-level secured subjects together
with trust.  In this
case,
we are talking about a network "guard" not a firewall.

In the TCSEC security models, some people confused the
term "multi-level
secure downgrade or upgrade guards" with "firewalls." 
A firewall is a
filter.
It blocks traffic; it shapes traffic; it translates
traffic.  But a firewall
does not have the capacity nor the ability to
downgrade secured information
from one level (Top Secret) do another level
(Confidential) or upgrading of
unsecured messages through a single-level highly
secured network.  A
MLS guard has to have the ability to isolate datagrams
or build messages
from
datagrams, audit, review, make changes to the message,
repackage the
message,
set the appropriate DAC (Discretionary Access
Control), and move the content
up or down to the appropriate single-level network
through a MLS controlled
by the MAC.

One example is a "manual-review" downgrade guard. In a
"manual-review"
guard, it takes a multi-level subject (usually a human
being) to review
the material and block out inappropriate portions (ala
black highlighter)
and allow some of information to pass through. (For
instance, material
obtained from the Freedom of Information Act blocks
out surnames,
addresses, and telephone numbers).

In a "software-review" guard, the data received has to
be formatted in a
particular manner, the source is authenticated and
sealed.  If the data
comes from a single level network, it is easier to
authenticate, audit,
and review. [And evaluate, if you are taking your
product through TCSEC
evaluation.]  If the data comes from an unsecured
network (i.e. Internet),
then additional methods must be taken to protect the
network interface,
the code and computer from subversion; reduce the
exploitation of covert
channels, and use orthogonal technologies such as VPN,
S-KEY, cryptographic
checksums, network puzzles, firewalls [note: here's
where the firewalls
come in], etc. to increase chances that the guard
receives the appropriate
datagrams.  Note: on baseband protocols, data always
arrives single-level,
then after it passes authentication, the auditing, the
guard passes it
to a MLS that builds the message and reviews the
content, modifies the
message (i.e. removes information with an electronic
black highlighter)
and then determines a new appropriate DAC; builds
packets; and sends the
packets to an assigned single level secured network.

If you are trying to use commercial-of-the-shelf COTS
software to build
a guard; I don't think there is product on the market
that does this
at reasonable costs.  And nearly all COTS network
products do not take
advantage of the MAC features of various vendors. The
mandatory access
control features have to be configured separately.

To find a MLS COTS firewall product; I don't think it
exists. Because
firewalls are inherently single-level filters.

> If you consider the NTCB modell of TCSEC, the picture
gets to be a little
> more fine. The main point is that you cannot
guarantee the integrity of
> the application (firewall proxies) if you don't have
a TCB under it,
> and the firewall proxies are integral part of the
NTCB (anywhere between
> 'M' and 'MIA' component). The little problem with
this that no firewall
> (which I know about) have been specifically designed
az an M component
> of an NTCB. The other problem is that no network
protocol I know of
> is designed for transmitting the labels as well
(though some of them
> like smtp and http is able to do that.

Installing an untrusted application (firewall) on a
TCB does not make the
application run with more trust.  You still have a
untrusted application
running on a TCB.  If it is a UNIX-based TCB, you can
assign with MAC to
run your untrusted software single-level to single
level network interfaces.
You should also be able to run another copy of the the
untrusted
application in another "address space" but are
required to attach to
different network interfaces because the MAC setup
reserved the first
interfaces for the first instance of the application.
A TCB should
prevent passing data from one address-space to the
other without a
trusted MLS subject--this includes sharing the same
transmit and
receive buffers on the network interface card. 
However, one advantage of
using a TCB, you will have the ability to manage
interfaces where you might
not on a untrusted OS.

Mr Arpad is absolutely correct.  Integrity of the
network applications
depends on the software. Starting with a good TCB is
only a small portion
of success.  To take advantage of a trusted
multi-level secured OS, the
foundation of layering of trusted code over an
evaluated TCB using
the same programming methodology and evaluation that
built the TCB
process is a way to go.  But the process is a very
difficult path to
follow.  Lots of Mil Specs, tedious documentation, and
rigourous QA
and review.

The successors in this field are found at
http://www.radium.ncsc.mil/tpep/epl/

Also, refer to
http://www.radium.ncsc.mil/tpep/epl/entries/CSC-EPL-94-008.html

Jackie Soares
Network Systems Consultant
Gap, Inc.





_____________________________________________________________________________
http://movies.yahoo.com.au - Yahoo! Australia & NZ Movies
- Find out what's on at the local cinema with Yahoo! Movies