[dpdk-dev] [PATCH v4 04/10] lib: introduce ipsec library

Akhil Goyal akhil.goyal at nxp.com
Fri Dec 21 12:57:20 CET 2018



On 12/20/2018 11:47 PM, Ananyev, Konstantin wrote:
>>>> +
>>>> +static int
>>>> +fill_crypto_xform(struct crypto_xform *xform,
>>>> +	const struct rte_ipsec_sa_prm *prm)
>>>> +{
>>>> +	struct rte_crypto_sym_xform *xf;
>>>> +
>>>> +	memset(xform, 0, sizeof(*xform));
>>>> +
>>>> +	for (xf = prm->crypto_xform; xf != NULL; xf = xf->next) {
>>>> +		if (xf->type == RTE_CRYPTO_SYM_XFORM_AUTH) {
>>>> +			if (xform->auth != NULL)
>>>> +				return -EINVAL;
>>>> +			xform->auth = &xf->auth;
>>>> +		} else if (xf->type == RTE_CRYPTO_SYM_XFORM_CIPHER) {
>>>> +			if (xform->cipher != NULL)
>>>> +				return -EINVAL;
>>>> +			xform->cipher = &xf->cipher;
>>>> +		} else if (xf->type == RTE_CRYPTO_SYM_XFORM_AEAD) {
>>>> +			if (xform->aead != NULL)
>>>> +				return -EINVAL;
>>>> +			xform->aead = &xf->aead;
>>>> +		} else
>>>> +			return -EINVAL;
>>>> +	}
>>>> +
>>>> +	return check_crypto_xform(xform);
>>>> +}
>>> how is this function handling the inbound and outbound cases.
>>> In inbound first xform is auth and then cipher.
>>> In outbound first is cipher and then auth. I think this should be
>>> checked in the lib.
>> Interesting, I didn't know about such limitation.
>> My understanding was that the any order (<auth,cipher>, <cipher,auth>)
>> for both inbound and outbound is acceptable.
>> Is that order restriction is documented somewhere?
>>
> Actually, if such restriction really exists, and cryptodev framework obeys it,
> then crypto session creation will fail anyway.
ipsec library should not rely on other components to give error.
it should handle the cases which it is expected to.
As per my understanding, IPSEC is a cipher then authenticate protocol 
for outbound case and it should give error in other case.
Similarly, auth then cipher in case of inbound case.
>>> Here for loop should not be there, as there would be at max only 2 xforms.



More information about the dev mailing list