> 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: [email protected] [mailto:ovs-dev- > > [email protected]] On Behalf Of Ian Stokes > > Sent: Thursday, May 18, 2017 10:16 AM > > To: [email protected] > > 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 > > [email protected] > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
