Re: [devel-ipsec] Re: [PATCH ipsec-next v5 8/8] xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration

Antony Antony
2026-03-08T14:43:10Z

On Fri, Feb 27, 2026 at 03:14:21PM -0800, Yan Yan via Devel wrote:
> > 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)

that is a limitation we should avoid. It would be nice to extend it
over time. We have been there before and it is a pain point. So it is
worth investigating alternatives if there is momentum here, otherwise
I would keep it simple:)

> That is true. I also have the concern that if all updatable attributes
> follow the "omit-to-clear" pattern, we lose the extensibility. Thus
> ideally we should switch to an "omit-to-inherit" model for some, if
> not all, attributes to ensure that adding new SA properties doesn't
> break backward compatibility.

Here is my proposal. I extended the code and am testing it now; I hope
to send out v6 soon.

How would omit-to-inherit look in practice? Specify almost all XFRMA
attributes supported in XFRM_MSG_NEWSA, minus some immutable ones.
The immutable attributes that come to mind are:

- XFRMA_ALG_* : crypto must not change during the life of an SA;
also *swan userspace does not keep this in memory
after the SA is installed, which is correct
behaviour.
- XFRMA_SA_DIR : direction is fixed at SA creation.
- XFRMA_SEC_CTX : security context is immutable.

currently supported attributes, using omit-to-inherit semantics:

sentinel value to clear, omit to inherit:
- XFRMA_ENCAP : encap_type=0 to clear
- XFRMA_OFFLOAD_DEV : ifindex=0 to clear

omit to inherit; send attr with value 0/0 to clear:
- XFRMA_SET_MARK / XFRMA_SET_MARK_MASK
- XFRMA_MARK : omit-to-inherit old_mark; note XFRMA_MARK
serves dual purpose -- old_mark in the
fixed header is the SA lookup key, and
XFRMA_MARK attribute sets the new mark.

set to zero to move from NAT to no-NAT; inherit when absent:
- XFRMA_NAT_KEEPALIVE_INTERVAL
- XFRMA_MTIMER_THRESH

omit to inherit; send 0 to clear:
- XFRMA_TFCPAD : TFC padding
- XFRMA_SA_EXTRA_FLAGS : e.g. DONT_ENCAP_DSCP, OSEQ_MAY_WRAP;
yes, these can change.
- XFRMA_IF_ID : xfrm interface ID; relevant when the SA
moves to a different xfrm interface.
- XFRMA_COADDR : Care-of Address (Mobile IPv6).

- XFRMA_REPLAY_ESN_VAL / XFRMA_REPLAY_VAL : may be later replay type
should not change.

Basic migration supported via fixed header fields (new_* fields):
- src and dst address family
- src and/or dst address
- reqid

I also added old_mark to the SA lookup alongside the SPI, so the SA
can be uniquely identified when marks are in use. XFRMA_MARK can then
be used to set the new mark value independently.

regards,
-antony

>
> On Fri, Feb 27, 2026 at 3:26 AM Sabrina Dubroca <sd@queasysnail.net> wrote:
> >
> > 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
>
>
>
> --
> --
> Best,
> Yan
> --
> Devel mailing list -- devel@lists.linux-ipsec.org
> To unsubscribe send an email to devel-leave@lists.linux-ipsec.org