Re: [dpdk-dev] [PATCH] ethdev: add security flow item

[Ferruh Yigit <ferruh.yigit@intel.com>]

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 <orika@nvidia.com>
>>> Sent: Thursday, September 24, 2020 3:22 PM
>>> To: Tejasree Kondoj <ktejasree@marvell.com>; Asaf Penso
>>> <asafp@nvidia.com>; Stephen Hemminger <stephen@networkplumber.org>
>>> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Radu Nicolau
>>> <radu.nicolau@intel.com>; Declan Doherty <declan.doherty@intel.com>;
>>> NBU-Contact-Thomas Monjalon <thomas@monjalon.net>; Ferruh Yigit
>>> <ferruh.yigit@intel.com>; Andrew Rybchenko
>>> <arybchenko@solarflare.com>; Jerin Jacob Kollanukkaran
>>> <jerinj@marvell.com>; Narayana Prasad Raju Athreya
>>> <pathreya@marvell.com>; Anoob Joseph <anoobj@marvell.com>;
>>> dev@dpdk.org
>>> Subject: [EXT] RE: [dpdk-dev] [PATCH] ethdev: add security flow item
>>>
>>> External Email
>>>
>>> ----------------------------------------------------------------------
>>> Thanks,
>>> Ori
>>>
>>>> -----Original Message-----
>>>> From: Tejasree Kondoj <ktejasree@marvell.com>
>>>> Sent: Thursday, September 24, 2020 8:31 AM
>>>>
>>>> Thanks,
>>>> Tejasree
>>>>
>>>>> -----Original Message-----
>>>>> From: Ori Kam <orika@nvidia.com>
>>>>> Sent: Wednesday, September 23, 2020 8:00 PM
>>>>> To: Tejasree Kondoj <ktejasree@marvell.com>; Asaf Penso
>>>>> <asafp@nvidia.com>; Stephen Hemminger
>>> <stephen@networkplumber.org>
>>>>> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Radu Nicolau
>>>>> <radu.nicolau@intel.com>; Declan Doherty <declan.doherty@intel.com>;
>>>>> NBU-Contact-Thomas Monjalon <thomas@monjalon.net>; Ferruh Yigit
>>>>> <ferruh.yigit@intel.com>; Andrew Rybchenko
>>>>> <arybchenko@solarflare.com>; Jerin Jacob Kollanukkaran
>>>>> <jerinj@marvell.com>; Narayana Prasad Raju Athreya
>>>>> <pathreya@marvell.com>; Anoob Joseph <anoobj@marvell.com>;
>>>>> dev@dpdk.org
>>>>> Subject: [EXT] RE: [dpdk-dev] [PATCH] ethdev: add security flow item
>>>>>
>>>>> External Email
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> -- 
>>>>> Hi
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Tejasree Kondoj <ktejasree@marvell.com>
>>>>>> 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 <orika@nvidia.com>; Asaf Penso <asafp@nvidia.com>;
>>>>>>> Stephen Hemminger <stephen@networkplumber.org>
>>>>>>> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Radu Nicolau
>>>>>>> <radu.nicolau@intel.com>; Declan Doherty
>>>>>>> <declan.doherty@intel.com>; NBU-Contact-Thomas Monjalon
>>>>>>> <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>;
>>>>>>> Andrew Rybchenko <arybchenko@solarflare.com>; Jerin Jacob
>>>>>>> Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju Athreya
>>>>>>> <pathreya@marvell.com>; Anoob Joseph <anoobj@marvell.com>;
>>>>>>> dev@dpdk.org
>>>>>>> Subject: RE: [dpdk-dev] [PATCH] ethdev: add security flow item
>>>>>>>
>>>>>>> Please see inline.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Tejasree
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Ori Kam <orika@nvidia.com>
>>>>>>>> Sent: Tuesday, September 22, 2020 1:22 PM
>>>>>>>> To: Asaf Penso <asafp@nvidia.com>; Tejasree Kondoj
>>>>>>>> <ktejasree@marvell.com>; Stephen Hemminger
>>>>>>>> <stephen@networkplumber.org>
>>>>>>>> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Radu Nicolau
>>>>>>>> <radu.nicolau@intel.com>; Declan Doherty
>>>>>>>> <declan.doherty@intel.com>; NBU-Contact-Thomas Monjalon
>>>>>>>> <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>;
>>>>>>>> Andrew Rybchenko <arybchenko@solarflare.com>; Jerin Jacob
>>>>>>>> Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju
>>>>>>>> Athreya <pathreya@marvell.com>; Anoob Joseph
>>>>>>>> <anoobj@marvell.com>; dev@dpdk.org
>>>>>>>> Subject: [EXT] RE: [dpdk-dev] [PATCH] ethdev: add security
>>>>>>>> flow item
>>>>>>>>
>>>>>>>> External Email
>>>>>>>>
>>>>>>>> --------------------------------------------------------------
>>>>>>>> ----
>>>>>>>> ----
>>>>>>>> Hi
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Asaf Penso <asafp@nvidia.com>
>>>>>>>>> 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 <ktejasree@marvell.com>
>>>>>>>>>> Sent: Monday, September 21, 2020 11:59 AM
>>>>>>>>>> To: Asaf Penso <asafp@nvidia.com>; Stephen Hemminger
>>>>>>>>>> <stephen@networkplumber.org>
>>>>>>>>>> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Radu Nicolau
>>>>>>>>>> <radu.nicolau@intel.com>; Declan Doherty
>>>>>>>>>> <declan.doherty@intel.com>; Ori Kam <orika@nvidia.com>;
>>>>>>>>>> NBU-Contact-Thomas Monjalon <thomas@monjalon.net>;
>>> Ferruh
>>>>> Yigit
>>>>>>>>>> <ferruh.yigit@intel.com>; Andrew Rybchenko
>>>>>>>>>> <arybchenko@solarflare.com>; Jerin Jacob Kollanukkaran
>>>>>>>>>> <jerinj@marvell.com>; Narayana Prasad Raju Athreya
>>>>>>>>>> <pathreya@marvell.com>; Anoob Joseph
>>> <anoobj@marvell.com>;
>>>>>>>>>> dev@dpdk.org
>>>>>>>>>> Subject: RE: [dpdk-dev] [PATCH] ethdev: add security flow
>>>>>>>>>> item
>>>>>>>>>>
>>>>>>>>>> Please see inline.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Tejasree
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Asaf Penso <asafp@nvidia.com>
>>>>>>>>>>> Sent: Thursday, September 17, 2020 3:09 PM
>>>>>>>>>>> To: Stephen Hemminger <stephen@networkplumber.org>;
>>>>> Tejasree
>>>>>>>>>> Kondoj
>>>>>>>>>>> <ktejasree@marvell.com>
>>>>>>>>>>> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Radu Nicolau
>>>>>>>>>>> <radu.nicolau@intel.com>; Declan Doherty
>>>>>>>>>>> <declan.doherty@intel.com>; Ori Kam <orika@nvidia.com>;
>>>>>>>>>>> NBU-Contact-Thomas Monjalon <thomas@monjalon.net>;
>>> Ferruh
>>>>>>>>>>> Yigit <ferruh.yigit@intel.com>; Andrew Rybchenko
>>>>>>>>>>> <arybchenko@solarflare.com>; Jerin Jacob Kollanukkaran
>>>>>>>>>>> <jerinj@marvell.com>; Narayana Prasad Raju Athreya
>>>>>>>>>>> <pathreya@marvell.com>; Anoob Joseph
>>>>>>>>>>> <anoobj@marvell.com>; dev@dpdk.org
>>>>>>>>>>> Subject: [EXT] RE: [dpdk-dev] [PATCH] ethdev: add
>>>>>>>>>>> security flow item
>>>>>>>>>>>
>>>>>>>>>>> External Email
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------
>>>>>>>>>>> ----
>>>>>>>>>>> ----
>>>>>>>>>>> -- 
>>>>>>>>>>> ---
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: dev <dev-bounces@dpdk.org> On Behalf Of Stephen
>>>>>>>> Hemminger
>>>>>>>>>>>> Sent: Thursday, September 10, 2020 7:46 PM
>>>>>>>>>>>> To: Tejasree Kondoj <ktejasree@marvell.com>
>>>>>>>>>>>> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Radu Nicolau
>>>>>>>>>>>> <radu.nicolau@intel.com>; Declan Doherty
>>>>>>>>>>>> <declan.doherty@intel.com>; Ori Kam
>>>>>>>>>>>> <orika@mellanox.com>; NBU-Contact-Thomas Monjalon
>>>>>>>>>>>> <thomas@monjalon.net>; Ferruh
>>>>>>> Yigit
>>>>>>>>>>>> <ferruh.yigit@intel.com>; Andrew Rybchenko
>>>>>>>>>>>> <arybchenko@solarflare.com>; Jerin Jacob
>>>>>>>>>>>> <jerinj@marvell.com>; Narayana Prasad
>>>>>>>>>>>> <pathreya@marvell.com>; Anoob Joseph
>>>>> <anoobj@marvell.com>;
>>>>>>>>>>>> dev@dpdk.org
>>>>>>>>>>>> Subject: Re: [dpdk-dev] [PATCH] ethdev: add security
>>>>>>>>>>>> flow item
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, 10 Sep 2020 22:14:41 +0530 Tejasree Kondoj
>>>>>>>>>>>> <ktejasree@marvell.com> 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 <ktejasree@marvell.com>
>>>>>>>>>>>>
>>>>>>>>>>>> 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.