On 18 May 2017 at 02:15, Ian Stokes <[email protected]> wrote: > 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 <[email protected]> > --- > 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. > + > +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`:: > + > + $ 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 \ Ok, I see that you have keys in hex here opposed to alphanumeric.
> + > + $ 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 \ I am confused about direction. Because for IPsec to operate properly it needs an inbound key and and outbound at the same time. However, based on these commands I am inclined to think that users are limited to either only inbound crypto or only outbound crypto, but not both at the same time. Did I misunderstand something in you User Interface? > + 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 \ I would think that IP and Port ranges should be rather defined with masks opposed to arbitrary ranges. At least that is how ip-xfrm works. See ADDR[/PLEN] in man ip-xfrm. > + options:ts_protocol=50 Why the selector protocol here is 50? is this for IPsec over IPsec use case? > + > +#. 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. > + > +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 > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
