Rolf Weber <weber @
iez .
com> writes:
>correct me if i'm wrong, network programming isn't my daily job:
>- with application-level proxies, you have 2 tcp handshakes instead of
> one, and 2 connections instead of one.
>- the data is read at TCP level, with it its headers have to be
> appended and deleted.
>(no idea if this are the ultimate performance winners)
This further illustrates how a "stateful" packet filter either behaves
the same as an application gateway or it behaves less ably. If you look
at the packet flow in these two situations you see the same packets
at the filter's interfaces that you see at the gateway's.
Connection setup might be faster with an application gateway since it
can complete the connection on one side at the same time it is
completing the connection on the other site. Thus, the initiator can
start data transfers a few milliseconds sooner, maybe.
>> > i don't think it's an eternal war, because both types of firewalls
>> > should fight at different battle fields.
Absolutely. Our favorite (most paranoid) sites generally use packet
filters as well as application gateways. In series, not in parallel,
of course. The packet filters establish various DMZes for various
purposes and give the sites an extra measure of comfort regarding
the nature of the traffic they're running.
>...but i'm sure, it's only a question of time till vendors will offer
>both, application level and packet filtering firewalls. it would be
>a very good argument if they are acting as a consulter, too.
I don't see much sense in putting application gateways and packet
filters in the same box, or hooking them up in parallel. If the
networks in question needs the degree of separation provided by an
application gateway, then you're dilluting the effect by letting a
filtered packet flow in along with it.
Rick.
smith @
sctc .
com secure computing corporation - ISO 9001 certified!
|
|
