Hi Antony,
Thanks for the patch. Yes the x->dir based gating approach looks good
to me and it works for Marvell.
Also this seems like the right direction. It preserves backward
compatibility for existing users, while still allowing strict RFC 4301
complaint SPI uniqueness as an opt-in feature. Anybody who wants the
stricter behaviour can upgrade to Strongswan 6.0.0+ and leverage
XFRM_SA_DIR_IN.
Thanks, Aakash
From: Antony Antony [off-list ref]
Date: Monday, 30 March 2026 at 10:24 PM
To: Yan Yan [off-list ref]
Cc: Nathan Harold [off-list ref], Tobias Brunner
[off-list ref], antony.antony@secunet.com
[off-list ref], Steffen Klassert
[off-list ref], paul@nohats.ca [off-list ref],
netdev@vger.kernel.org [off-list ref], Herbert Xu
[off-list ref], David S . Miller [off-list ref],
Eric Dumazet [off-list ref], Jakub Kicinski [off-list ref],
pabeni@redhat.com [off-list ref], horms@kernel.org
[off-list ref], Aakash Kumar Shankarappa
[off-list ref], akamluddin@marvell.com
[off-list ref], greg@kroah.com [off-list ref]
Subject: [EXTERNAL] Re: [REGRESSION] Discussion on "xfrm: Duplicate SPI
Handling"
Prioritize security for external emails:
Confirm sender and content safety before clicking links or opening
attachments
[1]Report Suspicious
Hi, I looked into this. I feel a simple solution is use x->dir as
Nathan proposed. When dir is not set we get pre commit 94f39804d891
("xfrm: Duplicate SPI Handling") behaviour. When XFRM_SA_DIR is set
alloc_spi() returns per direction unique spi. Another benfit is, this
would also keep PF_KEY use case as it was before that comit. Here is
simple RFC patch attached. How does this look? strongswan 6.0.0, from
Dec 2024, sets x->dir. Aakash would this work for for marvell? regads,
-antony On Fri, Mar 27, 2026 at 17:05:13 -0700, Yan Yan wrote: > Hi
all, > I wanted to send a friendly ping to see if we are aligning on
making > the strict global SPI uniqueness requirement optional, perhaps
via a > toggle or by leveraging the XFRM_SA_DIR attribute as previously
> discussed. > Are there any other questions or concerns regarding this
approach, or > anything else we should clarify to ensure backward
compatibility while > meeting the needs of modern standards? > Best, >
Yan > > On Tue, Feb 24, 2026 at 3:53 PM Nathan Harold
<[1]nharold@google.com> > wrote: > > > That should still be allowed
when using the intended APIs (i.e. > ALLOCSPI > > for the inbound and
NEWSA for the outbound SA). ALLOCSPI might > enforce > > a unique SPI
without considering the address, as that's intended > for > > local,
inbound SAs, where the kernel has full control (looking at > the > >
the patch, it's certainly not ideal, as it goes through all > installed
> > SAs to find a duplicate and it prevents an inbound SPI that >
matches an > > existing outbound SPI - I guess that could be resolved
by using > separate > > tables for in- and outbound SAs). But that must
not prevent > installing > > outbound SAs with the same SPI to another
peer using NEWSA, which > still > > uses a hash that includes the
destination address (that must > always be > > the case because peers
are free to allocate whatever SPI they > want). > Agreed that there are
some unfortunate limitations with the current > patch. Keying off the
inclusion of XFRM_SA_DIR would resolve the > issue > you noted
(conflating inbound and outbound SPIs) and function as an > opt-in for
this enforcement. Whatever the mechanism though, the new > behavior
should be opt-in rather than opt-out in order to maintain > backwards
compatibility. > > In my opinion, you are using the API incorrectly...
I also > > don't think there are any benefits in that "consistent
larval > lifecycle" > > (if you found any, please let us know). > The
Android architecture is multi-tenant and allows userspace apps > to >
establish SAs. At the time we designed it, this felt like the >
cleanest > way to facilitate leak-free resource management because the
chain of > associations between kernel resources could be symmetrical
(and > managing them was already quite complicated). Mea culpa
(Nathan). > But, > correctly or not, it has/had worked for many years.
> > By the way, are you using the min/max option for inbound SAs as >
well, > > with an SPI generated in userland? That would seem like a >
violation of > > the intention of the API as well (i.e. letting the
kernel control > the > > local SPIs). > We provide following two
Android APIs for app developers: >
[2][2]https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.an
droid.com_reference_android_net_IpSecManager-23&d=DwIDaQ&c=nKjWec2b6R0m
OyPaz7xtfQ&r=r6Wzn5LnVsk7Tgc5x4l_c04I_Hr_8TYqFn-YFi_gjqI&m=JsnNMKKypJWI
SL5BbGkfA2yD1_H51rd5M6YO4NG3WpRdteRwP5OdfTJFNEK0Xiec&s=9txNFXC-wFiRFV_Q
JlIQLW2AWSbERIOWcGHJfuQP2ZA&e= >
allocateSecurityParameterIndex(java.net.InetAddress) >
[3][3]https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.an
droid.com_reference_android_net_IpSecManager-23&d=DwIDaQ&c=nKjWec2b6R0m
OyPaz7xtfQ&r=r6Wzn5LnVsk7Tgc5x4l_c04I_Hr_8TYqFn-YFi_gjqI&m=JsnNMKKypJWI
SL5BbGkfA2yD1_H51rd5M6YO4NG3WpRdteRwP5OdfTJFNEK0Xiec&s=9txNFXC-wFiRFV_Q
JlIQLW2AWSbERIOWcGHJfuQP2ZA&e= >
allocateSecurityParameterIndex(java.net.InetAddress,%20int) > Indeed,
allocateSecurityParameterIndex is direction-agnostic; both > overloads
are implemented internally by including the min and max > values in
ALLOCSPI. For the variant where app developers provide a > specific SPI
(which is also useful in testing), Android simply sets > both the min
and max parameters to that exact value. Our > understanding > of
#xfrm_alloc_spi is that min/max are required for ALLOCSPI, and >
otherwise ENOENT will be returned. > Note that we also use the DADDR as
a mandatory part of the tuple > because of the issue mentioned above:
SPIs are only unique in > conjunction with a DADDR, regardless of
direction, and accordingly, > that’s how Android is expecting the
uniqueness requirement be > enforced. In this way, 5 duplicate SPIs can
be used on 5 unique IP > addresses on the same machine; therefore, a
strict "SPI only" > interpretation for ALLOCSPI (or SPI handling in
general) is curious. > We feel that ALLOCSPI should really enforce the
same uniqueness > requirements as the SAD. > Best, > Nathan and Yan >
-Nathan > On Wed, Feb 18, 2026 at 12:42 AM Tobias Brunner >
<[4]tobias@strongswan.org> wrote: > > > > Hi Yan, > > > > > For every
inbound SA, we allocate SPIs before negotiation. For > > > outbound
SAs, we allocate SPIs once requested by the peer. We > only > > >
require the (SPI, destination address) combo to be unique. Thus, > we >
> > may have an inbound and outbound SA sharing an SPI with > different
> > > destinations, or multiple outbound SAs to different peers >
sharing an > > > SPI. > > > > That should still be allowed when using
the intended APIs (i.e. > ALLOCSPI > > for the inbound and NEWSA for
the outbound SA). ALLOCSPI might > enforce > > a unique SPI without
considering the address, as that's intended > for > > local, inbound
SAs, where the kernel has full control (looking at > the > > the patch,
it's certainly not ideal, as it goes through all > installed > > SAs to
find a duplicate and it prevents an inbound SPI that > matches an > >
existing outbound SPI - I guess that could be resolved by using >
separate > > tables for in- and outbound SAs). But that must not
prevent > installing > > outbound SAs with the same SPI to another peer
using NEWSA, which > still > > uses a hash that includes the
destination address (that must > always be > > the case because peers
are free to allocate whatever SPI they > want). > > > > >> If so, why
would you use ALLOCSPI and not just install the > outbound SA? Is it to
avoid differences for in- and outbound SAs > (ALLOCSPI+UPDSA vs.
NEWSA)?" > > > > > > Exactly—it is primarily for code symmetry. By
using ALLOCSPI + > UPDSA > > > for both directions, we maintain a
consistent larval lifecycle > and > > > make it easier to maintain. > >
> > In my opinion, you are using the API incorrectly. ALLOCSPI is >
intended > > to allocate a free local SPI for an inbound SA. That is,
reserve > it > > before and while the details of the SA are negotiated
with the > peer > > using IKE. This step isn't necessary for outbound
SAs and forcing > such > > an allocation, after all the details are
known, to the responder's > SPI > > (which I assume you do via min/max
option) doesn't feel right. I > also > > don't think there are any
benefits in that "consistent larval > lifecycle" > > (if you found any,
please let us know). And the difference > between > > UPDSA and NEWSA
is the nlmsg_type (there are some attributes that > are > > different
for in- and outbound SAs, especially if you set the > direction > > in
newer kernels, but that's the case regardless of the message > type). >
> > > By the way, are you using the min/max option for inbound SAs as >
well, > > with an SPI generated in userland? That would seem like a >
violation of > > the intention of the API as well (i.e. letting the
kernel control > the > > local SPIs). > > > > As the XFRM API basically
mirrors PF_KEYv2 here, you can find more > about > > the two ways to
install SAs in RFC 2367 (SADB_GETSPI/UPDATE vs. > SADB_ADD). > > > >
Regards, > > Tobias > > > > -- > > -- > Best, > Yan > > References > >
1. mailto:nharold@google.com > 2.
[4]https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.andro
id.com_reference_android_net_IpSecManager-23allocateSecurityParameterIn
dex-28java.net.InetAddress-29&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=r6Wzn
5LnVsk7Tgc5x4l_c04I_Hr_8TYqFn-YFi_gjqI&m=JsnNMKKypJWISL5BbGkfA2yD1_H51r
d5M6YO4NG3WpRdteRwP5OdfTJFNEK0Xiec&s=UtpwkuoswT-6aK0he6dSS-0dvZfIcRjbfj
_Eu4A-c6E&e= > 3.
[5]https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.andro
id.com_reference_android_net_IpSecManager-23allocateSecurityParameterIn
dex-28java.net.InetAddress&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=r6Wzn5Ln
Vsk7Tgc5x4l_c04I_Hr_8TYqFn-YFi_gjqI&m=JsnNMKKypJWISL5BbGkfA2yD1_H51rd5M
6YO4NG3WpRdteRwP5OdfTJFNEK0Xiec&s=fVmYoLIpyuMX3AtAkU7ejR1dno_8QtnhCKLMD
4BmURc&e=, int) > 4. mailto:tobias@strongswan.org
References
Visible links:
1. https://us-phishalarm-ewt.proofpoint.com/EWT/v1/CRVmXkqW!tG3Tv5d8inv1_6DXc1X1B4ctthRq2qCkR8nIF_n_SOJiXQ-SqG_LUk--J5LZEwV9jGdXABQriDruLYnPEg$
2. https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.android.com_reference_android_net_IpSecManager-23&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=r6Wzn5LnVsk7Tgc5x4l_c04I_Hr_8TYqFn-YFi_gjqI&m=JsnNMKKypJWISL5BbGkfA2yD1_H51rd5M6YO4NG3WpRdteRwP5OdfTJFNEK0Xiec&s=9txNFXC-wFiRFV_QJlIQLW2AWSbERIOWcGHJfuQP2ZA&e=
3. https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.android.com_reference_android_net_IpSecManager-23&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=r6Wzn5LnVsk7Tgc5x4l_c04I_Hr_8TYqFn-YFi_gjqI&m=JsnNMKKypJWISL5BbGkfA2yD1_H51rd5M6YO4NG3WpRdteRwP5OdfTJFNEK0Xiec&s=9txNFXC-wFiRFV_QJlIQLW2AWSbERIOWcGHJfuQP2ZA&e=
4. https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.android.com_reference_android_net_IpSecManager-23allocateSecurityParameterIndex-28java.net.InetAddress-29&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=r6Wzn5LnVsk7Tgc5x4l_c04I_Hr_8TYqFn-YFi_gjqI&m=JsnNMKKypJWISL5BbGkfA2yD1_H51rd5M6YO4NG3WpRdteRwP5OdfTJFNEK0Xiec&s=UtpwkuoswT-6aK0he6dSS-0dvZfIcRjbfj_Eu4A-c6E&e=
5. https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.android.com_reference_android_net_IpSecManager-23allocateSecurityParameterIndex-28java.net.InetAddress&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=r6Wzn5LnVsk7Tgc5x4l_c04I_Hr_8TYqFn-YFi_gjqI&m=JsnNMKKypJWISL5BbGkfA2yD1_H51rd5M6YO4NG3WpRdteRwP5OdfTJFNEK0Xiec&s=fVmYoLIpyuMX3AtAkU7ejR1dno_8QtnhCKLMD4BmURc&e=
Hidden links:
7. https://aka.ms/GetOutlookForMac