Hi Ian, If my understanding is correct, your are asking whether we should add a specific IPsec tunnel interface instead of using "options" column to indicate IPsec tunnel. I think a new IPsec tunnel interface should work fine with my current patch. All I need to change is to tell the ovs-monitor-ipsec daemon to get the certificate and key information from the IPsec tunnel interface. And from OVS kernel datapath's point of view, this IPsec tunnel interface is just a normal tunnel interface.
I agree that it's important to make a unified IPsec tunnel configuration interface. The configuration interface in my patch allows user to choose from three authentication methods which are peer-cert, CA-cert, and PSK based authentication. Do you plan to support the similar configuration on DPDK IPsec? Thanks, Qiuyu On Thu, Jul 5, 2018 at 2:29 PM, Stokes, Ian <[email protected]> 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. > > 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 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
