From mboxrd@z Thu Jan 1 00:00:00 1970 From: Akhil Goyal Subject: Re: [RFC 0/7] ipsec inline Date: Fri, 14 Jul 2017 16:42:16 +0530 Message-ID: <7834b3bd-0800-500c-1c89-3b89e2eb47fa@nxp.com> References: <1499672117-56728-1-git-send-email-borisp@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: , "Nicolau, Radu" , To: Declan Doherty , Boris Pismenny , Return-path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0045.outbound.protection.outlook.com [104.47.34.45]) by dpdk.org (Postfix) with ESMTP id BDAEE2935 for ; Fri, 14 Jul 2017 13:12:29 +0200 (CEST) In-Reply-To: Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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