netdev - Re: IPsec policy database customization proposal

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] [day] [month] [year] [list]

Message-ID: <20140721110143.GA3396@secunet.com>
Date:	Mon, 21 Jul 2014 13:01:43 +0200
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Christophe Gouault <christophe.gouault@...nd.com>
CC:	Herbert Xu <herbert@...dor.apana.org.au>,
	"David S. Miller" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: IPsec policy database customization proposal

On Wed, Jul 16, 2014 at 09:35:41AM +0200, Christophe Gouault wrote:
> 
> There are several multi-field classification algorithms, but few seem
> adapted to SPD/SAD lookup:
> 
> - linear search
> - hierarchical tries
> - set-pruning tries
> - grid-of-tries
> - bit-vector linear search
> - cross-producting

We used a cross-producting algorithm for a while to do
policy lookups. It scaled for policy lookups because
the policy database was rather static. It does not
scale at all for state lookups because states change
quite often and the cross-product table must be
reconstructed whenever the database changes.

> 
> As far as I understand, the only things that concerned you about the
> patchset were:
> 
> - using /proc to configure the algorithm, you prefer netlink.
> - adding a configuration API that could potentially be later
> deprecated. My feeling is that the choice of a brand new SPD algorithm
> will not happen before long.
> - calculation of thresholds is not automatic. As I already suggested,
> it may be configured by a daemon if an automatic system is needed.

Why do you think a daemon can do a better job in automatic
configuration? We maintain the policy hashlists inside the
kernel, so we should know the best about their sizes.

But I agree that not everybody wants to have such an automatic
configuration, so we need some knobs to tune it from userspace.

> 
> What if I rework the patchset and replace the configuration via /proc
> by a configuration by netlink:
> 
> - supporting message XFRM_MSG_NEWSPDINFO from userland, with
>   attribute XFRMA_SPD_HTHRESH
> - adding XFRMA_SPD_HTHRESH attribute to XFRM_MSG_NEWSPDINFO messages
> from the kernel in reply to XFRM_MSG_GETSPDINFO?
> 

OK.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html