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?
(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.
(4) Crypto dev accelerators: Virtual crypto devices will be implemented first
however crypto accelerator hardware could be introduced at a later stage.
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
