On May 2, 2013, at 1:23 PM, Damien Miller <d...@mindrot.org> wrote:

> 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.

Agreed.  Let's put a hard limit on it.  5, 10, 20, 50?

>>> 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.

That sounds a bit too complex as well, but would likely work.  I'll read
into this some more, thanks.

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

Mainly to avoid any kind of introduction of latency, buffering,
asynchronous behaviour, packet reordering, not invoking the scheduler,
avoiding cache line bouncing, and being generally prone to multithreading
issues in a perfect world where multiple CPUs could drive the networking
stack. Also not having to reimplement certain packet parsing code, state
tracking, and so on and so forth.  Look, I have written all that stuff in
user space, but redundancy and complicated architectures are not suitable
for forwarding large loads of traffic.  User space is that magical place
that can do anything, even throw off your packet throughput by invoking
a syscall to pull the current time stamp.  Moving implementations to
user space does not necessarily make them better or less of a problem.

That's my concern.  :)


Reply via email to