ip xfrm delete / deleteall not able to delete SAs

Hi all,

I'm observing some quite strange behaviour and am wondering what is going
on...

So I have a single SA in the kernel (5.14.16, iproute 5.15.0):

--------------------------------------------------
$ sudo ip xfrm state
src 6.6.6.6 dst 5.5.5.5
        proto esp spi 0x00000000 reqid 2325 mode transport
        replay-window 32 
        auth-trunc hmac(sha1)  96
        enc ecb(cipher_null) 
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
        sel src 6.6.6.6/32 dst 5.5.5.5/32 sport 2222 dport 1111 
--------------------------------------------------

Then I try to delete it individually and fail

--------------------------------------------------
$ sudo ip xfrm state delete src 6.6.6.6 dst 5.5.5.5 proto esp spi 0
RTNETLINK answers: No such process
--------------------------------------------------

Then I try deleteall and it also fails

--------------------------------------------------
$ sudo ip xfrm state deleteall
Failed to send delete-all request
: No such process
--------------------------------------------------

And finally, the SA still exists:

--------------------------------------------------
$ sudo ip xfrm state
src 6.6.6.6 dst 5.5.5.5
        proto esp spi 0x00000000 reqid 2325 mode transport
        replay-window 32
        auth-trunc hmac(sha1)  96
        enc ecb(cipher_null)
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
        sel src 6.6.6.6/32 dst 5.5.5.5/32 sport 2222 dport 1111
--------------------------------------------------

The SA is not removed and re-added, there is no automagic other process
running for that.  'ip xfrm monitor' doesn't show any changes at all when
the 'delete' or the 'deleteall' is running.

Flushing via 'ip xfrm state flush' works, but that is sort-of beyond the
point:  Of course I need to be able to selectively delete SAs at runtime
without flushing the entire database.

Selective deletion and deleteall of policies works as expected.  Just SAs
exhibit the strange behavior described above.

Regards,
	Harald

-- 
- Harald Welte [off-list ref]           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Hi again,

I did a bit more testing and the problem seems to occur with SPI=0,
i.e. the kernel permits a SA for SPI=0 to be created via netlink, but then
it somehow fails to allow that to be deleted again via netlink, and it will
be stuck until the user manually flushes all SAs.

To be fair, RFC4303 says "The SPI value of zero (0) is reserved for local,
implementation-specific use and MUST NOT be sent on the wire"

However, despite that, I think the kernel should ether

a) reject creation of any SA with SPI=0

b) if it accepts a SA with SPI=0 in NEWSA, it should equally accept
   the symmetric DELSA operation with SP=0

-- 
- Harald Welte [off-list ref]           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)