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 feasible. 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, Franco
