[ovs-dev] [RFC PATCH v1 2/3] Docs: Add userspace-ipsec how to guide.
Chandran, Sugesh
sugesh.chandran at intel.com
Fri May 26 10:49:09 UTC 2017
I have given some comments for previous patch that has been addressed in this.
So please ignore them accordingly.
Regards
_Sugesh
> -----Original Message-----
> From: ovs-dev-bounces at openvswitch.org [mailto:ovs-dev-
> bounces at openvswitch.org] On Behalf Of Ian Stokes
> Sent: Thursday, May 18, 2017 10:16 AM
> To: dev at openvswitch.org
> Subject: [ovs-dev] [RFC PATCH v1 2/3] Docs: Add userspace-ipsec how to
> guide.
>
> This commit adds a how to guide for using the proposed IPsec userspace
> interface. It is not intended to be upstreamed but simply seeks to solicit feed
> back by providing an example of the proposed IPsec interface design setup
> and usage.
>
> The how to usecase deals with securing vxlan traffic between 2 VMs as
> described in the userspace-vxlan how to guide. It provides an example of
> how the proposed ipsec interface is configured with an SPD, creation of SAs
> including IPsec protocol, mode, crypto/authentication algorithms/keys,
> assigning SPD entires to SAs for inbound/outbound traffic with traffic
> selectors and finally updating the SA keys.
>
> Signed-off-by: Ian Stokes <ian.stokes at intel.com>
> ---
> Documentation/howto/userspace-ipsec.rst | 166
> +++++++++++++++++++++++++++++++
> 1 files changed, 166 insertions(+), 0 deletions(-) create mode 100644
> Documentation/howto/userspace-ipsec.rst
>
> diff --git a/Documentation/howto/userspace-ipsec.rst
> b/Documentation/howto/userspace-ipsec.rst
> new file mode 100644
> index 0000000..ae75516
> --- /dev/null
> +++ b/Documentation/howto/userspace-ipsec.rst
> @@ -0,0 +1,166 @@
> +..
> + Licensed under the Apache License, Version 2.0 (the "License"); you may
> + not use this file except in compliance with the License. You may obtain
> + a copy of the License at
> +
> + http://www.apache.org/licenses/LICENSE-2.0
> +
> + Unless required by applicable law or agreed to in writing, software
> + distributed under the License is distributed on an "AS IS" BASIS,
> WITHOUT
> + WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> See the
> + License for the specific language governing permissions and limitations
> + under the License.
> +
> + Convention for heading levels in Open vSwitch documentation:
> +
> + ======= Heading 0 (reserved for the title in a document)
> + ------- Heading 1
> + ~~~~~~~ Heading 2
> + +++++++ Heading 3
> + ''''''' Heading 4
> +
> + Avoid deeper levels because they do not render well.
> +
> +=========================================================
> =
> +Securing VXLAN traffic between VMs Using IPsec (Userspace)
> +=========================================================
> =
> +
> +This document describes how to use IPsec in Open vSwitch to secure
> +traffic between VMs on two different hosts communicating over VXLAN
> +tunnels. This solution works entirely in userspace.
> +
> +.. note::
> +
> + This guide covers the steps required to configure an IPsec interface to
> + secure VXLAN tunneling traffic. It does not cover the steps to configure
> + the vxlan tunnels in userspace. For these configuration steps please refer
> + to :doc:`userspace-tunneling`.
> +
> +.. TODO(stephenfin): Convert this to a (prettier) PNG with same styling as
> the
> + rest of the document
> +
> +::
> +
> + +--------------+ +--------------+
> + | vm0 | 192.168.1.1/24 192.168.1.2/24 | vm1 |
> + +--------------+ +--------------+
> + (vm_port0) (vm_port1)
> + | |
> + | |
> + | |
> + +--------------+ +--------------+
> + | br-int | | br-int |
> + +--------------+ +--------------+
> + | vxlan0 | 172.168.1.1/24 172.168.1.2/24 | vxlan0 |
> + +--------------+ +--------------+
> + | ipsec0 | | ipsec0 |
> + +--------------+ +--------------+
> + | |
> + | |
> + | |
> + +--------------+ +--------------+
> + | br-phy | | br-phy |
> + +--------------+ +--------------+
> + | dpdk0/eth1 |----------------------------------| dpdk0/eth1 |
> + +--------------+ +--------------+
> + Host 1 with OVS. Host 2 with OVS.
[Sugesh] Please ignore the previous comment about the setup diagram
Now the question on this is, after the vxlan tunneling how does datatpath know
Whether it has to be encrypted or not.
Lets say, if we wanted to encrypt only some VNIs(specific for some tenants)
How do we do that.
As you might know there is no specific link/port between vxlan port and br-phy.
OVS learns that to forward the packets.
Now there are two traffic path.
Vm-port0 --> vxlan0 -->br-phy -->dpdk0
Or
Vm-port0 -->vxlan0 -->ipsec0 -->br-phy -->dpdk0
Can you please explain how does these two cases work.
> +
> +Setup
> +-----
> +
> +This guide assumes the environment is configured as described below.
> +
> +Two Physical Hosts
> +~~~~~~~~~~~~~~~~~~
> +
> +The environment assumes the use of two hosts, named `host1` and
> +`host2`. We only detail the configuration of `host1` but a similar
> +configuration can be used for `host2`. Both hosts should be configured
> +with Open vSwitch with DPDK datapath, QEMU/KVM and suitable VM
> images.
> +Open vSwitch should be running before proceeding.
> +
> +Configuration Steps
> +-------------------
> +
> +Follow the configuration steps outlined in :doc:`userspace-tunneling`
> +to setup VXLAN tunneling between vm0 and vm1 using the DPDK datapath.
> +Complete the following steps to configure an IPsec interface for
> +securing VXLAN traffic between the VMs.
> +
> +Perform the following configuration on `host1`:
> +
> +#. On `host1`, add a port with an IPsec interface to bridge `br-int`::
> +
[Sugesh] Please ignore previous command about the configuration.
> + $ ovs-vsctl add-port br-int ipsec0 -- set Interface ipsec0
> + type=ipsec
> +
> +#. Create a SPD with ID `1` for `ipsec0`::
> +
> + $ ovs-vsctl set Interface ipsec0 options:spd_id=1
> +
> +#. Create two SAs with ID `10` and `20` for `ipsec0` with required SA info::
> +
> + $ ovs-vsctl set Interface ipsec0 options:sa_id=10 \
> + options:sa_spi=7A390BC1 \
> + options:sa_protocol=esp \
> + options:ipsec_mode=transport \
> + options:crypto_alg=aes_cbc \
> + options:crypto_key=4a506a794f574265564551694d653768 \
> + options:auth_alg=hmac_sha2_256_128 \
> + options:auth_key=4339314b55523947594d6d3547666b45764e6a58 \
[Sugesh] Is it possible to have these as a flow option? Can we have it in openflow with extension?
Have you looked at those possibilities?
Another point is, Does these keys stored as plain text in OVSDB?
Does it show as plain text when I run ovs-vsctl show?(Especially the keys)
I am not sure if its ok to show as plain text? I am OK to start with plain text now though.
> +
> + $ ovs-vsctl set Interface ipsec0 options:sa_id=20 \
> + options:sa_spi=7A390BC1 \
> + options:sa_protocol=esp \
> + options:ipsec_mode=transport \
> + options:crypto_alg=aes_cbc \
> + options:crypto_key=4a506a794f574265564551694d653768 \
> + options:auth_alg=hmac_sha2_256_128 \
> + options:auth_key=4339314b55523947594d6d3547666b45764e6a58 \
> +
> +#. Create a policy for inbound IPsec traffic with desired IP address info::
> +
> + $ ovs-vsctl set Interface ipsec0 options:policy_priority=20 \
> + options:policy_tdir=inbound \
> + options:policy_action=protect \
> + options:policy_sa=10 \
> + options:ts_local_ip_range=172.168.1.1 - 178.168.1.1 \
> + options:ts_remote_ip_range=172.168.1.2 - 172.168.1.2 \
> + options:ts_protocol=50
> +
> +#. Create a policy for outbound VXLAN traffic with desired IP address info::
> +
> + $ ovs-vsctl set Interface ipsec0 options:policy_priority=20 \
> + options:policy_tdir=outbound \
> + options:policy_action=protect \
> + options:policy_sa=20 \
> + options:ts_local_ip_range=172.168.1.1 - 178.168.1.1 \
> + options:ts_remote_ip_range=172.168.1.2 - 172.168.1.2 \
> + options:ts_remote_port_range=4789 - 4789 \
> + options:ts_protocol=17 \
> +
> + .. note::
> +
> + This assumes the user is using the IANA port `4789` for VXLAN traffic.
[Sugesh] May be another approach would be,
Separate the security association and create it using a different command.
Like
Ovs-vsctl add-ipsec-SA <name> <SA details>
After wards add that SA to different interfaces such as
$ ovs-vsctl set Interface ipsec0 options:security_policy=name
This way you may reuse the same SA over multiple port definitions.
> +
> +Repeat these steps for `host2`, but using ``172.168.1.1`` and
> +``172.168.1.2`` for the remote and local IP ranges, respectively.
> +
> +Testing
> +-------
> +
> +With this setup, ping to VXLAN target device (``192.168.1.2``) should work.
> +Outbound traffic will be VXLAN encapsulated, encrypted/authenticated
> +with the specified algorithms defined in SA `20` and sent over ``dpdk0``
> interface.
> +
> +Inbound traffic will be decrypted/authenticated with the specified
> +algorithms defined in SA `10`.
> +
> +Configuration Updates
> +---------------------
> +
> +#. The keys for SA `10` can be updated with the following command::
> +
> +
> + $ ovs-vsctl set Interface ipsec0 options:sa_id=10 \
> + options:crypto_key=4a506a794f574265564551694d653768 \
> + options:auth_key=4339314b55523947594d6d3547666b45764e6a58 \
> --
> 1.7.0.7
>
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
More information about the dev
mailing list