On Sat, Nov 14, 2015 at 13:27 +0100, Mike Belopuhov wrote: > 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. >
Forgot to clarify that this is only a userland to kernel interface. My personal opinion is just to list algorithms we support in consecutive order.
