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 C0327425EF; Wed, 20 Sep 2023 13:52:10 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5076B402A2; Wed, 20 Sep 2023 13:52:10 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by mails.dpdk.org (Postfix) with ESMTP id C53A34027B for ; Wed, 20 Sep 2023 13:52:08 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 38K9Fl5m028193; Wed, 20 Sep 2023 04:52:07 -0700 Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2108.outbound.protection.outlook.com [104.47.55.108]) by mx0b-0016f401.pphosted.com (PPS) with ESMTPS id 3t7htatu1e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Sep 2023 04:52:07 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FrhLjnhFwHyvjx7LPiOXvjMktDk+OplyOwK0bJUWztmDTxtjYBJFM8do7wkUwOqdvhM71u/eYXuDpl7AShmHepFqKkl37bJVm6gT/80wbsAgmkXJ/F5adAWxgGhyTC5vTNPf8eK6wiI5bdPCV+9rBGqE9qr75+xIfBFRDXBCN8+Bq9r806a4fhKAm2OX9HNZmfBVMOpzhmPG44C+9xTJ5uySDZI7DTH7lYeLyCwjoDY1BoWpCVBbEM6Qbemtg/QLfdjfDacxMzXZVp1rprmcr0kABQ51jox+iWjcxI//sQzy06Fxz2c8q4khCSme1TQBVyhwg5toBbeWiIGubcEpVQ== 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=h2iyI384PWh0WU+JsaZZwe1+t9srlBYVivdXoNqHVXI=; b=nYSs9mcKuYYzi/pNeCb9HbcgX/0tjPI6+Crtpoe1OD0o2XtAq85LoyCRdl9K05uMvfZKO8cibxjtJcVGHqciiXp8wktJFTU+/YAiH7k3oGlxImLDRM/kB4qKqH8th+Gjc0yPQwBatJMCQ8rDKv8bJ0geKTQcYD8bfxLq+VEQ5xgMPPCwy/Y9n+WZdmQh4pkbcaTSmDE5VFvbUE9C63bGpfw47zsAmR5gogp/UDNe2/Xq2pM9GA1mdzs0FCEZ+t/QZTdCOC2xbS6pClqqzUJnVyk7HzrtxglKAPqY20h6fXzqA4OScJ2gLycjJbHvsFMVZIJ9ms4Wql4lJd1WcDDnlg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h2iyI384PWh0WU+JsaZZwe1+t9srlBYVivdXoNqHVXI=; b=qQZ8jmSEjkeR7sfqQskPh0UIY5pZsY31JG1Oi+gQngoK/s7LidQbag6lxq2frHt/d9MeGoY619Lbsd341HMH63SkvpxSpzI0ZJ2pJyX3uJNkRfP51UEVAYJveSMUVTisQrhRqDzV/aL/pDOEEokyyCJTZwTf33v0tvjrxddQccI= Received: from PH0PR18MB4672.namprd18.prod.outlook.com (2603:10b6:510:c9::16) by PH7PR18MB5032.namprd18.prod.outlook.com (2603:10b6:510:15e::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.27; Wed, 20 Sep 2023 11:51:55 +0000 Received: from PH0PR18MB4672.namprd18.prod.outlook.com ([fe80::cd84:2ed1:5222:7527]) by PH0PR18MB4672.namprd18.prod.outlook.com ([fe80::cd84:2ed1:5222:7527%6]) with mapi id 15.20.6792.026; Wed, 20 Sep 2023 11:51:54 +0000 From: Anoob Joseph 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 Thread-Topic: [RFC PATCH 2/3] security: add TLS record processing Thread-Index: AQHZ66QdZuZNVqm6c0mtvwyxk/2qYbAjke7g Date: Wed, 20 Sep 2023 11:51:54 +0000 Message-ID: References: <20230811071712.240-1-anoobj@marvell.com> <20230811071712.240-3-anoobj@marvell.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-rorf: true x-dg-ref: =?us-ascii?Q?PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNcYW5vb2JqXGFw?= =?us-ascii?Q?cGRhdGFccm9hbWluZ1wwOWQ4NDliNi0zMmQzLTRhNDAtODVlZS02Yjg0YmEy?= =?us-ascii?Q?OWUzNWJcbXNnc1xtc2ctMTUzZWYwOTQtNTdhYy0xMWVlLTljNjYtNGMwMzRm?= =?us-ascii?Q?NWY5YjRmXGFtZS10ZXN0XDE1M2VmMDk1LTU3YWMtMTFlZS05YzY2LTRjMDM0?= =?us-ascii?Q?ZjVmOWI0ZmJvZHkudHh0IiBzej0iMTUzNjIiIHQ9IjEzMzM5Njg0MzExMDc4?= =?us-ascii?Q?Mzg1MiIgaD0iSWppMzh2dWpyNHZYemVUQUhOdDFjenJNVFRNPSIgaWQ9IiIg?= =?us-ascii?Q?Ymw9IjAiIGJvPSIxIiBjaT0iY0FBQUFFUkhVMVJTUlVGTkNnVUFBTjRQQUFC?= =?us-ascii?Q?czI4Ylh1T3ZaQVRvaTJ4ZXorV0Z3T2lMYkY3UDVZWEFaQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUhBQUFBQnVEd0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUVBQVFFQkFBQUE5UmVuTHdDQUFRQUFBQUFBQUFBQUFKNEFBQUJoQUdRQVpB?= =?us-ascii?Q?QnlBR1VBY3dCekFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?RUFBQUFBQUFBQUFnQUFBQUFBbmdBQUFHTUFkUUJ6QUhRQWJ3QnRBRjhBY0FC?= =?us-ascii?Q?bEFISUFjd0J2QUc0QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQVFBQUFBQUFBQUFDQUFB?= =?us-ascii?Q?QUFBQ2VBQUFBWXdCMUFITUFkQUJ2QUcwQVh3QndBR2dBYndCdUFHVUFiZ0Ix?= =?us-ascii?Q?QUcwQVlnQmxBSElBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUJBQUFBQUFBQUFBSUFBQUFBQUo0QUFBQmpBSFVB?= =?us-ascii?Q?Y3dCMEFHOEFiUUJmQUhNQWN3QnVBRjhBWkFCaEFITUFhQUJmQUhZQU1BQXlB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= x-dg-refone: =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFFQUFBQUFBQUFBQWdBQUFBQUFuZ0FBQUdN?= =?us-ascii?Q?QWRRQnpBSFFBYndCdEFGOEFjd0J6QUc0QVh3QnJBR1VBZVFCM0FHOEFjZ0Jr?= =?us-ascii?Q?QUhNQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBUUFBQUFBQUFBQUNBQUFBQUFDZUFBQUFZd0IxQUhNQWRBQnZBRzBB?= =?us-ascii?Q?WHdCekFITUFiZ0JmQUc0QWJ3QmtBR1VBYkFCcEFHMEFhUUIwQUdVQWNnQmZB?= =?us-ascii?Q?SFlBTUFBeUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQkFBQUFBQUFB?= =?us-ascii?Q?QUFJQUFBQUFBSjRBQUFCakFIVUFjd0IwQUc4QWJRQmZBSE1BY3dCdUFGOEFj?= =?us-ascii?Q?d0J3QUdFQVl3QmxBRjhBZGdBd0FESUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUVBQUFBQUFBQUFBZ0FBQUFBQW5nQUFB?= =?us-ascii?Q?R1FBYkFCd0FGOEFjd0JyQUhrQWNBQmxBRjhBWXdCb0FHRUFkQUJmQUcwQVpR?= =?us-ascii?Q?QnpBSE1BWVFCbkFHVUFYd0IyQURBQU1nQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFRQUFBQUFBQUFBQ0FBQUFBQUNlQUFBQVpBQnNBSEFBWHdCekFH?= =?us-ascii?Q?d0FZUUJqQUdzQVh3QmpBR2dBWVFCMEFGOEFiUUJsQUhNQWN3QmhBR2NBWlFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= x-dg-reftwo: =?us-ascii?Q?QUFBQUFBQUFBQUFCQUFBQUFBQUFBQUlBQUFBQUFKNEFBQUJrQUd3QWNBQmZB?= =?us-ascii?Q?SFFBWlFCaEFHMEFjd0JmQUc4QWJnQmxBR1FBY2dCcEFIWUFaUUJmQUdZQWFR?= =?us-ascii?Q?QnNBR1VBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBRUFB?= =?us-ascii?Q?QUFBQUFBQUFnQUFBQUFBbmdBQUFHVUFiUUJoQUdrQWJBQmZBR0VBWkFCa0FI?= =?us-ascii?Q?SUFaUUJ6QUhNQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFGZ0FBQUFBQUFBQUFBQUFBQVFBQUFBQUFBQUFDQUFBQUFB?= =?us-ascii?Q?Q2VBQUFBYlFCaEFISUFkZ0JsQUd3QVh3QndBSElBYndCcUFHVUFZd0IwQUY4?= =?us-ascii?Q?QWJnQmhBRzBBWlFCekFGOEFZd0J2QUc0QVpnQnBBR1FBWlFCdUFIUUFhUUJo?= =?us-ascii?Q?QUd3QVh3QmhBR3dBYndCdUFHVUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUJBQUFBQUFBQUFBSUFBQUFBQUo0QUFBQnRBR0VBY2dC?= =?us-ascii?Q?MkFHVUFiQUJmQUhBQWNnQnZBR29BWlFCakFIUUFYd0J1QUdFQWJRQmxBSE1B?= =?us-ascii?Q?WHdCeUFHVUFjd0IwQUhJQWFRQmpBSFFBWlFCa0FGOEFZUUJzQUc4QWJnQmxB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFF?= =?us-ascii?Q?QUFBQUFBQUFBQWdBQUFBQUFuZ0FBQUcwQVlRQnlBSFlBWlFCc0FGOEFjQUJ5?= =?us-ascii?Q?QUc4QWFnQmxBR01BZEFCZkFHNEFZUUJ0QUdVQWN3QmZBSElBWlFCekFIUUFj?= =?us-ascii?Q?Z0JwQUdNQWRBQmxBR1FBWHdCb0FHVUFlQUJqQUc4QVpBQmxBSE1BQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBUUFBQUFBQUFBQUNBQUFB?= =?us-ascii?Q?QUFDZUFBQUFiUUJoQUhJQWRnQmxBR3dBYkFCZkFHRUFjZ0J0QUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= x-dg-refthree: =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQkFBQUFBQUFBQUFJ?= =?us-ascii?Q?QUFBQUFBSjRBQUFCdEFHRUFjZ0IyQUdVQWJBQnNBRjhBWndCdkFHOEFad0Jz?= =?us-ascii?Q?QUdVQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUVBQUFBQUFBQUFBZ0FBQUFBQW5nQUFBRzBB?= =?us-ascii?Q?WVFCeUFIWUFaUUJzQUd3QVh3QndBSElBYndCcUFHVUFZd0IwQUY4QVl3QnZB?= =?us-ascii?Q?R1FBWlFCekFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFRQUFBQUFBQUFBQ0FBQUFBQUNlQUFBQWJRQmhBSElBZGdCbEFHd0Fi?= =?us-ascii?Q?QUJmQUhBQWNnQnZBR29BWlFCakFIUUFYd0JqQUc4QVpBQmxBSE1BWHdCa0FH?= =?us-ascii?Q?a0FZd0IwQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFCQUFBQUFBQUFB?= =?us-ascii?Q?QUlBQUFBQUFKNEFBQUJ0QUdFQWNnQjJBR1VBYkFCc0FGOEFjQUJ5QUc4QWFn?= =?us-ascii?Q?QmxBR01BZEFCZkFHNEFZUUJ0QUdVQWN3QmZBR01BYndCdUFHWUFhUUJrQUdV?= =?us-ascii?Q?QWJnQjBBR2tBWVFCc0FGOEFiUUJoQUhJQWRnQmxBR3dBYkFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBRUFBQUFBQUFBQUFnQUFBQUFBbmdBQUFH?= =?us-ascii?Q?MEFZUUJ5QUhZQVpRQnNBR3dBWHdCd0FISUFid0JxQUdVQVl3QjBBRjhBYmdC?= =?us-ascii?Q?aEFHMEFaUUJ6QUY4QVl3QnZBRzRBWmdCcEFHUUFaUUJ1QUhRQWFRQmhBR3dB?= =?us-ascii?Q?WHdCdEFHRUFjZ0IyQUdVQWJBQnNBRjhBYndCeUFGOEFZUUJ5QUcwQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= x-dg-reffour: =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQVFBQUFBQUFBQUFDQUFBQUFBQ2VB?= =?us-ascii?Q?QUFBYlFCaEFISUFkZ0JsQUd3QWJBQmZBSEFBY2dCdkFHb0FaUUJqQUhRQVh3?= =?us-ascii?Q?QnVBR0VBYlFCbEFITUFYd0JqQUc4QWJnQm1BR2tBWkFCbEFHNEFkQUJwQUdF?= =?us-ascii?Q?QWJBQmZBRzBBWVFCeUFIWUFaUUJzQUd3QVh3QnZBSElBWHdCbkFHOEFid0Ju?= =?us-ascii?Q?QUd3QVpRQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUJBQUFBQUFBQUFBSUFBQUFBQUo0QUFBQnRBR0VBY2dCMkFH?= =?us-ascii?Q?VUFiQUJzQUY4QWNBQnlBRzhBYWdCbEFHTUFkQUJmQUc0QVlRQnRBR1VBY3dC?= =?us-ascii?Q?ZkFISUFaUUJ6QUhRQWNnQnBBR01BZEFCbEFHUUFYd0J0QUdFQWNnQjJBR1VB?= =?us-ascii?Q?YkFCc0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFFQUFB?= =?us-ascii?Q?QUFBQUFBQWdBQUFBQUFuZ0FBQUcwQVlRQnlBSFlBWlFCc0FHd0FYd0J3QUhJ?= =?us-ascii?Q?QWJ3QnFBR1VBWXdCMEFGOEFiZ0JoQUcwQVpRQnpBRjhBY2dCbEFITUFkQUJ5?= =?us-ascii?Q?QUdrQVl3QjBBR1VBWkFCZkFHMEFZUUJ5QUhZQVpRQnNBR3dBWHdCdkFISUFY?= =?us-ascii?Q?d0JoQUhJQWJRQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBUUFBQUFBQUFBQUNBQUFBQUFD?= =?us-ascii?Q?ZUFBQUFiUUJoQUhJQWRnQmxBR3dBYkFCZkFIUUFaUUJ5QUcwQWFRQnVBSFVB?= =?us-ascii?Q?Y3dBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQkFBQUFBQUFBQUFJQUFBQUFBSjRBQUFCdEFHRUFjZ0Iy?= =?us-ascii?Q?QUdVQWJBQnNBRjhBZHdCdkFISUFaQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUVB?= =?us-ascii?Q?QUFBQUFBQUFBZ0FBQUFBQSIvPjwvbWV0YT4=3D?= x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH0PR18MB4672:EE_|PH7PR18MB5032:EE_ x-ms-office365-filtering-correlation-id: c2d46759-eb59-4dcc-8dec-08dbb9cffc7b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Y9CFQtvZMICAao9wpErE/hdsW/52ajNiWU5gX+qH9XsVL+EPGIaWyOgu2PJlvG6YTLoqEH+X9gUMZIyd9S7s/GS+S+jgHKzlLJ6etLj2d3CFKcXB91gHEAx+mRWnt2QVRkIp8ueAa8jI9W6Qte+VswflAVO/2azYGstYp3FfhzFOd8tjHaQcxnGifkxtIcXXP/t1ebwqlQCNzZmRqGoCiGcv3tnnGLU2AAzRe+qzgJTSqdNhSgle853omyJTJ2WWbJvZqXVdixtF4DR81ibCHhrAu0/Kj7lTbi7tN4Fm4C8B0c+8fp7/G2Ccwshl5JEMo3T4IwsNKZM9gF+J+R9RbPNHVmCDvMmA9uKj7l2Td3RlS9I0u6/8t9CVwVy4d9MNIWTUXrzfPQRTmCC4v8CQR2MPr5j5strIF26wbGzqQJvMD4vecIhA16pySxIGRD9hKrk85hpoJcsNKE4hEnzHYr0qyNYR1GB8Zh0O/RXSVGr2EDN/r7oOdOCPJsvXahci9g6sFgPXpXt+tGp8hGTfbHOOHCwC/6DNrW5QY7APOr3nhnn3CJ7E1wZxOasXUZe+Lh0+MzNBvqVK3DKIyVNcF9OJ1dQyH7CzkX8Bm+7LdX0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR18MB4672.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(136003)(376002)(39860400002)(346002)(396003)(366004)(451199024)(1800799009)(186009)(30864003)(71200400001)(478600001)(15650500001)(8936002)(66446008)(66556008)(316002)(966005)(6916009)(41300700001)(55016003)(83380400001)(5660300002)(2906002)(66946007)(4326008)(64756008)(54906003)(52536014)(66476007)(76116006)(8676002)(6506007)(7696005)(53546011)(9686003)(66899024)(26005)(66574015)(122000001)(33656002)(38100700002)(38070700005)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?7l+G+bWpSmM2i1mi2x5aiIeq7C11z5gwTyfcIwVmuGofOkgUDqL+upuw/i8a?= =?us-ascii?Q?Z3AMtPWCa2Ihd/RP73qFMEVj4jtMlh+r7rPDx5wzep0heXYLZ7/YTeRatMwW?= =?us-ascii?Q?rPqFv6Cy3GDoaZ59rL/9MvNKa6vRU0CU7Q0KXpPxS2dYgKFM7LS5+7PEgms0?= =?us-ascii?Q?OiKrRi+6NPNOdRbpWezkhEvjN5u5DcudnSsks2Fn0ApZf/ES+nm1AhYNEBQj?= =?us-ascii?Q?jaJuutfEvk8Tt2y9DnCN/zkB1PESIE/iE2+/8sKXM1BQOPdrWjmz5KbxXQN7?= =?us-ascii?Q?cTQr0VyaHjTlFxKr6Xkzp0GYS1uR2GLMdpm4wrl2IxmtrRZcGWptcG0acJ2M?= =?us-ascii?Q?T/qw21diqQwfBtTwKfUXsx1z+WzW0VWlzmRa76welt2Aqkh4xgYUV9eX+q36?= =?us-ascii?Q?J1NGnJEydqN4wXpKR7INLT105UTmourOetAxm2hhOusEtD9NGxnmXo8h54yg?= =?us-ascii?Q?pqSg+nK8Apa9rw/QbPvHFC4WQzZVAu5+RreHzg5TIY0O0hQsgzFXZvXiMe8k?= =?us-ascii?Q?WMzt7+1J6d9kVgrEbVV0qbxUa9N+ZIyj9E+jrYUc2LKXhvryyk0NJ0g+E9VZ?= =?us-ascii?Q?6sK7YqCD7oos6k1rrqF0iZDO54i4iqPGlUFpu803zp6atzJHjumj5iKlwtvR?= =?us-ascii?Q?52MUzYff0cIpj90UtxYhJenTaMIa8PX9bSMd1phWwcZ316HhmxtZB50neUBp?= =?us-ascii?Q?PSJbFPSUxnEKA7ml6MG3wA+f3HGQAzLNLO1izzL9m+0OST3OhLQl+bzRQvcP?= =?us-ascii?Q?ytSBrr7dyhGb71H1ETjfDqFfGjtAJjKBlwuUVVjNkyCtIy25jA1ziR6j9wbi?= =?us-ascii?Q?ZeBGCGxS4K6w1rHlIlDI32e8NdLx3rvugyzF/skTtQRB/PX42fWQpTZihPHY?= =?us-ascii?Q?Wex8FYX11tGngwLqhXGZhJAd73ltLfSUuSEHrlYV36VVQqsrje8qZ3eCzzab?= =?us-ascii?Q?0V6U2lff+tuUFxAqBxasZ5EL8tkRhjweeRmFZg7zmiumVTlRHzNav5c9YpOC?= =?us-ascii?Q?vO2MlK75b9stB3oQYdhoz6960swg41qIdeTr/p8B0SeLAWPfwnn8I6gDlp86?= =?us-ascii?Q?Gb2VE9KP9CCWAcP1qBcIH434mgepfLexaxaDCRbX/fBu6ck+wXtFwD3gaXxS?= =?us-ascii?Q?96hazEoyL3TKzPRq/YfGVRkIOlXzMjRbqMWz6WIYgQ4nqhZy5/92Tzz/B+a3?= =?us-ascii?Q?Wy3osYPrLabNuW79XnIX+a64puLMfQZHRsYjuAQ4VElhbDBtFo0RAGE8AAlI?= =?us-ascii?Q?pKQccktM7Far9Ni9DXsIb24PeoUsTEvP/E3K9O3oLnqyn6rJpIOCwIhwbwXO?= =?us-ascii?Q?k0IwSnwogihnJwW9A9obosSQ3ZMGVZU3EAdriXruoPrrlie1lOqsEZgs4nA0?= =?us-ascii?Q?RVH6wUoDRAsSbTfNNw9aMiKgxtU9g1HVSqoKd9LAf2ea9roVHHudK9JDkTNv?= =?us-ascii?Q?gQMWW/xLmBbRIW+KD6HsieT8tMMkbAQmxwhTpq2Zz9E7s7AnjF/gE9T6L2nn?= =?us-ascii?Q?7xdvfKSLLUfy8gwoiEkQEznUUJgWSgwuFrYtXanilqKIq57DiO2jJNsNyTrF?= =?us-ascii?Q?vvLfbyFKyWPXFwK5B8g=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: marvell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR18MB4672.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c2d46759-eb59-4dcc-8dec-08dbb9cffc7b X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2023 11:51:54.7880 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WBWXMY0255kvj9UTJa54xYAn2YJ70u1pBPkVchNtoE8Wq4xldW3oeofJPjkiMmRgAywWAOQax+NyWBLJoQL/BQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR18MB5032 X-Proofpoint-ORIG-GUID: vH0-GuLhNHCOg63Nf-YAPqi8CiKmfHs0 X-Proofpoint-GUID: vH0-GuLhNHCOg63Nf-YAPqi8CiKmfHs0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.601,FMLib:17.11.176.26 definitions=2023-09-20_05,2023-09-20_01,2023-05-22_02 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 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 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 >=20 > External Email >=20 > ---------------------------------------------------------------------- > > -----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 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. >=20 > 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. >=20 > 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. >=20 >=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(+) > > > > 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 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 d= ata > > + encryption (e.g., AES, DES, etc.). The keys for this symmetric > encryption > > + are generated uniquely for each connection and are based on a se= cret > > + negotiated by another protocol (such as the TLS Handshake Protoc= ol). > The > > + Record Protocol can also be used without encryption. > > + > > + - The connection is reliable. Message transport includes a messag= e > > + 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 mo= de > > + while another protocol is using the Record Protocol as a transpo= rt > > + for negotiating security parameters. > > + > > +.. code-block:: c >=20 > The code block below isn't C? Is there a better code block type for a tex= t > diagram? [Anoob] Valid point. I was just following the general scheme followed in th= is file. May be, I'll introduce a .svg image for newly added code. >=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 the TLS > > + record > > session is approaching > > + * hard limits for lifetime. This would result in a warning returned > > + in > > ``rte_crypto_op.aux_flags``. >=20 > 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 t= o the > appropriate part of the crypto_op.aux_flags documentation to help the use= r. >=20 [Anoob] The concept of lifetime is present in most protocols. Idea is to li= mit the max number of operations performed with a session. Soft expiry noti= fication is to help application prepare for an expiry and setup a new sessi= on before the current one expires. The idea was borrowed from IPsec which h= as the 'RTE_CRYPTO_OP_AUX_FLAGS_IPSEC_SOFT_EXPIRY' flag defined. But I rea= lize, 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#L6= 7 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. > > + */ > > +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 securi= ty > 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 >=20 > Replace "would be" with "must be"? And who must do this step, is it the > application? [Anoob] Padding is performed by the PMD/cryptodev device. I'll change "woul= d be" to "will be". Would that address your concern? >=20 > > + * 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; >=20 > Do we see TLS handshake xform being added in future? If so, is 'tls' a go= od > name, perhaps 'tls_record'? > That would allow 'tls_handshake' in future, with consistent naming scheme > without API/ABI break. [Anoob] In the future, I would like to see TLS handshake also offloaded in = a similar manner. But that would need some fundamental changes in security = library. Like, current security library is pretty much tied to symmetric op= erations but a handshake would involve both symmetric & asymmetric operatio= ns. Said that, I agree with your suggestion to rename the field. Will change it= to 'tls_record' in next version. >=20 >=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; >=20 > Missing /**< TLS Record Capability */ docstring here. [Anoob] Agreed. Will add in next version. >=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; > > }; > > }; > > > > -- > > 2.25.1