On Sat, 7 Feb 2026 at 12:36, Tobias Heider <[email protected]> wrote: > > On Wed, Feb 04, 2026 at 09:42:17AM -0500, Andrew Cagney wrote: > > > > > > Yes we should probably fix this. I am not sure if anyone uses queries. > > > > At least one project is :-) > > > > > I'm pretty certain iked doesn't but isakmpd might. > > > > > > Not sure how useful it is to have queries in an implementation that > > > already diverged quite a lot from all the others, but that is another > > > discussion I guess. > > > > The only divergence I know about for SADB_REGISTER is that OpenBSD > > includes SADB_X_EXT_SUPPORTED_COMP in its response. > > > > I find having the kernel announce what it supports acts as a friendly > > heads up that a new mysterious algorithm has been added, or some cruft > > has finally been deleted. > > > > One alternative is to try installing an SA with each algorithm, it > > works better when the crypto is in a yet-to-be-loaded kernel module, > > but misses new algorithms. > > Makes sense. I was just asking because apparently no one tried in > using it for a while. If it helps you I'll see if I can fix it.
Thanks! > > > CHACHA should also work. It might be easier to check existing users > > > of the API. In iked that would be: > > > https://github.com/openbsd/src/blob/master/sbin/iked/pfkey.c#L75-L95 > > > > I suspect NONE/NULL (can never remember which) is also missing from > > the integrity table. > > Looks like we are sending NONE in iked (by simply not initializing the field) > rather than an explicit NULL. We don't even have AALG_NULL defined it > seems. > Looking at NetBSD and FreeBSD both have NULL in their supported list > so I guess that is what we would want too. That works. It lets clients tick the box saying that support is present in the kernel. > Does libreswan actually send AALG_NULL for AEADs or just leave the > sadb_sa_auth field empty like iked does? Um, yea ... seems libreswan has a variation on that bug. It has a table to map between IKEv2 and SADB (there's a tick mark for any algorithm, including NULL, that the kernel reports as supported). On OpenBSD, since SADB_X_AALG_NULL isn't defined, that field defaulted to zero. Oops. For reference: external/pfkeyv2/darwin-xnu.h:#define SADB_X_AALG_NULL 5 /*251*/ /* null authentication */ external/pfkeyv2/freebsd.h:#define SADB_X_AALG_NULL 251 /* null authentication */ external/pfkeyv2/linux.h:#define SADB_X_AALG_NULL 251 /* kame */ external/pfkeyv2/netbsd.h:#define SADB_X_AALG_NULL 251 /* null authentication */ | sadb_sa @16 len=16(2*8) exttype=1(EXT_SA) spi=3641154862(d9079d2e) replay=16 state=1(SASTATE_MATURE) auth=0(SADB_AALG_NONE) encrypt=20(SADB_X_EALG_AESGCM16) flags=1028=X_SAFLAGS_TUNNEL+X_SAFLAGS_ESN > I am wondering whether it would be enough to announce support for NULL or if > we also need logic to map them on the kernel side. Announcing it is probably sufficient - and perhaps make 0 somewhat official. > > > > > Thanks
