[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