On Thu, 2 May 2013, Franco Fichtner wrote:

> > Well, bare minimum complexity per-protocol * large_number_of_protocols =
> > a lot of complexity. The incentive is always going to be to add more
> > protocols and never retire them.
> I guess that's true for most software projects.

We try not to implement an effectively unbounded number of protocol
parsers in the kernel.

> > Also, doesn't IPPROTO_DIVERT or SO_BINDANY+SO_SPLICE allow you to do
> > near zero-overhead DPI completely in userspace?
> Wouldn't that mean pf.conf(5) syntax extensions cannot be implemented?

It doesn't mean that - you'd just need some way for userspace to signal
information to pf. E.g add a SO_PF_TAG to set the pf tag. Then you could
use some program that used SO_BINDANY to inspect the beginning of the
session, set a pf tag using setsockopt, SO_SPLICE to avoid further need
to copy the session in userspace and control the traffic in pf using the
tagged keyword.

> It's not full-blown DPI analysis for extracting all kinds of events
> from a flow -- it's merely a tagging tool, and if that sits in user
> space, it's really not helpful except for logging / accounting. One
> could do that with a simple pcap(3) binding as well.

Why not do the tagging in userspace using the existing facilities?


Reply via email to