From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8CA01425EC; Wed, 20 Sep 2023 11:23:20 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7728540EE1; Wed, 20 Sep 2023 11:23:20 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id E925F4027B for ; Wed, 20 Sep 2023 11:23:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695201799; x=1726737799; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3v8pCOn40bAyuJtGGRjb4iVelFM2QHmkam8GrePWGRw=; b=B2ubWC4rV/X4QTu1ZlPvtYr8jHOCO5Db1+R6Kt9ASmDmc6n8aU2dl+JT E/Ry7AlhdxxT3hXEWr1gx1Iw+M1SnJ7UBLlL1Zd7nt0sGIDjCeVE/ZnS+ EdSvn5cjLktGYk2vaVOZjaesx55DuOz3TwelrvnlhYIHYjE/Yv0RuBY0W 8OGHhjX8JJbSVAqrkPDXGCH320GobUqaHoxy7LmWFrcmi5muAYAfhWxut UyWvnklVvs7qPiQpzNBLqqTVmudhlHvoX5e5DadytdumV+76QOeV6jBxa oPfjHofeqraZgup7wIatanTGQK7QDRDVJm0Tv0ZtlEelxu1/kJsxkd/O1 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10838"; a="444267528" X-IronPort-AV: E=Sophos;i="6.02,161,1688454000"; d="scan'208";a="444267528" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Sep 2023 02:23:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10838"; a="870292282" X-IronPort-AV: E=Sophos;i="6.02,161,1688454000"; d="scan'208";a="870292282" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by orsmga004.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 20 Sep 2023 02:23:17 -0700 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Wed, 20 Sep 2023 02:23:17 -0700 Received: from orsmsx602.amr.corp.intel.com (10.22.229.15) by ORSMSX612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Wed, 20 Sep 2023 02:23:17 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32 via Frontend Transport; Wed, 20 Sep 2023 02:23:17 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.102) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.32; Wed, 20 Sep 2023 02:23:16 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TDg44xj6uwjSBe45Z9NAdDYcSIS68X7HSJLnMy1t7PfqiQaN1w1TKqUTjp9SaAn0lwAzGL9ZBWA319CMejUWExVXzayC+t1S4aKflWxBomXNKU4X7x9g+J2GGEnOtZCvr6Bg4ilmhDzNLy1g0KOmPN3vURiqu6X6WkICSCdDOpVt7LMRFa66TDCQGoAWzB6+8mAPKp4C6yXHYAB5ot1nogOcAMdt/0DkeYb1KNRucP0y4Kbdg/NUWTe99vatU5jYGo08z6jIaSrmmBYl9Qcrx2fiJMPHwqwyMxLlFc/J1sepy70tjls5wgPoPr3WYNPqzYqY2UKkbhHtmQLoSIYGrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ksgE5c8h7oew1qHLryut1VqpAPel+1eTJrgC4Qn43QE=; b=cg752nR9QTuXrujvHgJxHvv+PxgsWHCqQaI4gB4fnToDUk0EaNfbUfoUpXrh7oMdGPZW4b6imvvKQM8RskU60gxRtainlCuTlbJElezKVnyzm7v94CLpruUaoyFCA9H6ZlD9mFZy43vJkyNeCO4H5BrjKwiJMay9szEJgcnJZkDRqTfblxFL3E4IKFGCP6Ss9I/vJ8q5hadgjftpkFi8qSceIUKUtzri+6OPFLTWfRts/i/J09AnaWeLYraQe8VS8wPLeUyY33voaKkOQeoTNE7EwXGZFpYAwP+oXhdhUhbxReraMn0iXYjO3UVB3wKkX92Z+Ep92PK9YGdY2Hh7lw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from PH8PR11MB6803.namprd11.prod.outlook.com (2603:10b6:510:1cb::12) by SA3PR11MB7582.namprd11.prod.outlook.com (2603:10b6:806:31e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.20; Wed, 20 Sep 2023 09:23:06 +0000 Received: from PH8PR11MB6803.namprd11.prod.outlook.com ([fe80::7602:b1b7:3114:c3da]) by PH8PR11MB6803.namprd11.prod.outlook.com ([fe80::7602:b1b7:3114:c3da%3]) with mapi id 15.20.6768.029; Wed, 20 Sep 2023 09:23:06 +0000 From: "Van Haaren, Harry" To: Anoob Joseph , Thomas Monjalon , Akhil Goyal , Jerin Jacob , Konstantin Ananyev CC: Hemant Agrawal , "dev@dpdk.org" , "Matz, Olivier" , Vidya Sagar Velumuri Subject: RE: [RFC PATCH 2/3] security: add TLS record processing Thread-Topic: [RFC PATCH 2/3] security: add TLS record processing Thread-Index: AQHZzCQAUWE2ZXoed0OthIBi/WtY87AjqZwg Date: Wed, 20 Sep 2023 09:23:06 +0000 Message-ID: References: <20230811071712.240-1-anoobj@marvell.com> <20230811071712.240-3-anoobj@marvell.com> In-Reply-To: <20230811071712.240-3-anoobj@marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH8PR11MB6803:EE_|SA3PR11MB7582:EE_ x-ms-office365-filtering-correlation-id: 531ee5f2-6c94-4468-389c-08dbb9bb32e5 x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lZepnsty3boqSCi4t3dZyMczV+CmJfMlR/poZWfQyfDLpGjqG4GdjUJJvqD4RLMzHYvsp3K3b1LwL2E/xPem0sbOQYktkSIT69VbKtnhoTsjiqwVFDqzhq6dNrlLi3Dt4LXvkIT81bnHJiOQvvnKYRnU0Q9KukkBFG6l0kf1yQg9a8QhLlPJZBXB0x1t+8HOPluLGLdn5gaBw1eBvYj0+aE4sGA/lF8oO8XTFUUM4MzDdDzg6BHRU+VJjYFV5RjD6zGtOg10laPfKJokgMz4rBRoU9X2+W/W3xPM79N7389aPjuhmobBlLNSyMfIjZZJsoxG9eMeAHyM8/pTyS8vZ+mw0gfQBEDh+IuiWTBybUnCveCYQ6tlrkjrIjGijPCPs2Y3veEKkigqhoeVUySFXoOq27WvqdvyVG8bVe0psr9vtjfdDT4fGwLO4yAVoeImRyUK/ryLqe5oQzJUqVech1iMyeXoHAv9L8CpblaMfm8IJdTeE0DadAPnPJfmRDcbxSgQ2sUNKT2u+O1IWYe4SGdWl8pFEXGKa2VXw5rQyy7n4tnIJRWaNyIzf3/lrFnIjcP/+MToR8N7WLSaWhnq41Ue+sMBBisGBrvcawUe/JdEPbP2a4S08r9NCJXyhSgA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH8PR11MB6803.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(39860400002)(376002)(396003)(366004)(136003)(346002)(186009)(451199024)(1800799009)(316002)(66899024)(2906002)(86362001)(26005)(66574015)(9686003)(6506007)(7696005)(33656002)(71200400001)(478600001)(83380400001)(82960400001)(38100700002)(55016003)(122000001)(38070700005)(41300700001)(53546011)(52536014)(8676002)(4326008)(8936002)(64756008)(66476007)(66446008)(66946007)(76116006)(66556008)(15650500001)(54906003)(30864003)(5660300002)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?d07WeYyNfm4rjZTu2h6HwcfWuAVAuvaHoH4eXcAun5JZvAbmdPtcYC3cEvcs?= =?us-ascii?Q?KNDgiJ6MCDcazsGI4o55JHdKtR0dCbVLsisiNhG9nWbAyf0iDvLQMMWvH44z?= =?us-ascii?Q?9sGqTxGTCS+ePoJt9OoqL3BhYGNbG5Nu3TsHvP61fTpvKSULXlbqmjHuEtFi?= =?us-ascii?Q?BTYoI7jCsAreISHxvQdcNV56/8wm52sYeKYSA5bCaepgo/AfVYWTBbnIiBIM?= =?us-ascii?Q?awfcifGgp32jUjGthxt3VJjChab40mwziSBNmdpSICMbXxt4nCRAm/blg+0a?= =?us-ascii?Q?grtSUn9YxvI90TRiKfBPGfT3PxeQxMVoXUiA37hKT1/ANDY+44bkAiIOilrK?= =?us-ascii?Q?c3YMTNgLRbciIuQyun/aP2BQi3GDUsraZgVXJhdl6z56CNDWbg731OIMz7cL?= =?us-ascii?Q?h6MezmFIW18g1hHlbi7yIXK49ofgFhHoOpYw/YevF30qPaVyWajvoeOZETTM?= =?us-ascii?Q?sJXQO4OBGmbKtsOienRfJgh7Juw6RqPAgV51I2a3lOnbg3cZ9/KKH53D6v3i?= =?us-ascii?Q?kOc6USIS1gE8OtG4f3xqGY+RYGjl1EL5upQylpL5PYwr8xhAySy3JifF86Rz?= =?us-ascii?Q?fSxozLVWzo+aCawld/sX9gDXypQeC0vzs4mzwjR7Zt62SdJKYAALlW5jQzKT?= =?us-ascii?Q?zMsC+yrRGFOY/B2gn7ekJpV36Kg7yUoCatW04Pq3SUc6ReRRhyHVhLtp720p?= =?us-ascii?Q?0Ms0/CqsT2OyLzN3DYjiTX9vehdTWEh5zNui3mn1vkz4CX9pm3YgVui/S3PJ?= =?us-ascii?Q?J2TFDvt09kQFMIdTchJqwsWbbpPhK5HQmh21m4mMtfvI1vG5xiGzJympNI3W?= =?us-ascii?Q?1mCSw2cvTSIaV6SmT9Z7sc+CDb2OUDAOFBSN3gOzCDJTKFLL39JDxJokDQC5?= =?us-ascii?Q?qSn1m1YNuVce/F8gEUxx0Cr6BFKTZgO/PAdTs0018CsgsoUzK+qdMyurzxEE?= =?us-ascii?Q?DIS7tY7h+NfdhhzsoVrvnrsQLVS12burk9mIEVMelBWpWjsrC3HpyU0KGgCP?= =?us-ascii?Q?vag2PTF8gjqYFLcVIYrV3AnEUcV5zEzZmE1f2t705+6e5rv04N9xfC0lG5Ds?= =?us-ascii?Q?oTDWH0MkXov4mW0drEGSlo0RcnYsl03p/WuvB00WOREkwPHGVz0WulkM5Pzz?= =?us-ascii?Q?TGfUOPPb68fE3QbaKVTvzZxZrjS1ZIG5QEFwHOI0v9mpL3kY2KqX5exo8QMT?= =?us-ascii?Q?j0rRhpUOywR7niNWJFPmnwIV6Qo6aTNde2sO6LthUWiTtWHK0wIpJAPxXQIK?= =?us-ascii?Q?IGO2zTAA7wfhha42k7bNsYsxzdEo1tj4M75aXmASa0kr7N32jWbjXXpiT28l?= =?us-ascii?Q?b5QTzY597ncTqYYdet8bpV2/Wr4+LEMChLSdX/vPMOfkGfMsRafmPGiI9UyX?= =?us-ascii?Q?SDc/pNgmuCSTMIGYH3yy8wTFmSJGnh85S2HtBphSUk7GUl9x3UJEpO9VuEds?= =?us-ascii?Q?rCyCCLnDGaBDrz3iBgSVzftEliM+zujCPwj7DpZjU8fzYqzVp50gwJ1Gndk4?= =?us-ascii?Q?p+8Jl0c10pxChKvOmj2on3DBTG2yXdRwgSRq6J2RVi08sO+3t8/+MMSYIAzF?= =?us-ascii?Q?oIlIOujMnVJRKqYBEW5l9M/vkMuDfDekxe3s6zGE?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB6803.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 531ee5f2-6c94-4468-389c-08dbb9bb32e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2023 09:23:06.6810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KYfqg0LAT3Bd8Nisjhar/wlyKO4OUfyB7TxoGe59ntZWS78TZPdAAUI5bsuTdMZvldY2f6kD10zEci18xRIfYnw2Lo8605DW8DGC6BiD3gA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR11MB7582 X-OriginatorOrg: intel.com X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > -----Original Message----- > From: Anoob Joseph > Sent: Friday, August 11, 2023 8:17 AM > To: Thomas Monjalon ; Akhil Goyal > ; Jerin Jacob ; Konstantin Ananye= v > > Cc: Hemant Agrawal ; dev@dpdk.org; Matz, > Olivier ; Vidya Sagar Velumuri > > Subject: [RFC PATCH 2/3] security: add TLS record processing >=20 > Add Transport Layer Security (TLS) and Datagram Transport Layer Security > (DTLS). The protocols provide communications privacy for L4 protocols > such as TCP & UDP. >=20 > TLS (and DTLS) protocol is composed of two layers, > 1. TLS Record Protocol > 2. TLS Handshake Protocol >=20 > While TLS Handshake Protocol helps in establishing security parameters > by which client and server can communicate, TLS Record Protocol provides > the connection security. TLS Record Protocol leverages symmetric > cryptographic operations such as data encryption and authentication for > providing security to the communications. >=20 > Cryptodevs that are capable of offloading TLS Record Protocol may > perform other operations like IV generation, header insertion, atomic > sequence number updates and anti-replay window check in addition to > cryptographic transformations. >=20 > The support is added for TLS 1.2, TLS 1.3 and DTLS 1.2. >From the code below, my understanding is that *ONLY* the record layer is be= ing added/supported? The difference is described well above, but the intended support added is not clearly defined. Suggest reword the last line to clarify: "Support for TLS record protocol is added for TLS 1.2, TLS 1.3 and DTLS 1.2= ." =20 > Signed-off-by: Akhil Goyal > Signed-off-by: Anoob Joseph > Signed-off-by: Vidya Sagar Velumuri > --- > doc/guides/prog_guide/rte_security.rst | 58 +++++++++++++ > lib/security/rte_security.c | 4 + > lib/security/rte_security.h | 110 +++++++++++++++++++++++++ > 3 files changed, 172 insertions(+) >=20 > diff --git a/doc/guides/prog_guide/rte_security.rst > b/doc/guides/prog_guide/rte_security.rst > index 7418e35c1b..7716d7239f 100644 > --- a/doc/guides/prog_guide/rte_security.rst > +++ b/doc/guides/prog_guide/rte_security.rst > @@ -399,6 +399,64 @@ The API ``rte_security_macsec_sc_create`` returns a > handle for SC, > and this handle is set in ``rte_security_macsec_xform`` > to create a MACsec session using ``rte_security_session_create``. >=20 > +TLS-Record Protocol > +~~~~~~~~~~~~~~~~~~~ > + > +The Transport Layer Protocol provides communications security over the > Internet. The protocol > +allows client/server applications to communicate in a way that is design= ed to > prevent eavesdropping, > +tampering, or message forgery. > + > +TLS protocol is composed of two layers: the TLS Record Protocol and the = TLS > Handshake Protocol. At > +the lowest level, layered on top of some reliable transport protocol (e.= g., TCP), > is the TLS Record > +Protocol. The TLS Record Protocol provides connection security that has = two > basic properties: > + > + - The connection is private. Symmetric cryptography is used for dat= a > + encryption (e.g., AES, DES, etc.). The keys for this symmetric en= cryption > + are generated uniquely for each connection and are based on a secr= et > + negotiated by another protocol (such as the TLS Handshake Protocol= ). The > + Record Protocol can also be used without encryption. > + > + - The connection is reliable. Message transport includes a message > + integrity check using a keyed MAC. Secure hash functions (e.g., > + SHA-1, etc.) are used for MAC computations. The Record Protocol > + can operate without a MAC, but is generally only used in this mode > + while another protocol is using the Record Protocol as a transport > + for negotiating security parameters. > + > +.. code-block:: c The code block below isn't C? Is there a better code block type for a text = diagram? > + Record Write Record Read > + ------------ ----------- > + > + TLSPlaintext TLSCiphertext > + | | > + ~ ~ > + | | > + V V > + +---------|----------+ +----------|---------+ > + | Seq. no generation | | Seq. no generation | > + +---------|----------+ +----------|---------+ > + | | > + +---------|----------+ +----------|---------+ > + | Header insertion | | Decryption & | > + +---------|----------+ | MAC verification | > + | +----------|---------+ > + +---------|----------+ | > + | MAC generation & | +----------|---------+ > + | Encryption | | TLS Header removal | > + +---------|----------+ +----------|---------+ > + | | > + ~ ~ > + | | > + V V > + TLSCiphertext TLSPlaintext > + > +Supported Versions > +^^^^^^^^^^^^^^^^^^ > + > +* TLS 1.2 > +* TLS 1.3 > +* DTLS 1.2 >=20 > Device Features and Capabilities > --------------------------------- > diff --git a/lib/security/rte_security.c b/lib/security/rte_security.c > index c4d64bb8e9..bd7b026547 100644 > --- a/lib/security/rte_security.c > +++ b/lib/security/rte_security.c > @@ -282,6 +282,10 @@ rte_security_capability_get(struct rte_security_ctx > *instance, > if (capability->docsis.direction =3D=3D > idx->docsis.direction) > return capability; > + } else if (idx->protocol =3D=3D > RTE_SECURITY_PROTOCOL_TLS_RECORD) { > + if (capability->tls_record.ver =3D=3D idx- > >tls_record.ver && > + capability->tls_record.type =3D=3D idx- > >tls_record.type) > + return capability; > } > } > } > diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h > index 3b2df526ba..b9d064ed84 100644 > --- a/lib/security/rte_security.h > +++ b/lib/security/rte_security.h > @@ -620,6 +620,99 @@ struct rte_security_docsis_xform { > /**< DOCSIS direction */ > }; >=20 > +/** Salt len to be used with AEAD algos in TLS 1.2 */ > +#define RTE_SECURITY_TLS_1_2_SALT_LEN 4 > +/** Salt len to be used with AEAD algos in TLS 1.3 */ > +#define RTE_SECURITY_TLS_1_3_SALT_LEN 12 > +/** Salt len to be used with AEAD algos in DTLS 1.2 */ > +#define RTE_SECURITY_DTLS_1_2_SALT_LEN 4 > + > +/** TLS version */ > +enum rte_security_tls_version { > + RTE_SECURITY_VERSION_TLS_1_2, /**< TLS 1.2 */ > + RTE_SECURITY_VERSION_TLS_1_3, /**< TLS 1.3 */ > + RTE_SECURITY_VERSION_DTLS_1_2, /**< DTLS 1.2 */ > +}; > + > +/** TLS session type */ > +enum rte_security_tls_sess_type { > + /** Record read session > + * - Decrypt & digest verification. > + */ > + RTE_SECURITY_TLS_SESS_TYPE_READ, > + /** Record write session > + * - Encrypt & digest generation. > + */ > + RTE_SECURITY_TLS_SESS_TYPE_WRITE, > +}; > + > +/** > + * Configure soft and hard lifetime of a TLS record session > + * > + * Lifetime of a TLS record session would specify the maximum number of > packets that can be > + * processed. TLS record processing operations would start failing once = hard > limit is reached. > + * > + * Soft limits can be specified to generate notification when the TLS re= cord > session is approaching > + * hard limits for lifetime. This would result in a warning returned in > ``rte_crypto_op.aux_flags``. Can we define "a warning" better? Perhaps an example of a soft-limit and hard-limit, what the user can check aux_flags for, to identify? Or link to = the appropriate part of the crypto_op.aux_flags documentation to help the user. > + */ > +struct rte_security_tls_record_lifetime { > + /** Soft expiry limit in number of packets */ > + uint64_t packets_soft_limit; > + /** Hard expiry limit in number of packets */ > + uint64_t packets_hard_limit; > +}; > + > +/** > + * TLS record protocol session configuration. > + * > + * This structure contains data required to create a TLS record security= session. > + */ > +struct rte_security_tls_record_xform { > + /** TLS record version. */ > + enum rte_security_tls_version ver; > + /** TLS record session type. */ > + enum rte_security_tls_sess_type type; > + /** TLS record session lifetime. */ > + struct rte_security_tls_record_lifetime life; > + union { > + /** TLS 1.2 parameters. */ > + struct { > + /** Starting sequence number. */ > + uint64_t seq_no; > + /** Salt to be used for AEAD algos. */ > + uint8_t salt[RTE_SECURITY_TLS_1_2_SALT_LEN]; > + } tls_1_2; > + > + /** TLS 1.3 parameters. */ > + struct { > + /** Starting sequence number. */ > + uint64_t seq_no; > + /** Salt to be used for AEAD algos. */ > + uint8_t salt[RTE_SECURITY_TLS_1_3_SALT_LEN]; > + /** > + * Minimum payload length (in case of write sessions). > For shorter inputs, > + * the payload would be padded appropriately before > performing crypto Replace "would be" with "must be"? And who must do this step, is it the ap= plication? > + * transformations. > + */ > + uint32_t min_payload_len; > + } tls_1_3; > + > + /** DTLS 1.2 parameters */ > + struct { > + /** Epoch value to be used. */ > + uint16_t epoch; > + /** 6B starting sequence number to be used. */ > + uint64_t seq_no; > + /** Salt to be used for AEAD algos. */ > + uint8_t salt[RTE_SECURITY_DTLS_1_2_SALT_LEN]; > + /** Anti replay window size to enable sequence replay > attack handling. > + * Anti replay check is disabled if the window size is 0. > + */ > + uint32_t ar_win_sz; > + } dtls_1_2; > + }; > +}; > + > /** > * Security session action type. > */ > @@ -654,6 +747,8 @@ enum rte_security_session_protocol { > /**< PDCP Protocol */ > RTE_SECURITY_PROTOCOL_DOCSIS, > /**< DOCSIS Protocol */ > + RTE_SECURITY_PROTOCOL_TLS_RECORD, > + /**< TLS Record Protocol */ > }; >=20 > /** > @@ -670,6 +765,7 @@ struct rte_security_session_conf { > struct rte_security_macsec_xform macsec; > struct rte_security_pdcp_xform pdcp; > struct rte_security_docsis_xform docsis; > + struct rte_security_tls_record_xform tls; Do we see TLS handshake xform being added in future? If so, is 'tls' a good= name, perhaps 'tls_record'? That would allow 'tls_handshake' in future, with consistent naming scheme w= ithout API/ABI break. > }; > /**< Configuration parameters for security session */ > struct rte_crypto_sym_xform *crypto_xform; > @@ -1190,6 +1286,16 @@ struct rte_security_capability { > /**< DOCSIS direction */ > } docsis; > /**< DOCSIS capability */ > + struct { > + enum rte_security_tls_version ver; > + /**< TLS record version. */ > + enum rte_security_tls_sess_type type; > + /**< TLS record session type. */ > + uint32_t ar_win_size; > + /**< Maximum anti replay window size supported for > DTLS 1.2 record read > + * operation. Value of 0 means anti replay check is not > supported. > + */ > + } tls_record; Missing /**< TLS Record Capability */ docstring here. > }; >=20 > const struct rte_cryptodev_capabilities *crypto_capabilities; > @@ -1251,6 +1357,10 @@ struct rte_security_capability_idx { > struct { > enum rte_security_docsis_direction direction; > } docsis; > + struct { > + enum rte_security_tls_version ver; > + enum rte_security_tls_sess_type type; > + } tls_record; > }; > }; >=20 > -- > 2.25.1