Kristian Koehntopp replies to Marcus Ranum:
>I see your case now: It is possible to either implement an
>application level gateway that handles a protocol or to tap an
>incoming connection and attach a state machine (or some other
>mechanism) to this connection that tracks the protocol on this
>connection at an arbitrary level of detail.
As long as a "packet filter" is relatively stateless the distinction
between gateways and filters makes sense and the layering works.
I believe that once you start maintaining much state about a
connection, this so-called packet filter is implementing something
more like a gateway. If the packet filter is reconstructing FTP
messages so it can extract port numbers from the data stream, then
it's a mislabeled application gateway.
In other words, I think the layering is relevant. If the firewall
reconstructs data streams according to application level protocols
it's an application gateway. The term "stateful packet filter" simply
describes how the application gateway was built.
>I agree with you that any filter that is going to track a
>connection at application level has to be just as complex as
>the corresponding application level gateway.
Having built more than my share of state driven software I admit a
sympathy towards a stateful filter implementation -- it has the
potential to be screamingly fast. Given the right tools you could also
do some interesting behavioral analysis just from the design
specification. But without the tools it can be ugly, very ugly to
build correctly.
The problem is that you have to construct *lots* of states in order to
assemble meaningful data at higher levels. The approach doesn't tend
to scale well to keep up with higher level protocols. It becomes a
program where *every* statement has branches attached.
>I just think that it might be easier to write and verify such
>application specific code for applications (much of this code
>already exists) than for something that has to perform such
>checks on the fly while it is wading knee deep through partially
>received data.
I agree that it's easier to get sequential source code developed and
debugged, since that's what everyone is taught to create. If the
programming community had evolved differently, we might have all been
taught to program in terms of state transition diagrams. We'd have the
the insight, experience, and tools to develop, analyze, and debug such
stuff. But without all that, it's riskier.
Rick.
smith @
sctc .
com secure computing corporation
Follow-Ups:
|
|
