* Re: [RFC PATCH v2 0/4] IPSec Inline and look aside crypto offload
@ 2017-08-28 14:23 Narayana Prasad Athreya
2017-08-28 14:26 ` Narayana Prasad Athreya
0 siblings, 1 reply; 3+ messages in thread
From: Narayana Prasad Athreya @ 2017-08-28 14:23 UTC (permalink / raw)
To: dev
> This patchet showcases the definition and usage of the rte_security
> APIs described in the RFC v1 sent earlier.
>
> The data path and configuration path is similar to what was proposed in
> version 1. However, rte_security_configure API is removed, as it looked
> redundant.
>
> Also the rte_security.x files are placed inside the lib/librte_cryptodev/
> as the APIs are defined with the help of crypto APIs and it makes more sense
> to extend the cryptodev library instead of a separate library which perform
> similar actions.
>
> Some of the parameters of the APIs are also modified for better usability.
> The parameter ``dev_name`` is removed as the appropriate device(crypto/eth)
> can be obtained by using the action type.
>
> The patchset is still in work in progress state and there may be some changes
> and cleanup in the next version. This is just to enable others to work
> in parallel on the crypto offloading using ethernet devices.
>
> This patchset include the definition of rte_security APIs in patch 1,
> changes required in cryptodev in patch 2, sample driver implementation
> in patch 3 and ipsec-secgw application changes in patch 4.
>
> Akhil Goyal (4):
> RFC2: rte_security: API definitions
> cryptodev: entend cryptodev to support security APIs
> crypto/dpaa2_sec: add support for protocol offload ipsec
> example/ipsec-secgw: add support for offloading crypto op
>
> drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 368 ++++++++++++++++++++++++-
> drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h | 33 +++
> examples/ipsec-secgw/ipsec.c | 125 ++++++---
> examples/ipsec-secgw/ipsec.h | 13 +-
> examples/ipsec-secgw/sa.c | 142 +++++++---
> lib/librte_cryptodev/Makefile | 3 +-
> lib/librte_cryptodev/rte_crypto_sym.h | 15 +
> lib/librte_cryptodev/rte_cryptodev.h | 20 +-
> lib/librte_cryptodev/rte_cryptodev_pmd.h | 35 +++
> lib/librte_cryptodev/rte_security.c | 171 ++++++++++++
> lib/librte_cryptodev/rte_security.h | 409 ++++++++++++++++++++++++++++
> 11 files changed, 1243 insertions(+), 91 deletions(-)
> create mode 100644 lib/librte_cryptodev/rte_security.c
> create mode 100644 lib/librte_cryptodev/rte_security.h
>
> --
> 2.9.3
I have a few questions/comments on the v1 and v2 versions of this patch.
I accumulated these from a few different cavium stakeholders.
1. conf_ipsec_sa::sa_dir and ipsec_xform::op seem to have same purpose.
2. Its unclear how the Crypto Device will be configured to use a
specific Network device and vice-versa. The situation is when the same
network port must process IPsec and regular traffic. Should regular
traffic also use the singular device?
3. The spec seems to assume PMD Network device. Event driven model is
also needed.
4. SA Options for expiry(byte/time) are lacking.
5. Error handling and Status notifications are not specified. These can
be tricky in the inline mode of operation, particularly inbound.
6. SA expiry handling is another key aspect which hasn’t been accounted for.
7. No anti-replay window size SA param.
8. ESP TFC padding not addressed.
9. Incremental checksum computation in transport mode ESP doesnt appear
to be addressed
10. Didnt spot details for tunnel mode header preservation
11. Selector checking, especially for the inner packet in tunnel mode
appears to be missing
12. Dynamic offloading - selectively offload some packets in hardware is
a feature we would like to support.
13. Destination queue for IPSEC events: Operations in asynchronous or
inline mode enqueue resulting events into this queue. This helps with
our 93xx inline ipsec design.
14. If event model (ASYNC) and inline are supported, there should be a
“pipeline” classifier option for inbound SAs.
15. Maximum number of destination CoSes is not supported. The same CoS
may be used for many SAs.
16. Per protocol header parsing capability after inbound processing is
missing. Preferred options : None/L2/L3/L4/ALL protocols.
17. Per protocol outer header retention in inbound processing is
missing. Preferred options : None/L2/L3/L4/ALL protocols.
Thanks
Prasad
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC PATCH v2 0/4] IPSec Inline and look aside crypto offload
2017-08-28 14:23 [RFC PATCH v2 0/4] IPSec Inline and look aside crypto offload Narayana Prasad Athreya
@ 2017-08-28 14:26 ` Narayana Prasad Athreya
0 siblings, 0 replies; 3+ messages in thread
From: Narayana Prasad Athreya @ 2017-08-28 14:26 UTC (permalink / raw)
To: dev, Berestovskyy, Andriy, Manoharan, Balasubramanian
Cc: Kulkarni, Sunil, Chandran, Suheil, Murthy, Nidadavolu
On Monday 28 August 2017 07:53 PM, Narayana Prasad Athreya wrote:
>> This patchet showcases the definition and usage of the rte_security
>> APIs described in the RFC v1 sent earlier.
>>
>> The data path and configuration path is similar to what was proposed in
>> version 1. However, rte_security_configure API is removed, as it looked
>> redundant.
>>
>> Also the rte_security.x files are placed inside the lib/librte_cryptodev/
>> as the APIs are defined with the help of crypto APIs and it makes more sense
>> to extend the cryptodev library instead of a separate library which perform
>> similar actions.
>>
>> Some of the parameters of the APIs are also modified for better usability.
>> The parameter ``dev_name`` is removed as the appropriate device(crypto/eth)
>> can be obtained by using the action type.
>>
>> The patchset is still in work in progress state and there may be some changes
>> and cleanup in the next version. This is just to enable others to work
>> in parallel on the crypto offloading using ethernet devices.
>>
>> This patchset include the definition of rte_security APIs in patch 1,
>> changes required in cryptodev in patch 2, sample driver implementation
>> in patch 3 and ipsec-secgw application changes in patch 4.
>>
>> Akhil Goyal (4):
>> RFC2: rte_security: API definitions
>> cryptodev: entend cryptodev to support security APIs
>> crypto/dpaa2_sec: add support for protocol offload ipsec
>> example/ipsec-secgw: add support for offloading crypto op
>>
>> drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 368 ++++++++++++++++++++++++-
>> drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h | 33 +++
>> examples/ipsec-secgw/ipsec.c | 125 ++++++---
>> examples/ipsec-secgw/ipsec.h | 13 +-
>> examples/ipsec-secgw/sa.c | 142 +++++++---
>> lib/librte_cryptodev/Makefile | 3 +-
>> lib/librte_cryptodev/rte_crypto_sym.h | 15 +
>> lib/librte_cryptodev/rte_cryptodev.h | 20 +-
>> lib/librte_cryptodev/rte_cryptodev_pmd.h | 35 +++
>> lib/librte_cryptodev/rte_security.c | 171 ++++++++++++
>> lib/librte_cryptodev/rte_security.h | 409 ++++++++++++++++++++++++++++
>> 11 files changed, 1243 insertions(+), 91 deletions(-)
>> create mode 100644 lib/librte_cryptodev/rte_security.c
>> create mode 100644 lib/librte_cryptodev/rte_security.h
>>
>> --
>> 2.9.3
> I have a few questions/comments on the v1 and v2 versions of this
> patch. I accumulated these from a few different cavium stakeholders.
>
> 1. conf_ipsec_sa::sa_dir and ipsec_xform::op seem to have same purpose.
> 2. Its unclear how the Crypto Device will be configured to use a
> specific Network device and vice-versa. The situation is when the same
> network port must process IPsec and regular traffic. Should regular
> traffic also use the singular device?
> 3. The spec seems to assume PMD Network device. Event driven model is
> also needed.
> 4. SA Options for expiry(byte/time) are lacking.
> 5. Error handling and Status notifications are not specified. These
> can be tricky in the inline mode of operation, particularly inbound.
> 6. SA expiry handling is another key aspect which hasn’t been
> accounted for.
> 7. No anti-replay window size SA param.
> 8. ESP TFC padding not addressed.
> 9. Incremental checksum computation in transport mode ESP doesnt
> appear to be addressed
> 10. Didnt spot details for tunnel mode header preservation
> 11. Selector checking, especially for the inner packet in tunnel mode
> appears to be missing
> 12. Dynamic offloading - selectively offload some packets in hardware
> is a feature we would like to support.
> 13. Destination queue for IPSEC events: Operations in asynchronous or
> inline mode enqueue resulting events into this queue. This helps with
> our 93xx inline ipsec design.
> 14. If event model (ASYNC) and inline are supported, there should be a
> “pipeline” classifier option for inbound SAs.
> 15. Maximum number of destination CoSes is not supported. The same CoS
> may be used for many SAs.
> 16. Per protocol header parsing capability after inbound processing
> is missing. Preferred options : None/L2/L3/L4/ALL protocols.
> 17. Per protocol outer header retention in inbound processing is
> missing. Preferred options : None/L2/L3/L4/ALL protocols.
>
> Thanks
> Prasad
cc'ed the cavium stakeholders.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [RFC PATCH 0/1] IPSec Inline and look aside crypto offload
@ 2017-07-25 11:21 Akhil Goyal
2017-08-15 6:35 ` [RFC PATCH v2 0/4] " Akhil Goyal
0 siblings, 1 reply; 3+ messages in thread
From: Akhil Goyal @ 2017-07-25 11:21 UTC (permalink / raw)
To: dev, borisp, declan.doherty
Cc: radu.nicolau, aviadye, sandeep.malik, hemant.agrawal,
pablo.de.lara.guarch, Akhil Goyal
Below is a counter proposal for the RFC sent by Boris.
If we find some consensus, we can have implementation for this proposal in a few weeks.
The proposal is largely inline with the thoughts from Declan with a few exceptions.
Here we are proposing a security framework which can be used both by crypto drivers
and the hw offloaded NIC to showcase the protocol offload support as well as inline
ipsec in hw offloaded NIC.
The placement of the rte_security.X can either be a separate library like
lib/librte_security/ or it can be taken as an extension to the lib/librte_cryptodev/.
The reason for placing this in the cryptodev is that we are referring to some
crypto enums and the APIs look similar to that of cryptodev.
Here we propose that the application may be able to configure either NIC or
crypto PMD to perform IPSec and other security operations.
This is configured using the API
int
rte_security_configure(uint16_t dev_id, char *dev_name);
This API take dev_id and dev_name to identify which device needs to perform security
operation. Once the device is enabled for Security operations, the application can
create and initialize the session for the enabled device.
struct rte_security_session *
rte_security_session_create(struct rte_mempool *mempool);
int
rte_security_session_init(uint16_t dev_id, char *dev_name,
struct rte_security_session *sess,
struct rte_security_sess_conf *conf,
struct rte_mempool *mempool);
These two APIs are similar to the rte_cryptodev_sym_session_create and
rte_cryptodev_sym_session_init respectively, except that rte_security_session_init
takes device name also to identify between the NIC(IPSEC inline or full offload)
or crypto(look aside protocol offload).
These sessions can be cleared and freed with the APIs
int
rte_security_session_clear(uint8_t dev_id, char *dev_name,
struct rte_security_session *sess);
int
rte_security_session_free(struct rte_security_session *sess);
The details for various structures used are mentioned in the below patch.
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
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.
Configuration path for both crypto and NIC can be illustrated as below
Configuration Path Configuration Path
for NIC for Crypto
| |
+--------|--------+ +--------|--------+
| Add/Remove | | Add/Remove |
| IPsec SA | | IPSec SA |
| | | | | |
|--------|--------| +--------|--------+
| |
+--------V--------+ |
| Flow API | |
+--------|--------+ |
| |
+--------V--------+ +--------V--------+
| | | |
| NIC PMD | | Crypto PMD |
| | | |
+--------|--------+ +--------|--------+
| |
+--------|--------+ +--------|--------+
| HW ACCELERATED | | HW Crypto |
| NIC | | Protocol Aware |
| | | Device |
+--------|--------+ +--------|--------+
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)
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 */
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.
*/
RTE_SECURITY_SESS_NONE
/**< Non protocol offload. Application need to manage everything */
};
Egress Data Path
For ETH_INLINE_CRYPTO For CRYPTO_PROTO_OFFLOAD
| |
+--------|--------+ +-----------|-----------+
| egress IPsec | | Plain packet from NIC |
| | | | | |
| +------V------+ | | +--------V--------+ |
| | SABD lookup | | | | SA lookup | |
| +------|------+ | | +--------|--------+ |
| +------V------+ | | +--------V--------+ |
| | Tunnel | | | | session attach | |
| +------|------+ | | +--------|--------+ | +------------+
| +------V------+ | | +--------V--------+ | | Hw crypto |
| | ESP | | | |Enqueue to crypto|------> Device | <--- Headers are added by the HW device.
| | | | | | Device | | | |
| +------|------+ | | +-----------------+ | +-----|------+
+--------V--------+ | +-----------------+ | |
| | | Dequeue from |<-----------+
+--------V--------+ | | Crypto Device | |
| L2 Stack | | +--------|--------+ |
+--------|--------+ | +--------V--------+ |
| | | L2 Stack | |
+--------V--------+ | +--------|--------+ |
| | +-----------|-----------+
| NIC PMD | |
| | +-----------V-----------+
+--------|--------+ | NIC PMD |
| | (packet sent out) |
+--------|--------+ +-----------|-----------+
| HW ACCELERATED |
| NIC |
| |
+--------|--------+
Ingress Data Path
For ETH_INLINE_CRYPTO For CRYPTO_PROTO_OFFLOAD
| |
+--------|--------+ +-----------|-----------+
| Ingress ipsec | | Encap packet from NIC |
| | | | | |
| +------V------+ | | +--------V--------+ |
| | HW ACC NIC | | | | SA lookup | |
| +------|------+ | | +--------|--------+ |
| +------V------+ | | +--------V--------+ |
| |validate ESP | | | | session attach | |
| +------|------+ | | +--------|--------+ | +------------+
| +------V------+ | | +--------V--------+ | | Hw crypto |
| |Remove ESP | | | |Enqueue to crypto|------> Device | <--- Headers are removed by the HW device.
| | and Tunnel | | | | Device | | | |
| +------|------+ | | +-----------------+ | +-----|------+
+--------V--------+ | +-----------------+ | |
| | | Dequeue from |<-----------+
+--------V----------+ | | Crypto Device | |
|Plain packet to App| | +--------|--------+ |
+--------|----------+ | +--------V--------+ |
| |Plain packet to | |
| | app | |
| +-----------------+ |
+-----------------------+
Akhil Goyal (1):
RFC: rte_security: proposal
lib/librte_security/rte_security.h | 405 +++++++++++++++++++++++++++++++++++++
1 file changed, 405 insertions(+)
create mode 100644 lib/librte_security/rte_security.h
--
2.9.3
^ permalink raw reply [flat|nested] 3+ messages in thread* [RFC PATCH v2 0/4] IPSec Inline and look aside crypto offload
2017-07-25 11:21 [RFC PATCH 0/1] " Akhil Goyal
@ 2017-08-15 6:35 ` Akhil Goyal
0 siblings, 0 replies; 3+ messages in thread
From: Akhil Goyal @ 2017-08-15 6:35 UTC (permalink / raw)
To: dev, declan.doherty, thomas, radu.nicolau, aviadye, borisp,
pablo.de.lara.guarch, sergio.gonzalez.monroy
Cc: hemant.agrawal, sandeep.malik, Akhil Goyal
This patchet showcases the definition and usage of the rte_security
APIs described in the RFC v1 sent earlier.
The data path and configuration path is similar to what was proposed in
version 1. However, rte_security_configure API is removed, as it looked
redundant.
Also the rte_security.x files are placed inside the lib/librte_cryptodev/
as the APIs are defined with the help of crypto APIs and it makes more sense
to extend the cryptodev library instead of a separate library which perform
similar actions.
Some of the parameters of the APIs are also modified for better usability.
The parameter ``dev_name`` is removed as the appropriate device(crypto/eth)
can be obtained by using the action type.
The patchset is still in work in progress state and there may be some changes
and cleanup in the next version. This is just to enable others to work
in parallel on the crypto offloading using ethernet devices.
This patchset include the definition of rte_security APIs in patch 1,
changes required in cryptodev in patch 2, sample driver implementation
in patch 3 and ipsec-secgw application changes in patch 4.
Akhil Goyal (4):
RFC2: rte_security: API definitions
cryptodev: entend cryptodev to support security APIs
crypto/dpaa2_sec: add support for protocol offload ipsec
example/ipsec-secgw: add support for offloading crypto op
drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 368 ++++++++++++++++++++++++-
drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h | 33 +++
examples/ipsec-secgw/ipsec.c | 125 ++++++---
examples/ipsec-secgw/ipsec.h | 13 +-
examples/ipsec-secgw/sa.c | 142 +++++++---
lib/librte_cryptodev/Makefile | 3 +-
lib/librte_cryptodev/rte_crypto_sym.h | 15 +
lib/librte_cryptodev/rte_cryptodev.h | 20 +-
lib/librte_cryptodev/rte_cryptodev_pmd.h | 35 +++
lib/librte_cryptodev/rte_security.c | 171 ++++++++++++
lib/librte_cryptodev/rte_security.h | 409 ++++++++++++++++++++++++++++
11 files changed, 1243 insertions(+), 91 deletions(-)
create mode 100644 lib/librte_cryptodev/rte_security.c
create mode 100644 lib/librte_cryptodev/rte_security.h
--
2.9.3
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-08-28 14:26 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-28 14:23 [RFC PATCH v2 0/4] IPSec Inline and look aside crypto offload Narayana Prasad Athreya
2017-08-28 14:26 ` Narayana Prasad Athreya
-- strict thread matches above, loose matches on Subject: below --
2017-07-25 11:21 [RFC PATCH 0/1] " Akhil Goyal
2017-08-15 6:35 ` [RFC PATCH v2 0/4] " Akhil Goyal
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.