Ok, that is what Henning calls a proxy. But this is not my definition : for me a proxy receive connexion from a client, and initiates another connexion to the server. In that case there are two connexions, instead of one when only firewalling. Anyway, you know that, and that is not the most important.A piece of kernel code smart enough to inspect packets comprising a partular protocol, and extract enough information to determine if they are, in fact "related" is exactly what Henning is referring to as a kernel "proxy"
Again, I agree. But that does not resolve the issue. Please consider the case I'm talking about (Bridge, ...). What we need is a OpenBSD solution. We do one of the best packet filter available, make bridging surprisingly easy, but the killer feature is missing. In fact, I do not care whether it is in the kernel or not. The only thing I'm sure is that it cannot be a proxy (in my definition).Yes. Since the kernel sees traffic a packet at a time, it essentially has to "fake" the statefulness of TCP in order to track these things. It's a layer violation. It's also next to impossible, without re-implementing TCP. This is EXACTLY why the decision to make these kinds of per-protocol decision was relegated to userland in the first place: because TCP will handle the state issues, before userland sees the packets.
Think fragment attacks. Think of the attacks against IPF's ftp kernel code. Think of EVERY ambiguity that scrub was intended to help correct.
We had this debate long ago. The kernel way is the WRONG way. Writing
a userland proxy for a particular protocol is by definition easier
than writing the kernel equivalent, since you don't have to figure out what
the TCP will do with ambiguities.
As I said, there may a user land solution. Some kind of global user space "advisor" daemon, helping packet filter to make complicated decisions, for example.
henning wrote:
you have a solution. it is called ftp-proxy.
But that's not bridging any longer...
Julien
