Re: [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload

[Thomas Monjalon <thomas@monjalon.net>]

Hi,

I try to understand how things are connected,
but too many things are not clear for someone not involved in security.

25/07/2017 13:21, Akhil Goyal:
> struct rte_security_session *
> rte_security_session_create(struct rte_mempool *mempool);

What is the usage of this mempool?

[...]
> These are very similar to what Declan proposed with a few additions.
> This can be updated further for other security protocols like MACSec and DTLS

You should avoid referencing another proposal without
- link to the proposal
- summary of the proposal

[...]
> Now, after the application configures the session using above APIs, it needs to
> attach the  session with the crypto_op in case the session is configured for
> crypto look aside protocol offload. For IPSec inline/ full protocol offload
> using NIC, the mbuf ol_flags can be set as per the RFC suggested by Boris.

Again a missing reference (link + summary).

Even worst, the RFCv2 references this v1 without copying the explanations.
It is too hard to track, or maybe it is cryptic on purpose ;)

[...]
> Now the application(ipsec-secgw) have 4 paths to decide for the data path.
> 1. Non-protocol offload (currently implemented)
> 2. IPSec inline(only crypto operations using NIC)
> 3. full protocol offload(crypto operations along with all the IPsec header
>    and trailer processing using NIC)
> 4. look aside protocol offload(single-pass encryption and authentication with
>    additional levels of protocol processing offload using crypto device)

I feel these 4 paths are the most important to discuss.
Unfortunately there are not enough detailed.
Please explain the purpose and implementation of each one.

> The application can decide using the below action types
> enum rte_security_session_action_type {
>         RTE_SECURITY_SESS_ETH_INLINE_CRYPTO,
>         /**< Crypto operations are performed by Network interface */

In this mode, the ethdev port does the same thing as a crypto port?

>         RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD,
>         /**< Crypto operations with protocol support are performed
>          * by Network/ethernet device.
>          */
>         RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD,
>         /**< Crypto operations with protocol support are performed
>          * by Crypto device.
>          */

I guess the difference between ETH_PROTO_OFFLOAD and CRYPTO_PROTO_OFFLOAD
is that we must re-inject packets from CRYPTO_PROTO_OFFLOAD to the NIC?

>         RTE_SECURITY_SESS_NONE
> 	/**< Non protocol offload. Application need to manage everything */
> };

What RTE_SECURITY_SESS_NONE does? It is said to be implemented above.