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

[Ben Pfaff]

On Thu, Jul 05, 2018 at 09:29:37PM +0000, Stokes, Ian wrote:
> > 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.

I don't understand yet why a new tunnel type is preferable.  Keep in
mind that it wouldn't be a single new tunnel type but a new tunnel type
per current tunnel type (gre_ipsec, vxlan_ipsec, stt_ipsec,
geneve_ipsec, ...).