linux-kernel - Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 02 Oct 2018 19:34 +0200
From:   Wolfgang Walter <linux@...m.de>
To:     Florian Westphal <fw@...len.de>
Cc:     Steffen Klassert <steffen.klassert@...unet.com>,
        David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
        christophe.gouault@...nd.com
Subject: Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels

Am Dienstag, 2. Oktober 2018, 16:56:16 schrieb Florian Westphal:
> Wolfgang Walter <linux@...m.de> wrote:
> > Since my last reply to this message I didn't get a reply: is there any
> > progress how to fix this performance regression I missed?
> 
> Did you test/experiment with hthresh config option?

I did. It did not improve the situation.

I suppose that is because our masks range from /16 to /30 and excpecially have 
for example /16 <=> /8 and vice versa.

When forwarding, every policy A => B also implies that you add a policy B => 
A.

I'm not familiar when the policy database is consulted, but I think it now has 
to for every not encrypted paket, and for those all rules have to be 
consulted. And unencrypted traffic is a large part of the traffic on that 
router.

That is: for unencrypted traffic neither the buckets of the hash nor the 
inexact list may be large.

> 
> > Or are we stuck here with longterm kernel 4.9 for a long time?
> 
> I'm experimenting with per-dst inexact lists in an rbtree but
> this will take time.

Hmm, I doubt that this is worth the effort. And certainly not that easy 
correctly done, as it still would have to obey the original order of the rules 
(their priority).

You may have a lot of rules of the form say

	10.0.0.0/16 <=> 10.1.0.0/29 encrypt ....
	10.0.0.0/16 <=> 10.1.0.8/29 encrypt ....
	....

And things like that.

Also, you get something like that

	10.0.1.0/24 <=> 10.0.2.0/29 allow
	10.0.0.0/16 <=> 10.0.2.0/24 encrypt
	0.0.0.0 <=> 10.0.2.0/16 block

And people may use source port and/or destination port or protocol 
(tcp/udp/imcp) to further tailor there ruleset.

Here is the approach HiPAC took for packet classification

https://pdfs.semanticscholar.org/a0bb/9d31e2499fb659c9e0d9544072d2f3c25079.pdf
https://pdfs.semanticscholar.org/0dea/8ee87f596f200de2722cbe9480610dd1a0db.pdf

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts