On Mon, 9 Mar 2020 at 12:06, Paul Wouters <[email protected]> wrote: > > > > Begin forwarded message: > > From: Andrew Cagney <[email protected]> > Date: March 9, 2020 at 11:32:17 EDT > To: [email protected] > Subject: [Swan-commit] Changes to ref refs/heads/master > Reply-To: [email protected] > > New commits: > commit 7a7224b0e2381c416decb1d08bc191cd9fd783f1 > Author: Andrew Cagney <[email protected]> > Date: Mon Mar 9 11:27:01 2020 -0400 > > ikev2: rename enum notify_payload_hash_algorithms to enum > ikev2_hash_algorithm > > > This is confusing. We have an IANA registry for ikev2 hash (integ) algorithms > and this is not it.
IKEv1 confused all this yes. > See: > > https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-7 In IKEv2, these are called: Transform Type 3 - Integrity Algorithm Transform IDs and are not hash algorithms. > Versus: > > https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#hash-algorithms > > The first is a transform type, the second is a notify value. Better name > would be ikev2_rfc7427_hash_algo ? While what we've got here is explicitly called: IKEv2 Hash Algorithms hence the rename. Both RFC 7427 and the IANA table are, seemingly, very careful to not tie these values directly to the notify. If that was the intent, the table would have been called something like IKEv2 Notification IPCOMP Transform IDs (Value 16387) My read between the lines is that the IKEv2 group don't want a repetition of IKEv1 - where the same algorithm is given a different number in different contexts - and so defined a generic table. > > I fear ikev2_hash_algorithm is prone to be misused as a transform value. OTOH, IKEv2_HASH_ALGORITHM_.... (unlike IKEv2_AUTH_HASH_...) won't be confused with IKEv2_AUTH_... et.al. Much of the code instead uses struct hash_desc instead of the enum and gcc 10's new enum warnings make that significantly harder. BTW, if you're looking for something confusing try 'enum ikev2_auth_method' vs `enum keyword_authby'. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
