Jussi Kivilinna wrote:
>>> > diff --git a/include/uapi/linux/pfkeyv2.h
>>> > b/include/uapi/linux/pfkeyv2.h
>>> > index 0b80c80..d61898e 100644
>>> > --- a/include/uapi/linux/pfkeyv2.h
>>> > +++ b/include/uapi/linux/pfkeyv2.h
>>> > @@ -296,6 +296,7 @@ struct sadb_x_kmaddress {
>>> > #define SADB_X_AALG_SHA2_512HMAC 7
>>> > #define SADB_X_AALG_RIPEMD160HMAC 8
>>> > #define SADB_X_AALG_AES_XCBC_MAC 9
>>> > +#define SADB_X_AALG_AES_CMAC_MAC 10
>>> > #define SADB_X_AALG_NULL 251 /* kame */
>>> > #define SADB_AALG_MAX 251
>>>
>>> Should these values be based on IANA assigned IPSEC AH transform
>>> identifiers?
>>>
>>> https://www.iana.org/assignments/isakmp-registry/isakmp-registry.xml#isakmp-registry-6
>>
>> There is no CMAC entry apparently ... despite the fact that CMAC is a
>> proposed RFC standard for IPsec.
>>
>> It might be safer to move that to 14 since it's currently unassigned and
>> then go through whatever channels are required to allocate it. Mostly this
>> affects key setting. So this means my patch would break AH_RSA setkey calls
>> (which the kernel doesn't support anyways).
>>
>
> Problem seems to be that PFKEYv2 does not quite work with IKEv2, and XFRM API
> should be used instead. There is new numbers assigned for IKEv2:
> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml#ikev2-parameters-7
>
> For new SADB_X_AALG_*, I'd think you should use value from "Reserved for
> private use" range. Maybe 250?
We can choose any value unless we do not break existing
binaries. When IKE used, the daemon is responsible
for translation.
--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
