From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 2E54D1B502 for ; Tue, 9 Oct 2018 20:23:57 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2018 11:23:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,361,1534834800"; d="scan'208";a="77469414" Received: from sivswdev02.ir.intel.com (HELO localhost.localdomain) ([10.237.217.46]) by fmsmga008.fm.intel.com with ESMTP; 09 Oct 2018 11:23:50 -0700 From: Konstantin Ananyev To: dev@dpdk.org Cc: Konstantin Ananyev Date: Tue, 9 Oct 2018 19:23:31 +0100 Message-Id: <1539109420-13412-1-git-send-email-konstantin.ananyev@intel.com> X-Mailer: git-send-email 1.7.0.7 In-Reply-To: <1535129598-27301-1-git-send-email-konstantin.ananyev@intel.com> References: <1535129598-27301-1-git-send-email-konstantin.ananyev@intel.com> Subject: [dpdk-dev] [RFC v2 0/9] ipsec: new library for IPsec data-path processing X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 18:23:57 -0000 This RFC targets 19.02 release. This RFC introduces a new library within DPDK: librte_ipsec. The aim is to provide DPDK native high performance library for IPsec data-path processing. The library is supposed to utilize existing DPDK crypto-dev and security API to provide application with transparent IPsec processing API. The library is concentrated on data-path protocols processing (ESP and AH), IKE protocol(s) implementation is out of scope for that library. Though hook/callback mechanisms might be defined in future to allow integrate it with existing IKE implementations. Due to quite complex nature of IPsec protocol suite and variety of user requirements and usage scenarios a few API levels will be provided: 1) Security Association (SA-level) API Operates at SA level, provides functions to: - initialize/teardown SA object - process inbound/outbound ESP/AH packets associated with the given SA (decrypt/encrypt, authenticate, check integrity, add/remove ESP/AH related headers and data, etc.). 2) Security Association Database (SAD) API API to create/manage/destroy IPsec SAD. While DPDK IPsec library plans to have its own implementation, the intention is to keep it as independent from the other parts of IPsec library as possible. That is supposed to give users the ability to provide their own implementation of the SAD compatible with the other parts of the IPsec library. 3) IPsec Context (CTX) API This is supposed to be a high-level API, where each IPsec CTX is an abstraction of 'independent copy of the IPsec stack'. CTX owns set of SAs, SADs and assigned to it crypto-dev queues, etc. and provides: - de-multiplexing stream of inbound packets to particular SAs and further IPsec related processing. - IPsec related processing for the outbound packets. - SA add/delete/update functionality Current RFC concentrates on SA-level API only (1), detailed discussion for 2) and 3) will be subjects for separate RFC(s). SA (low) level API ================== API described below operates on SA level. It provides functionality that allows user for given SA to process inbound and outbound IPsec packets. To be more specific: - for inbound ESP/AH packets perform decryption, authentication, integrity checking, remove ESP/AH related headers - for outbound packets perform payload encryption, attach ICV, update/add IP headers, add ESP/AH headers/trailers, setup related mbuf felids (ol_flags, tx_offloads, etc.). - initialize/un-initialize given SA based on user provided parameters. The following functionality: - match inbound/outbound packets to particular SA - manage crypto/security devices - provide SAD/SPD related functionality - determine what crypto/security device has to be used for given packet(s) is out of scope for SA-level API. SA-level API is based on top of crypto-dev/security API and relies on them to perform actual cipher and integrity checking. To have an ability to easily map crypto/security sessions into related IPSec SA opaque userdata field was added into rte_cryptodev_sym_session and rte_security_session structures. That implies ABI change for both librte_crytpodev and librte_security. Due to the nature of crypto-dev API (enqueue/deque model) we use asynchronous API for IPsec packets destined to be processed by crypto-device. Expected API call sequence would be: /* enqueue for processing by crypto-device */ rte_ipsec_crypto_prepare(...); rte_cryptodev_enqueue_burst(...); /* dequeue from crypto-device and do final processing (if any) */ rte_cryptodev_dequeue_burst(...); rte_ipsec_crypto_group(...); /* optional */ rte_ipsec_process(...); Though for packets destined for inline processing no extra overhead is required and synchronous API call: rte_ipsec_process() is sufficient for that case. Current implementation supports all four currently defined rte_security types. Though to accommodate future custom implementations function pointers model is used for both rte_ipsec_crypto_prepare() and rte_ipsec_process(). Implemented: ------------ - ESP tunnel mode support (both IPv4/IPv6) - Supported algorithms: AES-CBC, AES-GCM, HMAC-SHA1, NULL - Anti-Replay window and ESN support - Unit Test (few basic cases for now) TODO list: ---------- - ESP transport mode support (both IPv4/IPv6) - update examples/ipsec-secgw to use librte_ipsec - extend Unit Test Konstantin Ananyev (9): cryptodev: add opaque userdata pointer into crypto sym session security: add opaque userdata pointer into security session net: add ESP trailer structure definition lib: introduce ipsec library ipsec: add SA data-path API ipsec: implement SA data-path API ipsec: rework SA replay window/SQN for MT environment ipsec: helper functions to group completed crypto-ops test/ipsec: introduce functional test config/common_base | 5 + lib/Makefile | 2 + lib/librte_cryptodev/rte_cryptodev.h | 2 + lib/librte_ipsec/Makefile | 27 + lib/librte_ipsec/crypto.h | 74 ++ lib/librte_ipsec/ipsec_sqn.h | 315 ++++++++ lib/librte_ipsec/meson.build | 10 + lib/librte_ipsec/pad.h | 45 ++ lib/librte_ipsec/rte_ipsec.h | 156 ++++ lib/librte_ipsec/rte_ipsec_group.h | 151 ++++ lib/librte_ipsec/rte_ipsec_sa.h | 166 ++++ lib/librte_ipsec/rte_ipsec_version.map | 15 + lib/librte_ipsec/rwl.h | 68 ++ lib/librte_ipsec/sa.c | 1005 ++++++++++++++++++++++++ lib/librte_ipsec/sa.h | 92 +++ lib/librte_ipsec/ses.c | 45 ++ lib/librte_net/rte_esp.h | 10 +- lib/librte_security/rte_security.h | 2 + lib/meson.build | 2 + mk/rte.app.mk | 2 + test/test/Makefile | 3 + test/test/meson.build | 3 + test/test/test_ipsec.c | 1329 ++++++++++++++++++++++++++++++++ 23 files changed, 3528 insertions(+), 1 deletion(-) create mode 100644 lib/librte_ipsec/Makefile create mode 100644 lib/librte_ipsec/crypto.h create mode 100644 lib/librte_ipsec/ipsec_sqn.h create mode 100644 lib/librte_ipsec/meson.build create mode 100644 lib/librte_ipsec/pad.h create mode 100644 lib/librte_ipsec/rte_ipsec.h create mode 100644 lib/librte_ipsec/rte_ipsec_group.h create mode 100644 lib/librte_ipsec/rte_ipsec_sa.h create mode 100644 lib/librte_ipsec/rte_ipsec_version.map create mode 100644 lib/librte_ipsec/rwl.h create mode 100644 lib/librte_ipsec/sa.c create mode 100644 lib/librte_ipsec/sa.h create mode 100644 lib/librte_ipsec/ses.c create mode 100644 test/test/test_ipsec.c -- 2.13.6