YOSHIFUJI Hideaki wrote:
> 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.
I meant, we can choose any values "if" we do not break ...
--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
