pfkey has a feature to announce supported algorithms.
This makes it easier to write portable daemons which on start
discover which alogrithms are supported.

When some of the more recent ESP algorithms were added, they
were not added to the supported list (probably since iked and
isakmpd doesn't use this feature and just hard codes a list of
supported algorithms on OpenBSD).
Below is a diff to add the missing ones which should make it
easier to port other ike implementations like libreswan,
see https://marc.info/?l=openbsd-bugs&m=177017688300753&w=2

The list is based on what iked supports. We define a few more code
points for AUTH algorithms but those are only used internally so
I think it doesn't make sense to add them here.

AEADs only use the encryption algorithm API and ignore the auth
algorithm passed via pfkey entirely. The auth algorithm gets
overwritten with a matching internal ID (see netinet/ip_esp.c:167),
iked simply passes 0 but in theory it shouldn't matter.
This is even true for AES GMAC which is a bit weird since it
technically doesn't offer any encryption at all.

The IV, minlen and maxlen fields should be in sync with crypto/xform.c

ok?

diff ea7513787810d64759a3a840e5b3fcc10e202581 96a3a92b24082e4bc76c9bd018c02a4377fcaf0d
commit - ea7513787810d64759a3a840e5b3fcc10e202581
commit + 96a3a92b24082e4bc76c9bd018c02a4377fcaf0d
blob - 0c5340831b78f5e8b86ad581205ab7fc18614daf
blob + d8e434b1aa8767e09a03ce8a663e5d75aacae605
--- sys/net/pfkeyv2.c
+++ sys/net/pfkeyv2.c
@@ -102,7 +102,10 @@ static const struct sadb_alg ealgs[] = {
 	{ SADB_X_EALG_BLF, 64, 40, BLF_MAXKEYLEN * 8},
 	{ SADB_X_EALG_CAST, 64, 40, 128},
 	{ SADB_X_EALG_AES, 128, 128, 256},
-	{ SADB_X_EALG_AESCTR, 128, 128 + 32, 256 + 32}
+	{ SADB_X_EALG_AESCTR, 128, 128 + 32, 256 + 32},
+	{ SADB_X_EALG_AESGCM16, 64, 128 + 32, 256 + 32},
+	{ SADB_X_EALG_AESGMAC, 64, 128 + 32, 256 + 32},
+	{ SADB_X_EALG_CHACHA20POLY1305, 64, 256 + 32, 256 + 32}
 };
 
 static const struct sadb_alg aalgs[] = {