[ovs-dev] [RFC PATCH v1 2/3] Docs: Add userspace-ipsec how to guide.
Stokes, Ian
ian.stokes at intel.com
Wed Jul 5 14:30:13 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.
So the idea here is that a traffic selector would work on the vxlan IP source and destination to select traffic that needs to be encrypted.
The traffic selector fields currently don't include VNI field from what I can recall for the latest IPsec RFC, instead works on IP ranges, port ranges etc.
I understand the point you are making with regards to whether a packet should be encrypted or not based on VNI but as a starting point I was aiming to keep it simpler and encrypt based on source/dest mac address as well as port range if that makes sense?
A possibility here also could be to combine the vxlan and ipsec operations, i.e. a vxlan-ipsec port where a SA is associated with the vxlan port for any traffic being transmitted or received. Again this work is investigative with the aim of understanding what is currently achievable vs what needs to be implemented.
>
>
>
> > +
> > +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?
I haven't thought of this, can you give an example of how something like this would work?
> 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.
This is a good point, initially it may be visible as a starting point, I'm thinking is there a need to limit visibility of the OVSDB to root or select secure group?
>
>
> > +
> > + $ 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.
An initial approach I had towards this veered this way, this was feedback I was looking for.
We can go down this route sure, but one consideration I had is that we are then implementing a new concept for the ovs schema, no?
Similar to how a QoS policy can be defined and applied to different ports. Previously I've seen feedback on the ML that it's preferred to avoid modifying the schema if possible so I kept the SA as options for the interface but I see your point. Would be interesting to see how others feel on this.
> > +
> > +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