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 94F09425FF; Thu, 21 Sep 2023 13:01:21 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 80595402C7; Thu, 21 Sep 2023 13:01:21 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 9A340402B5 for ; Thu, 21 Sep 2023 13:01: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=1695294079; x=1726830079; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NDnZNOknl+ZTTw+XyRwCXsuEWo62dTp0QFwSeSfUA68=; b=f9oLJ6vatDICemV6mSn5Q+hBqGFqv74dYPkhByDAitL1X+pee1oYiy4z J1LIOuxYpc/PhFcz9WBM80kZzQyuBjSDaRp1zR/ljH7br7kPwULk5+qk5 hXqwYyMbfPxlsHswW1A+niN8WYWRMjIHzorzxgJv6Ku/ny340BcedJ3wb sDIVNTIPAQvP40xe2TLnWkL96Cg20+A2FfauG+q4tfWLF++rBsE7i0VxA bC34PqJQ7aGy+0ARr8bOrUWn9vnLratCYgPTfhq5hAw7S31C+MpvgbM7y yV+9ToMz3zVzDVH5ZghyuNcxEO1j+PT1NpJSnDDES/lLNZprxzZSMgFXZ g==; X-IronPort-AV: E=McAfee;i="6600,9927,10839"; a="446959227" X-IronPort-AV: E=Sophos;i="6.03,165,1694761200"; d="scan'208";a="446959227" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2023 04:01:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10839"; a="776375014" X-IronPort-AV: E=Sophos;i="6.03,165,1694761200"; d="scan'208";a="776375014" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by orsmga008.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 21 Sep 2023 04:01:12 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX601.amr.corp.intel.com (10.22.229.14) 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 04:01:12 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX610.amr.corp.intel.com (10.22.229.23) 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 04:01:11 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx610.amr.corp.intel.com (10.22.229.23) 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 04:01:11 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.170) by edgegateway.intel.com (134.134.137.103) 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 04:01:11 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PpDkT6cYVOMHHZTAwKbCizmYTJbvXIPlvxTw6E3jv4g0Ke0EkF4Rje5rEXyrzqxAILkvnH2Z547bNyTgztFEoBErlk0ouamYyluNw2tNsomUvyBorW2otI9ILAjgTKy9tDAsty7sdBFSjm/D81GsLSiI09fJoIFFePhaa3Ffk2Jcmw3ozIyUtR31oWZ3fVSk3IAMthQ1OckB04kFDx3cjeQ4LISK7Xb2YxQqysshIYyPVLVQRcTUvARmHvPkx2gOUrM+bkP2XPDj4do4z1//MztQhqaKYduMlANGcP2oANtSakMPFR4pasmp2bFeF5lHChrYvM6UIZAO1MJA3QipSg== 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=liI6cpeH7sL274NZQCCGa2m8ckoQsa/QHtTFhrsKjUc=; b=TIITzVFkzR7FfllWXyhflyt/0YvHnsW3/e7mcnbMl+jCJQJTCjPRA20oiHtY/VzgW+u3/pYtmwt/XCZe/hLzzUmgfSSiG72GqhvyIIBZ8H9j7FmCgF50NlWn0M3WKS9r8CpZONZWCkm2UQvt6VHal+rlzcQv8dzT6vqvZHb5Vwz56qyhHpV0nsYHzYOx9oHdxmee/Rm1Qje2F2oXaosfDoEgFGI5NmuskhkqgUQuyGP2YBxvtf8/uW7YmPMo4iSAZgHifMKFslSnvAG95BRz4W1tYKplNZ/RMHHLW9FZL3Kn2AUrlt6yywy4SiUxOCK48LZh8y/QNmFpCyolBeFGGw== 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 MN0PR11MB5986.namprd11.prod.outlook.com (2603:10b6:208:371::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.28; Thu, 21 Sep 2023 11:01:08 +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 11:01:08 +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/WtY87AjqZwggAAvzwCAAVLfcIAAL5+AgAAAuPA= Date: Thu, 21 Sep 2023 11:01:08 +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_|MN0PR11MB5986:EE_ x-ms-office365-filtering-correlation-id: 0f9ef6ec-17d8-4193-dcf9-08dbba920ef6 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: vGGSXzWGPAiw+3FsHHkx2P+OuJAimX8DwNgAGIlWvZgLPhztlHErIZc1j+Udle4+uUV2RsMhlVDvD6mx1E81JQWaPz940SML4puChTBK1cqfp2ejdPNUyhupCY2i2WgME8izFDCtomB0VOMPaA04RucUCmk8BUIIJElivIZaZFJ7fJoXSgv4UiKNaA5oi/x+B+IqYreZq5m7xbzTe1CH9WYo7wtdyBc8iEPehCv1EdClgVWT1I4klKFwiqKv8rYrhTKPxRtjiVziusJyFmp3xGDnOIv/eNM5KhlysKQM9cmJVZobLIOTn4PDNyoBssuXPuAFzvtqLjEk4D873E59G76rgU14LFiipn3m86hr0Z0f6gFFFagNh0/A5bH0IUmeJXhEphJKhjtmQ0are1Ot0tEkSacKqeiNyLwHmW9FLjEzOsGkvW+L+npNHucjYLOJ1eQbyfCniKU1vUxCJYXnGNzwNVh3RtTATmGUZgtVwe/m8qfQjjVBbki5+xCpbz3e5TEcjsvdGmSISXMbjxaFRilk+4EbbSmlC3KZgGBrDHP1YnCJ685TycuLbWIT+PhFtOlolPJ6RsO4Ty+tt5NxjeYzr7qv6Adotd81+0Jc5ds= 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)(396003)(376002)(39860400002)(366004)(136003)(346002)(186009)(1800799009)(451199024)(66899024)(7696005)(53546011)(6506007)(478600001)(83380400001)(33656002)(82960400001)(55016003)(86362001)(38100700002)(966005)(122000001)(38070700005)(2906002)(15650500001)(41300700001)(30864003)(26005)(71200400001)(19627235002)(9686003)(4326008)(66574015)(52536014)(8936002)(54906003)(66556008)(5660300002)(8676002)(76116006)(6916009)(66946007)(66446008)(64756008)(316002)(66476007)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?2L5Ww9IOsMLtdxeECRTc6ZzbPnnAQFF7N7dtjjkRXNfAP4N7zX40sONuw6VJ?= =?us-ascii?Q?wk1ZXlqTHZIBfev9jt3lFfEYZ3dEmLbMx0lwxhf+4wdXaWhX5XVeXtuHz0Tu?= =?us-ascii?Q?9Jdv3gOwt/NaoJNjBdNybIXt5v0lCcAQwHP7svg1DiVDXwYJ42Cy9tcEqgj0?= =?us-ascii?Q?VdhDHtJchaAJ/5eTOQmc7OA84mlKtwWF6QkFI7I1F5an9j6aurYhm/LZtKcK?= =?us-ascii?Q?7u9GD9QF6XgSlV2UzQCN8Gd2afbqS2X4FYm0UTaiqNv4oOyoXlX6Q3fp2oFq?= =?us-ascii?Q?A2nIVrWmRkLZUogHriQIUFHIhZr1QpMTm4VTme6M92HJtlj7hxShbnpSCj/1?= =?us-ascii?Q?cbH9ta0jgQ35fwmwzzuECxxNvQJkzszMzTfoOvxMb+2c0nzm4o3K2Ezt3Sjl?= =?us-ascii?Q?pcA7zURYHfo4gWnkRQyhrtgoKyPU4WxixEhzuswh+OBedd7qJmiWSmf/tE+R?= =?us-ascii?Q?/KZVfxlp82DGnBiq/6O0Bn8Gcgg7raFv9qKGxu7syjnUmLMYGr4FRURAellO?= =?us-ascii?Q?yA9EQrYx66Mu1CZc8ju2skrsizEV/ip1aXuP3SryTewox0FQ9ITUWT048LU9?= =?us-ascii?Q?0SjuXMo7zjHdjgLSylphB0LznvRqGaeArihjSIj3mn5jtLZYvVPJPcINrBjy?= =?us-ascii?Q?zF8wHrNc2r9WTBLbnvb5x6UmRiA9Ahfhu8h973b23Vo4RC7fh+XxvR4ftimi?= =?us-ascii?Q?ADpyAqJKKydNMey0VQU2F6Zcn5c4eDdivdpzZM4cwmVXEym4mHbaAvkL9fGR?= =?us-ascii?Q?AdxcCCxqTVp5A/tXEoFw3hAb0k08jy6sRSO3G4P9KS3YmhneRiFGVwS/r+Hl?= =?us-ascii?Q?ZqTc634mMgGXBoHzmS9z8Hzgc2Rt2OXE90yOiJQE6PknJmDmpN8hFdpBx6/S?= =?us-ascii?Q?rhQqStzNwTdFjCD8SYDa990aCKtMaINlMZlDfTq8AlkgA07q7w4NWq23bvos?= =?us-ascii?Q?z5B+axDFdgAJSG1ZVgrheXU6IxRNJ4ohIKPGw0ejACT1FO4n0pwC/8huaq1f?= =?us-ascii?Q?rv9l6vcmjrU2D06jaZjz12b1kji+oDm4m3m4FAlVOuvw7KXKKz/baU9RAiT3?= =?us-ascii?Q?AWeBqCReWXOBikuD9Co+VCRgUPIEPIyWiTHOaIPkQZuosdRmxQ8R69on4H5U?= =?us-ascii?Q?GevL7lHEVrky9O9s51jtjY3wIucxMNFixzaNS+aoU/k6AijZ5076VVB9fBGY?= =?us-ascii?Q?MkBR2YBvEksGpoiNohzhQwzoDHbEa8mT3BI8Oka6v47+4bb/hYspRTUnA1/r?= =?us-ascii?Q?er3MJvH0wmhCvxd7eIqpP8DCMnj5vzCRL8mwaF5DV7ATIORO8MIjwDEC//ap?= =?us-ascii?Q?r70cOYxaAXvCcOMdQcZ8HLc3cogajLyYWaLIe53FOlwf5w/9r/DABXoNQyAM?= =?us-ascii?Q?wvIl9Mqk/9Y2gTVuZr8bIgw5u54KBXaJpfoOF1JuIywc/KRPiZwOrFOBtGaI?= =?us-ascii?Q?Qn8hxh3W08TS0+4JhiXR9F2syN/Cx5EOEJKpC7hSYnpiEb3YxndOHczUEqoQ?= =?us-ascii?Q?RD379DyPqE+yP53wNjOnCF31Up7YsqAEMCZdkrEXhPEjQR25zPnGR5DUz7Qy?= =?us-ascii?Q?fHINxZQRpvNqu5Gm5NZWu45qvIiw6POV23LSoBrC?= 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: 0f9ef6ec-17d8-4193-dcf9-08dbba920ef6 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2023 11:01:08.1732 (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: 1MEEMqu+FMTp1gBMbYlPWfcpIXWeDD5Qadp1ouO7Bsb91Vp8bCPFKe5Co0U6B6AHdPVYVUwJRCCV317+UyTUq/Z3QDumDy8yptOoCEjw8N4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR11MB5986 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: Thursday, September 21, 2023 11:55 AM > 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 > Please see inline. Read all comments inline below, agree that improving docs is the only actio= n. I wasn't aware a unit-test suite for the TLS record work was in progress, g= lad to see that. All looks good, happy to Ack next version with doc updates. > Thanks, > Anoob >=20 > > -----Original Message----- > > From: Van Haaren, Harry > > Sent: Thursday, September 21, 2023 2:09 PM > > To: Anoob Joseph > > Cc: Hemant Agrawal ; dev@dpdk.org; Matz, > > Olivier ; Vidya Sagar Velumuri > > ; Thomas Monjalon ; > > Akhil Goyal ; Jerin Jacob Kollanukkaran > > ; Konstantin Ananyev > > > > Subject: [EXT] RE: [RFC PATCH 2/3] security: add TLS record processing > > > > External Email > > > > ---------------------------------------------------------------------- > > > -----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 > > > > > > Hi Harry, > > > > > > Thanks for the review. Please see inline. > > > > > > Thanks, > > > Anoob > > > > > > > -----Original Message----- > > > > From: Van Haaren, Harry > > > > Sent: Wednesday, September 20, 2023 2:53 PM > > > > To: Anoob Joseph ; Thomas Monjalon > > > > ; Akhil Goyal ; Jerin Jaco= b > > > > 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 ; Konstanti= n > > > > > 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 > > > > > 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. > > > > > > > > > > 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 is 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." > > > > > > [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`` > > > > > 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``. > > > > > > > > > > +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 i= s > > > > > +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 > > > > > + symmetric > > > > encryption > > > > > + are generated uniquely for each connection and are based o= n a > > secret > > > > > + 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 Pr= otocol > > > > > + can operate without a MAC, but is generally only used in t= his mode > > > > > + while another protocol is using the Record Protocol as a t= ransport > > > > > + 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? > > > > > > [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 exis= ts. > > No need to make a .svg in my opinion, the text-diagrams are clear. >=20 > [Anoob] Thanks for the confirmation. I do not think "code-block:: text-di= agram" > exists. Anyway, I'll improve the diagrams to make the padding etc more cl= ear. >=20 > > > > > > > > > + 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 th= e > > > > > + TLS 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-limi= t > > > > 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 document= ation > > to help the user. > > > > > > > > > > [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 notification 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://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__elixir.bootlin= .co > > > m_dpdk_latest_source_lib_cryptodev_rte-5Fcrypto.h- > > 23L67&d=3DDwIFAg&c=3DnKj > > > Wec2b6R0mOyPaz7xtfQ&r=3DjPfB8rwwviRSxyLWs2n6B- > > WYLn1v9SyTMrT5EQqh2TU&m=3DF6 > > > > > WuwwuvXG0eJ1IWAMFgcXlMdQwKFDx6C1qsQgSaDa2XGr3PZ6LEDtSw0OeC > > DstG&s=3D0iO8Y > > > sr0f4cnE8ihg40sZfEEZfPzEXvJBvcNcyOdS98&e=3D > > > > So we cannot "just rename" the flag, its an API break. It likely is pos= sible to > > add an additional #define with the same value as IPSEC_SOFT_EXPIRY, and > > call it SEC_SOFT_EXPIRY. > > Is that the best/most descriptive name? SYM_ALG_SOFT_EXPIRY? I'm not > > sure here, input welcomed. > > > > Perhaps we can improve the doc-string there, to explain what it means a= bit > > more verbosely. >=20 > [Anoob] Agreed. Let me try to improve these aspects in next version. We c= an > revisit this topic after that and see if we are able to reach a conclusio= n. >=20 > > > > > Do note that once hard expiry is hit, the operation would fail. > > > Expectation 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 > > > > > +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 i= t > > > > the application? > > > > > > [Anoob] Padding is performed by the PMD/cryptodev device. I'll change > > > "would be" to "will be". Would that address your concern? > > > > I suppose my concern is "is it clear to PMD authors that they must impl= ement > > X in their PMD", and to ensure we (DPDK community) do our best to clari= fy > > API demands, and to ensure future contributions are of high quality too= . > > > > For example, could we have a security library unit-test that checks the > > padding case, to ensure correct & consistent behaviour across different > > crypto PMDs? >=20 > [Anoob] Glad that you brought up that point. For IPsec, we have rather ex= tensive > framework which covers all the features that are supported today in rte_s= ecurity. > Features like soft expiry & hard expiry are tested on platforms that supp= ort the > same. As for TLS, we are working on adding unit test framework. It would = be part > of the next version. Perfect, I wasn't aware of plans to add it - great!=20 > > 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". >=20 > [Anoob] It won't. Soft expiry can be very low value as well. It is alread= y covered. > Please check. > https://elixir.bootlin.com/dpdk/latest/source/app/test/test_cryptodev.c#L= 10272 Ah great, good to hear. > > It's not about wording, its about clarity between PMD devs, security li= brary > > devs, and application facing APIs, to ensure that DPDK provides the > > most/best help it can to provide correctness. Does that clarify what I'= d like to > > see? >=20 > [Anoob] I understand your concern. My understanding is that for security = offloads > (rte_security lib), documentation has complete details of application & P= MD > expectations. If we have missed some features, we can take a re-look at t= he > features and add as required. Other than documentation, do you have any o= ther > suggestions in mind? Not right now - with additional unit tests (like IPsec has) all seems well = in hand. > > For this patchset, could we document a list of "caveats" when implement= ing > > PMD functionality for TLS-record security offload, and indicate that: > > 1) Padding must be added by the PMD based on security library flags& al= go in > > use, not application layer (I know this is demanded by the sym algos an= yway, > > but let's make it explicit) >=20 > [Anoob] Agreed. Will update documentation as required. >=20 > > 2) It is strongly recommended to build unit-tests for _SOFT and _HARD e= rror > > cases (potentially by "fast forwarding" the internal counters via priva= te APIs > > to avoid hours of enc/decryption) >=20 > [Anoob] For IPsec, it is already added. For TLS, we have plans to add the= same. >=20 > > > > I think that limits scope-impact to this patchset, but is clear for PMD > > implementations in future what expectations are. > > Thoughts, is that a good way forward? >=20 > [Anoob] Indeed. Having a very well defined API interface for applications= is a very > positive change. I'm open to more ideas than just updating the documentat= ion. >=20 > Appreciate your feedback. >=20 >