[ovs-dev] [RFC PATCH v2 00/10] RFC for Userspace IPsec Interface

[Stokes, Ian]

> On 09/01/17 17:19, Chandran, Sugesh wrote:
> > Hi Ian,
> >
> > Thank you for working on this.
> > This feature is going to be very useful in OVS-DPDK deployment.
> > I also did some basic testing of this implementation.
> > Here are the comments,
> 
> 
> I'm curious, is this using MACsec?  Can MACsec be used?
> 
> The following slide deck indicates that MACsec (already in the Linux
> kernel), could be used with VXLAN.  (I am not sure about cross platform
> support though).
> 
> http://www.netdevconf.org/1.1/proceedings/slides/dubroca-macsec-
> encryption-wire-lan.pdf
> 
> Other links I had encountered a while back about MACsec (considering that
> VXLAN is L2 carriage):
> 
> https://developers.redhat.com/blog/2016/10/14/macsec-a-different-solution-
> to-encrypt-network-traffic/
> 
> http://costiser.ro/2016/08/01/macsec-implementation-on-linux/
> 
> MACsec might get you to a solution faster, if appropriate.
> 

Thanks Raymond for the feedback, this isn’t using macsec currently, it's using ipsec in transport mode to secure from UCDP, VXLAN and original payload.

The thinking behind this was that IPsec had to work at the IP level so combining it in transport mode with a tunnel guarantees that.

I hadn't looked at macsec myself previously.

I had went with IPsec as it had been introduced previously to OVS (but later removed).

For this case Macsec may also be used but I'd like to dig a little deeper on some of the info you've passed on before making a decision.

Is there particular advantage you see with it over ipsec? Would be interested in discussing it further as I'm working on the v3 RFC for the IPsec patch at the moment.

Thanks
Ian
> 
> >
> > 	1) The dpctl show still shows the port as vxlan. It must be changed
> to vxlan-ipsec
> > 	2) Its mentioned in the cover letter, however I see the flows stats
> are looks ok. Only the port stats are need to be properly handled.
> > 	3) The dpctl/dump-flows says the actions as vxlan. It should be
> vxlan-ipsec .
> > 	4) I think the ovs-vsctl show should be extended to show the SPI
> information.(Even its static for now)
> > 	5) Similarly the ipsec port should provided with security association
> it is using. This should be in the options.
> > 	6) I tried to do run a following test on the ipsec tunnel
> implementation and it looks like there is some issue with rule translation
> as I don’t see the 	  	 packets are forwarding.
> > 	PKT-IN -->BR1--(ENCAP)-->BR2 -->(MOD-PKT 'patch port')---->BR3--
> >(DECAP) -->BR4.
> > 	I see the encap is happening and but nothing afterwards. It works
> fine on normal VxLAN.
> >
> >
> >
> >
> > Regards
> > _Sugesh
> >
> >
> >> -----Original Message-----
> >> From: ovs-dev-bounces at openvswitch.org [mailto:ovs-dev-
> >> bounces at openvswitch.org] On Behalf Of Ian Stokes
> >> Sent: Friday, August 25, 2017 5:40 PM
> >> To: dev at openvswitch.org
> >> Subject: [ovs-dev] [RFC PATCH v2 00/10] RFC for Userspace IPsec
> >> Interface
> >>
> >>
> > [snip]
> >
> >>
> >> The flow structer has been modified to allow the storing of the ESP
> >> SPI value
> > [Sugesh] structure?
> >> of a packet. The Minflow extract process has been modified accordingly.
> >>
> >> Base IPsec functionality has been detailed in 'Docs: Update releases
> >> with IPsec feature support info.'
> >>
> >> A proposed design of a new IPsec interface is included with its
> >> options in the
> >> 'vswitch.xml: Detail ipsec user interface' RFC. Note this is the
> >> final target the patch series should resemble as development continues.
> >>
> >> A `how-to` guide has been added to provide some context of how the
> >> IPsec interface would be configured by a user in the 'Docs: Add
> >> userspace-ipsec how to guide.'
> >>
> >> Please note this is a early approach and is not intended for
> >> upstreaming, instead it is to provide an insight into some of the
> >> requirements the work will have. It is subject to change following
> >> feedback from the community and ongoing investigation during future RFC
> implementations.
> >>
> >>
> >> (ii) Known Issues
> >>
> >> As investigation progresses I'm sure there will be more opens to be
> >> added to the list below, but from the outset there are a few issues
> >> I'd like to flag at this stage as the patch the feature is still in
> development.
> >>
> >> (1) Cipher/Authentication Algorithms: The current RFC is limited in
> >> that the algorithm used for cipher/authentication are hard coded to
> >> 128 AES-CBC and
> >> HMAC-SHA1-96 respectively. Keys are also hardcoded. I will add the
> >> ability to read keys from a user in the next revision along with
> >> selection of algorithms for the operations. The current series should
> >> provide a feel for how crypto operations work with DPDK.
> >>
> >> (2) Crypto device: Currently only software crypto devices are
> >> supported, specifically the AESN-NI vdev PMD in DPDK.
> >>
> >> (3) Single PMD support within OVS: The current RFC is limited to
> >> running on a single PMD.
> >> Running it with more than 1 PMD will (probably) cause a segfault.
> >> Multiple pmd support will be added in the next revision after some
> >> discussion on how cryptodevs should be accessed on a multi core system.
> >>
> >> (4) Use of DPDK crypto devs requires installing the Intel(R)
> >> Multi-Buffer Crypto for IPSec library. This is an opensource library
> >> available on github and is used by DPDK to perform crypto operations
> >> when with a vdev such as the AESN-NI PMD. Setup instructions have been
> included in the patch series.
> >>
> >> (5) Stats: I haven’t looked into how this will affect stats within
> >> OVS yet but
> > [Sugesh] There are some special characters.
> >> this is another item I will look at for the next revision in the
> series.
> >>
> >> (6) OVS mode: The series has been tested with OVS with DPDK only. A
> >> few rte libraries have been introduced to areas where DPDK previously
> >> was not active, for instance the tunneling code. I'm aware that this
> >> will break compilation if a user compiles OVS without DPDK. How the
> >> libraries should be introduced to prevent this is an item I would be
> >> interested in receiving feedback on as I will be working on this for
> the next revision.
> > [Sugesh] I think this shouldn’t be a problem as you are not using any of
> existing tunnel interface.
> > May be its worth to considering enabling ipsec only when DPDK support is
> available in OVS.
> > Also the changes are on only on native tunnel, this shouldn’t break non
> DPDK build.
> >
> > [snip]
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >
> 
> --
> Raymond Burkholder
> https://blog.raymond.burkholder.net/
> 
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
> 
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev