Hi all,

adhering to the basic rule of not reinventing the wheel has sort of
crippled the efforts to come up with an elegant solution for the
topic at hand.  Two approaches have been proposed earlier, so let's
go through them:

(1) Diverting traffic to userspace

That's generally a good idea, but defeats the purpose of having
zero-latency functionality in pf(4) itself, because going through
the scheduler isn't optimal (scheduler people, don't hate me).
Worse still, the way TCP incorporates handshakes makes loosely-
coupled DPI worthless, because the divert cannot happen before
the payload is seen.  The only way around this is not diverting
at all -- that can only happen with a pf(4) that's completely
contained in userspace.  I understand the requirement of not doing
anything reckless in the kernel and I don't think it's a wise
decision to try it anyway.  Remember that the goal was to keep
consistency and utilise the base functionality in the firewall
code itself.

(2) bpf(4)-based filters

The BPF-VM is neat and the idea of its filters in accordance with
the current requirements for the proposed code.  However, the amount
of work and infrastructure to be built around bpf(4) to avoid any kind
of unwanted complexity inside the DPI code is -- at least for me -- not

Instead, the route to take at this point is a userspace library, which
can grow, try different things, stumble, explode, adapt, and some day
may even be the base of a firewall away from the restriction of the kernel.
Others can still implement (1).  I don't think (2) will be of much interest
in real world applications.  Feel free to contact me on and off-list if you
have any further questions.  :)

Thank you all for your participation,


Reply via email to