RFC - IPsec Sample App
We are looking for feedback on the proposal to create a new sample application to showcase the new cryptodev library (1) for acceleration in both SW and HW of crypto processing with a real world example of an IPsec implementation on DPDK.
In the proposed implementation the core IPsec logic will be based on a port of NetBSD IPsec kernel module, and will support the ESP protocol and IPv4 tunneling only using statically defined key material (no external IKE client support).
* Application Design
The sample application will be based on a simple l2fwd application with packets being statically forwarded between defined ports. The IPsec processing of IP packets will occur on the ethdev callbacks.
The library will have two processing paths, an ingress(inbound) and egress(outbound) traffic path, which will handle bursts of packets and return bursts of processed packets in an asynchronous fashion.
We envisage the APIs for processing bursts looking like the following:
int rte_ipsec_ingress_process_burst(struct rte_ipsec_instance *instance,
struct rte_mbuf **pkts, int nb_pkts, int max_pkts);
int rte_ipsec_egress_process_burst(struct rte_ipsec_instance *instance,
struct rte_mbuf **pkts, int nb_pkts, int max_pkts);
One or more cryptodevs must be bound to an IPsec instance. If more than one cryptodev is bound to an instance then traffic balancing will be implemented with the caveat that all packets from a flow will always be process on the same cryptodev. It will also be possible to specify that a flow should be processed on a specified device.
A set of generic APIs for the configuration of IPsec security policies and associations will be provided, which will be independent of the underlying BSD database implementation.
* NOTE
This sample app has a dependency on the new DPDK crypto API (1).
2015-09-16 09:29, Gonzalez Monroy, Sergio:
Quoted 2 lines
We are looking for feedback on the proposal to create a new sample application
[...]
Quoted 2 lines
A set of generic APIs for the configuration of IPsec security policies and associations will be provided, which will be independent of the
How can you have some API in a sample application?
It looks like an IPsec library, not an application.
Are we going to add a library for each protocol in DPDK like it is done in the Linux kernel stack (including OVS)? Probably no.
Quoted 8 lines · Thomas Monjalon
2015-09-16 09:29, Gonzalez Monroy, Sergio:
Quoted 2 lines
We are looking for feedback on the proposal to create a new sample application
[...]
Quoted 2 lines
A set of generic APIs for the configuration of IPsec security policies and associations will be provided, which will be independent of the
How can you have some API in a sample application? It looks like an IPsec library, not an application.
The intention of those APIs was just to provide flexibility to the users and allow them to easily setup different Security Policies (SP) and Security Associations (SA) for testing of different environments if they are looking to base something off this example app.
Quoted 2 lines
Are we going to add a library for each protocol in DPDK like it is done in the Linux kernel stack (including OVS)? Probably no.
You are probably right in that sense and we probably shouldn't have a sample app for every protocol, but we feel that to really put the new cryptodev API under test we need a good example, and showing how the cryptodev API could be use to do IPsec would certainly fill the bill. A more trivial application would not necessarily reveal any gaps in the API that would prevent cryptodev being used for an IPSec implementation. By creating a sample app incorporating much of an IPsec implementation, we get greater confidence in the usefulness of our APIs
- and the performance of the cryptodev - in a realistic setting, while also providing sample code that may well be of use to a wider audience.
Sergio
I am looking for making some app on IpSec VPN , the below thread has thrown some light on the North bound interface on CLI , do we have any such existing implantations in place so that we can take ref from that and take it forward , Thanks for your support
Best Regards
Gunaseelan V
91 98408 60856
-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Gonzalez Monroy, Sergio
Sent: Wednesday, September 16, 2015 10:15 PM
To: Thomas Monjalon; [email protected]
Subject: Re: [dpdk-dev] RFC - IPsec Sample App
Quoted 9 lines · Thomas Monjalon
2015-09-16 09:29, Gonzalez Monroy, Sergio:
Quoted 2 lines
We are looking for feedback on the proposal to create a new sample application
[...]
Quoted 3 lines
A set of generic APIs for the configuration of IPsec security policies and associations will be provided, which will be independent of the
How can you have some API in a sample application? It looks like an IPsec library, not an application.
The intention of those APIs was just to provide flexibility to the users and allow them to easily setup different Security Policies (SP) and Security Associations (SA) for testing of different environments if they are looking to base something off this example app.
Quoted 2 lines
Are we going to add a library for each protocol in DPDK like it is done in the Linux kernel stack (including OVS)? Probably no.
You are probably right in that sense and we probably shouldn't have a sample app for every protocol, but we feel that to really put the new cryptodev API under test we need a good example, and showing how the cryptodev API could be use to do IPsec would certainly fill the bill. A more trivial application would not necessarily reveal any gaps in the API that would prevent cryptodev being used for an IPSec implementation. By creating a sample app incorporating much of an IPsec implementation, we get greater confidence in the usefulness of our APIs
- and the performance of the cryptodev - in a realistic setting, while also providing sample code that may well be of use to a wider audience.
Sergio
::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
----------------------------------------------------------------------------------------------------------------------------------------------------