Hi Declan/Boris,
On 7/11/2017 10:36 PM, Declan Doherty wrote:
On 10/07/2017 8:35 AM, Boris Pismenny wrote:
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.
Hey Boris, we've been working on v2 of the RFC based on the feedback you
and others gave on our original , but as what we were going to propose
is largely inline with your proposal here, with one or 2 exceptions,
mainly on the IPsec SA management elements, I'll just comment here
instead of sending another RFC.
We agree the rte_flow based approach as proposed here is the more
flexible approach and should work better with futures devices which
could offer support for other protocols as well as full protocol offload.
The main difference to your proposal below and what we are considering
is that we would like to introduce the idea of a port based rte_security
API which would support a generic API for security protocol
configuration, I can see MACsec, IPsec, DTLS all working easily under
this approach.
struct rte_security_session *
rte_security_session_create(uint8_t port_id,
struct rte_security_sess_conf *sess_conf);
Is this a proposal to add another library to add APIs and structures
rte_security_XXX.
If not, is it not worth to add a generic security library which can be
used both by ethdev and cryptodev. We may have crypto devices(dpaa2_sec)
which can also support look-aside protocol offload.
rte_security_session_create(), may take a dev_id and device type as
input and call respective device's security session create.
The session create function will return a opaque security session which
would be used in the security flow action programming. The session
configuration will contain the security protocol specific information,
in IPsec case the SA parameter as well as the crypto xforms.
/** IPsec Security Session Configuration */
struct rte_security_conf_ipsec_sa {
unsigned int spi;
/**< SA security parameter index */
enum rte_security_conf_ipsec_sa_dir {
RTE_SECURITY_IPSEC_SA_DIR_INGRESS,
RTE_SECURITY_IPSEC_SA_DIR_EGRESS
} direction;
/**< IPsec SA direction - ingress / egress */
enum rte_security_conf_ipsec_sa_mode {
RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT,
RTE_SECURITY_IPSEC_SA_MODE_TUNNEL
} mode;
/**< IPsec SA Mode - transport/tunnel */
enum rte_security_conf_ipsec_sa_protocol {
RTE_SECURITY_IPSEC_SA_PROTO_AH,
RTE_SECURITY_IPSEC_SA_PROTO_ESP
} proto;
/**< IPsec SA Protocol - AH/ESP */
struct ipaddr src_ip; /**< Source IP */
struct ipaddr dst_ip; /**< Destination IP */
};
/**
* Security Session Configuration
*/
struct rte_security_sess_conf {
enum {
RTE_SECURITY_SESS_INLINE_CRYPTO,
RTE_SECURITY_SESS_FULL_PROTO_OFFLOAD
} action_type;
enum rte_security_sess_conf_type {
SEC_CONF_DTLS,
SEC_CONF_IPSEC,
SEC_CONF_MACSEC
} type;
/**< Type of security session to be configured */
struct {
struct rte_security_conf_dtls dtls;
struct rte_security_conf_ipsec_sa ipsec_sa;
struct rte_security_conf_macsec macsec;
};
/* Configuration parameters for security session */
struct rte_crypto_sym_xform *xform;
/**< Symmetric Crypto Transform Chain */
};
The APIs would be introduced in the same manner as the flow and traffic
management API as a plug-able component into a ethdev, and would provide
the abstraction to configure security protocols state (IPsec SA, DTLS
record etc.) and then the flow action would be a security flow action
instead of the crypto flow action as proposed below.
This gives a flexible approach to future extension to other protocols
and modes (crypto vs full offload) and also addresses an issue raised on
the our previous RFC regarding polluting the crypto namespace with
security protocol specific information. One other issue with putting the
protocol information into a crypto transform is that we won't have any
crypto devices which support them.
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 */
};
Authentication algos and key missing.
-Akhil
