On 7/9/2018 5:54 PM, Ben Pfaff wrote:
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, ...).
I was thinking of an IPsec tunnel that uses esp mode, from feedback I
had received previously on ipsec transport with vxlan it use was
limited. The ipsec tunnel would not be specific for another tunnel
encapsulation such as vxlan etc as those tunnel headers would be
encapsulated within the IPsec payload in esp mode so would not be
visible. the idea being once IPsec is decapsulated the packet would be
recirculated, if the packet was vxlan or gre etc it would then
decapsulated for that protocol.
I'll take sometime and look at Qiuyus patch in more detail to provide
better feedback.
Ian
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
