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.
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: [email protected] [mailto:ovs-dev-
[email protected]] On Behalf Of Ian Stokes
Sent: Friday, August 25, 2017 5:40 PM
To: [email protected]
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
[email protected]
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
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
