[ovs-dev] [PATCH 0/3] IPsec support for tunneling

Ian Stokes ian.stokes at intel.com
Tue Jul 10 20:11:03 UTC 2018

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.


More information about the dev mailing list