In some mail from Ryan Russell/SYBASE, sie said:
> >An SPF keeps state information about connections, which may let through
> >arbitary packets (so long as port #'s match) or not. It will let the
> >entire packet go out, just as it came in or visa versa, so long as it
> >matches the rules. It doesn't handle the data, which makes it quicker
> >and therefore more desirable to use (for some anyway). It doesn't talk
> >on your behalf which is what a proxy does. When using a proxy, you don't
> >need to (try to) immitate TCP/UDP/ICMP handling because the kernel does
> >that for you.
> You seem to be implying that SPFs only keep information in the state
> tables on port numbers, which is incorrect. The also keep sequence
> numbers for TCP connections, and of course, source and destination IP.
Really ? How amazing. I guess if I'd never written one, I'd never have
known this. However, I haven't seen all implementations so I can't be sure
they all do it the same.
> >Now, let me pick on this:
> >> ...For example, a SPF will usually work at layer 4 for
> >> something like telnet, but will go to layer 7 for FTP, because it has
> >> to. (For an explanation of why FTP is a pain in the ass, check out
> >> Comer or Stevens.)
> >Wrong. It still goes to layer 4 for FTP. Why ? Because it is still
> >dealing with packets, not a data stream.
> Perhaps you don't understand the FTP mode that passes IP address
> in the data stream of the control channel? The proxy or SPF in question
> has to change that to match it's external address, and hence, modify the
> data stream. Most people would call that layer 7.
It's layer 7 when it has to pass the data through the other layers first.
That doesn't happen in SPF's. What does happen is a "layer violation".
i.e. you have code running at layer 3 messing with data that belongs to
If an SPF operated at layer 7, it would have a proxy too.
> >> 1. Proxies are a special case of a SPF.
> >Wrong. FWIW, proxies can be implemented at layers 5, 6 or 7.
> That's got nothing to do with whether or not a proxy is a
> special case of a SPF. Hardly a useful argument.
I should have mentioned that separately.
Proxies are proxies. They're not SPF's although if the protocol in
question has a "state machine" in it (i.e. TELNET/FTP) then it may
well implement some sort of state checking. If anything, packet filtering
is a special case of proxying.
> >I put this to you: if you connect a sniffer to both sides of a firewall,
> >one using SPFs and the other proxies, you will see vastly different types
> >of "packet conversations" between the firewall and the external host it is
> >connecting to. The assertion about "wasted CPU time" is purely subjective
> >and has no real meaning.
> How vastly different could they be? Are you referring to proxies that
> require special client software, like socks does? One would hope that
> the packets wouldn't be too different, or it wouldn't work very well.
For proxies, the headers are going to be quite different, whereas an SPF
will change very little (if anything).
> >> Ok, so SPFs can have bugs to, right? Sure. So, now you
> >> have to "proxy" two protocols. You still don't want to do any special
> >> filtering, just pass it through. So, let's assume that proxies have
> >> one bug each, as do SPFs. So, we have one SPF and two proxies. One bug
> >> with the SPF and two for the proxies.
> >That is crap. If you are using the same code for the SPF then you should be
> >able to use the same code for the proxy.
> >If the proxies are different for each, it indicates to me that the SPF
> >solution hasn't really been developed for either protocol whereas the
> >proxies have been tailored properly for a better fit.
> How could the SPF code and proxy code possibly be the same?
Maybe I didn't make myself clear. If you are using the same SPF code to
allow through two "applications", then it should be possible to use the
same proxy code to pass through two "applications". e.g. tcp_relay (or
plug-gw) is sufficiently generic to proxy almost anything.
However, you couldn't expect the SPF code for FTP to do anything meaningful
for a TELNET connection, much like ftp-gw wouldn't work either (but