Re: [dpdk-dev] [RFC 0/7] ipsec inline

[Akhil Goyal <akhil.goyal@nxp.com>]

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