)]}'
{
  "commit": "355f808d8a11fa69b19dfd8811bc87d97830f5d6",
  "tree": "eadc95f807ba7af7192412b5c2a0e6386a7564c1",
  "parents": [
    "41c4d3b26f5e23609cd4b5ca561a399a097daabe",
    "c13c0cc6f52e491186f6521dc80031c35737162d"
  ],
  "author": {
    "name": "Steffen Klassert",
    "email": "steffen.klassert@secunet.com",
    "time": "Tue Jun 09 16:02:12 2026 +0200"
  },
  "committer": {
    "name": "Steffen Klassert",
    "email": "steffen.klassert@secunet.com",
    "time": "Tue Jun 09 16:02:12 2026 +0200"
  },
  "message": "Merge branch \u0027xfrm: XFRM_MSG_MIGRATE_STATE new netlink message\u0027\n\nAntony Antony says:\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nThe current XFRM_MSG_MIGRATE interface is tightly coupled to policy and\nSA migration, and it lacks the information required to reliably migrate\nindividual SAs. This makes it unsuitable for IKEv2 deployments,\ndual-stack setups (IPv4/IPv6), and scenarios where policies are managed\nexternally (e.g., by daemons other than the IKE daemon).\n\nMandatory SA selector list\nThe current API requires a non-empty SA selector list, which does not\nreflect the IKEv2 use case.\nA single Child SA may correspond to multiple policies,\nand SA discovery already occurs via address and reqid matching. With\ndual-stack Child SAs this leads to excessive churn: the current method\nwould have to be called up to six times (in/out/fwd × v4/v6) on SA,\nwhile the new method only requires two calls.\n\nSelectors lack SPI (and marks)\nXFRM_MSG_MIGRATE cannot uniquely identify an SA when multiple SAs share\nthe same policies (per-CPU SAs, SELinux label-based SAs, etc.). Without\nthe SPI, the kernel may update the wrong SA instance.\n\nReqid cannot be changed\nSome implementations allocate reqids based on traffic selectors. In\nhost-to-host or selector-changing scenarios, the reqid must change,\nwhich the current API cannot express.\n\nBecause strongSwan and other implementations manage policies\nindependently of the kernel, an interface that updates only a specific\nSA - with complete and unambiguous identification - is required.\n\nSA Selector, x-\u003esel, can\u0027t be changed, especially Transport mode.\n\nXFRM_MSG_MIGRATE_STATE provides that interface. It supports migration\nof a single SA via xfrm_usersa_id (including SPI) and we fix\nencap removal in this patch set, reqid updates, address changes,\nand other SA-specific parameters. It avoids the structural limitations\nof XFRM_MSG_MIGRATE and provides a simpler, extensible mechanism for\nprecise per-SA migration without involving policies.\nThis method also allows migtrating SA selectors typically used with\nhost-to-host in Transport mode.\n\nNew migration steps: first install block policy, remove the old policy,\ncall XFRM_MSG_MIGRATE_STATE for each state, then re-install the\npolicies and remove the block policy.\n\nIf the target SA tuple (daddr, SPI, proto, family) is already\noccupied, the operation returns -EEXIST. In this case the original\nSA is not preserved. Userspace must handle -EEXIST by\nre-establishing the SA at the IKE level and manage policies.\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nSigned-off-by: Steffen Klassert \u003csteffen.klassert@secunet.com\u003e\n",
  "tree_diff": []
}