[ovs-dev] [PATCH 0/3] IPsec support for tunneling
qiuyu.xiao.qyx at gmail.com
Thu Jul 5 22:19:50 UTC 2018
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
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?
On Thu, Jul 5, 2018 at 2:29 PM, Stokes, Ian <ian.stokes at intel.com> 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.
More information about the dev