[ovs-dev] [PATCH 0/3] IPsec support for tunneling

Stokes, Ian ian.stokes at intel.com
Thu Jul 5 21:29:37 UTC 2018


> On Thu, Jul 05, 2018 at 09:29:12PM +0100, Ian Stokes wrote:
> > On 6/27/2018 6:58 PM, Qiuyu Xiao wrote:
> > >This patch series reintroduce IPsec support for OVS tunneling and
> > >adds new features to prepare for the OVN IPsec support. The new
> features are:
> > >
> > >1) Add CA-cert based authentication support to ovs-monitor-ipsec.
> > >2) Enable ovs-pki to generate x.509 version 3 certificate.
> > >
> >
> > Thanks for working on the series.
> >
> > Just had a general query as regards IPsec in userspace.
> >
> > I had previously looked at implementing a *rough* IPsec Tunnel
> > interface for userspace last year for OVS DPDK. I had put the work on
> > hold as DPDK has begun working on a general IPsec library which would
> > make implementation simpler and cleaner/simpler to maintain in the
> > future. Targeted for DPDK
> > 18.11 (November this year).
> >
> > Would the introduction of a specific IPsec tunnel interface still be
> > acceptable in light of this patch?
> >
> > There are other libraries such as macsec that DPDK has libraries for
> > as well that could be introduced in the future for user space.
> >
> > I'm just aware of the divergence of approaches between whats available
> > in kernel vs userspace so thought it was worth raising for discussion
> > at this point?
> 
> Qiuyu probably doesn't have the context for this so let me respond.
> 
> Ideally, I'd like to have a single IPsec tunnel configuration interface
> that works well with all datapaths.  The one that Qiuyu is (re)introducing
> works for the kernel datapath.  I don't know IPsec or DPDK well enough to
> guess whether changes would be needed to better adapt it to a userspace
> datapath.  Do you see weaknesses in that area?
> It'd be great to get it right now, if we can.

Ok, Cc'ing Declan who is heading up the IPsec library for DPDK.

>From the userspace POV I guess we would have to do the IPsec processing (encryption/decryption, SA lookup/selection/installation) from when a packet is received on the datapath (if certs had not been setup previously). This is why I had suggested using a new tunnel type previously. The encap/decap action can be associated with the SA actions ideally.

We also have to think of the ofproto layer, I was thinking of the case an esp packet is received. It would have to be classified and recirculated to be decapped for IPsec or dropped if no SA existed. This should be fleshed out more for sure, just wanted to highlight the broad strokes of what's involved in userspace.

Ian


More information about the dev mailing list