From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0085.outbound.protection.outlook.com [104.47.32.85]) by dpdk.org (Postfix) with ESMTP id A1DE11AEF5 for ; Wed, 20 Sep 2017 12:59:41 +0200 (CEST) Received: from BN3PR03CA0057.namprd03.prod.outlook.com (10.167.1.145) by DM5SPR00MB235.namprd03.prod.outlook.com (10.173.215.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 20 Sep 2017 10:59:39 +0000 Received: from BY2FFO11FD044.protection.gbl (2a01:111:f400:7c0c::118) by BN3PR03CA0057.outlook.office365.com (2a01:111:e400:7a4d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10 via Frontend Transport; Wed, 20 Sep 2017 10:59:39 +0000 Received-SPF: Fail (protection.outlook.com: domain of nxp.com does not designate 192.88.168.50 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.168.50; helo=tx30smr01.am.freescale.net; Received: from tx30smr01.am.freescale.net (192.88.168.50) by BY2FFO11FD044.mail.protection.outlook.com (10.1.14.229) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.20.35.14 via Frontend Transport; Wed, 20 Sep 2017 10:59:38 +0000 Received: from [10.232.134.49] (B35197-11.ap.freescale.net [10.232.134.49]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id v8KAxXUI004659; Wed, 20 Sep 2017 03:59:33 -0700 To: Jerin Jacob CC: , , , , , , , , References: <20170914082651.26232-1-akhil.goyal@nxp.com> <20170914082651.26232-3-akhil.goyal@nxp.com> <20170918111338.GA16299@jerin> From: Akhil Goyal Message-ID: <12f5910e-5253-be9f-72d4-64b43e435fa9@nxp.com> Date: Wed, 20 Sep 2017 16:29:32 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170918111338.GA16299@jerin> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131503787790768683; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.168.50; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(336005)(7966004)(39380400002)(346002)(376002)(39860400002)(2980300002)(1109001)(1110001)(339900001)(377454003)(13464003)(189002)(24454002)(199003)(81156014)(15650500001)(81166006)(106466001)(8676002)(498600001)(105606002)(230700001)(31686004)(8656003)(33646002)(8936002)(356003)(305945005)(229853002)(36756003)(64126003)(31696002)(6246003)(4326008)(53936002)(50466002)(68736007)(86362001)(7416002)(316002)(65806001)(5660300001)(2906002)(77096006)(189998001)(23676002)(65826007)(65956001)(83506001)(54356999)(54906003)(76176999)(97736004)(53546010)(50986999)(104016004)(58126008)(5890100001)(2950100002)(6916009)(47776003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5SPR00MB235; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD044; 1:+4m2agoCH09lY0NcUGDD9trgqtmK375H4LYNoYCCUSiIe0o+bl0jF5nuBgWhFt3DEpbf5WeCyz20OpCdJKdHk/QxqqO86skcosFcRH3kKiNE1qYIW111Q1sBFyjY/8bo X-MS-Office365-Filtering-Correlation-Id: a1281caf-030e-42b1-0f23-08d50016b047 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(2017052603199)(201703131430075)(201703131517081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5SPR00MB235; X-Microsoft-Exchange-Diagnostics: 1; DM5SPR00MB235; 3:hZn4ytDduMeqkMW6hRj31S3XfJDf2XN99O5bPOCkeRJcCChYf932O9Whej78SfV7lCsSyESuZTuZkRSH9OpqzZH/W7IBg82/qxUqE26oUkBlMFaQGOVlF64zQPQcOFSlBMJQsdgW3s83DA0HIpjyor6ySp34K4BBu7YsqyWuPysmi9kvYoCxLyEaoQfDbC/H61Mb52xrlzlVsSiUISesZnYt8DT/KiyEAPozPe4JopC4qZzr/0FV3VRch9V2Qr4CCnlkxjBbaAAMVkyV654krrMByQbAli1gouGcSPAsfcRHmat1gg33LZQtOBoDiafg8GC67NrdLX6tmQoBuuRHcHB95qPpvRHuoqF5NnAdEsM=; 25:gq5KvWlB5efPcy7XgPWMccPE+JnQ2xVYkrDwqrK3Ai241GwucmZiPF7RAnRQ8Iu6t13vj/KcJ7iHq89fKJvuiCK8oDz9tOMuHIBmy/6q4qA/wSlj2ZcqWlxUk1GjYcEof3XbZb/6mQyuOU0D5SODiKWU0o1PxKM+nkm/RTKJVAvnq/yzXVSzL/IPX3P71S5qC+u7hiFOZtzEFcoM3WHOWiuqzAdmvSo+NQxSyyyd5i90iZrR4xCJH/Yddtu3GX9ttVPkgZ/2ynnqAeF6C2OnucaSQy6hRvKGiSfGuYkeCdvM4+C/TjpPen35Lq4smc8U6A++2lYDwXRvEkRJPUc/kA== X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM5SPR00MB235: X-Microsoft-Exchange-Diagnostics: 1; DM5SPR00MB235; 31:d9JiN+c02fnNOJpT25AcLLh3RJFCfu8ZWlPmcQoPb57ENPjH+/PK088HzDvjKu/G7mb0obOkjuR+6Ehn/7ZAJQOhx12p/apIqZmBt180C3JBT/K1vGMoTf2GpW1r/px9hbDZv9azizwnRW/SYpWCLlm9eWr742uq1t2bgihsyy0rAMimVMeMuRddJzWnK0oi1ougU7RQfIhH81oDMkyv5tpRbnjR6PPytCu84u8xB/4=; 4:QSmNa4X+nrBdW3G+h4XwwHAJuoVzU8Swo2FtlToOB9WMnamhfUjWK059pBtj42oMi57uhe6GGEFmEVJEfm8luv+UVCdjL4Zu/50I0gmlIbD+J8niywMzVpMBUxtclN0d3saQ6ClL+tNr8U9nLMNTHt9ldlRO/KIdIETvu2OlkwFE38T2Oaoa3LWH88GsrxOL4kcxR/LxU69PH2vd7qVEAHBbKxXw+FGStEemo8S065YdpSuJFXdDV3x46Dao2Yy29loTthE5sT7jXL+inVIhOnLsaV/RZ/EECeGAP74uPALEB2OjLn/YgOiRPa6Mm1GY5+3nW5F/MbKvbcYx642JOzdZT4EdkaVVw+JbhYEYQ8U= X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(185117386973197)(228905959029699); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6095135)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6096035)(20161123565025)(201703131430075)(201703131433075)(201703131441075)(201703131448075)(201703161259150)(20161123559100)(20161123563025)(20161123556025)(20161123561025)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5SPR00MB235; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(400006)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5SPR00MB235; X-Forefront-PRVS: 04362AC73B X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVTUFIwME1CMjM1OzIzOm5XYVdvbFZOWjk5OEg4ZlplZ3lBbysweG5I?= =?utf-8?B?VDNqa3lLMjZ5TmhLTk8zNXZqMDY0WDZIek1wNllJV3RTWDNtcDdTQ25xKzQx?= =?utf-8?B?WmxZNklTdE5BaDBBS1g2c3BxWmZGUzdRM2xiZmU2SzZ5YkxpUEVLMFZ6c20y?= =?utf-8?B?SG5Ca0Q2c2pCV3dLeFhpaG42ODFBSml6UzNJWk8zb2MyZk96QnQ3c2Raa1ZE?= =?utf-8?B?ZzlDYys3MkdnSE1WdGFNQjg4bnE1SFVNZnR1THdNTDlTQ0l6enE5MFBPaTJ5?= =?utf-8?B?MjBsY2J0U2xPQzlodXIvM2ZTcFJrL3Y1L0VoaFhKS1oxQ3RkOXdjV1JjZHdW?= =?utf-8?B?cldBa3Q1a0JSa21aNEVYTEw0b0xjZEFXVkRGZ0RUaDk5V2lnUmNGdWlSRmFT?= =?utf-8?B?c0RsUTFDbVpCa1dIQzhiUFVWdW80dUJKS0ZCcmxld1dwK01LNjRBVjMwNXFw?= =?utf-8?B?QkowTWVoMmxsd0ZRQU5TekJOenAwK3M3elQybFZFZ3BCa29LdGphcmMwdnBQ?= =?utf-8?B?Ym1qdHBvUWtsNDdaYWdiWm9GVENhcDhnQVJubmNaWktUQlkya2pHTURHTnhC?= =?utf-8?B?MGk3cm5vRGJiMjVLU1JRYWw0UVIyeWpoQUZ3ZU0yb3pnNkkxSjkydjBHZlcv?= =?utf-8?B?WDdLWWNRN0cxZlFXbDc3QkpBZlR3WnQ1dmZBc2FjaS9yNTUrOFkwbDhIZVRT?= =?utf-8?B?VWlDL1Q4WHBESmtSVzFmVkxRdGlMQkNOK3ZyaWl1cG9sS3h5bUJCVUVGTi90?= =?utf-8?B?SFdqVlFIczdqUzRZV0I0U0RTdDdxem5nTTdwTmxNU1dNNTZFQ1B2RzkzSUhn?= =?utf-8?B?UDZIVCttQnlQTkRyVjUvMXJhNDlKVUtaZ2dXTTJFVGRpdW9IQkE3Q1IvRjN3?= =?utf-8?B?WE11LzNuQ3FiNE1Ja3QzUGNqdGtDcklLazZlbUQzRzk3Z01LeklnWDMrN29R?= =?utf-8?B?RzZocjB6QU1PaUFybkRjY3NCbUw3RkQra3NQczFHQkNMMGFEbVVReVQ4ZXlF?= =?utf-8?B?WmpmZ2RTQXdTa1JGQW04anI1TDZZV0lDTHE0VWg2RVhubmtidzREL2VXcnVo?= =?utf-8?B?RENRb2c0aDVsdnFFVlV1WUpkSVdCMWF5M3Ewbm05VnVzUWVaakRwSkRPRGZC?= =?utf-8?B?ZHd3cW1LNncwK2tSQTZGQzVKN3hXSnR5RmEvMWJVYXNSM3dJZkpTdUsxcTV4?= =?utf-8?B?MzlzemN1Y3V6bXZhYytlRHhtZWtJYXc5ZnFUMnlMTTU3ekU0Yk42ZzFEaXJr?= =?utf-8?B?UzA0ZE9BZVlITmZML3VsSENEZm56SWJTSDJOZFR2dGJMNnVpTW9hQjFMekFj?= =?utf-8?B?d1U3bUR0VDh3S0RpSEI3Q05TRXFOOEhrN2VVUUhrZVJtN2lOU1lGTlZySytO?= =?utf-8?B?NEZ0WVlHTktWVXRMN095RldOWk1NcTlZNnBvYlJVb3lKMUoweElVZWtaMFIr?= =?utf-8?B?TldVZ093N1JHV251ZnpYVHhncmtYdnRXQ2xiU042ZmdtZjFmNm9YeGRkbzZM?= =?utf-8?B?eGd3cXpHY05tc2VxNmduWGVqMjZCRTBkS1dQQkNOZHZOYUMxalZZQzhGS0Jm?= =?utf-8?B?R3VmWVFJc05zODhJWUsyY21aZEVSUCtCMkZpTlVuSi9pR2JlNWxwUTZnbEtk?= =?utf-8?B?ZXRwYWpEYzAwVys0NHhwOS9GWjhiVFNOOEdNdXdZRkVoVXhEMTdPRjdyY3N0?= =?utf-8?B?WElLZjA5S2tsSEVnbVVCUERvN0ljMjN4WkNrdno5YTM1VStQSlR3ektidUNM?= =?utf-8?B?SkpGQi9VT085MlRzTFVpcEJtVytiTzFSVEcvazUxU1hsaC9YZEs1cVhXS28r?= =?utf-8?B?N1EyTTVKbU1abnVidWxIdmJhUVRkdG02VEY3dnRWc1BQaitNaFIyZWxPblBi?= =?utf-8?B?REZZSXhlK3M2RWVxRWM3dHhqdkZxTS9mL2p2R21wRDJ3MTNtRklxT1FOck5l?= =?utf-8?B?RXVnMzdIUXBpRHpQNXNxUUJTNFh5NXVZcXA3VUNvUndGR2xCVmVpL1d5MHVz?= =?utf-8?Q?W4kwsR?= X-Microsoft-Exchange-Diagnostics: 1; DM5SPR00MB235; 6:6IzWXcuBgOjpvOpbYwQJoyDzfBW8ylkZNpP17pbN/Eh7XYykJc6WhIuRL2CaFdTme43cWcftEZ5J4aBnWKUwS9XbVge4tKJV9kdxTiBEtYYoezbnKWvY/Pdq2Cj4y3NothG3beMebxGfPE8Eh8krv3KpOUCVHDz/PwSm4TsaQj5RFw7xaMkIzFYayySokF50LAayyw6Gjm069W4kGgH1omAAaOSibd3IkEMs+ZI3lkOyyj0qVENFvsJ1jOeV9sZSyzraxZJp9YOIG9//LB3xl7sLVjOuKCID4szha5IyiLTg04ypuozt12Uu//zDcOspWY5Fgay5ehMjnyPdVXw2tw==; 5:6+DJOikaJqdWXp93I+VrHK+FX4f4cXfXITLmMxcOpT7EgrzCSj7HcrPwkbjvOLUaEiKGRknKNy6D7AfEN53+hi62YPGycEQsVtBvY55qzhAyPJDfCpDwKA8vcCMNG3/WF6TPzX4ocMMcVa0AEk9aKg==; 24:AQxEnIQGx6ZUK4rxd0/1mtcHjdzR6RS7eWvjzazxdxcd8LwjQjC+Y6W0ooUmBDuHdJnLB6ZT9YFeJo2igemD6j4wibbz5ccwNzwIeXPxCKU=; 7:Slf8wst+xibhThiRIV5lQYtoOQv35aiF4dPiLXOwZ7Nmdx4SYP50fTkhujR9+I3RySDZU4+yv3NzR6zoRKlwHgITuTwDqxGJMPgaVWwBa75i6s47l+7FcnFwFDFSh/l/vj0aJlb/PVVMqPc4+Jv8DbHHkUj1ly2maOl9GsUplP9RV7NgIvwfb5Ogo6YWrJhBku0FDp0n7gK8HEbd6cVEb0FYE9pyGUqI5KuxAevZUI4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2017 10:59:38.6244 (UTC) X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[192.88.168.50]; Helo=[tx30smr01.am.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5SPR00MB235 Subject: Re: [dpdk-dev] [PATCH 02/11] doc: add details of rte security X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 10:59:42 -0000 Hi Jerin, On 9/18/2017 4:43 PM, Jerin Jacob wrote: > -----Original Message----- >> Date: Thu, 14 Sep 2017 13:56:42 +0530 >> From: Akhil Goyal >> To: dev@dpdk.org >> CC: declan.doherty@intel.com, pablo.de.lara.guarch@intel.com, >> hemant.agrawal@nxp.com, radu.nicolau@intel.com, borisp@mellanox.com, >> aviadye@mellanox.com, thomas@monjalon.net, sandeep.malik@nxp.com, >> jerin.jacob@caviumnetworks.com >> Subject: [PATCH 02/11] doc: add details of rte security >> X-Mailer: git-send-email 2.9.3 >> +Security Library >> +================ >> + >> +The security library provides a framework for management and provisioning >> +of security protocol operations offloaded to hardware based devices. The >> +library defines generic APIs to create and free security sessions which can >> +support complete protocol offload as well as inline crypto operation with >> +NIC or crypto devices. The framework currently only supports IPSEC protocol >> +and it's operations, other protocols will be added in future. >> + >> +Design Principles >> +----------------- >> + >> +The security library provides an additional offload capability to existing >> +crypto device and/or ethernet device. >> + >> +.. code-block:: console >> + >> + +---------------+ >> + | rte_security | >> + +---------------+ >> + \ / >> + +-----------+ +--------------+ >> + | NIC PMD | | CRYPTO PMD | >> + +-----------+ +--------------+ >> + >> +Following offload types can be supported: >> + >> +Inline Crypto >> +~~~~~~~~~~~~~ >> + >> +RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO: >> +The crypto processing for security protocol (e.g. IPSEC) is processed >> +inline during receive and transmission on NIC port. The flow based >> +security action should be configured on the port. >> + >> +Ingress Data path - The packet is decrypted in RX path and relevant >> +crypto status is set in rx descriptors. After the successful inline >> +crypto processing the packet is presented to host as a regular rx packet >> +but all security protocol related headers are still attached to the >> +packet. e.g. In case of IPSEC, the IPSEC tunnel headers (if any), >> +ESP/AH headers will remain in the packet but the received packet >> +contains the decrypted data where the encrypted data was when the packet >> +arrived. The driver rx path check the descriptos and and based on the > > s/descriptos/descriptors > >> +crypto status sets additional flags in the rte_mbuf.ol_flags field. >> + >> +.. note:: >> + >> + The underlying device may not support crypto processing all ingress packet >> + matching to a particular flow (e.g. fragmented packets), such packets will >> + be passed as encrypted packets. It is the responsibility of driver to > ^^^^^^^^^^^ > Do you mean application here instead of driver? > >> + process such encrypted packets using other crypto driver instance. >> + >> +Egress Data path - The software prepares the egress packet by adding >> +relevant security protocol headers in the packets. Only the data will not be >> +encryptoed by the software. The driver will accordingly configure the > > s/encryptoed/encrypted > >> +tx descriptors. The HW device will encrypt the data before sending the >> +the packet out. >> + >> +.. note:: >> + >> + The underlying device may support post encryption TSO. >> + >> +.. code-block:: console >> + >> + Egress Data Path >> + | >> + +--------|--------+ >> + | egress IPsec | >> + | | | >> + | +------V------+ | >> + | | SABD lookup | | >> + | +------|------+ | > > s/SABD/SADB > >> + | +------V------+ | >> + | | Tunnel | | <------ Add tunnel header to packet >> + | +------|------+ | >> + | +------V------+ | >> + | | ESP | | <------ Add ESP header without trailer to packet >> + | | | | <------ Mark packet to be offloaded, add trailer >> + | +------|------+ | meta-data to mbuf >> + +--------V--------+ >> + | >> + +--------V--------+ >> + | L2 Stack | >> + +--------|--------+ >> + | >> + +--------V--------+ >> + | | >> + | NIC PMD | <------ Set hw context for inline crypto offload >> + | | >> + +--------|--------+ >> + | >> + +--------|--------+ >> + | HW ACCELERATED | <------ Packet Encryption/Decryption and > > Only packet Encryption here. Right? > >> + | NIC | Authentication happens inline >> + | | >> + +--------|--------+ > ^^^ > I guess the "|" can be removed. > >> + >> + >> +Inline protocol offload >> +~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL: >> +The crypto and protocol processing for security protocol (e.g. IPSEC) >> +is processed inline during receive and transmission. The flow based >> +security action should be configured on the port. >> + >> +Ingress Data path - The packet is decrypted in RX path and relevant >> +crypto status is set in rx descriptors. After the successful inline >> +crypto processing the packet is presented to host as a regular rx packet >> +but all security protocol related headers optionally removed from the >> +packet. e.g. In case of IPSEC, the IPSEC tunnel headers (if any), >> +ESP/AH headers will be removed from the packet and the received packet >> +will contains the decrypted packet only. The driver rx path check the >> +descriptos and and based on the crypto status sets additional flags in > > s/descriptos/descriptors > >> +the rte_mbuf.ol_flags field. >> + >> +.. note:: >> + >> + The underlying device in this case is stateful.It is expected that >> + the device shall support crypto processing for all kind of packets matching >> + to a given flow, this includes fragemented packets (post reassembly). > > s/fragemented/fragmented > >> + e.g. In case of IPSEC the device may internally manage anti-replay etc. >> + It will provide configuration option for anti-replay behavior i.e. to drop >> + the packets or pass them to driver with err flags set in descriptor. >> + >> +Egress Data path - The software will send the unencryptoed packet > > s/unencryptoed/clear > >> +without any security protocol headers added to the packet.The driver >> +will configure the security index and requirement in the tx descriptors. >> +The HW device will do security processing on the packet that includes >> +adding the relevant protocol headers and encrypt the data before sending >> +the the packet out.The software should make sure that the buffer >> +has required header and tailer space for any protocol header addition. The >> +software may also do early fragmentation if the resulatant packet is expected >> +to cross MTU. >> + >> + >> +.. note:: >> + >> + The underlying device will manage state information required for egress >> + processing. e.g. In case of IPSEC, the seq number will be added to be the >> + packet, It shall provide indication when sequence number is about to >> + overflow. The underlying device may support post encryption TSO. >> + >> +.. code-block:: console >> + >> + Egress Data Path >> + | >> + +--------|--------+ >> + | egress IPsec | >> + | | | >> + | +------V------+ | >> + | | SABD lookup | | >> + | +------|------+ | > > s/SABD/SADB > >> + | +------V------+ | >> + | | Desc | | <------ Mark packet to be offloaded >> + | +------|------+ | >> + +--------V--------+ >> + | >> + +--------V--------+ >> + | L2 Stack | >> + +--------|--------+ >> + | >> + +--------V--------+ >> + | | >> + | NIC PMD | <------ Set hw context for inline crypto offload >> + | | >> + +--------|--------+ >> + | >> + +--------|--------+ >> + | HW ACCELERATED | <------ Add tunnel, ESP header etc header to >> + | NIC | packet.Packet Encryption/Decryption and > > Only packet Encryption here. Right? > >> + | | Authentication happens inline. >> + +--------|--------+ > > I guess the "|" can be removed. > > >> + >> + >> +Lookaside protocol offload >> +~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL: >> +This extend the librte_cryptodev to support the programming of IPsec >> +Security Association (SA) as part of crypto session creation including >> +the definition. In addition to standard crypto processing, as defined by >> +the cryptodev, the security protocol processing is also offloaded to the >> +crypto device. >> + >> +Decryption: The packet is sent to the crypto device for security >> +protocol processing. The device will decrypt the packet and it will also >> +optionally remove the additional security headers from the packet. >> +e.g. In case of IPSEC, the IPSEC tunnel headers (if any), ESP/AH headers >> +will be removed from the packet and the decrypted packet may contains >> +the decrypted packet only. >> + >> +.. note:: >> + >> + In case of IPSEC the device may internally manage anti-replay etc. >> + It will provide configuration option for anti-replay behavior i.e. to drop >> + the packets or pass them to driver with err flags set in descriptor. >> + >> +Encryption: The software will submit the packet to cryptodev as usual >> +to encryption, the HW device in this case will also add relevant >> +security protocol header along with encrypting the packet. The software >> +should make sure that the buffer has required header and tailer space > > head room and tail room > >> +for any protocol header addition. >> + >> +.. note:: >> + >> + In case of IPSEC, the seq number will be added to be the packet, >> + It shall provide indication when sequence number is about to >> + overflow. >> + >> +.. code-block:: console >> + >> + Egress Data Path >> + | >> + +--------|--------+ >> + | egress IPsec | >> + | | | >> + | +------V------+ | >> + | | SABD lookup | | <------ SA maps to cryptodev session >> + | +------|------+ | > > s/SABD/SADB > >> + | +------|------+ | >> + | | \--------------------\ >> + | | Crypto | | | <- Crypto processing through >> + | | /----------------\ | inline crypto PMD >> + | +------|------+ | | | >> + +--------V--------+ | | >> + | | | >> + +--------V--------+ | | create <-- SA is added to hw >> + | L2 Stack | | | inline using existing create >> + +--------|--------+ | | session sym session APIs >> + | | | | >> + +--------V--------+ +---|---|----V---+ >> + | | | \---/ | | <--- Add tunnel, ESP header etc >> + | NIC PMD | | INLINE | | header to packet.Packet >> + | | | CRYPTO PMD | | Encryption/Decryption and >> + +--------|--------+ +----------------+ Authentication happens >> + | inline. >> + +--------|--------+ >> + | NIC | >> + +--------|--------+ >> + V >> + >> +Device Features and Capabilities >> +--------------------------------- >> + >> +Device Capabilities For Security Operations >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +The device(crypto or ethernet) capabilities which support security operations, >> +are defined by the security action type, security protocol, protocol >> +capabilities and corresponding crypto capabilities for security. For the full >> +scope of the Security capability see the definition of the structure in the >> +*DPDK API Reference*. >> + >> +.. code-block:: c >> + >> + struct rte_security_capability; >> + >> +Each driver(crypto or ethernet) defines its own private array of capabilities >> +for the operations it supports. Below is an example of the capabilities for a >> +PMD which supports the IPSec protocol. >> + >> +.. code-block:: c >> + >> + static const struct rte_security_capability pmd_security_capabilities[] = { >> + { /* IPsec Lookaside Protocol offload ESP Transport Egress */ >> + .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, >> + .protocol = RTE_SECURITY_PROTOCOL_IPSEC, >> + .ipsec = { >> + .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP, >> + .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL, >> + .direction = RTE_SECURITY_IPSEC_SA_DIR_EGRESS, >> + .options = { 0 } >> + }, >> + .crypto_capabilities = pmd_capabilities >> + }, >> + { /* IPsec Lookaside Protocol offload ESP Tunnel Ingress */ >> + .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, >> + .protocol = RTE_SECURITY_PROTOCOL_IPSEC, >> + .ipsec = { >> + .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP, >> + .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL, >> + .direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS, >> + .options = { 0 } >> + }, >> + .crypto_capabilities = pmd_capabilities >> + }, >> + { >> + .action = RTE_SECURITY_ACTION_TYPE_NONE >> + } >> + }; >> + static const struct rte_cryptodev_capabilities pmd_capabilities[] = { >> + { /* SHA1 HMAC */ >> + .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, >> + .sym = { >> + .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH, >> + .auth = { >> + .algo = RTE_CRYPTO_AUTH_SHA1_HMAC, >> + .block_size = 64, >> + .key_size = { >> + .min = 64, >> + .max = 64, >> + .increment = 0 >> + }, >> + .digest_size = { >> + .min = 12, >> + .max = 12, >> + .increment = 0 >> + }, >> + .aad_size = { 0 }, >> + .iv_size = { 0 } >> + } >> + } >> + }, >> + { /* AES CBC */ >> + .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, >> + .sym = { >> + .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER, >> + .cipher = { >> + .algo = RTE_CRYPTO_CIPHER_AES_CBC, >> + .block_size = 16, >> + .key_size = { >> + .min = 16, >> + .max = 32, >> + .increment = 8 >> + }, >> + .iv_size = { >> + .min = 16, >> + .max = 16, >> + .increment = 0 >> + } >> + } >> + } >> + } >> + } >> + >> + >> +Capabilities Discovery >> +~~~~~~~~~~~~~~~~~~~~~~ >> + >> +Discovering the features and capabilities of a driver(crypto/ethernet) >> +is achieved through the ``rte_security_capabilities_get`` function. >> + >> +.. code-block:: c >> + >> + const struct rte_security_capability *rte_security_capabilities_get(uint16_t id); >> + >> +This allows the user to query a specific driver and get all the device >> +security capabilities. It returns an array of ``rte_security_capability`` structure >> +which contains all the capabilities for the device. >> + >> +Security Session Create/Free >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +Security Sessions are created to store the immutable fields of a particular Security >> +association for a particular protocol which is defined by a security session >> +configuration structure which is used in the operation processing of a packet flow. >> +Sessions are used to manage protocol specific information as well as crypto parameters. >> +Security sessions cache this immutable data in a optimal way for the underlying PMD >> +and this allows further acceleration of the offload of Crypto workloads. >> + >> +The Secutiry framework provides APIs to create and free sessions for crypto/ethernet >> +devices, where sessions are mempool objects. It is the application's responsibility >> +to create and manage the session mempools. Mempool object size should be able to >> +accommodate the driver's private data of the session. >> + >> +Once the session mempools have been created, ``rte_security_session_create()`` >> +is used to allocate and initialize a session for the required crypto/ethernet device. >> +Sessions already created can be updated with the ``rte_security_session_update``. >> + >> +When a session is no longer used, user must call ``rte_security_session_destroy()`` >> +to free driver private session data and return the memory back to the mempool. >> + >> +For look aside protocol offload to hardware crypto device, the ``rte_crypto_op`` >> +created by the application is attached to the security session by the API >> +``rte_security_attach_session``. >> + >> +For Inline Crypto and Inline protocol offload, device specific defined metadata is >> +updated in the mbuf using ``rte_security_set_pkt_metadata``. > > If DEV_TX_OFFLOAD_SEC_NEED_MDATA is set. > > >> + >> +Session configuration >> +~~~~~~~~~~~~~~~~~~~~~ >> + >> +Security Session configuration structure is defined as ``rte_security_session_conf`` >> + >> +.. code-block:: c >> + >> + struct rte_security_session_conf { >> + enum rte_security_session_action_type action_type; >> + /**< Type of action to be performed on the session */ >> + enum rte_security_session_protocol protocol; >> + /**< Security protocol to be configured */ >> + union { >> + struct rte_security_ipsec_xform ipsec; >> + struct rte_security_macsec_xform macsec; >> + }; >> + /**< Configuration parameters for security session */ >> + struct rte_crypto_sym_xform *crypto_xform; >> + /**< Security Session Crypto Transformations */ >> + }; >> + >> +The configuration structure reuses the ``rte_crypto_sym_xform`` for crypto related >> +configuration. ``rte_security_session_action_type`` specify whether the session is >> +configured for Lookaside Protocol offload or Inline Crypto or Inline Protocol >> +Offload. >> + >> +.. code-block:: c >> + >> + enum rte_security_session_action_type { >> + RTE_SECURITY_ACTION_TYPE_NONE, >> + /**< No security actions */ >> + RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO, >> + /**< Crypto processing for security protocol is processed inline >> + * during transmission */ >> + RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL, >> + /**< All security protocol processing is performed inline during >> + * transmission */ >> + RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL >> + /**< All security protocol processing including crypto is performed >> + * on a lookaside accelerator */ >> + }; >> + >> +The ``rte_security_session_protocol`` is defined as >> + >> +.. code-block:: c >> + >> + enum rte_security_session_protocol { >> + RTE_SECURITY_PROTOCOL_IPSEC, >> + /**< IPsec Protocol */ >> + RTE_SECURITY_PROTOCOL_MACSEC, >> + /**< MACSec Protocol */ >> + }; >> + >> +Currently the library defines configuration parameters for IPSec only. For other >> +protocols like MACSec, structures and enums are defined as place holders which >> +will be updated in the future. >> + >> +IPsec related configuration parameters are defined in ``rte_security_ipsec_xform`` >> + >> +.. code-block:: c >> + >> + struct rte_security_ipsec_xform { >> + uint32_t spi; >> + /**< SA security parameter index */ >> + uint32_t salt; >> + /**< SA salt */ >> + struct rte_security_ipsec_sa_options options; >> + /**< various SA options */ >> + enum rte_security_ipsec_sa_direction direction; >> + /**< IPSec SA Direction - Egress/Ingress */ >> + enum rte_security_ipsec_sa_protocol proto; >> + /**< IPsec SA Protocol - AH/ESP */ >> + enum rte_security_ipsec_sa_mode mode; >> + /**< IPsec SA Mode - transport/tunnel */ >> + struct rte_security_ipsec_tunnel_param tunnel; >> + /**< Tunnel parameters, NULL for transport mode */ >> + }; >> + >> + >> +Security API >> +~~~~~~~~~~~~ >> + >> +The rte_security Library API is described in the *DPDK API Reference* document. >> + >> +Flow based Security Session >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +In case of NIC based offloads, the security session specified in the >> +'rte_flow_action_security' must be created on the same port as the >> +flow action that is being specified. >> + >> +The ingress/egress flow attribute should match that specified in the security >> +session if the security session supports the definition of the direction. >> + >> +Multiple flows can be configured to use the same security session. For >> +example if the security session specifies an egress IPsec SA, then multiple >> +flows can be specified to that SA. In the case of an ingress IPsec SA then >> +it is only valid to have a single flow to map to that security session. >> + >> +.. code-block:: console >> + >> + Configuration Path >> + | >> + +--------|--------+ >> + | Add/Remove | >> + | IPsec SA | <------ Build security flow action of >> + | | | ipsec transform >> + |--------|--------| >> + | >> + +--------V--------+ >> + | Flow API | >> + +--------|--------+ >> + | >> + +--------V--------+ >> + | | >> + | NIC PMD | <------ Add/Remove SA to/from hw context >> + | | >> + +--------|--------+ >> + | >> + +--------|--------+ >> + | HW ACCELERATED | >> + | NIC | >> + | | >> + +--------|--------+ >> + >> +o Add/Delete SA flow: >> + To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP >> + using the SA selectors and the rte_crypto_ipsec_xform as the rte_flow_action. >> + Note that any rte_flow_items may be empty, which means it is not checked. >> + >> +.. code-block:: console >> + >> + In its most basic form, IPsec flow specification is as follows: >> + +-------+ +----------+ +--------+ +-----+ >> + | Eth | -> | IP4/6 | -> | ESP | -> | END | >> + +-------+ +----------+ +--------+ +-----+ >> + >> + However, the API can represent, IPsec crypto offload with any encapsulation: >> + +-------+ +--------+ +-----+ >> + | Eth | -> ... -> | ESP | -> | END | >> + +-------+ +--------+ +-----+ >> -- >> 2.9.3 >> > Thanks for your comments, I would include these in my next version. -Akhil