0

I was testing the xfrm framework through the ip xfrm commands, and when testing the state update operation, I did not manage to change either the encryption keys or the authentication keys. A similar issue can be found in this link.

I am not sure if this is intended behaviour to protect some how the SAD entries installed in the kernel or is some bug.

From my google research I did find out in the following link that they define this issue as a bug and they fixed it. Still I am not sure if this is an intended behaviour or is something still not fixed in the linux kernel.

AdminBee
  • 22,803
dcrypt
  • 1

1 Answers1

0

The primary use case for XFRM_MSG_UPDSA (ip xfrm state update) is to update an inbound SA for which only an SPI has been allocated via XFRM_MSG_ALLOCSPI. The latter can be replicated with ip xfrm state allocspi:

Usage: ip xfrm state allocspi ID [ mode MODE ] [ mark MARK [ mask MASK ] ]
    [ reqid REQID ] [ seq SEQ ] [ min SPI max SPI ]

When using IKE, this is necessary as the SPI is required before the algorithms and keys are negotiated with the peer. Afterwards, this temporary state can be updated once with all the missing information, including algorithms and keys.

However, for states added with XFRM_MSG_NEWSA (ip xfrm state add), which is e.g. the case for outbound SAs for which no SPI is allocated locally, or those that were updated once, the kernel only allows very specific information to be changed. As of writing this (i.e. kernel version 6.3/6.4), this includes:

  • the ports for UDP encapsulation (but not whether encapsulation is used or the IPs)
  • the MIPv6 care-of address (if any)
  • the lifetimes
  • the XFRM interface ID
  • the mark set by the SA on processed packets

But it's not possible to change fundamental information like the algorithms or the keys for such SAs.

ecdsa
  • 819
  • 4
  • 7
  • Great, thanks for the clarification. I was expecting this type of behaviour for security reasons, but I was not totally sure since I didn´t find any more information. – dcrypt May 10 '23 at 07:16
  • It's not really for security reasons, all these commands require the NET_ADMIN capability (which usually just root has). There is generally just no use case for it. Updating the algorithms and/or keys (or other parameters like ESN) of an existing SA with the same SPI isn't interoperable. That's why during IPsec SA rekeying, a new SA (with different keys) is created and, once that's in place, the old one is deleted. – ecdsa May 10 '23 at 09:31