All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antony Antony <antony.antony@secunet.com>
To: Steffen Klassert <steffen.klassert@secunet.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	<netdev@vger.kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	<devel@linux-ipsec.org>, <linux-kernel@vger.kernel.org>
Subject: [PATCH ipsec-next 0/6] xfrm: XFRM_MSG_MIGRATE_STATE new netlink message
Date: Fri, 9 Jan 2026 14:29:52 +0100	[thread overview]
Message-ID: <cover.1767964254.git.antony@moon.secunet.de> (raw)


    The current XFRM_MSG_MIGRATE interface is tightly coupled to policy and
    SA migration, and it lacks the information required to reliably migrate
    individual SAs. This makes it unsuitable for IKEv2 deployments,
    dual-stack setups (IPv4/IPv6), and scenarios where policies are managed
    externally (e.g., by other daemons than IKE daemon).

    Mandatory SA selector list
    The current API requires a non-empty SA selector list, which does not
    reflect IKEv2 use case.
    A single Child SA may correspond to multiple policies,
    and SA discovery already occurs via address and reqid matching. With
    dual-stack Child SAs this leads to excessive churn: the current method
    would have to be called up to six times (in/out/fwd × v4/v6) on SA,
    while the new method only requires two calls. While polices are
    migrated, first installing a block policy

    Selectors lack SPI (and marks)
    XFRM_MSG_MIGRATE cannot uniquely identify an SA when multiple SAs share
    the same policies (per-CPU SAs, SELinux label-based SAs, etc.). Without
    the SPI, the kernel may update the wrong SA instance.

    Reqid cannot be changed
    Some implementations allocate reqids based on traffic selectors. In
    host-to-host or selector-changing scenarios, the reqid must change,
    which the current API cannot express.

    Because strongSwan and other implementations manage policies
    independently of the kernel, an interface that updates only a specific
    SA — with complete and unambiguous identification — is required.

    XFRM_MSG_MIGRATE_STATE provides that interface. It supports migration
    of a single SA via xfrm_usersa_id (including SPI) and we fix
    encap removal in this patch set, reqid updates, address changes,
    and other SA-specific parameters. It avoids the structural limitations
    of
    XFRM_MSG_MIGRATE and provides a simpler, extensible mechanism for
    precise per-SA migration without involving policies.

Antony Antony (6):
  xfrm: remove redundent assignment
  xfrm: allow migration from UDP encapsulated to non-encapsulated ESP
  xfrm: rename reqid in xfrm_migrate
  xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration
  xfrm: reqid is invarient in old migration
  xfrm: check that SA is in VALID state before use

 include/net/xfrm.h          |   3 +-
 include/uapi/linux/xfrm.h   |  11 +++
 net/key/af_key.c            |  10 +--
 net/xfrm/xfrm_policy.c      |   4 +-
 net/xfrm/xfrm_state.c       |  41 ++++-----
 net/xfrm/xfrm_user.c        | 164 +++++++++++++++++++++++++++++++++++-
 security/selinux/nlmsgtab.c |   3 +-
 7 files changed, 206 insertions(+), 30 deletions(-)

--
2.39.5


             reply	other threads:[~2026-01-09 13:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-09 13:29 Antony Antony [this message]
2026-01-09 13:37 ` [PATCH ipsec-next 1/6] xfrm: remove redundent assignment Antony Antony
2026-01-13 14:59   ` Simon Horman
2026-01-09 13:37 ` [PATCH ipsec-next 2/6] xfrm: allow migration from UDP encapsulated to non-encapsulated ESP Antony Antony
2026-01-09 13:37 ` [PATCH ipsec-next 3/6] xfrm: rename reqid in xfrm_migrate Antony Antony
2026-01-09 13:38 ` [PATCH ipsec-next 4/6] xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration Antony Antony
2026-01-13 14:57   ` Simon Horman
2026-01-14 16:09     ` [devel-ipsec] " Antony Antony
2026-01-15 13:44       ` Simon Horman
2026-01-16 11:02         ` Antony Antony
2026-01-16 11:26           ` Simon Horman
2026-01-09 13:38 ` [PATCH ipsec-next 5/6] xfrm: reqid is invarient in old migration Antony Antony
2026-01-09 13:38 ` [PATCH ipsec-next 6/6] xfrm: check that SA is in VALID state before use Antony Antony

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1767964254.git.antony@moon.secunet.de \
    --to=antony.antony@secunet.com \
    --cc=davem@davemloft.net \
    --cc=devel@linux-ipsec.org \
    --cc=edumazet@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=steffen.klassert@secunet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.