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

Message-ID: <CADdy8Hq=Pi2PwuA4JLhd2smV7FKSwFLGCDvbCpviSqxhFaKTfg@mail.gmail.com>
Date:	Mon, 30 Jun 2014 14:50:18 +0200
From:	Christophe Gouault <christophe.gouault@...nd.com>
To:	Steffen Klassert <steffen.klassert@...unet.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	"David S. Miller" <davem@...emloft.net>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
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).

Remarks:

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

I would like your opinion/questions/advices.

Best Regards,
Christophe
--
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