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, ...). _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev