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 5C8C3A0524; Tue, 20 Apr 2021 03:08:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D642A41549; Tue, 20 Apr 2021 03:08:15 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id 5286541448 for ; Tue, 20 Apr 2021 03:08:14 +0200 (CEST) IronPort-SDR: TWueZEHBAsXQkUmo6Yv1RU0S1I41BITnFH+KkfcRwfs8HwBv+3iSDcEhHN5FCibsm7nguzHeoA A3Hh60OqUkPA== X-IronPort-AV: E=McAfee;i="6200,9189,9959"; a="174908699" X-IronPort-AV: E=Sophos;i="5.82,235,1613462400"; d="scan'208";a="174908699" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2021 18:08:13 -0700 IronPort-SDR: ge70JMXI2JCnyvHchLcgj94qgqAlBno07HPCyzUPksYnTwWCt4VM1ZZlF+1SNfSHb/jYDmnpoO mtwCfsOTmyQQ== X-IronPort-AV: E=Sophos;i="5.82,235,1613462400"; d="scan'208";a="452329001" Received: from agrady-mobl.ger.corp.intel.com (HELO [10.213.224.96]) ([10.213.224.96]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2021 18:08:09 -0700 From: Ferruh Yigit To: Tejasree Kondoj , Ori Kam , Asaf Penso , Stephen Hemminger Cc: Akhil Goyal , Radu Nicolau , Declan Doherty , NBU-Contact-Thomas Monjalon , Andrew Rybchenko , Jerin Jacob Kollanukkaran , Narayana Prasad Raju Athreya , Anoob Joseph , "dev@dpdk.org" References: <20200910164441.7245-1-ktejasree@marvell.com> <20200910094558.0398145b@hermes.lan> X-User: ferruhy Message-ID: <47d0904e-136e-69ef-e713-4fd3dc388849@intel.com> Date: Tue, 20 Apr 2021 02:08:07 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] ethdev: add security flow item 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 Sender: "dev" On 2/17/2021 5:36 PM, Ferruh Yigit wrote: > On 9/24/2020 11:07 AM, Tejasree Kondoj wrote: >> Hi Ori, >> >> Please see inline. >> >> Thanks, >> Tejasree >> >>> -----Original Message----- >>> From: Ori Kam >>> Sent: Thursday, September 24, 2020 3:22 PM >>> To: Tejasree Kondoj ; Asaf Penso >>> ; Stephen Hemminger >>> Cc: Akhil Goyal ; Radu Nicolau >>> ; Declan Doherty ; >>> NBU-Contact-Thomas Monjalon ; Ferruh Yigit >>> ; Andrew Rybchenko >>> ; Jerin Jacob Kollanukkaran >>> ; Narayana Prasad Raju Athreya >>> ; Anoob Joseph ; >>> dev@dpdk.org >>> Subject: [EXT] RE: [dpdk-dev] [PATCH] ethdev: add security flow item >>> >>> External Email >>> >>> ---------------------------------------------------------------------- >>> Thanks, >>> Ori >>> >>>> -----Original Message----- >>>> From: Tejasree Kondoj >>>> Sent: Thursday, September 24, 2020 8:31 AM >>>> >>>> Thanks, >>>> Tejasree >>>> >>>>> -----Original Message----- >>>>> From: Ori Kam >>>>> Sent: Wednesday, September 23, 2020 8:00 PM >>>>> To: Tejasree Kondoj ; Asaf Penso >>>>> ; Stephen Hemminger >>> >>>>> Cc: Akhil Goyal ; Radu Nicolau >>>>> ; Declan Doherty ; >>>>> NBU-Contact-Thomas Monjalon ; Ferruh Yigit >>>>> ; Andrew Rybchenko >>>>> ; Jerin Jacob Kollanukkaran >>>>> ; Narayana Prasad Raju Athreya >>>>> ; Anoob Joseph ; >>>>> dev@dpdk.org >>>>> Subject: [EXT] RE: [dpdk-dev] [PATCH] ethdev: add security flow item >>>>> >>>>> External Email >>>>> >>>>> -------------------------------------------------------------------- >>>>> -- >>>>> Hi >>>>> >>>>>> -----Original Message----- >>>>>> From: Tejasree Kondoj >>>>>> Sent: Tuesday, September 22, 2020 5:18 PM >>>>>> Subject: RE: [dpdk-dev] [PATCH] ethdev: add security flow item >>>>>> >>>>>> Hi Ori, >>>>>> >>>>>> Please see inline. >>>>>> >>>>>> Thanks, >>>>>> Tejasree >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Tejasree Kondoj >>>>>>> Sent: Tuesday, September 22, 2020 2:37 PM >>>>>>> To: Ori Kam ; Asaf Penso ; >>>>>>> Stephen Hemminger >>>>>>> Cc: Akhil Goyal ; Radu Nicolau >>>>>>> ; Declan Doherty >>>>>>> ; NBU-Contact-Thomas Monjalon >>>>>>> ; Ferruh Yigit ; >>>>>>> Andrew Rybchenko ; Jerin Jacob >>>>>>> Kollanukkaran ; Narayana Prasad Raju Athreya >>>>>>> ; Anoob Joseph ; >>>>>>> dev@dpdk.org >>>>>>> Subject: RE: [dpdk-dev] [PATCH] ethdev: add security flow item >>>>>>> >>>>>>> Please see inline. >>>>>>> >>>>>>> Thanks >>>>>>> Tejasree >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ori Kam >>>>>>>> Sent: Tuesday, September 22, 2020 1:22 PM >>>>>>>> To: Asaf Penso ; Tejasree Kondoj >>>>>>>> ; Stephen Hemminger >>>>>>>> >>>>>>>> Cc: Akhil Goyal ; Radu Nicolau >>>>>>>> ; Declan Doherty >>>>>>>> ; NBU-Contact-Thomas Monjalon >>>>>>>> ; Ferruh Yigit ; >>>>>>>> Andrew Rybchenko ; Jerin Jacob >>>>>>>> Kollanukkaran ; Narayana Prasad Raju >>>>>>>> Athreya ; Anoob Joseph >>>>>>>> ; dev@dpdk.org >>>>>>>> Subject: [EXT] RE: [dpdk-dev] [PATCH] ethdev: add security >>>>>>>> flow item >>>>>>>> >>>>>>>> External Email >>>>>>>> >>>>>>>> -------------------------------------------------------------- >>>>>>>> ---- >>>>>>>> ---- >>>>>>>> Hi >>>>>>>>> -----Original Message----- >>>>>>>>> From: Asaf Penso >>>>>>>>> Sent: Monday, September 21, 2020 7:09 PM >>>>>>>>> Subject: RE: [dpdk-dev] [PATCH] ethdev: add security flow >>>>>>>>> item >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Asaf Penso >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Tejasree Kondoj >>>>>>>>>> Sent: Monday, September 21, 2020 11:59 AM >>>>>>>>>> To: Asaf Penso ; Stephen Hemminger >>>>>>>>>> >>>>>>>>>> Cc: Akhil Goyal ; Radu Nicolau >>>>>>>>>> ; Declan Doherty >>>>>>>>>> ; Ori Kam ; >>>>>>>>>> NBU-Contact-Thomas Monjalon ; >>> Ferruh >>>>> Yigit >>>>>>>>>> ; Andrew Rybchenko >>>>>>>>>> ; Jerin Jacob Kollanukkaran >>>>>>>>>> ; Narayana Prasad Raju Athreya >>>>>>>>>> ; Anoob Joseph >>> ; >>>>>>>>>> dev@dpdk.org >>>>>>>>>> Subject: RE: [dpdk-dev] [PATCH] ethdev: add security flow >>>>>>>>>> item >>>>>>>>>> >>>>>>>>>> Please see inline. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Tejasree >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Asaf Penso >>>>>>>>>>> Sent: Thursday, September 17, 2020 3:09 PM >>>>>>>>>>> To: Stephen Hemminger ; >>>>> Tejasree >>>>>>>>>> Kondoj >>>>>>>>>>> >>>>>>>>>>> Cc: Akhil Goyal ; Radu Nicolau >>>>>>>>>>> ; Declan Doherty >>>>>>>>>>> ; Ori Kam ; >>>>>>>>>>> NBU-Contact-Thomas Monjalon ; >>> Ferruh >>>>>>>>>>> Yigit ; Andrew Rybchenko >>>>>>>>>>> ; Jerin Jacob Kollanukkaran >>>>>>>>>>> ; Narayana Prasad Raju Athreya >>>>>>>>>>> ; Anoob Joseph >>>>>>>>>>> ; dev@dpdk.org >>>>>>>>>>> Subject: [EXT] RE: [dpdk-dev] [PATCH] ethdev: add >>>>>>>>>>> security flow item >>>>>>>>>>> >>>>>>>>>>> External Email >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------- >>>>>>>>>>> ---- >>>>>>>>>>> ---- >>>>>>>>>>> -- >>>>>>>>>>> --- >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: dev On Behalf Of Stephen >>>>>>>> Hemminger >>>>>>>>>>>> Sent: Thursday, September 10, 2020 7:46 PM >>>>>>>>>>>> To: Tejasree Kondoj >>>>>>>>>>>> Cc: Akhil Goyal ; Radu Nicolau >>>>>>>>>>>> ; Declan Doherty >>>>>>>>>>>> ; Ori Kam >>>>>>>>>>>> ; NBU-Contact-Thomas Monjalon >>>>>>>>>>>> ; Ferruh >>>>>>> Yigit >>>>>>>>>>>> ; Andrew Rybchenko >>>>>>>>>>>> ; Jerin Jacob >>>>>>>>>>>> ; Narayana Prasad >>>>>>>>>>>> ; Anoob Joseph >>>>> ; >>>>>>>>>>>> dev@dpdk.org >>>>>>>>>>>> Subject: Re: [dpdk-dev] [PATCH] ethdev: add security >>>>>>>>>>>> flow item >>>>>>>>>>>> >>>>>>>>>>>> On Thu, 10 Sep 2020 22:14:41 +0530 Tejasree Kondoj >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Introduce a new item type RTE_FLOW_ITEM_TYPE_SECURITY >>>>>>>>>>>>> to >>>>>>>>>>> distinguish >>>>>>>>>>>>> plain packets from IPsec decrypted plain packets. >>>>>>>>>>>>> >>>>>>>>>>>>> Signed-off-by: Tejasree Kondoj >>>>>>>>>>>> >>>>>>>>>>>> Please provide an implementation, API's without any >>>>>>>>>>>> driver support should not be accepted. >>>>>>>>>>>> >>>>>>>>>>>> Also, we need a test for this. >>>>>>>>>> >>>>>>>>>> [Tejasree] We would like to defer the patch and add >>>>>>>>>> implementation, test case in next cycle. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> +1 >>>>>>>>>>> Also, I think the word SECURITY is too high-level, and if >>>>>>>>>>> specifically you mention here an item for IPSec, perhaps >>>>>>>>>>> you can >>>>>>>> consider renaming. >>>>>>>>>> >>>>>>>>>> [Tejasree] This item matches security processed packets and >>>>>>>>>> not specific to IPsec. >>>>>>>>>> Will change commit description as follows: >>>>>>>>>> " Introduce a new item type RTE_FLOW_ITEM_TYPE_SECURITY to >>>>>>>>>> match packets that were security processed. For example, in >>>>>>>>>> case of inline IPsec, it can be used to distinguish plain >>>>>>>>>> packets from IPsec decrypted >>>>>>>> plain packets" >>>>>>>>>> Would that be fine? >>>>>>>>> >>>>>>>>> It would be more clear, yes, thank you, but in this case I >>>>>>>>> suggest to have a field in the spec that you can match on it. >>>>>>>>> For example, is it viable to know if the packet was >>>>>>>>> processed by IPSec and not AES? Maybe you want to have 2 >>>>>>>>> flow with this new item, but still differentiate between the types. >>>>>>>> >>>>>>>> Why not use mark/tag/meta to set this value? >>>>>>>> The application will insert a flow that sends to security and >>>>>>>> mark the flow with some ID then the application can check this ID. >>>>>>> >>>>>>> [Tejasree] SECURITY itself wouldn't make distinction on protocol. >>>>>>> It would be combined with MARK_ID to know if the packet was >>>>>>> processed by IPsec and not AES. >>>>>>> >>>>>>> MARK_ID alone couldn't be used as we wouldn't know if it is >>>>>>> plain packet or security processed plain packet. >>>>>>> >>>>>>> Rules would be as follows: >>>>>>> Rule #1 >>>>>>> [ETH] [IP] [ESP] [SPI] → [SECURITY] [MARK_ID] [END] Rule #2 >>>>>>> [SECURITY] [MARK_ID] [ETH] [IP] → [QUEUE] [END] >>>>>>> >>>>>>> I don't understand why in rule #1 you can't have the mark value >>>>>>> to also mark the security. >>>>>>>  From your patch I understand that security is just one bit This >>>>>>> means that you can say if MSB bit in mark is set then it comes >>>>>>> from security. >>>>>> >>>>>> [Tejasree] We can use MSB of MARK_ID but that would mean we would >>>>>> be reserving it for security. >>>>>> >>>>> [Ori] but why does the PMD needs it? the application know what it >>>>> needs so it can use it, It is the application decision to send to >>>>> the security right? So it knows what values to set. >>>>> >>>>> Also the application can use tag or any other data item. >>>>> >>>> [Tejasree] PMD needs it to establish connection between security and >>>> final action to be done (queue for example). >>>> >>>> First rule works on the outer packet where the inner packet would be >>>> hidden by the protocol (like encrypted payload in IPsec) and the >>>> second rule will act on the de-capsulated packet. So the packets >>>> itself are different and we cannot have one rule. >>>> >>>>   In IPsec it is valid (and a very trivial usage) to have one outer >>>> flow constitute multiple inner flows. Without this, application will >>>> not be able to configure hardware to treat inner flows differently. >>>> >>> Fully agree with you about the app needs to know if it passed security But >>> this goes also for example simple tunnel where the app may decap the >>> packet in the on the first flow and then do matching on the inner 5 tuple but >>> it will need to know if the packet was decaped or what is the vni. >>> >>> So in your case the app will send traffic to security and mark it as one that >>> was gone to security then in the second rule the app will match on the mark >>> and do what it wants with it. >>> >>> I simply don't see why you need new metadata item just to mark if it passed >>> security. >>> >> >> [Tejasree] Plain packets need to be differentiated from protocol processed ones. >> In case of regular tunnel, it may or may not be required to differentiate. But >> with IPsec, it is mandatory to differentiate. So either we will need to >> reserve MSB of MARK_ID or allow SECURITY. >> > > Reserving a bit in MARK is same as using SECURITY item, I didn't get why any > arbitrary MARK value can't be used for this as suggested. > > Can't application do as following: > [flow A] -> [decrypt] [mark id=0x10 all processed packets] > [packets with mark id=0x10] -> [queue 3] > > Since application knows the mark value for first rule, it can use same value for > second rule. > > Or are we missing something? Like packets are decrypted without a specific rule, > hence preventing to mark them, but you still want to apply an action to > processed packets? > Missing implementation makes it harder to understand your intention. The patch is stale, rejecting it, please send a new version if required.