[dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: add fallback session

Anoob Joseph anoobj at marvell.com
Thu Sep 19 04:50:51 CEST 2019


Hi Konstantin, 

Please see inline.

Thanks,
Anoob

> -----Original Message-----
> From: Ananyev, Konstantin <konstantin.ananyev at intel.com>
> Sent: Thursday, September 19, 2019 3:49 AM
> To: Anoob Joseph <anoobj at marvell.com>; Smoczynski, MarcinX
> <marcinx.smoczynski at intel.com>; akhil.goyal at nxp.com
> Cc: dev at dpdk.org; Narayana Prasad Raju Athreya <pathreya at marvell.com>;
> Jerin Jacob Kollanukkaran <jerinj at marvell.com>; Archana Muniganti
> <marchana at marvell.com>
> Subject: RE: [dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: add fallback
> session
> 
> 
> 
> Hi Anoob,
> 
> > > > Sorry for the late response. But how do you plan to handle "inline
> protocol"
> > > processed packets?
> > >
> > > Right now that feature is supported for "inline crypto" only.
> >
> > [Anoob] The description says "inline processed" packets. Hence the confusion.
> >
> > > For the case when SA doesn't enable replay window and/or ESN current
> > > patch should also work for "inline proto" too, but this is just my
> > > understanding (not tested, etc.).
> >
> > [Anoob] In case of inline ipsec processing, the ipsec state (which
> > would track sequence number etc) will be internal to the PMDs. So
> > anti- replay/ESN would have to be done either in the h/w or PMD. This would
> mean application will not have state information regarding ipsec processing.
> Hence fallback handling with the above scheme will not work in that case.
> 
> Agree, that's why I wrote above that current wok might work for inline-proto
> *only* if replay window and ESN is disabled.

[Anoob] Any feature that makes use of protocol "state" would fail with this scheme. In case of inline ipsec, that is anti-replay & ESN. I see that you are not planning for fallback session for outbound. If at all that is planned, this scheme will fail to co-ordinate sequence number between original and fallback sessions.

> 
> >
> > To address this properly for inline protocol, we will have to come up
> > with some logic to share session private data b/w "eligible" PMDs. This would
> involve library changes to rte_security, etc.
> 
> Again, totally agree.
> As I remember we already discussed it about a year ago, but didn't come up with
> any concrete proposal.
> 
> > Once that is proposed, there will be one kind of handling for inline
> > protocol processing and another kind for inline crypto processing. Would you
> be fine with that?
> 
> For sure something needs to be changed for inline-proto to sync replay-
> window/ESN related data between HW/PMD and SW.
> What it should be - new function, or something else - hard to tell right now.

[Anoob] No disagreement. My only concern is the incompleteness of this solution. We will have to propose a totally new scheme for inline protocol. You do agree that this approach will not help inline protocol offloading, right? If you are okay with having different solutions for inline crypto & inline protocol, I don't have any issue with this series.

Also, how do you plan to pass "state" info to lookaside protocol session? That will be required to handle ESN/anti-replay in lookaside protocol capable PMD as well.
 
> Konstantin
> 
> >
> > > Konstantin
> > >
> > > >
> > > > Thanks,
> > > > Anoob
> > > >
> > > > > -----Original Message-----
> > > > > From: dev <dev-bounces at dpdk.org> On Behalf Of Marcin Smoczynski
> > > > > Sent: Wednesday, September 4, 2019 7:47 PM
> > > > > To: konstantin.ananyev at intel.com; akhil.goyal at nxp.com
> > > > > Cc: dev at dpdk.org; Marcin Smoczynski
> > > > > <marcinx.smoczynski at intel.com>
> > > > > Subject: [dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: add
> > > > > fallback session
> > > > >
> > > > > Inline processing is limited to a specified subset of traffic.
> > > > > It is often unable to handle more complicated situations, such
> > > > > as fragmented traffic. When using inline processing such traffic is
> dropped.
> > > > >
> > > > > Introduce multiple sessions per SA allowing to configure a
> > > > > fallback lookaside session for packets that normally would be dropped.
> > > > > A fallback session type in the SA configuration by adding 'fallback'
> > > > > with 'lookaside-none' or 'lookaside-protocol' parameter to
> > > > > determine type of session.
> > > > >
> > > > > Fallback session feature is available only when using librte_ipsec.
> > > > >
> > > > > v1 to v2 changes:
> > > > >  - disable fallback offload for outbound SAs
> > > > >  - add test scripts
> > > > >
> > > > > Marcin Smoczynski (3):
> > > > >   examples/ipsec-secgw: ipsec_sa structure cleanup
> > > > >   examples/ipsec-secgw: add fallback session feature
> > > > >   examples/ipsec-secgw: add offload fallback tests
> > > > >
> > > > >  doc/guides/sample_app_ug/ipsec_secgw.rst      |  17 +-
> > > > >  examples/ipsec-secgw/esp.c                    |  35 ++--
> > > > >  examples/ipsec-secgw/ipsec-secgw.c            |  16 +-
> > > > >  examples/ipsec-secgw/ipsec.c                  |  99 ++++++-----
> > > > >  examples/ipsec-secgw/ipsec.h                  |  61 +++++--
> > > > >  examples/ipsec-secgw/ipsec_process.c          | 113 +++++++-----
> > > > >  examples/ipsec-secgw/sa.c                     | 164 +++++++++++++-----
> > > > >  .../test/trs_aesgcm_common_defs.sh            |   4 +-
> > > > >  .../trs_aesgcm_inline_crypto_fallback_defs.sh |   5 +
> > > > >  .../test/tun_aesgcm_common_defs.sh            |   6 +-
> > > > >  .../tun_aesgcm_inline_crypto_fallback_defs.sh |   5 +
> > > > >  11 files changed, 358 insertions(+), 167 deletions(-)  create
> > > > > mode
> > > > > 100644
> > > > > examples/ipsec-secgw/test/trs_aesgcm_inline_crypto_fallback_defs
> > > > > .sh  create mode 100644 examples/ipsec-
> > > > > secgw/test/tun_aesgcm_inline_crypto_fallback_defs.sh
> > > > >
> > > > > --
> > > > > 2.21.0.windows.1



More information about the dev mailing list