Re: FW-1 throughput question

[Aaron Turner <aturner () vicinity com>]

The part of the Solaris kernel that routes packets (FW-1 is a router) is
single threaded.  Hence, max throughput is determined more by the speed of
the CPU than the number of CPU's.  Two CPU's is probably the sweet spot in
terms of price/performance for sites needing a lot of throughput.  (The
other CPU would be dedicated to other OS/Firewall tasks such as logging.)

50Mbps is well withing the boundries of Firewall-1 for one CPU though
(assuming no encryption).  If you want more than 4-8Mbps of encryption,
you'll need a hardware accelerator card.

Network Mag. (I think) showed an Ultra 60 w/ 2x360Mhz CPU's did about
~150Mbps.  Even with the encryption accelerator, max throughput was under
30Mbps of VPN traffic.

Lies, damned lies, and benchmarks.

-- 
Aaron Turner        aturner () vicinity com  650.237.0300 x252
Security Engineer                         Vicinity Corp.        
Cell: 408-314-9874                        http://www.vicinity.com

On Tue, 2 May 2000, Randy Garbrick wrote:

> 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.