| Message ID | 20180627175844.2809-1-qiuyu.xiao.qyx@gmail.com |
|---|---|
| Headers | show |
| Series | IPsec support for tunneling | expand |
Qiuyu Xiao <qiuyu.xiao.qyx@gmail.com> writes: > 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. > > Ansis Atteka (1): > ipsec: reintroduce IPsec support for tunneling > > Qiuyu Xiao (2): > ipsec: add CA-cert based authentication > ovs-pki: generate x.509 v3 certificate When the bot tested this, all of the IPSec tests failed. I had disabled the bot's report to the list. ovs-monitor-ipsec (XFRM) 876: Parse "ip xfrm policy" output FAILED (ovs-monitor-ipsec.at:145) 877: Parse "ip xfrm state" output FAILED (ovs-monitor-ipsec.at:175) ovs-monitor-ipsec (strongSwan) 878: Ignore non-IPsec tunnels FAILED (ovs-monitor-ipsec.at:195) 879: Parse "ipsec status" output FAILED (ovs-monitor-ipsec.at:226) 880: ipsec_gre with PSK authentication FAILED (ovs-monitor-ipsec.at:243) 881: ipsec_stt with PSK authentication FAILED (ovs-monitor-ipsec.at:317) 882: ipsec_geneve with PSK authentication FAILED (ovs-monitor-ipsec.at:400) 883: ipsec_vxlan with PSK authentication FAILED (ovs-monitor-ipsec.at:483) 884: ipsec_gre with PKI authentication (use_ssl_cert) FAILED (ovs-monitor-ipsec.at:570) 885: ipsec_gre with PKI authentication FAILED (ovs-monitor-ipsec.at:649) 886: ipsec_gre and ipsec_stt to two different hosts FAILED (ovs-monitor-ipsec.at:727) 887: ipsec_gre and ipsec_stt to the same host FAILED (ovs-monitor-ipsec.at:816) 888: Sequence of IPsec tunnel reconfiguration events FAILED (ovs-monitor-ipsec.at:907) I have the complete dist directory saved off (which includes the testsuite.dir) if you'd like to see it. > Documentation/automake.mk | 1 + > Documentation/howto/index.rst | 1 + > Documentation/howto/ipsec.rst | 259 +++++++ > Makefile.am | 1 + > debian/automake.mk | 3 + > debian/control | 21 + > debian/openvswitch-ipsec.dirs | 1 + > debian/openvswitch-ipsec.init | 189 ++++++ > debian/openvswitch-ipsec.install | 1 + > ipsec/automake.mk | 9 + > ipsec/ovs-monitor-ipsec | 763 +++++++++++++++++++++ > tests/automake.mk | 1 + > tests/ovs-monitor-ipsec.at | 1076 ++++++++++++++++++++++++++++++ > tests/testsuite.at | 1 + > utilities/ovs-pki.in | 18 +- > vswitchd/vswitch.xml | 83 ++- > 16 files changed, 2421 insertions(+), 7 deletions(-) > create mode 100644 Documentation/howto/ipsec.rst > create mode 100644 debian/openvswitch-ipsec.dirs > create mode 100644 debian/openvswitch-ipsec.init > create mode 100644 debian/openvswitch-ipsec.install > create mode 100644 ipsec/automake.mk > create mode 100755 ipsec/ovs-monitor-ipsec > create mode 100644 tests/ovs-monitor-ipsec.at
Hi Aaron, I made some changes to the interface of the ovs-monitor-ipsec configuration, that is why the tests all failed. I am waiting for Ansis' review for the patch. If he agrees the change, I will change the test script as well. That will fix this. BTW, 0-day robot is really cool! Sorry to trigger so many complaints. Regards, Qiuyu On Wed, Jun 27, 2018 at 12:41 PM, Aaron Conole <aconole@redhat.com> wrote: > Qiuyu Xiao <qiuyu.xiao.qyx@gmail.com> writes: > > > 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. > > > > Ansis Atteka (1): > > ipsec: reintroduce IPsec support for tunneling > > > > Qiuyu Xiao (2): > > ipsec: add CA-cert based authentication > > ovs-pki: generate x.509 v3 certificate > > When the bot tested this, all of the IPSec tests failed. I had disabled > the bot's report to the list. > > ovs-monitor-ipsec (XFRM) > > 876: Parse "ip xfrm policy" output FAILED ( > ovs-monitor-ipsec.at:145) > 877: Parse "ip xfrm state" output FAILED ( > ovs-monitor-ipsec.at:175) > > ovs-monitor-ipsec (strongSwan) > > 878: Ignore non-IPsec tunnels FAILED ( > ovs-monitor-ipsec.at:195) > 879: Parse "ipsec status" output FAILED ( > ovs-monitor-ipsec.at:226) > 880: ipsec_gre with PSK authentication FAILED ( > ovs-monitor-ipsec.at:243) > 881: ipsec_stt with PSK authentication FAILED ( > ovs-monitor-ipsec.at:317) > 882: ipsec_geneve with PSK authentication FAILED ( > ovs-monitor-ipsec.at:400) > 883: ipsec_vxlan with PSK authentication FAILED ( > ovs-monitor-ipsec.at:483) > 884: ipsec_gre with PKI authentication (use_ssl_cert) FAILED ( > ovs-monitor-ipsec.at:570) > 885: ipsec_gre with PKI authentication FAILED ( > ovs-monitor-ipsec.at:649) > 886: ipsec_gre and ipsec_stt to two different hosts FAILED ( > ovs-monitor-ipsec.at:727) > 887: ipsec_gre and ipsec_stt to the same host FAILED ( > ovs-monitor-ipsec.at:816) > 888: Sequence of IPsec tunnel reconfiguration events FAILED ( > ovs-monitor-ipsec.at:907) > > I have the complete dist directory saved off (which includes the > testsuite.dir) if you'd like to see it. > > > Documentation/automake.mk | 1 + > > Documentation/howto/index.rst | 1 + > > Documentation/howto/ipsec.rst | 259 +++++++ > > Makefile.am | 1 + > > debian/automake.mk | 3 + > > debian/control | 21 + > > debian/openvswitch-ipsec.dirs | 1 + > > debian/openvswitch-ipsec.init | 189 ++++++ > > debian/openvswitch-ipsec.install | 1 + > > ipsec/automake.mk | 9 + > > ipsec/ovs-monitor-ipsec | 763 +++++++++++++++++++++ > > tests/automake.mk | 1 + > > tests/ovs-monitor-ipsec.at | 1076 ++++++++++++++++++++++++++++++ > > tests/testsuite.at | 1 + > > utilities/ovs-pki.in | 18 +- > > vswitchd/vswitch.xml | 83 ++- > > 16 files changed, 2421 insertions(+), 7 deletions(-) > > create mode 100644 Documentation/howto/ipsec.rst > > create mode 100644 debian/openvswitch-ipsec.dirs > > create mode 100644 debian/openvswitch-ipsec.init > > create mode 100644 debian/openvswitch-ipsec.install > > create mode 100644 ipsec/automake.mk > > create mode 100755 ipsec/ovs-monitor-ipsec > > create mode 100644 tests/ovs-monitor-ipsec.at >
On Wed, Jun 27, 2018 at 10:58:41AM -0700, 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 a lot for working on this. I think that Aaron made a lot of valuable suggestions here. I hope that you can implement his suggestions (and the few that I made) and then post v2. Thanks, Ben.
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? Appreciate any input. Thanks Ian
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.
> 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
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 <ian.stokes@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. > > Ian
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, ...).
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