Great Circle Associates Firewalls
(October 1997)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: sex, lies, and firewall code
From: Chris Brenton <cbrenton @ sover . net>
Date: Mon, 20 Oct 1997 21:41:40 -0400
To: firewalls @ GreatCircle . COM
References: <3 . 0 . 2 . 32 . 19971017224755 . 00a3d4c0 @ 9 . 1 . 1 . 1>
Reply-to: cbrenton @ sover . net

Frank Darden wrote:
> 
> You know, it is so humorous. These Firewall manufacturers will stop at
> nothing to "out compete" one another. Now I am not trying to start any
> religious wars over firewalls, but I feel the time comes when you have to
> say enough is enough. I am referring to the following publication
> http://www.tis.com/docs/products/gauntlet/firewallcomp.html

Actually, as an independant consultant that is not tied to any firewall
company (i.e. I'll install Gauntlet or FW-1 dependant on the client's
needs), I found the paper on "Application Gateways and Stateful Packet
Filters" to be mostly accurate with only a small quantity of
"marketspeak".

For example, I found the discussion on how application firewalls can
screen payload while packet filtering can not to be right on the money.

However, I found the discussion on why the transistion from
non-transparent to transparent application firewalls is considered a
"new generation", while the transistion from static to stateful
filtering is simply an "enhancement" to be a bit of "marketspeak". IMO
these comments are more based on opinion than fact.

The discussion on why Gauntlet can deal with SQL better than FW-1 was
cool, but I think the Netmeeting example was a bit of stretch. It easy
to say "our product, which we plan on shipping some day "real soon now",
will be better than the product that someone else has already put to
market". IMO, this is sales speak, not technicial information. The paper
should have stuck with the SQL example.

Also, I found the discussion of "holes" in firewall-1 compared to
"plug-gw" on Gauntlet to be a bit misleading. While both perform the
same function, the verbage leads the reader to beleive that one is
better than the other. A "hole" implies that the firewall is wide open
at this point which is not true, state is still maintained (even though
payload is still not analyzed). While this is not as good as having an
app aware process to handle the data, it really is not a wide open hole
(again, IMO).

In short, I think the paper is a good reference for someone trying to
sort out the differences within the firewall market provided the
reference is given with a qualifier, the site publishing the information
stands to benefit from the context of the message. With that said the
paper is quite informative.

Cheers,

Chris


References:
Indexed By Date Previous: Re: sex, lies, and firewall code
From: Ryan Russell/SYBASE <Ryan . Russell @ sybase . com>
Next: Re:
From: "Baek, Seok-Chul" <scbaek @ rcunix . kotel . co . kr>
Indexed By Thread Previous: Re: sex, lies, and firewall code
From: Peter da Silva <peter @ baileynm . com>
Next: RE: sex, lies, and firewall code
From: "Craig S. Wright" <craig . wright @ asx . com . au>

Google
 
Search Internet Search www.greatcircle.com