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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 30 Jun 2014 14:50:18 +0200
From:	Christophe Gouault <>
To:	Steffen Klassert <>,
	Herbert Xu <>,
	"David S. Miller" <>
Cc:	"" <>
Subject: IPsec policy database customization proposal

Hi IPsec and network maintainers,

After proposing a patchset to netdev (xfrm: scalability enhancements
for policy database) and discussing with Steffen Klassert, we agree on
the fact that the SPD lookup algorithm needs performance and
scalability improvements: SPs with non-prefixed selectors are
optimized through a hash table, but other SPs (the majority) are
stored in a sorted chained list, which does not scale. Additionally a
flowcache is used, and is known not to scale.

The bottleneck is the SPD lookup by selector (configuration and lookup itself).

Unfortunately, there is no all-in-one multi-field classifier that
would behave well in all situations. However, various classifiers
exist that are fitted to this or that use case. Therefore, I suggest
the following approach: adding hooks in the IPsec SPD, so that one can
dynamically register a custom SPD implementation ("SPD driver") fitted
to its use case, typically by loading a kernel module.

This obviously needs discussion before starting any development, so
here is a more detailed proposal:

- Define the minimum handlers to manipulate the SPD lookup by selector (alloc,
  insert, delete, flush, lookup_bysel, lookup_byflow, destroy...).
- export a register/unregister function, so that an SPD implementation may
  register/unregister its handlers.
- Separate the SPD common code from the SPD lookup by selector code. Keep the
  policy_all and policy_byidx tables in the common code, extract the current
  policy_inexact + policy_bydst implementation as an SPD driver. It is the
  default implementation when no SPD driver is registered.
- *struct xfrm_policy* must offer a private area for SPD driver data (void * or
  opaque place holder of fixed size or opaque place holder of size specific to
  driver implementation).
- since we keep the current implementation as the default, the policy_inexact +
  policy_bydst database heads (currently stored in netns->xfrm and xfrm_policy
  link fields (bydst and flo) may remain at their current location.
- SPD drivers needing some configuration may export their specific
  configuration API (/proc, netlink...)
- as a first step, we only support one registered handler at a time.
- as a first step, an SPD driver can only be loaded or unloaded if the SPD is
  empty (return EBUSY otherwise).


- this architecture is open to later evolutions such as supporting the
  registration of several handlers, dynamically listing/selecting/switching
  drivers via netlink messages (to support dynamic change of SPD implementation
  according to SPD content).
- loading/unloading or changing SPD drivers with a non empty SPD implies to
  rebuild the SPD from the SP list. This may lock the SPD for a rather long

I would like your opinion/questions/advices.

Best Regards,
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists