# Re: \[EXTERNAL\] Re: \[REGRESSION\] Discussion on "xfrm: Duplicate SPI Handling" - From: Antony Antony \ - Date: 2026-03-31 10:47:35 - List: netdev - Page: https://ratatoskr.run/netdev/2026/03/11352015 - Thread: https://ratatoskr.run/netdev/2026/03/11352015/t.md ```text Hi, I have tweaked the patch a bit more, uniqueness is only when x->dir == XFRM_SA_DIR_IN. See the attached patch. I have added tags Fixes: and Reported-by: Yan Yan Yan, are you ok with this? So fart I don't have any tests for this, so more tags welcome:) regards, -antony PS: recent libreswan is setting direction. Thta should not be problem. On Mon, Mar 30, 2026 at 20:34:07 +0000, Aakash Kumar Shankarappa wrote: > 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 [ref] > Date: Monday, 30 March 2026 at 10:24 PM > To: Yan Yan [ref] > Cc: Nathan Harold [ref], Tobias Brunner > [ref], antony.antony@secunet.com > [ref], Steffen Klassert > [ref], paul@nohats.ca [ref], > netdev@vger.kernel.org [ref], Herbert Xu > [ref], David S . Miller [ref], > Eric Dumazet [ref], Jakub Kicinski [ref], > pabeni@redhat.com [ref], horms@kernel.org > [ref], Aakash Kumar Shankarappa > [ref], akamluddin@marvell.com > [ref], greg@kroah.com [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 ``` ## Attachments - [0001-xfrm-enforce-SPI-uniqueness-for-inbound-SAs-only.patch](https://ratatoskr.run/netdev/2026/03/11352015/attachment/0) (text/x-diff, 3671 bytes)