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

[Anoob Joseph <anoobj@marvell.com>]

Hi Konstantin,

Please see inline.

Thanks,
Anoob

> -----Original Message-----
> From: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Sent: Thursday, September 19, 2019 1:04 PM
> To: Anoob Joseph <anoobj@marvell.com>; Smoczynski, MarcinX
> <marcinx.smoczynski@intel.com>; akhil.goyal@nxp.com
> Cc: dev@dpdk.org; Narayana Prasad Raju Athreya <pathreya@marvell.com>;
> Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Archana Muniganti
> <marchana@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.
> 
> Right now we don't do outbound fallback sessions.
> Again, similar scheme would work for TX with lookaside-none and inline-crypto,
> but not for inline/lookaside-proto.
> Of course few extra changes would be needed - move fragmentation before
> ipsec processing part.

[Anoob] Understood.
 
> 
> >
> > >
> > > >
> > > > 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.
> 
> Sure, looking forward for it.
> In fact, I asked these questions a year ago but as I said before there was no
> progress on that.
> 
> > You do agree that this approach will not help inline protocol offloading, right?
> 
> Yes, see above.
> 
> > 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.
> 
> Obviously there is no such API for any *-proto devices, see above.
> Not sure why do you keep repeating it, I already agreed with you, see above :)
> Just to summarize:
> 1. Yes I think for lookaiside/iniline-proto devices there is a need for some extra
> API
>     to sync session state between HW and SW.
>    Right now, I don't have a clear idea how exactly it should look like.
> 2. Intel team doesn't plan to work on this API right now.
> 3. I am happy to review with what you guys will come-up with and provide my
> feedback.
> Hope that makes things clear.

[Anoob] My apologies if the queries seemed repetitive. I guess all my concerns are answered. Please do update the logs (and description) to state limitations regarding protocol offloads. I would suggest using "inline crypto processing" instead of "inline processing" wherever applicable. Also, if lookaside protocol is mentioned, better state that the "protocol state" will have to be maintained by application (or lib ipsec in case of lookaside ipsec offload).
 
> Konstantin
> 
> >
> > > Konstantin
> > >
> > > >
> > > > > Konstantin
> > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Anoob
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: dev <dev-bounces@dpdk.org> On Behalf Of Marcin
> > > > > > > Smoczynski
> > > > > > > Sent: Wednesday, September 4, 2019 7:47 PM
> > > > > > > To: konstantin.ananyev@intel.com; akhil.goyal@nxp.com
> > > > > > > Cc: dev@dpdk.org; Marcin Smoczynski
> > > > > > > <marcinx.smoczynski@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