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 8280B42606; Thu, 21 Sep 2023 10:39:00 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6DF754026D; Thu, 21 Sep 2023 10:39:00 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id D39394014F for ; Thu, 21 Sep 2023 10:38:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695285539; x=1726821539; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=h+hswxkjPiYh7ELSCjuBDry+OubepVBW2QxOQUzPeGk=; b=Mc8DnwmBFvQfEGKqidqWugB7K9GS9ywK8VQhOEdzE0pi5TPRkBQr6WDB rnD1OI/dqYpO/ScGWcUDf/IZvsk7TR99GQI+VzfoqD4QkXOivHTMmHLPl 38QDwBAHbX/EZ7QOzYuRU+ZXs6xYPK+sILMW6AtzAF/0SdAOMti910VHQ 3YTY7CnZqtFIVb3RQKpOJ4jWRqguGC/c8CEXhKV8U5mTRVMTJ1S5SBYYt UyIXq22CbJPcWXteGg0MXUoNsTX6+LJTNvfkYfCxWMh9zVFVCA0es0D3X 5NVGG+xbXppBBR+FsWzb8QJjuPQOA6qWuBjyt5m09iZh4K+uwiYgcLx/y A==; X-IronPort-AV: E=McAfee;i="6600,9927,10839"; a="446926773" X-IronPort-AV: E=Sophos;i="6.03,164,1694761200"; d="scan'208";a="446926773" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2023 01:38:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10839"; a="862381293" X-IronPort-AV: E=Sophos;i="6.03,164,1694761200"; d="scan'208";a="862381293" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by fmsmga002.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 21 Sep 2023 01:38:37 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Thu, 21 Sep 2023 01:38:37 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Thu, 21 Sep 2023 01:38:36 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32 via Frontend Transport; Thu, 21 Sep 2023 01:38:36 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.168) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.32; Thu, 21 Sep 2023 01:38:35 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FZ4TISJiQpDHTxMunIqEugobXQTd+Cn+rdmV4PmoMUrf9jW0tG+mPKi6yHnehq5ETZHlZGZq80oVrhMKfFu+fs6D/Y87acHqJe6pBkOAes5IHkox2M6CvPFVsztJMqxddtavwijFqmV7BHbLAQGv1ksI1l67XVTjb1zFKOug2r7vS/LY1Idp14GRoK7lN7Tw83Mbuf3BPkrmvpLEaEJkFR3QDhsJF2YZvh7dhACulioZXTvwilR84xUi3MEUVYBWpkpTrSmR5upq863J7WYim4eT554pScxSOmuefzKFDuid83AhMsJBKigLZvOiuZtN5aSsdK2rHk27vd6+faOquw== 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=Kt8tV2FxQcF2ujN256Q9z3FRcf0Zbb54wpE9fifWqYg=; b=Jz8LGH62DFVVgNa6NDCccM80XUq6DIaVvZCqpV1/1uFsuq0mK94eqqstluE0kscQ5Y//zkdttV5LZ4oRK4Q9Z7JJ1fjZLHdPMEtlcsMWYC3lUxhApKpvZ/TJDTKKegLAH8pmJEun3yICpbxP6Xvtmb/j14aKewvTLvLNYhxuFCvkoJe7t6uCpHMjQPva1bg+KYbGu9zlANVEmWNzhd4yOJ1ESGsZCIYFaaIx5jMRY2yIAHvpkdWKu8hr2/96ene+Y7Gd2ICxDTIHC1R2BRQ0C9Z4jDBvKTsdHOvkTFD8vmVW5HwDeS0K0+FWkFnZalhuHUTPs6/IhzPFFjTjdqfbSg== 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 SJ1PR11MB6154.namprd11.prod.outlook.com (2603:10b6:a03:45f::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.20; Thu, 21 Sep 2023 08:38:33 +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; Thu, 21 Sep 2023 08:38:32 +0000 From: "Van Haaren, Harry" To: Anoob Joseph CC: Hemant Agrawal , "dev@dpdk.org" , "Matz, Olivier" , Vidya Sagar Velumuri , Thomas Monjalon , Akhil Goyal , Jerin Jacob Kollanukkaran , Konstantin Ananyev 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/WtY87AjqZwggAAvzwCAAVLfcA== Date: Thu, 21 Sep 2023 08:38:32 +0000 Message-ID: References: <20230811071712.240-1-anoobj@marvell.com> <20230811071712.240-3-anoobj@marvell.com> In-Reply-To: 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_|SJ1PR11MB6154:EE_ x-ms-office365-filtering-correlation-id: ef25fbf1-d25a-4844-957b-08dbba7e239b 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: E1rbZC4lpPQFTkb4+/sqQh17uQhISnVwYZmdLUCvlfjmYr3ugKlyWj2nRq+ElUT4JD14yPCKLau7azXBcsFjzgmZWqP5dWwu7IkAuipNHYaruyNfiANAwFGSOUT4WcHTMUyeMh/QtZGFgGfyWKY0o5e+Y8WfcuvpG1/KC0G0CgpdnF8RNFEaZ/MvxLniWI8iEmwag3FCRUElmLfH6WDraATdblag5DJcnh/IDVrCengi/sY6GV4euG8pO6cMQtJw/g3h1jAV520RHd21+MiRSscBoCo0VyOwGXN3z6xPIj3ahIRrOwu6WpAjCAFU/XQC2aCww54xfGlprkAyaUdxbYWfpAfX9tH6ZeW9X98SpicKn/Y/op3pq7xi2lC8ybV1nUbMdb3yjibPnmyVlGRbJq3X8WIBzCEYEkIcOk0wFQYB8hLlW4lOC/CRRBLHFKzzwnRHn9OQlsohgVjQBO/DcBdFp2bBsfQ8S/CG34eATXVhNfECWdo46g0dz4l/XxcNZ+83X4x9t/6AVSKuMI31pHordQqLCTaXi5rv2rBe0moGhIRIE7Np0Xi/zy0Oe3bKIdtl6hSx87kV1Z10gYCyTEsgDIOC8zAUcHDLWJNdzXo= 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)(346002)(366004)(376002)(39860400002)(136003)(396003)(1800799009)(451199024)(186009)(2906002)(64756008)(26005)(66476007)(55016003)(316002)(66899024)(6916009)(66574015)(15650500001)(30864003)(71200400001)(83380400001)(82960400001)(76116006)(52536014)(5660300002)(53546011)(66446008)(54906003)(4326008)(966005)(66946007)(41300700001)(7696005)(8936002)(8676002)(122000001)(6506007)(9686003)(478600001)(38070700005)(38100700002)(86362001)(66556008)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?NoLrE7+9NbeN7qbMqphL7piESt//6VQZJ9zC0AqJ3rAN1hL4hgKzxMAsWLFe?= =?us-ascii?Q?Vx73Hk0jn3FdGUCsCLNGWYZW/Zd/TAOMXw6eiwb+lZNbEZp0LAF7VSKiDAfa?= =?us-ascii?Q?uyypdEIrYclJpmY/1N6cGS9qc1TaEIvsqlTAR66074f9f/Ss82YdUNjJjVe+?= =?us-ascii?Q?soJ0qGkX4BoCpdrJJo+/wehikdrRwLYuw52ZHLM/SczBmqlHfbTSqYrIxs+4?= =?us-ascii?Q?B59ON8fknTXgwxv1t+rZ/MS9bJI7yzOZhxet1HIkOIgzd1jHlEmGr/FQ7yHf?= =?us-ascii?Q?rTuxeiCM6+gvyyHnncMD2eLql3iilWkyJNTiDBGSO8XDC9H+oihnVVNaKUfS?= =?us-ascii?Q?R19lOVd7SCD1i3R7cBA3cbMTXSWoz0BHEHgUjrOOceqMckRrTOubBXUDosRB?= =?us-ascii?Q?STu09A72RGkWWPjcC8iiwJscQCacLf0qhp8rXdNQNlfrdqKJIpjlgRduWSfA?= =?us-ascii?Q?ieg4+It+tWWI10PPVJtesp77gYtLhNV0uvPvfsQ9Yn9AAUW8XdrWucHVb0qD?= =?us-ascii?Q?1S5vBSTLQ7PZPYUshFqtQgeyqQ5vzgIFLPx9PeBqcivKNF5d2iawCHkKsqO1?= =?us-ascii?Q?krfc8bGJTrksjUprXt2fBzu86CyqDRWvWSJpu/paRrz9aXGK0aLHSU5t7eNt?= =?us-ascii?Q?A899uZ/94XCP9F3vowahEYCJSZ9CkZOU0crQrSgtPuYRA7h7AQ+wjJoQYpaM?= =?us-ascii?Q?BDP0oIOoTSlOlRu4AfFu9WUTPDK/+7r6J//yQdwC089xyWYgkMgv6XdJCADX?= =?us-ascii?Q?J7VgjypUBof/3pEGBu91U7XSxkM80OKY4t4RP/6fYrpewVmlBKBU60uzPVtw?= =?us-ascii?Q?cVhJyysVWVBAJhnZyirD4Cpw4kzK78GfhDBY9E2mQ3NOFJbzBpE63q5Ie2au?= =?us-ascii?Q?fgGJbQ3QMGyc0/rUcOa1BARVOF+R9suI24vEgjBDvv62dkLArkTlS3z5lWkJ?= =?us-ascii?Q?ePjcIuj8x9hwXSOrGxgoJUK4N2phaqA2uE6JvcBUA/UUTWycOzRg8uCb6ICL?= =?us-ascii?Q?YeZOIt/cedaaVwnAKPisI2nPL4PwmTteMhSFzDt0Z1WmL6EPMMf3hnUUaGRQ?= =?us-ascii?Q?0yIZbHuYwYhsaO4DxwNmiXjZ67f6IC4CqjW5gQTkYI1MhuQtBp/i0K31g1g8?= =?us-ascii?Q?ggIIIiD6/kted4BRXk0XivuF0CAKZPtJilqqXi5i4bR12xealtMU6kV8p81k?= =?us-ascii?Q?ArJm2WjSK1lRbEAQ80vZXbayheseTQrfVbktiOgp6G/0lpcDA4raJ1i+BoKc?= =?us-ascii?Q?WkAVysqBRDDlQpZK/1kcgoRO4xcyTIvRfUUS4fQB2r5GgKDqIeeo0gm4lZ+A?= =?us-ascii?Q?/POwA/4l8SJS29696sUMYEKy7WMq2nUJs9GBblTJuArQtCGOF2ipgsOal3AV?= =?us-ascii?Q?6iOq6sYhpK8PpjfcmZVR3M9qJYA6DF8UylzQonZHJhWgH2yk6tqT2Z1KKlXS?= =?us-ascii?Q?Fii+9yV6cAMvJdAUow3bwRwjsLkzi8+sLxdeOZKwYE0SYj2WV9wUoRq4fco6?= =?us-ascii?Q?rvglMvgWr7JzOz0RR7KikcY6fTFdDiCn5KSuzMZiZ8H0EFjQ9y0kJbJ9G1Ut?= =?us-ascii?Q?fd8Gcg7r/zmksramwDfyJj6HX53Gg9mo1XuEahyQ?= 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: ef25fbf1-d25a-4844-957b-08dbba7e239b X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2023 08:38:32.8616 (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: xcj9wgvhXrdHrmp+DBr83CvptYha0DsMDg3Q66INnf9NikrZy8WIKOq7ftDKr7batYH0lCCFD2//qQnDpnkZt1Or6lDZzXuAI5qSZnDLHd0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR11MB6154 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: Wednesday, September 20, 2023 12:52 PM > To: Van Haaren, Harry > Cc: Hemant Agrawal ; dev@dpdk.org; Matz, > Olivier ; Vidya Sagar Velumuri > ; Thomas Monjalon ; Akhil > Goyal ; Jerin Jacob Kollanukkaran ; > Konstantin Ananyev > Subject: RE: [RFC PATCH 2/3] security: add TLS record processing >=20 > Hi Harry, >=20 > Thanks for the review. Please see inline. >=20 > Thanks, > Anoob >=20 > > -----Original Message----- > > From: Van Haaren, Harry > > Sent: Wednesday, September 20, 2023 2:53 PM > > To: Anoob Joseph ; Thomas Monjalon > > ; Akhil Goyal ; Jerin Jacob > > Kollanukkaran ; Konstantin Ananyev > > > > Cc: Hemant Agrawal ; dev@dpdk.org; Matz, > > Olivier ; Vidya Sagar Velumuri > > > > Subject: [EXT] RE: [RFC PATCH 2/3] security: add TLS record processing > > > > External Email > > > > ---------------------------------------------------------------------- > > > -----Original Message----- > > > From: Anoob Joseph > > > Sent: Friday, August 11, 2023 8:17 AM > > > To: Thomas Monjalon ; Akhil Goyal > > > ; Jerin Jacob ; Konstantin > > > Ananyev > > > Cc: Hemant Agrawal ; dev@dpdk.org; Matz, > > > Olivier ; Vidya Sagar Velumuri > > > > > > Subject: [RFC PATCH 2/3] security: add TLS record processing > > > > > > Add Transport Layer Security (TLS) and Datagram Transport Layer > > > Security (DTLS). The protocols provide communications privacy for L4 > > > protocols such as TCP & UDP. > > > > > > TLS (and DTLS) protocol is composed of two layers, 1. TLS Record > > > Protocol 2. TLS Handshake Protocol > > > > > > While TLS Handshake Protocol helps in establishing security parameter= s > > > 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. > > > > > > 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. > > > > > > 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 i= s > > being 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 > [Anoob] Indeed. Will reword as suggested. Thanks. > > > 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(+) > > > > > > 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`` return= s > > > a handle for SC, and this handle is set in > > > ``rte_security_macsec_xform`` to create a MACsec session using > > > ``rte_security_session_create``. > > > > > > +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 > > > +designed 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= data > > > + encryption (e.g., AES, DES, etc.). The keys for this symmetri= c > > encryption > > > + are generated uniquely for each connection and are based on a = secret > > > + negotiated by another protocol (such as the TLS Handshake Prot= ocol). > > The > > > + Record Protocol can also be used without encryption. > > > + > > > + - The connection is reliable. Message transport includes a mess= age > > > + integrity check using a keyed MAC. Secure hash functions (e.g= ., > > > + SHA-1, etc.) are used for MAC computations. The Record Protoc= ol > > > + can operate without a MAC, but is generally only used in this = mode > > > + while another protocol is using the Record Protocol as a trans= port > > > + for negotiating security parameters. > > > + > > > +.. code-block:: c > > > > The code block below isn't C? Is there a better code block type for a t= ext > > diagram? >=20 > [Anoob] Valid point. I was just following the general scheme followed in = this file. > May be, I'll introduce a .svg image for newly added code. This was a nit-pick that perhaps "code-block:: text-diagram" or so exists. No need to make a .svg in my opinion, the text-diagrams are clear. > > > + 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 > > > > > > 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 */ > > > }; > > > > > > +/** 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 TL= S > > > + record > > > 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 an= d > > 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 u= ser. > > >=20 > [Anoob] The concept of lifetime is present in most protocols. Idea is to = limit the > max number of operations performed with a session. Soft expiry notificati= on is > to help application prepare for an expiry and setup a new session before = the > current one expires. Understood, yes. > The idea was borrowed from IPsec which has the > 'RTE_CRYPTO_OP_AUX_FLAGS_IPSEC_SOFT_EXPIRY' flag defined. But I realize, = it > should be better defined. I can rename the flag to > 'RTE_CRYPTO_OP_AUX_FLAGS_SEC_SOFT_EXPIRY' to avoid redefining same flag > for each security offload. Do you agree to this suggestion? > > https://elixir.bootlin.com/dpdk/latest/source/lib/cryptodev/rte_crypto.h#= L67 So we cannot "just rename" the flag, its an API break. It likely is possibl= e to add an additional #define with the same value as IPSEC_SOFT_EXPIRY, and call it SE= C_SOFT_EXPIRY. Is that the best/most descriptive name? SYM_ALG_SOFT_EXPIRY? I'm not sure h= ere, input welcomed. Perhaps we can improve the doc-string there, to explain what it means a bit= more verbosely. > Do note that once hard expiry is hit, the operation would fail. Expectati= on is, > cryptodev would return 'RTE_CRYPTO_OP_STATUS_ERROR' in case of errors. That is good. > > > + */ > > > +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 secu= rity > > 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 th= e > > application? >=20 > [Anoob] Padding is performed by the PMD/cryptodev device. I'll change "wo= uld > be" to "will be". Would that address your concern? I suppose my concern is "is it clear to PMD authors that they must implemen= t X in their PMD", and to ensure we (DPDK community) do our best to clarify API demands, and t= o ensure future contributions are of high quality too. For example, could we have a security library unit-test that checks the pad= ding case, to ensure correct & consistent behaviour across different crypto PMDs? Same thoughts for SOFT and HARD error variants, (although they might take..= . hours?) to execute. But it is nice to automate-and-test these "corner cases". It's not about wording, its about clarity between PMD devs, security librar= y devs, and application facing APIs, to ensure that DPDK provides the most/best help it can to provide correctne= ss. Does that clarify what I'd like to see? For this patchset, could we document a list of "caveats" when implementing = PMD functionality for TLS-record security offload, and indicate that: 1) Padding must be added by the PMD based on security library flags& algo i= n use, not application layer (I know this is demanded by the sym algos anyw= ay, but let's make it explicit) 2) It is strongly recommended to build unit-tests for _SOFT and _HARD error= cases (potentially by "fast forwarding" the internal counters via private = APIs to avoid hours of enc/decryption) I think that limits scope-impact to this patchset, but is clear for PMD imp= lementations in future what expectations are. Thoughts, is that a good way forward? > > > > > + * 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 */ > > > }; > > > > > > /** > > > @@ -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 sche= me > > without API/ABI break. >=20 > [Anoob] In the future, I would like to see TLS handshake also offloaded i= n a > similar manner. But that would need some fundamental changes in security > library. Like, current security library is pretty much tied to symmetric > operations but a handshake would involve both symmetric & asymmetric > operations. >=20 > Said that, I agree with your suggestion to rename the field. Will change = it to > 'tls_record' in next version. Agreed, that handshake is significantly more complex, thanks for rename to = "tls_record". >=20 > > > > > > > }; > > > /**< 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 > [Anoob] Agreed. Will add in next version. Thanks!