Message-ID: <aEqXpFSawrMOO25V@Antony2201.local>
Date: Thu, 12 Jun 2025 11:02:28 +0200
From: Antony Antony <antony@...nome.org>
To: Steffen Klassert <steffen.klassert@...unet.com>
Cc: Aakash Kumar S <saakashkumar@...vell.com>, netdev@...r.kernel.org,
	herbert@...dor.apana.org.au, davem@...emloft.net,
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
	horms@...nel.org, akamaluddin@...vell.com, devel@...ux-ipsec.org
Subject: Re: [PATCH]   xfrm: Duplicate SPI Handling – IPsec-v3 Compliance Concern

On Wed, Jun 11, 2025 at 12:51:51PM +0200, Steffen Klassert wrote:
> On Mon, Jun 09, 2025 at 12:20:14PM +0530, Aakash Kumar S wrote:
> >         The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI
> >         Netlink message, which triggers the kernel function xfrm_alloc_spi().
> >         This function is expected to ensure uniqueness of the Security Parameter
> >         Index (SPI) for inbound Security Associations (SAs). However, it can
> >         return success even when the requested SPI is already in use, leading
> >         to duplicate SPIs assigned to multiple inbound SAs, differentiated
> >         only by their destination addresses.

Is this an issue in xfrm stack without hardware offload? Does it affect packet
flow? It seems SA install will allow non uniqe SPI for incoming, even
after this. Which is the correct behaviour.

I have a feeling this is an issue due to hardware implementer's choice
of only support one option from RFC 4301 section 4.4.2?

> > 
> >         This behavior causes inconsistencies during SPI lookups for inbound packets.
> >         Since the lookup may return an arbitrary SA among those with the same SPI,
> >         packet processing can fail, resulting in packet drops.
> > 
> >         According to RFC 6071, in IPsec-v3, a unicast SA is uniquely identified
> >         by the SPI alone. Therefore, relying on additional fields
> >         (such as destination addresses, proto) to disambiguate SPIs contradicts
> >         the RFC and undermines protocol correctness.

> 
> This is not quite right, RFC 4301 says:
> 
> If the packet is addressed to the IPsec device and AH or ESP is
> specified as the protocol, the packet is looked up in the SAD.
> For unicast traffic, use only the SPI (or SPI plus protocol).
> 
> So using the potocol as as lookup key is OK.

That’s correct—the commit message should not reference RFC 6701. I would suggest instead referring to RFC 4301, specifically sections 4.1 and 4.4.2. These sections describe the three SPI uniqueness constraints allowed by the architecture for the incoming path.

- Unique SPI
- Unique (SPI + protocol (AH/ESP) + destination IP of the incoming SA)
- Unique (SPI + protocol + destination IP + source IP)

The IPsec architecture RFC 4301 explicitly allows all three options for 
incoming SAs, which is why I don’t believe anything is currently broken in 
the data path.

So it is not complaince issue. In my opinion, RFC 6071 is not standard RFC 
to be complaint with. It looks like an odd RFC among IPsec standards, what 
is IPsec-v3? IPsec IMHO should refer RFC 7296, 4303 and 4301 and related 
RFCs. We can also take this on IETF mailing list, instead of netdev.

As for SPI allocation, it is indeed permissible to be restrictive, as proposed by this patch.
However, section 4.4.2 of RFC 4301—which indirectly governs SPI 
allocation—is only applicable to unicast SAs.

So I’m also supportive of the patch, provided the commit message offers a 
clearer explanation and outlines what exactly is broken under the current 
behavior. Ideally also how to re-produce it.  This is important. I would 
love to see generic hardware supporting all 3 cases above, just like xfrm 
implementation.

PS: I am ccing more IPsec experts.
latest version of the patch is at:
https://lore.kernel.org/all/20250612055017.806273-1-saakashkumar@marvell.com/

-antony

Powered by blists - more mailing lists