Best option to process packet ACL

[Ze Claudio Pastore]

Because actually, this is ot a packet firewall.

When I mentioned pf/ipfw is only to reffer to ideas on how to best match
each acl criteria.

But my userland application is a proxy, ACL will handle L7 requests within
the packets. I will filter based on the mentioned criteria but it will be
processed at a different moment unrelated to packet in kernel. It's also
DPDK enabled so it's mostly skipping the whole kernel.



2016-04-28 11:50 GMT-03:00 Alan Somers <asomers at freebsd.org>:

> On Wed, Apr 27, 2016 at 1:21 PM, Zé Claudio Pastore <zclaudio at bsd.com.br>
> wrote:
>
>> Hello everyone,
>>
>> I would like to hear your suggestion regarding the best approach to
>> process
>> IP packets for filtering, in such a way I can avoid lowering my pps rate.
>>
>> Today a have a simple application proxies http application. It's dual
>> threaded on a 4 core system with low CPU power. The current application
>> uses two threads, one for control and one for data flow processing.
>>
>> I need to implement a simple set of stateless filtering, I will process
>> only:
>>
>> - src-ip
>> - dst-ip
>> - src-port
>> - dst-port
>> - iplen
>> - proto (tcp/udp/other)
>>
>> My current rate of requests per second is high, around 200K. I have no
>> idea
>> how I can leverage the IDLE CPUs the best way to implement this ACL
>> filtering trying not to impact on the pps rate I have today.
>>
>> I have implemented it serial today (not threaded) and I get 40%
>> performance
>> loss. I will handle max 128 filter rules, this is a decision which is
>> made.
>> This is going to be first match wins.
>>
>> My current plans are to test:
>>
>> 1) Create 6 threads, one to test each aspect of the ACL (src-ip, dst-ip,
>> etc) the first thread that returns false to parent thread I stop
>> processing
>> that rule and go to the next, and tell all other threads to die/exit since
>> they don't matter anymore.
>>
>> 2) Create one thread to process a batch of rules, say, 8 rules per thread
>> per request. Don't know if I would limit total number of threads and lock
>> requests while threads ar e busy.
>>
>> 3) Someone suggested "do as pf/ipfw do" but I have no idea how it's done,
>> how multithreaded it is and what is done on each thread.
>>
>> 4) Other suggestion?
>>
>> This is going to run FreeBSD 11, I use libevent2 on the current
>> application
>> so far.
>>
>> Thanks.
>> _______________________________________________
>>
>>
> Is there some reason why you can't simply use pf or ipfw?  ipfw can do
> everything you described.  pf can do most of it, but I'm not sure if pf can
> filter on iplen.  If I were you, I wouldn't attempt to write my own
> userland firewall until I was absolutely sure that neither pf nor ipfw
> would work.  If that's the case, then I would try using diverter sockets.
> With a diverter socket, pf or ipfw does most of the work, but when it
> encounters a packet it can't process it pushes it up to a userland helper.
> The userland helper processes the packet and then tells pf or ipfw what to
> do with it.  In realistic applications, pf or ipfw also creates a temporary
> rule based on the userland helper's decision.  Applying the temporary rule
> in the future is far faster than invoking the userland helper.  After a
> certain amount of time, the temporary rule will expire again.
>
>
> Here's an example in action:
> http://daemonforums.org/showthread.php?t=8846
>
> -Alan
>