[dpdk-dev] [RFC 0/7] ipsec inline
Boris Pismenny
borisp at mellanox.com
Mon Jul 10 09:35:10 CEST 2017
In this RFC we introduce a infrastructure for IPSec inline hardware offloading.
This RFC introduces device capabilities, configuration API and data path
processing. We also provide a comparison with a previous RFC posted on the list
for this feature.
1. Inline crypto processing
1.1. Device Capabilities:
o DEV_RX_OFFLOAD_IPSEC_CRYPTO - device support inline ipsec
decryption offload.
o DEV_TX_OFFLOAD_IPSEC_CRYPTO_HW_TRAILER - device support inline ipsec
encrypted offload, ipsec trailer is added by hardware.
o DEV_TX_OFFLOAD_IPSEC_CRYPTO_TSO - device support inline ipsec
encrypted offload within segment large packets, ipsec trailer is added by
hardware to each segment.
1.2. Configuration API:
We will modify steering API in order to add IPsec transform actions.
o Definition of ESP header:
struct esp_hdr {
int32_t spi; /**< Security Parameters Index */
uint32_t seq; /**< packet sequence number */
} __attribute__((__packed__));
o New flow item:
enum rte_flow_item_type {
...
/**
* Matches a ESP header.
*
* See struct rte_flow_item_esp.
*/
RTE_FLOW_ITEM_TYPE_ESP,
};
struct rte_flow_item_esp {
struct esp_hdr hdr; /**< ESP header definition. */
};
struct rte_flow_item_esp {
static const struct rte_flow_item_esp rte_flow_item_esp_mask = {
.hdr = {
.spi = 0xffffffff,
},
};
o New ipsec transform:
struct rte_crypto_ipsec_xform {
enum rte_crypto_cipher_operation op;
enum rte_crypto_cipher_algorithm algo;
struct {
uint8_t *data; /**< pointer to key data */
size_t length; /**< key length in bytes */
} key;
uint32_t salt; /* salt for this security association */
};
/** Crypto transformation types */
enum rte_crypto_sym_xform_type {
...
RTE_CRYPTO_SYM_XFORM_CIPHER, /**< Cipher xform */
RTE_CRYPTO_SYM_XFORM_IPSEC, /**< IPsec xform */
};
struct rte_crypto_sym_xform {
...
struct rte_crypto_ipsec_xform ipsec;
/**< IPsec xform */
};
o New flow action:
enum rte_flow_action_type {
...
/**
* Encrypts or decrypts packets matching this flow. Must be either egress
* or ingress, but not both.
*
* See struct rte_flow_action_crypto.
*/
RTE_FLOW_ACTION_TYPE_CRYPTO,
};
struct rte_flow_action_crypto {
struct rte_crypto_sym_xform xform; /* applied crypto transform */
};
Configuration Path
|
+--------|--------+
| Add/Remove |
| IPsec SA | <------ Build crypto flow action of ipsec transform
| | |
|--------|--------|
|
+--------V--------+
| Flow API |
+--------|--------+
|
+--------V--------+
| |
| NIC PMD | <------ Add/Remove SA to/from hw context
| |
+--------|--------+
|
+--------|--------+
| HW ACCELERATED |
| NIC |
| |
+--------|--------+
o Add/Delete SA flow:
To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP
using the SA selectors and the rte_crypto_ipsec_xform as the rte_flow_action.
Note that any rte_flow_items may be empty, which means it is not checked.
In its most basic form, IPsec flow specification is as follows:
+-------+ +----------+ +--------+ +-----+
| Eth | -> | IP4/6 | -> | ESP | -> | END |
+-------+ +----------+ +--------+ +-----+
However, the API can represent, IPsec crypto offload with any encapsulation:
+-------+ +--------+ +-----+
| Eth | -> ... -> | ESP | -> | END |
+-------+ +--------+ +-----+
1.3. Data Path Processing:
1.3.1. mbuf Changes
o New rx mbuf offload flags to indicate that a packet has gone through
inline crypto processing on to the NIC PMD and the result of this processing.
On failure, packets should be dropped.
/**
* Mask of bits used to determine the status of RX IPsec crypto.
* - PKT_RX_IPSEC_CRYPTO_UNKNOWN : no information about the RX IPsec crypto
* - PKT_RX_IPSEC_CRYPTO » : decryption and authentication were performed
* - PKT_RX_IPSEC_CRYPTO_FAILED : ipsec processing failed
*/
#define PKT_RX_IPSEC_CRYPTO_UNKNOWN 0
#define PKT_RX_IPSEC_CRYPTO (1ULL << 18)
#define PKT_RX_IPSEC_CRYPTO_FAILED (1ULL << 19)
o New tx mbuf offload flags to indicate that a packet requires IPsec inline
crypto processing and trailer construction on the NIC PMD.
/**
* Offload the IPsec encryption with software provided trailer.
* This flag must be set by the application to enable this
* offload feature for a packet to be transmitted.
*/
#define PKT_TX_IPSEC_CRYPTO (1ULL << 42)
/**
* Offload the IPsec encryption and trailer construction. This flag must
* be set by the application to enable this offload feature for a packet
* to be transmitted.
*/
#define PKT_TX_IPSEC_CRYPTO_HW_TRAILER (1ULL << 43)
Egress Data Path
|
+--------|--------+
| egress IPsec |
| | |
| +------V------+ |
| | SABD lookup | |
| +------|------+ |
| +------V------+ |
| | Tunnel | | <------ Add tunnel header to packet
| +------|------+ |
| +------V------+ |
| | ESP | | <------ Add ESP header without trailer to packet
| | | | <------ Mark packet to be offloaded, add trailer meta-data
| +------|------+ | to mbuf
+--------V--------+
|
+--------V--------+
| L2 Stack |
+--------|--------+
|
+--------V--------+
| |
| NIC PMD | <------ Set hw context for inline crypto offload
| |
+--------|--------+
|
+--------|--------+
| HW ACCELERATED | <------ Packet Encryption/Decryption and
| NIC | Authentication happens inline
| |
+--------|--------+
2. IPsec Gateway Sample Application
2.1. Add/Delete SA
SAs are configured as previously via the configuration file, the user could
specify which SAs require inline offload by adding "offload" for that SA.
We then store for each SA whether it is offloaded in the ipsec_sa structure.
Additionally, we extended the ipsec_sa structure with additional fields
related to rte_flow, which are initialized if offload is requested.
struct ipsec_sa {
...
#define MAX_RTE_FLOW_PATTERN (4)
// ETH + IP + ESP + END
union {
struct rte_flow_item_ipv4 ipv4;
struct rte_flow_item_ipv6 ipv6;
} ip_spec;
struct rte_flow_item_esp esp_spec;
struct rte_flow_item pattern[MAX_RTE_FLOW_PATTERN];
#define MAX_RTE_FLOW_ACTIONS (3)
struct rte_flow_action_crypto crypto_action;
struct rte_flow_action action[MAX_RTE_FLOW_ACTIONS];
struct rte_flow *flow;
...
int offload;
#define OFFLOAD_ENABLED 1
#define OFFLOAD_DISABLED 0
...
};
When a user attempts to crete a session it checks whether inline offload is
needed. If yes, then rte_flow_create is called with the parameters
initialized above. In any case, create_session_cryptodev is called. The
cryptodev session is used to handle software fallback for packets that are
not processed by hardware.
3. Comparison with previous RFC
In the section we compare the previous RFC
(http://dpdk.org/ml/archives/dev/2017-May/065513.html)
with this RFC.
The main difference is in NIC capabilities. Mellanox hardware
is capable of applying IPsec inline based on packet pattern, while
intel use mbuf metadata. This API allows application to save cycles
by not storing metadata on each packet mbuf, but instead store metadata
once per flow.
Another difference is the use of Crypto PMD for inline IPsec vs.
NIC PMD. Using the NIC PMD has several advantages. First, configuration
is simpler - crypto is performed by the same device to which packets
are routed, and there is no chance for configuring a crypto context on
one device and routing packets to another device and transmitting
plaintext as a result. Second, Crypto PMD semantics imply that data has
been processed after dequeue. This is not true for inline IPsec, where
data is processed only when it goes through the NIC. Finally, using the
NIC PMD directly has better performance, because the Crypto PMD code is
not involved.
Aviad Yehezkel (2):
mbuf: Added next_esp_proto field
example/ipsec_gw: Support SA offload in datapath
Boris Pismenny (5):
ethdev: add device ipsec encrypt/decrypt capability flags
ethdev: Add ESP header to generic flow steering
ethdev: add rte flow action for crypto
cryptodev: add ipsec xform
mbuf: Add IPsec crypto flags
examples/ipsec-secgw/esp.c | 68 ++++++++++++----
examples/ipsec-secgw/esp.h | 13 +---
examples/ipsec-secgw/ipsec.c | 142 +++++++++++++++++++++++++++++-----
examples/ipsec-secgw/ipsec.h | 30 +++++++
examples/ipsec-secgw/sa.c | 120 ++++++++++++++++++++++++----
lib/Makefile | 1 +
lib/librte_cryptodev/rte_crypto_sym.h | 42 +++++++++-
lib/librte_ether/rte_ethdev.h | 4 +
lib/librte_ether/rte_flow.h | 50 ++++++++++++
lib/librte_mbuf/rte_mbuf.c | 16 ++++
lib/librte_mbuf/rte_mbuf.h | 38 ++++++++-
lib/librte_net/Makefile | 2 +-
12 files changed, 466 insertions(+), 60 deletions(-)
--
1.8.3.1
More information about the dev
mailing list