[Swan-dev] ikev2_hash_algorithm , was Fwd: [Swan-commit] Changes to ref refs/heads/master
andrew.cagney at gmail.com
Mon Mar 9 17:47:57 UTC 2020
On Mon, 9 Mar 2020 at 12:06, Paul Wouters <paul at nohats.ca> wrote:
> Begin forwarded message:
> From: Andrew Cagney <cagney at vault.libreswan.fi>
> Date: March 9, 2020 at 11:32:17 EDT
> To: swan-commit at lists.libreswan.org
> Subject: [Swan-commit] Changes to ref refs/heads/master
> Reply-To: swan-dev at lists.libreswan.org
> New commits:
> commit 7a7224b0e2381c416decb1d08bc191cd9fd783f1
> Author: Andrew Cagney <cagney at gnu.org>
> 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.
In IKEv2, these are called:
Transform Type 3 - Integrity Algorithm Transform IDs
and are not 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'.
More information about the Swan-dev