[ovs-dev] [RFC PATCH v1 0/3] RFC for Userspace IPsec Interface

Stokes, Ian ian.stokes at intel.com
Wed Jul 5 13:58:23 UTC 2017


> Hi Ian,
> Thank you for working on this!
> Good initiative and its definitely very useful.
> Few high level comments as below.
> Have added some more comments in the following patches as well.
> 
> 
> 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 0/3] RFC for Userspace IPsec
> > Interface
> >
> > Hi all,
> >
> > I'm starting to work on enabling IPsec for userspace in OVS.
> >
> > IPsec was previously implemented for OVS but was removed in OVS 2.6
> > due to a number of issues.
> >
> > This RFC patchset aims to outline the approach I'm considering for re-
> > introducing it to userspace and to gather feedback at the early stages
> > of development.
> >
> > The RFC patch for the actual implementation will be submitted at a later
> date.
> >
> > I'd like to discuss 2 areas in this cover letter which are not
> > directly covered in the accompanying RFC patches.
> >
> > (i) Usecase: Securing isolated tenant VM traffic.
> > (ii) Known Opens
> >
> >
> > (i) Usecase: Securing isolated tenant VM traffic.
> >
> > Users can isolate traffic between VMs in a data center by the use of
> > an appropriate tunneling protocol i.e. VXLAN.
> >
> > However although the traffic is isolated in terms of its source and
> > destination, it is not encrypted.
> >
> > A rogue entity with access to the network could listen and examine the
> > clear text payload of this traffic between VMs.
> >
> > The aim of this work is to introduce IPsec in userspace to secure the
> > traffic payloads.
> >
> > As such, the malicious entity could still see the traffic as it
> > traverses the network but the payload of the traffic will be secured
> > via encryption and authentication provided by IPsec.
> >
> > The steps involved in securing the vxlan payload would be done with
> > VXLAN over IPsec (transport Mode). This would look as follows
> >
> > 1.) Original header | Payload ! before VXLAN
> >
> > 2.) Outer header | UDP |VXLAN | Original header | Payload ! after
> > VXLAN
> >
> > 3.) Outer header | ESP | Encrypt ( UDP | VXLAN | Original header |
> Payload )
> >     ! after IPsec transport mode
> >
> > A more detailed description of the expected packet format is given
> below.
> >
> >    Outer Ethernet Header:
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |             Outer Destination MAC Address                     |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Outer Destination MAC Address | Outer Source MAC Address      |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                Outer Source MAC Address                       |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |OptnlEthtype = C-Tag 802.1Q    | Outer.VLAN Tag Information    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Ethertype = 0x0800            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    Outer IPv4 Header:
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |Version|  IHL  |Type of Service|          Total Length         |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |         Identification        |Flags|      Fragment Offset    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |  Time to Live | Protocol = 50 (ESP) |   Header Checksum       |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                       Outer Source IPv4 Address               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                   Outer Destination IPv4 Address              |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    ESP Header:
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                SPI (Security Parameter Index)                 |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                      Sequence Number                          |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    Outer UDP Header:
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |           Source Port         |       Dest Port = VXLAN Port  |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |           UDP Length          |        UDP Checksum           |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    VXLAN Header:
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |R|R|R|R|I|R|R|R|            Reserved                           |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                VXLAN Network Identifier (VNI) |   Reserved    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    Inner Ethernet Header:
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |             Inner Destination MAC Address                     |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Inner Destination MAC Address | Inner Source MAC Address      |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                Inner Source MAC Address                       |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |OptnlEthtype = C-Tag 802.1Q    | Inner.VLAN Tag Information    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    Payload:
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Ethertype of Original Payload |                               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
> >    |                                  Original Ethernet Payload    |
> >    |                                                               |
> >    |(Note that the original Ethernet Frame's FCS is not included)  |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     Padding (variable)                        |
> >    |                                         +-+-+-+-+-+-+-+-+-+-+-|
> >    |                                         | Pad Len | next = UDP|
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    ESP Authentication
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                  Authentication Data (optional)               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> > Encryption would be provided from the UDP Header to the Padding while
> > authentication would be provided from the ESP header to the padding.
> >
> > Not all aspects of IPsec are required to meet the requirements of this
> > usecase.
> >
> > 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.
> >
> > 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 an early description of the approach and is
> > subject to change following feedback from the community and ongoing
> > investigation during the RFC implementation.
> >
> > (ii) Known Opens
> >
> > As invetigation 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 raise at this stage for feedback from the community.
> >
> > (1) SA generation: With the proposed RFC, SA generation is completed
> > manually by the user. A better approach would be an implementation
> > such as IKEv2. One approach to this could be to use an existing 3rd
> > party component such as Strong Swan. Strong Swan has the ability to
> > operate is userspace via the kernel-libipsec plugin. The use of Strong
> > Swan would be for control plane operations only (such as SA generation
> > and key exchange). This could be a way to provide IKEv2 functionality
> > in OVS userspace but may require further modification to both OVS and
> > Strong Swan to allow this. This approach would require a dependency on
> > a 3rd party project. As such I would like to gauge the communities
> feelings towards this?
> >
> > (2) ESP Mode: This RFC proposes the use of IPsec in transport mode only.
> > However tunnel mode could be supported in the future. Do people feel
> > transport is enough initially?
> [Sugesh] I feel the transport mode is a good start.
> >
> > (3) Encap support: Initially vxlan is the usecase but this could be
> > expanded at a later date to work with all supported tunnel encapsulation
> types.
> [Sugesh] Are these ipsec can only used for tunnel interfaces?
> I feel the support would be any type of traffic. As a user should able to
> apply ipsec on any interface. I am not sure ipsec is defined as interface
> or flow item. May be its mentioned in the following patch sets and will
> have a look.

Ideally it will work with all traffic types in future, but for the initial use case I think vxlan tunnel type is a good litmus test when investigating the potential issues we'll hit.

> 
> >
> > (4) Crypto dev accelerators: Virtual crypto devices will be
> > implemented first however crypto accelerator hardware could be
> introduced at a later stage.
> >
> [Sugesh] Another open I can think of is about the MTU consideration.
> Since OVS-DPDK doesn't support reassembly, it is possible to consider the
> MTU before doing any encryption/decryption.

Is this the MTU Good point, the initial work can we consider keeping the MTU minimized until a solution for the re-assembly can be found.

> [Sugesh] : Connection tracking, How is that gonna work with crypto,
> Especially when we are doing the crypto operation in hardware in the
> future.
> 
Connection tracking is something I'll consider, I'm not the most experienced with it but I'll keep it in mind during initial investigation.
> 
> > I would appreciate any feedback people have regarding the proposed
> > approach for the initial RFC.
> >
> > Thanks
> > Ian
> >
> >
> > Ian Stokes (3):
> >   vswitch.xml: Detail ipsec user interface.
> >   Docs: Add userspace-ipsec how to guide.
> >   Docs: Update releases with IPsec feature support info.
> >
> >  Documentation/faq/releases.rst          |   51 +++++++
> >  Documentation/howto/userspace-ipsec.rst |  166
> > +++++++++++++++++++++++
> >  vswitchd/vswitch.xml                    |  222
> > +++++++++++++++++++++++++++++++
> >  3 files changed, 439 insertions(+), 0 deletions(-)  create mode
> > 100644 Documentation/howto/userspace-ipsec.rst
> >
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev


More information about the dev mailing list