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? -d
