[ovs-dev] [RFC PATCH v1 0/3] RFC for Userspace IPsec Interface
Chandran, Sugesh
sugesh.chandran at intel.com
Fri May 26 10:21:54 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.
>
> (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.
[Sugesh] : Connection tracking, How is that gonna work with crypto,
Especially when we are doing the crypto operation in hardware in the future.
> 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