Hi, Since there are no IANA numbers assigned for transformations in PFKEYv2 messages we have been following ISAKMP registry and then with GCM have switched to the IKEv2 registry. The only reason to do so [that I can think of] and not just pick a consecutive number is in hopes of userland software (iked) being compatible to other PFKEYv2 implementations that will pick the same number and/or define.
Unfortunately in practice this doesn't always happen: NetBSD has picked different (ISAKMP) numbers (but same defines) for SADB_X_AALG_AES*GMAC and I question whether we should actually strive to preserve the number compatibility with any standard or registry? Should we maybe just list them all in a consecutive order w/o adherence to a particular standard and eliminate gaps so that checks for "greater than SADB_EALG_MAX" actually make sense? Or do we want to continue following IKEv2 registry? IANA ISAKMP registry: http://www.iana.org/assignments/isakmp-registry/isakmp-registry.xhtml IANA IKEv2 registry: http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml If we decide to follow IKEv2, then I'd like some OKs for the diff below. diff --git sys/net/pfkeyv2.h sys/net/pfkeyv2.h index 2af10ea..ca69d53 100644 --- sys/net/pfkeyv2.h +++ sys/net/pfkeyv2.h @@ -314,8 +314,8 @@ struct sadb_x_tap { #define SADB_X_EALG_AESGCM12 19 #define SADB_X_EALG_AESGCM16 20 #define SADB_X_EALG_AESGMAC 21 -#define SADB_X_EALG_CHACHA20POLY1305 22 -#define SADB_EALG_MAX 22 +#define SADB_X_EALG_CHACHA20POLY1305 28 +#define SADB_EALG_MAX 28 #define SADB_X_CALG_NONE 0 #define SADB_X_CALG_OUI 1
