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.
