Re: [devel-ipsec] Re: [PATCH ipsec-next v5 8/8] xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration
From: Sabrina Dubroca
Date: Fri Feb 27 2026 - 06:28:13 EST
2026-02-26, 17:44:51 -0800, Yan Yan via Devel wrote:
> Hi Antony,
>
> May I request that we also support updating the XFRMA_SET_MARK as part
> of the new XFRM_MSG_MIGRATE_STATE message?
>
> In Android, the primary use case for migration is switching the
> underlying physical network for an IPsec tunnel (e.g. VPN, Wifi
> calling). Currently, due to the limits of XFRM_MSG_MIGRATE, we are
> forced to use a separate UPDSA call to update the set-mark. Supporting
> XFRMA_SET_MARK within the migrate message would allow us to update the
> addresses and the routing mark together in one atomic call.
>
> Regarding the logic, I believe the set-mark can follow the same
> omit-to-clear pattern as XFRMA_ENCAP and XFRMA_OFFLOAD_DEV.
I think this raises a wider question: clearly definining and
documenting which attributes need to be explicitly provided
("omit-to-clear" as you write), and which will be implicitly copied.
Currently it looks like we copy:
- all the crypto stuff (aalg/aead/etc)
- security context stuff
- coaddr
- replay/replay_esn
- pcpu_num, if_id, tfcpad
- dir
- mark
- extra_flags
but not
- nat_keepalive_interval
- offload
- encap
[gathered from a quick read of xfrm_state_clone_and_setup + the
definition of xfrma_policy]
Anything that we leave as implicit copy will have to be "forever"
implicitly copied with this new MIGRATE_STATE op -- unless we find a
way to pass a new "clear these properties" flag (probably via a list
of XFRMA_* attribute names), but then we could also implement that
with the existing MIGRATE code.
--
Sabrina