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

[Ori Kam <orika@nvidia.com>]

Hi Tejasree,
PSB

> -----Original Message-----
> From: Tejasree Kondoj <ktejasree@marvell.com>
> 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.

Ori,

> >
> > Best,
> > Ori